Migration WordPress sans coupure: DNS, base de données et fichiers pas à pas

Tu veux réussir une migration WordPress sans interruption de service, même en pleine journée, sans stress ni perte de données ? Ce guide complet te montre comment planifier et exécuter une migration WordPress zéro coupure de manière sûre et reproductible. Dans les 200 premières lignes de ce plan, tu vas croiser les fondamentaux: réduction du DNS TTL pour accélérer la bascule, synchronisation incrémentale des fichiers avec rsync, export/import de la base puis search-replace via WP-CLI, tests en staging, bascule contrôlée et rollback prêt à l’emploi. L’objectif: pas de 404, pas de 500, pas de panier perdu, pas d’utilisateur déconnecté. C’est précisément ce que nous mettons en place au quotidien chez WP Builders pour des sites vitrine, médias à fort trafic et boutiques WooCommerce.

Pourquoi c’est si critique ? Une coupure de 10 minutes sur un site e‑commerce peut effacer une journée de marge. Un formulaire qui ne part plus après migration, et ce sont des leads envolés. Une configuration PHP trop juste, et la bascule casse en prod. Ce guide t’aide à éviter ces pièges avec une méthode « prête à déployer ». Si tu manques de temps ou si la fenêtre de maintenance est inexistante, notre équipe peut intervenir rapidement, documenter chaque étape et garantir un filet de sécurité. Avançons, étape par étape, jusqu’à la bascule finale sans douleur.

Plan de vol: architecture de migration WordPress zéro coupure

Avant d’écrire la moindre commande, nous clarifions l’architecture de départ et d’arrivée: hébergeur source, hébergeur cible, versions de PHP/MySQL, serveur web (Nginx/Apache), certificats SSL/ACME, CDN éventuel, cache objet, workers, CRON. L’idée est de réduire l’écart entre l’environnement actuel et le futur: même timezone, même limite memory_limit, même upload_max_filesize, et une version PHP au moins aussi récente sur la cible. On prévoit aussi l’alignement du wp-config.php (salts, clés, préfixe de tables si nécessaire) et des services externes (SMTP, S3, passerelles de paiement).

On définit surtout la stratégie de synchronisation: 1) première copie massive des fichiers (médias, thèmes, plugins, core) avec rsync, 2) export de la base depuis la source, import sur la cible, 3) search-replace propre pour remplacer l’URL et tout contenu sérialisé, 4) tests en staging, 5) synchronisation différentielle juste avant la bascule, 6) mise à jour des DNS avec un DNS TTL court, 7) surveillance et rollback prêt si un détail échappe aux tests.

Préparer le terrain: inventaire, accès et réduction du DNS TTL

Checklist d’accès

• Accès SSH source et cible (clé SSH, IP autorisées).
• Accès à la console DB (mysql/mariadb) et/ou phpMyAdmin.
• Accès au DNS (registrar ou DNS provider) pour modifier le TTL et les enregistrements.
• Accès CDN/WAF si présent (purge, modes de contournement).

Réduire le TTL bien avant la bascule

Réduis le DNS TTL à 300 secondes (ou 120 si ton fournisseur l’autorise) au moins 24 à 48 heures à l’avance. Ainsi, quand tu mettras à jour l’enregistrement A/AAAA/CNAME, la propagation effective sera quasi instantanée. Si tu veux creuser, consulte la documentation DNS TTL pour comprendre l’impact côté résolveurs.

Options de bascule sans DNS

Quand le DNS n’est pas sous ton contrôle, tu peux déployer une stratégie Blue-Green via un reverse proxy ou un load balancer. Autre option simple pour tester: modifier temporairement ton fichier hosts sur ta machine, afin de pointer le domaine vers l’IP cible sans affecter le public.

Mettre en place l’environnement cible et un staging propre

Sur la cible, configure PHP (version récente, extensions: curl, mbstring, intl, gd/imagemagick, zip), active l’OPcache, ajuste max_execution_time à 120–300s si nécessaire pour l’import initial. Crée la base de données et un utilisateur dédié avec droits suffisants. Préconfigure Nginx/Apache avec un vhost en staging (par ex. staging.domaine.com) protégé par HTTP auth pour éviter l’indexation. Installe un certificat Let’s Encrypt sur staging si tu dois tester du contenu mixte.

