L'essentiel à retenir : une migration WordPress cause une interruption quand les étapes se produisent dans le mauvais ordre — le DNS est basculé avant que le nouveau site ne soit vérifié, ou le contenu change sur l'ancien site après que la base de données a déjà été exportée. Faire le travail en parallèle sur le nouvel environnement, le tester entièrement avant la bascule, et abaisser le TTL DNS à l'avance, voilà ce qui rend le changement invisible aux visiteurs.
Pourquoi les migrations causent habituellement des interruptions
La façon par défaut, non planifiée, de déplacer un site WordPress — exporter la base de données, copier les fichiers, pointer le DNS vers le nouveau serveur, puis commencer à réparer ce qui est cassé — crée une fenêtre où le site est soit complètement hors ligne, soit sert une version à moitié migrée et cassée. Chaque étape de cette séquence se produit directement sur le site en ligne lui-même, donc toute erreur est immédiatement visible pour les visiteurs.
La migration sans interruption résout cela en inversant l'ordre : construire et vérifier entièrement le nouvel environnement pendant que l'ancien continue de servir le trafic sans y toucher, et ne basculer qu'une fois que tout est confirmé fonctionnel. Le site en ligne ne se trouve jamais dans un état intermédiaire cassé, car le travail de migration ne se produit jamais directement dessus.
Checklist avant la migration
- Faites une sauvegarde complète des fichiers et de la base de données du site actuel, stockée quelque part en dehors du compte d'hébergement actuel.
- Abaissez le TTL DNS de l'enregistrement A du domaine à 300 secondes (5 minutes) au moins 24 à 48 heures avant la bascule prévue — voir le détail technique ci-dessous sur pourquoi ce timing à l'avance compte.
- Faites l'inventaire des plugins et thèmes actifs, en notant les versions, car le nouvel environnement doit correspondre à la version PHP et aux exigences d'extensions.
- Confirmez que le nouvel hébergeur est entièrement configuré — WordPress installé, prêt à recevoir les fichiers et la base de données migrés, mais pas encore publiquement lié au domaine.
Étape 1 : abaisser le TTL DNS avant de commencer
Le TTL DNS (time to live) contrôle combien de temps les résolveurs à travers Internet mettent en cache l'adresse IP actuelle d'un domaine avant de revérifier. Un TTL par défaut typique de plusieurs heures (parfois 24 ou plus) signifie que même après la mise à jour du DNS pour pointer vers le nouveau serveur, une part significative des visiteurs continue d'atteindre l'ancien jusqu'à ce que la copie en cache de leur résolveur expire. L'explication de Cloudflare sur le TTL DNS couvre ce mécanisme plus en profondeur techniquement.
Abaisser le TTL à 300 secondes un jour ou deux avant la bascule réelle signifie qu'au moment où le DNS est basculé, le délai de propagation se compte en minutes plutôt qu'en heures — l'étape de préparation la plus impactante pour une bascule véritablement peu interruptive.
Étape 2 : construire le nouvel environnement en parallèle
Configurez WordPress sur le nouvel hébergeur complètement indépendamment du site en ligne — même version PHP, mêmes extensions requises, prêt à recevoir du contenu mais pas encore lié de manière publiquement visible au domaine en ligne. C'est l'étape qui rend le "sans interruption" possible : tout le travail de configuration se produit sur une infrastructure que personne ne visite encore.
Étape 3 : migrer les fichiers et la base de données
Des outils comme Duplicator ou le plugin All-in-One WP Migration regroupent les fichiers et la base de données du site en une seule archive transférable, gérant les détails techniques d'un export et import de base de données propre. Pour les agences gérant des migrations fréquentes, un outil de migration hébergeur à hébergeur intégré aux plateformes d'hébergement géré (Kinsta, WP Engine et d'autres l'offrent) gère souvent le processus avec moins de travail manuel.
Un piège technique spécifique à éviter ici : ne pas exécuter une simple recherche-remplacement sur la base de données pour mettre à jour le domaine de l'ancienne URL vers la nouvelle. WordPress stocke les données PHP sérialisées — utilisées par de nombreux widgets, certains réglages de plugins et options de thème — sous forme de chaînes avec un préfixe de longueur de caractères intégré. Un remplacement de texte naïf change la longueur de la chaîne sans mettre à jour ce préfixe, corrompant silencieusement les données. La commande search-replace de WP-CLI est conçue spécifiquement pour gérer correctement les données sérialisées et est l'outil standard pour cette étape précise.
Étape 4 : tester le nouveau site via votre propre fichier hosts
Avant de toucher au DNS public, modifiez le fichier hosts local de votre propre ordinateur pour faire pointer le domaine vers l'adresse IP du nouveau serveur — cela n'affecte que votre machine, vous permettant de naviguer sur le nouveau site en utilisant le vrai nom de domaine (tester la connexion, le paiement, les formulaires de contact et tout ce qui dépend de la correspondance du domaine) sans qu'aucun autre visiteur ne soit affecté. C'est l'étape qui détecte les problèmes de migration avant qu'ils ne deviennent publics.
Étape 5 : réconcilier les changements de contenu effectués pendant la fenêtre de migration
Si le site en ligne a continué à recevoir des commentaires, commandes ou soumissions de formulaires après l'export de la base de données, ce contenu existe sur l'ancien site mais pas sur le nouveau. Pour la plupart des sites vitrines, cette fenêtre est assez petite pour être ignorée ; pour tout ce qui est transactionnel (e-commerce, contenu d'adhésion), exportez uniquement les nouveaux enregistrements créés pendant la fenêtre de migration et importez-les dans la nouvelle base de données avant la bascule.
Étape 6 : basculer le DNS
Une fois le nouveau site entièrement testé via la méthode du fichier hosts et les écarts de contenu réconciliés, mettez à jour l'enregistrement A DNS du domaine pour pointer vers le nouveau serveur. Comme le TTL a été abaissé à l'avance, la plupart des visiteurs résolvent vers le nouveau serveur en quelques minutes plutôt qu'en heures.
Étape 7 : vérifier et surveiller après la bascule
- Confirmez que le SSL est actif sur le nouveau serveur pour le domaine, car un certificat manquant ou mal configuré casse immédiatement l'accès HTTPS.
- Vérifiez les avertissements de contenu mixte causés par des URL http:// codées en dur restées dans la base de données ou les fichiers de thème.
- Vérifiez que les redirections fonctionnent toujours si la migration incluait un changement de structure d'URL, et surveillez la Google Search Console pour un pic d'erreurs d'exploration dans les jours suivants.
- Surveillez les journaux serveur pour des erreurs 404 sur des URL qui fonctionnaient auparavant, ce qui indique généralement un fichier manqué ou une recherche-remplacement incomplète.
Chronologie de migration en un coup d'œil
| Phase | Timing | Actions clés |
|---|---|---|
| Avant migration | 24-48 heures avant | Abaisser le TTL DNS, faire une sauvegarde, confirmer que le nouvel hébergeur est prêt |
| Construction parallèle | Avant la bascule | Configurer le nouvel environnement, migrer fichiers/base de données avec un outil approprié |
| Vérification | Avant la bascule | Tester via le fichier hosts local en utilisant le vrai domaine |
| Bascule | Jour de migration | Réconcilier tout écart de contenu, basculer le DNS |
| Après migration | 48-72 premières heures | Vérifier le SSL, contrôler le contenu mixte, surveiller les journaux et la Search Console |
Erreurs courantes de migration
- Sauter l'étape d'abaissement du TTL DNS, laissant la propagation de la bascule à la merci de ce à quoi l'ancien TTL était réglé.
- Exécuter une simple recherche-remplacement sur la base de données au lieu d'un outil conscient de la sérialisation comme le search-replace de WP-CLI, corrompant silencieusement les réglages de widgets et de thème.
- Basculer le DNS avant de tester le nouveau site, découvrant un plugin cassé ou un fichier manquant seulement après que les visiteurs y accèdent déjà.
- Oublier le contenu créé pendant la fenêtre de migration, perdant des commentaires, commandes ou soumissions arrivés sur l'ancien site après l'export.
- Ne pas confirmer le SSL sur le nouveau serveur avant la bascule, causant un avertissement de certificat visible au moment où le DNS bascule.
Quand obtenir de l'aide pour montrer les progrès à un client
Les agences migrant le site d'un client doivent souvent montrer le nouvel environnement parallèle pour approbation avant la bascule réelle — sans céder les identifiants d'hébergement ni un contournement de fichier hosts déroutant à suivre pour un client non technique. Un outil comme Erdo Client Preview ou Erdo Draft Links donne à un client un simple lien pour examiner directement le nouveau site, ce qui s'associe naturellement aux habitudes de test couvertes dans notre guide de staging WordPress et notre guide plus large de vitesse et d'hébergement WordPress pour évaluer l'hébergeur de destination lui-même.
En résumé
En bref, une migration WordPress sans interruption repose sur le séquencement : abaisser le TTL DNS bien à l'avance, construire et tester entièrement le nouvel environnement en parallèle en utilisant votre propre fichier hosts plutôt que le DNS public, utiliser un outil conscient de la sérialisation pour toute mise à jour d'URL, et ne basculer le DNS qu'une fois que tout est vérifié fonctionnel. Suivez cet ordre et le site en ligne ne se trouve jamais dans un état intermédiaire cassé — les visiteurs résolvent simplement vers le nouveau serveur une fois que celui-ci est déjà confirmé prêt.