Déplacer un site WordPress d’un hébergeur à un autre est une tâche qui semble simple mais qui, en pratique, est truffée de petits pièges. Une migration ratée peut faire perdre des visiteurs, casser des formulaires, égarer du contenu récent ou, pire encore, laisser le site dans un état où, pendant des jours, certains visiteurs atteignent l’ancien hébergeur et d’autres le nouveau.
Bien réalisée, une migration est invisible pour les visiteurs et sans stress pour le chef d’entreprise. Voici la séquence exacte en huit étapes que nous utilisons chez Defyn pour déplacer des sites WordPress, affinée au fil de plus d’une centaine de migrations.
Étape 1 : Faites un audit avant de toucher à quoi que ce soit
Avant que le nouvel hébergeur ne reçoive la base de données, avant que le DNS ne s’approche d’un changement, recensez tout ce qui compte. Versions des extensions, code sur mesure, tâches planifiées, intégrations tierces, passerelles de paiement, comptes e-mail, enregistrements DNS, fournisseur du certificat SSL, clés antispam, destinations de sauvegarde. Tout ce qui ne figure pas sur la liste risque d’être oublié.
Cette étape prend une à deux heures. Elle évite quatre heures à éteindre des incendies après la migration.
Étape 2 : Abaissez le TTL du DNS
Trois jours avant la bascule, abaissez le TTL de l’enregistrement A et des CNAME qui comptent depuis la valeur par défaut (souvent 24 ou 48 heures) jusqu’à 300 secondes. Ainsi, une fois la bascule effectuée, le DNS se propage en cinq minutes au lieu d’attendre l’expiration des caches sur un ou deux jours.
Cette seule étape est ce qui distingue une migration propre d’un purgatoire DNS de 36 heures où certains visiteurs voient l’ancien site et d’autres le nouveau.
Étape 3 : Préparez le nouvel hébergeur comme un environnement de préproduction
Mettez en route le nouvel hébergeur avec le site WordPress chargé sur une URL temporaire ou via une surcharge du fichier hosts. C’est là que se fait le vrai travail : importer la base de données, copier les fichiers, installer le certificat SSL, configurer la mise en cache et vérifier que tout fonctionne réellement.
Cette étape prend généralement une journée de travail complète. L’approche par le fichier hosts permet à l’équipe de tester l’ensemble du site depuis le bureau sans que le DNS public ne pointe encore vers le nouvel hébergeur.
Étape 4 : Testez chaque formulaire, paiement et intégration
C’est là que la plupart des migrations échouent. Le formulaire de contact a la même apparence, mais les identifiants SMTP doivent être reconfigurés pour le nouvel hébergeur. La passerelle de paiement est active, mais les URL des webhooks pointent toujours vers l’ancien hébergeur. L’extension d’e-mail fonctionne, mais la réputation de l’IP du nouvel hébergeur est inconnue.
Parcourez chaque formulaire du site. Soumettez-les. Confirmez l’arrivée de l’e-mail. Effectuez une vraie transaction (remboursée). Lancez manuellement les tâches cron planifiées et vérifiez le résultat. Testez dans trois navigateurs, mobile compris.
Étape 5 : Synchronisation finale de la base de données
Juste avant la bascule du DNS, effectuez une synchronisation finale de la base de données pour récupérer toute modification de contenu, tout commentaire ou toute transaction survenus pendant les tests. Ensuite, si possible, passez le site source en lecture seule (une extension de maintenance ou un bref gel du contenu) afin qu’aucune nouvelle donnée ne soit générée sur l’ancien hébergeur pendant la bascule.
Étape 6 : Basculez le DNS
Le TTL ayant déjà été abaissé, pointez l’enregistrement A (ou CNAME, ou ANAME selon l’hébergeur) vers le nouveau serveur. En cinq minutes, la plupart des visiteurs atteignent le nouvel hébergeur. En une heure, la quasi-totalité.
Laissez les deux serveurs en service pendant les premières 24 heures. Si un visiteur utilise un résolveur DNS lent qui n’a pas encore propagé, il atteint l’ancien hébergeur et voit toujours un site fonctionnel. La fenêtre à deux serveurs coûte une journée d’hébergement sur l’ancien compte. La protection en vaut la peine.
Étape 7 : Surveillez pendant les premières 48 heures
Surveillez la supervision de disponibilité, surveillez les journaux d’erreurs de l’hébergeur, surveillez la boîte de réception du formulaire de contact. La plupart des problèmes qui surgissent après la migration apparaissent dans les 12 premières heures : une redirection manquante, un certificat SSL mal configuré pour un sous-domaine, une intégration tierce qui nécessitait la mise à jour d’une liste blanche d’IP.
Étape 8 : Mettez hors service et documentez
Après 48 heures de trafic propre sur le nouvel hébergeur, faites une dernière sauvegarde de l’ancien environnement à des fins d’archivage, puis mettez l’ancien compte hors service. Documentez la nouvelle architecture : où se trouve la base de données, quel niveau de forfait, quels identifiants de connexion résident où, quelle supervision est en place et quelle serait la procédure de retour arrière en cas de catastrophe.
Cette documentation est le livrable qui comptera dans six mois. Sans elle, la prochaine personne qui devra prendre une décision d’hébergement n’aura aucun contexte.
Là où les migrations en autonomie déraillent
Les deux échecs les plus courants des migrations en autonomie sont le fait de sauter l’étape 2 (l’abaissement du TTL) et l’étape 4 (les tests d’intégration complets). Les deux semblent ennuyeux. Les deux évitent des heures de frustration de l’autre côté. Une migration qui suit les huit étapes complètes est, d’après notre expérience, invisible pour les visiteurs et sans incident pour le chef d’entreprise.
Si vous êtes confronté à un changement d’hébergement et souhaitez un partenaire qui l’a fait des dizaines de fois, l’équipe hébergement de Defyn traite les migrations WordPress comme un projet structuré à périmètre fixe. Le site est déplacé proprement, vous continuez à travailler, et personne ne mentionne la migration ensuite parce que rien n’a mal tourné. Si vous avez besoin d’aide pour quitter votre hébergeur actuel, parlez-en à Defyn.
Most Read
-
Le coût réel de négliger la maintenance de WordPress en 2026
-
SEO local pour les banlieues de Sydney : comment gagner une place dans le pack local
-
À quoi ressemble vraiment le SEO local en 2026 pour une entreprise de Sydney
-
La liste de contrôle d’audit SEO technique que toute entreprise de Sydney devrait exécuter