Nous conseillons de garder les clés/« salts » identiques à la source pour éviter des reconnexions intempestives d’utilisateurs au moment de la bascule. Ajuste wp-config.php sur la cible (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, DISABLE_WP_CRON en true pendant la migration), et prépare un cache objet (Redis) si le site en bénéficiait déjà sur la source.

Première synchronisation des fichiers avec rsync

On commence par une copie « bulk » qui n’impacte pas la prod. rsync permet une reprise incrémentale ultra rapide pour la suite.

rsync -avz --progress \  --exclude='wp-config.php' \  --exclude='cache/' --exclude='*.log' \  user@source:/var/www/html/ /var/www/html/

Pourquoi exclure wp-config.php ? Parce que tu l’as déjà préparé côté cible avec les bons identifiants. Évite aussi de synchroniser des caches lourds et inutiles. Sur les gros médias, l’option --partial peut sauver du temps si la connexion coupe.

Exporter la base depuis la source et l’importer sur la cible

Tu peux passer par mysqldump ou par WP-CLI. Ce dernier est souvent plus simple pour rester dans l’écosystème WordPress. Référence utile: la doc officielle WP-CLI.

# Sur la source (depuis la racine WP)wp db export /tmp/source.sql --add-drop-table# Transfert du dump vers la ciblersync -avz /tmp/source.sql user@cible:/tmp/source.sql# Sur la ciblewp db import /tmp/source.sql

Pour les bases volumineuses, ajoute --single-transaction côté mysqldump pour éviter les verrous. Vérifie également la collation et le charset (utf8mb4 recommandé) pour garantir l’intégrité des emojis et caractères spéciaux.

Search-replace fiable et sérialisations préservées

Une migration implique presque toujours un changement d’URL (ne serait-ce que le staging). WP-CLI search-replace sait gérer les données sérialisées, ce qui évite de casser des widgets, des options ou des champs ACF.

# Exemple: staging → prod à venirwp search-replace 'https://www.domaine.com' 'https://staging.domaine.com' \  --all-tables --precise --all-tables-with-prefix --report-changed-only

Sur le dernier aller-retour avant la bascule, tu referas l’opération inverse pour repasser du staging vers le domaine final. Utilise --dry-run sur un premier passage pour contrôler l’impact. En parallèle, vérifie les constantes qui peuvent traîner dans wp-config.php (adresses d’API, CDN, S3, etc.).

Tests en staging: performance, SEO, e‑commerce et paiements

Le staging n’est pas une aimable formalité. Il doit reproduire l’expérience réelle: URLs, HTTPS, cache, minification, WebP/AVIF, CRON, envois d’emails. Teste:

• Page d’accueil, pages clés SEO, recherche interne, pagination.
• Formulaires (contact, newsletter), envois et réception réels (boîte de test).
• Sur WooCommerce: navigation catalogue, ajout au panier, panier persistant, passage de commande en mode test/sandbox, réception d’emails transactionnels.
• Compte client, réinitialisation de mot de passe, rôles et capacités.
• Back‑office: mises à jour, éditeur de blocs, média uploads, génération de vignettes.

Pense aussi à la conformité: sitemaps (index et children), robots.txt, canonical tags, hreflang si multilingue. Profite-en pour corriger des 404 historiques avec des redirections, et vérifier que la compression (gzip/brotli) et HTTP/2/3 sont actifs.

Synchronisation différentielle juste avant la bascule

Le point clé d’une migration sans coupure est de limiter le delta entre la source et la cible au moment du cutover. Voici la séquence type:

1. Ralentir les écritures côté source (courte fenêtre): désactive les CRON lourds, gèle temporairement le back‑office si besoin, ou passe certaines zones en lecture seule. Sur WooCommerce, privilégie une fenêtre creuse et évite les opérations de masse (import produits) pendant la dernière heure.
2. rsync incrémental des médias (uploads) puis des thèmes/plugins: --delete pour supprimer ce qui n’existe plus sur la cible, --bwlimit si tu dois limiter la bande passante.

rsync -avz --delete \  --exclude='cache/' --exclude='*.log' \  user@source:/var/www/html/wp-content/uploads/ /var/www/html/wp-content/uploads/rsync -avz --delete user@source:/var/www/html/wp-content/plugins/ /var/www/html/wp-content/plugins/rsync -avz --delete user@source:/var/www/html/wp-content/themes/ /var/www/html/wp-content/themes/

