Changer d’hébergeur est une opération fréquente dans la vie d’un site WordPress : fin de contrat, besoin de performance, passage à de l’auto-hébergement. Le risque ne vient presque jamais de la copie des fichiers elle-même, mais de la bascule DNS et de l’ordre dans lequel les étapes sont enchaînées. Une migration bien préparée se joue à quelques réglages faits plusieurs jours à l’avance, pas le jour même.
Pourquoi la bascule DNS est le point de rupture
Chaque enregistrement DNS porte une durée de vie, le TTL (Time To Live), exprimée en secondes. Tant que ce délai n’est pas écoulé, les résolveurs DNS intermédiaires — ceux des fournisseurs d’accès, des navigateurs, des caches d’entreprise — continuent de répondre avec l’ancienne adresse IP. Avec un TTL par défaut de 86 400 secondes (24 heures), une partie des visiteurs peut continuer à taper sur l’ancien serveur pendant une journée entière après la bascule, ce qui pose un problème dès que l’ancien serveur est éteint ou que le contenu diverge entre les deux environnements.
| Échéance | Action | Objectif |
|---|---|---|
| J-3 | Abaisser le TTL de l’enregistrement A à 300 secondes | Réduire la fenêtre de propagation avant la bascule |
| J-1 | Copier fichiers et base sur le nouvel hébergeur, tester en local via le fichier hosts | Valider le site sans toucher au DNS de production |
| J0 matin | Synchronisation finale (delta) puis bascule du DNS | Minimiser l’écart de contenu entre les deux copies |
| J0 + quelques heures | Vérifier les logs des deux serveurs, confirmer que le trafic a basculé | S’assurer qu’aucun visiteur ne reste bloqué sur l’ancien serveur |
| J+7 | Couper l’ancien hébergement | Laisser une marge pour les caches DNS les plus lents |
Préparer le nouvel hébergeur avant toute copie
Avant de déplacer le moindre fichier, le nouvel environnement doit être prêt à recevoir le site dans des conditions identiques ou supérieures à l’existant : même version de PHP au minimum, mêmes extensions actives, certificat TLS déjà en place pour le nom de domaine final. Sur un panneau d’auto-hébergement comme celui déjà couvert pour l’auto-hébergement WordPress avec CloudPanel, cette étape se limite à créer le site et son certificat avant toute copie. Provisionner cet environnement en avance permet de tester la configuration serveur (réécriture d’URL, limites de mémoire PHP, configuration de cache) indépendamment de la migration du contenu, et d’isoler les problèmes de configuration des problèmes de données.
Synchroniser fichiers et base de données sans erreur
La copie se fait en deux flux distincts : les fichiers via rsync ou un transfert SFTP, la base de données via un export SQL. WP-CLI simplifie nettement cette étape sur un serveur en auto-hébergement, en particulier pour le remplacement des URL stockées dans les champs sérialisés, que les outils de recherche-remplacement génériques abîment souvent.
# Sur l'ancien serveur : export propre de la base
wp db export backup.sql --add-drop-table
# Copie des fichiers, en excluant le cache et les journaux
rsync -avz --exclude 'wp-content/cache' --exclude '*.log' \
./ user@nouveau-serveur:/var/www/site/
# Sur le nouvel hébergeur : import et réécriture des URL
wp db import backup.sql
wp search-replace 'https://ancien-domaine.tld' 'https://nouveau-domaine.tld' \
--all-tables --precise
Le choix de wp search-replace plutôt qu’un remplacement de texte brut évite de casser les tableaux et objets PHP sérialisés que WordPress stocke dans certains champs (widgets, options de thème, données de constructeurs de page) : un remplacement naïf y change la longueur de la chaîne sans mettre à jour le compteur de caractères qui la précède, ce qui corrompt silencieusement la donnée.
Basculer le DNS et vérifier avant de couper l’ancien serveur
Une fois la synchronisation finale effectuée, la mise à jour de l’enregistrement DNS déclenche la bascule progressive du trafic. C’est le moment de surveiller les journaux d’accès des deux serveurs en parallèle : une baisse progressive du trafic sur l’ancien et une montée symétrique sur le nouveau confirment une propagation normale. Tester le site depuis plusieurs réseaux (mobile, connexion fixe, VPN) donne une image plus fidèle de ce que voient réellement les visiteurs que depuis un seul poste.
Un TTL abaissé à 300 secondes trois jours avant la bascule ramène la fenêtre de propagation DNS à quelques minutes, contre plusieurs heures avec la valeur par défaut de 86 400 secondes.
Point de vigilance : ne pas couper l’ancien hébergement dès que le nouveau répond correctement. Les résolveurs DNS les plus lents et certains caches d’entreprise peuvent conserver l’ancienne réponse plusieurs jours au-delà du TTL affiché. Garder l’ancien serveur actif, même en lecture seule, pendant au moins une semaine évite qu’une poignée de visiteurs ne tombe sur une page blanche.
Les pièges classiques d’une migration mal préparée
Trois erreurs reviennent le plus souvent. La première consiste à modifier le DNS avant d’avoir testé le site sur le nouvel hébergeur : sans bascule, un test via le fichier hosts local (en pointant temporairement le nom de domaine vers la nouvelle adresse IP depuis un seul poste) permet de valider le rendu et les fonctionnalités sans exposer un site encore instable au public. La deuxième erreur est d’oublier les URL codées en dur dans des extensions tierces : constructeurs de page, plugins de formulaire ou services de paiement stockent parfois l’ancienne adresse en dehors des tables couvertes par wp search-replace --all-tables, ce qui impose de vérifier aussi les fichiers de configuration propres à ces extensions. La troisième tient aux tâches planifiées (cron WordPress ou cron système) : une sauvegarde automatisée ou un envoi d’e-mails groupés encore configuré pour se déclencher sur l’ancien serveur peut continuer à tourner en double pendant plusieurs jours si personne ne pense à le désactiver.
Un contrat d’hébergement qui se termine à date fixe ajoute une contrainte supplémentaire : mieux vaut caler la bascule DNS plusieurs jours avant l’échéance du contrat plutôt que le jour même, pour conserver une marge de repli si un imprévu retarde la vérification finale.
Nettoyer et surveiller après la migration
Une fois la bascule confirmée, il reste à mettre à jour les services tiers qui pointent explicitement vers l’ancienne adresse IP ou l’ancien serveur : robots de sauvegarde, service de monitoring, éventuel pare-feu applicatif, et les enregistrements SPF si l’envoi d’e-mails transite par le même hébergeur. C’est aussi le bon moment pour revérifier le socle de durcissement minimal sur le nouveau serveur, dont les réglages par défaut diffèrent souvent de l’ancien hébergeur. Un contrôle de la Search Console quelques jours après la migration permet de repérer une éventuelle erreur d’exploration liée à un certificat TLS mal configuré ou à une règle de réécriture oubliée sur le nouveau serveur.
Ce qu’il faut retenir
Le risque d’une migration d’hébergeur ne vient presque jamais de la copie des données, mais du délai de propagation DNS et de l’ordre des opérations autour de cette bascule. Abaisser le TTL plusieurs jours à l’avance, valider le nouvel environnement avant de toucher au DNS, puis garder l’ancien serveur actif une semaine après la bascule couvre l’essentiel des scénarios de coupure évitable.
La migration ratée la plus fréquente que j’ai vue vient toujours du même oubli : le TTL laissé à sa valeur par défaut, découvert seulement une fois l’ancien serveur éteint. Un abaissement du TTL préparé trois jours à l’avance coûte cinq minutes de configuration et évite quasiment tous les incidents de bascule que je continue de dépanner en urgence pour des clients — Simon Janvier.
Pour aller plus loin : la documentation officielle de la commande wp search-replace.