3. Export différentiel DB: si les écritures utilisateurs sont importantes, fais un nouvel export rapide (les tables auront surtout évolué sur les commandes, commentaires, usermeta, etc.).
4. Import DB sur la cible et search-replace final vers le domaine de production.

# Dernier exportwp db export /tmp/final.sql --add-drop-tablersync -avz /tmp/final.sql user@cible:/tmp/final.sql# Côté ciblewp db import /tmp/final.sqlwp search-replace 'https://staging.domaine.com' 'https://www.domaine.com' \  --all-tables --precise --all-tables-with-prefix --report-changed-only

Sur les très gros sites, on peut scinder par tables (ex. ignorer les logs ou transients), ou utiliser une réplication temporaire de la DB. L’essentiel: réduire le « gap » de données au minimum.

Bascule contrôlée via DNS: propagation rapide et vérifications

Avec un DNS TTL déjà bas, tu peux mettre à jour l’enregistrement A/AAAA/CNAME vers l’IP cible. Garde la console de logs ouverte (Nginx/Apache, PHP‑FPM, erreurs applicatives) et surveille en temps réel. Purge le CDN si présent, et invalide les caches de page/objet pour forcer un rafraîchissement rapide.

Vérifie immédiatement:

• Réponse HTTP 200 sur la page d’accueil et quelques pages profondes.
• Authentification WP-Admin et actions critiques (création d’article, upload d’image).
• Transactions WooCommerce en sandbox si la plateforme le permet, ou au moins simulation de panier/checkout.
• Les webhooks et callbacks (paiements, CRM, ERP) reçoivent bien les requêtes (regarde les logs).

Astuce: conserve le staging opérationnel pendant 24–48h. En cas d’imprévu, tu auras une copie isochrone très proche de la prod.

Rollbacks intelligents: prépare la marche arrière avant la marche avant

Une migration sereine a toujours un rollback documenté. Prévoyez:

• Snapshots côté cible (disque/VM + dump DB) juste avant le cutover.
• Un export DB final de la source conservé en lieu sûr.
• Le plan pour rebasculer le DNS vers la source si une anomalie critique apparaît dans l’heure.

Si tu dois revenir en arrière, communique clairement en interne: fenêtre de rollback, impact attendu, consignes pour mettre pause sur les campagnes marketing pendant la manœuvre. Chez WP Builders, on garde toujours un chemin de repli testable en local (via hosts) pour valider les hypothèses sans affecter les visiteurs.

Cas particulier: WooCommerce, membres et sites à fort trafic

Les sites transactionnels exigent une discipline supplémentaire. Deux approches complémentaires:

Fenêtre faible trafic + delta minimal

Caler la bascule à une heure creuse réduit fortement le risque de perdre des commandes entre l’export final DB et la mise à jour DNS. L’intervalle doit être inférieur au TTL effectif. Un export DB + import + search-replace, puis le cutover dans la foulée.

Lecture seule temporaire

Sur les forums ou sites membres, passe certaines fonctions en lecture seule quelques minutes: suspension des nouveaux commentaires, geler la création de comptes. Sur WooCommerce, c’est plus délicat (checkout actif). On peut, le temps de la bascule, informer les utilisateurs que « les paiements reprennent dans 2 minutes ». Cette approche reste compatible avec une promesse « zéro coupure » de navigation publique.

Logs et cohérence

Collecte et analyse les logs (Nginx/Apache, PHP, WooCommerce) pour repérer les erreurs 4xx/5xx, les timeouts, les appels API en échec. Mets en place une alerte (Slack/Email) sur le taux d’erreur et le temps de réponse. Un monitoring pro (uptime + real user monitoring) te donne un filet de sécurité dès la première minute après cutover.

Sécurité, performance et finitions post‑bascule

• Réactive le wp-cron.php (ou garde un cron système) et vérifie les tâches planifiées critiques (sitemaps, envois, synchronisations).
• Réinstalle ou réactive les extensions de sécurité, règle le firewall applicatif.
• Régénère les permaliens si nécessaire, purge tous les caches (page, objet, CDN), reconstruit les assets minifiés.
• Vérifie la génération d’images responsives (WebP/AVIF) et les headers cache.
• Soumets le nouveau sitemap à la Search Console, contrôle l’indexation.

Profite de la migration pour mettre à jour le cœur, les thèmes et plugins si le staging a validé la compatibilité. Un socle technique propre t’évitera des régressions à la prochaine montée de version PHP.

Commandes utiles: rsync, WP‑CLI et MySQL

# rsync avec limitation de bande passantersync -avz --bwlimit=4096 user@source:/var/www/html/ /var/www/html/# Export MySQL transactionnel (hors WP-CLI)mysqldump --single-transaction -u user -p dbname > /tmp/source.sql# WP-CLI: vérifier la santé du sitewp core verify-checksumswp plugin statuswp theme status# Search-replace en dry-run pour contrôlerwp search-replace 'http://old' 'https://new' --dry-run --all-tables

Pièges fréquents et parades express

• Médias manquants: tu as oublié un répertoire personnalisé (ex. wp-content/uploads/custom/). Solution: refais un rsync ciblé et pense à --delete.
• URLs mixtes HTTP/HTTPS: contenu mixte post‑bascule. Solution: search-replace supplémentaire et headers HSTS.
• Sessions et connexions: utilisateurs déconnectés. Solution: conserver les mêmes clés/salts et vérifier la persistance de session (WooCommerce).
• CRON désynchronisé: tâches doublées. Solution: désactiver WP-Cron pendant la migration, puis basculer sur un cron système unique.
• Cache agressif: CDN ou plugin qui sert l’ancienne version. Solution: purge intégrale et réchauffe des pages clés.

Blue-Green et alternatives si le DNS est sensible

Quand la mise à jour DNS est complexe (comités, DSI, multiples zones), une bascule Blue-Green via un proxy est idéale: le trafic public bascule par changement de backend instantané. Autre possibilité: affecter un CNAME contrôlé (ex. app.domaine.com) pointant vers la cible, puis rediriger proprement. Ces modèles s’intègrent parfaitement dans une approche zéro coupure.

Documentation, traçabilité et transfert de connaissances

Documente tout: versions, commandes, horodatages, décisions, anomalies, solutions. Une bonne fiche de runbook te servira pour les prochaines migrations et facilitera un handover propre à ton équipe ou à un prestataire. Chez WP Builders, on remet systématiquement un rapport de migration avec la timeline, les points de contrôle et les optimisations proposées.

Checklist récapitulative: ta to‑do list prête à l’emploi

• J‑2: abaisser le DNS TTL à 300s, vérifier accès SSH/DB/DNS.
• J‑1: préparer la cible (PHP, DB, vhost, HTTPS), staging protégé.
• J‑1: premier rsync complet des fichiers, export DB, import sur cible.
• J‑1: search-replace vers staging, tests fonctionnels et perf.
• H‑1: rsync différentiel, export DB final, import et search-replace prod.
• H: mise à jour DNS, purge CDN, vérifs clés, monitoring serré.
• H+1: réactiver cron, réchauffer cache, publier le nouveau sitemap.
• J+1: revue des logs, corrections mineures, levée du TTL (remonte à 1h).

Pourquoi confier la manœuvre à WP Builders

Tu peux suivre ce guide et réussir ta migration WordPress sans coupure. Si tu veux aller plus vite, sécuriser chaque étape et bénéficier d’un rollback testé, notre équipe t’accompagne: préparation, exécution, monitoring et amélioration continue. On intervient souvent en moins de 2 heures sur les projets urgents, avec des process éprouvés et des outils maison pour fiabiliser rsync, WP‑CLI et les bascules DNS.

Aller plus loin: tests de charge et optimisations pro

Une migration est l’occasion de renforcer la performance: tester les temps TTFB, les goulots d’étranglement PHP/MySQL, activer un object cache (Redis), optimiser les règles de cache et le warm‑up. Programme un test de charge léger après bascule pour valider le dimensionnement de la cible. Si tu utilises un CDN/WAF, vérifie le comportement des pages privées (no‑cache) et des endpoints (REST, AJAX).

Conclusion

Une migration WordPress sans coupure repose sur une mécanique simple mais rigoureuse: TTL bas, rsync incrémental, export/import DB propre, search-replace maîtrisé via WP‑CLI, tests en staging, cutover rapide, monitoring et rollback prêt. En appliquant cette méthode, tu réduis drastiquement le risque technique et l’impact business. Et si tu préfères dormir tranquille, WP Builders s’occupe de tout, de la planification à la surveillance post‑prod.