Lors d’une migration, le DNS ne déplace ni WordPress ni la base de données. Il indique aux résolveurs où trouver un service. Une stratégie DNS migration site web doit donc séparer la préparation du nouvel hébergement, la modification des enregistrements, le comportement des caches et la continuité des autres services du domaine.
Changer le mauvais serveur de noms ou remplacer toute une zone pour modifier un seul enregistrement peut interrompre le courrier, la validation d’un service ou un sous-domaine. Une bascule sûre commence par un inventaire exporté et une compréhension de l’autorité DNS actuelle.
Sommaire
La réponse courte
Identifiez le registrar, les serveurs de noms faisant autorité, l’éditeur de zone et chaque enregistrement utile. Préparez et testez la nouvelle origine avant le changement. Réduisez le TTL assez tôt si la politique le permet, puis modifiez uniquement les enregistrements nécessaires.
Surveillez ancienne et nouvelle origine pendant que les caches expirent, gardez l’ancienne disponible et définissez un seuil de retour arrière. Ne publiez jamais les adresses IP, noms internes, jetons de validation, captures de zone ou détails d’infrastructure réels.
Le guide Google sur un changement d’hébergement sans changement d’URL recommande de préparer et tester la nouvelle infrastructure, basculer le DNS, surveiller puis arrêter l’ancienne seulement lorsque le trafic a bien migré.
Le fonctionnement distribué du DNS, ses caches et le rôle du TTL sont définis dans la spécification fondamentale du DNS publiée par l’IETF ; cette base explique pourquoi une bascule doit prévoir une période de coexistence plutôt qu’une heure universelle de « propagation terminée ».
Principes qui restent valables
Le DNS reste un système distribué mis en cache. Le TTL indique pendant combien de temps une réponse peut être conservée ; il ne crée pas un minuteur universel qui force tous les appareils à se mettre à jour ensemble.
Les interfaces ont évolué et certains fournisseurs masquent des détails, mais la distinction reste cruciale entre enregistrement A ou AAAA, alias CNAME, courrier MX, politiques TXT, délégation NS et enregistrement DS de DNSSEC.
Une migration de site n’implique pas nécessairement un transfert de domaine ni une migration des e-mails.
Cartographier les responsabilités
Le registrar enregistre le domaine et sa délégation. Les serveurs de noms autoritaires répondent pour la zone. Un panneau DNS permet de modifier les enregistrements servis par cette autorité. L’hébergement web reçoit ensuite le trafic destiné au site.
Ces fonctions peuvent être proposées par la même entreprise ou par plusieurs services. Notez qui contrôle chacune, comment l’accès est protégé et qui peut approuver un changement.
Vérifiez depuis une source DNS publique quels serveurs sont réellement autoritaires ; ne vous fiez pas seulement au logo du tableau de bord ouvert.
Exporter la zone avant toute modification
Conservez un export ou un relevé de chaque nom, type, valeur, TTL et éventuelle priorité. Incluez racine, www, sous-domaines, MX, SPF, DKIM, DMARC, validations et enregistrements de services.
Le document est sensible : il peut révéler l’architecture ou des prestataires. Stockez-le dans le dossier de changement à accès limité, pas dans un article ni un ticket public.
Comparez l’export à des requêtes externes. Une interface peut afficher une zone non autoritaire ou une valeur en attente.
Séparer trois projets souvent confondus
Le transfert de domaine change le registrar. Le changement de serveurs de noms déplace l’autorité de la zone. La modification d’un A, AAAA ou CNAME redirige un nom vers une autre cible. Une migration web peut ne demander que la troisième opération.
Si vous changez les serveurs de noms, recopiez d’abord toute la zone et vérifiez les services. Si vous transférez le domaine, assurez-vous que la délégation restera stable pendant le processus.
Évitez de regrouper ces changements le même jour sans nécessité : une panne devient plus difficile à attribuer et à corriger.
Inventorier les noms servis par le site
Le domaine nu et www peuvent utiliser des types différents et rediriger l’un vers l’autre. Des sous-domaines peuvent servir une boutique, une API, des médias ou un espace privé. Une redirection HTTP ne remplace pas une résolution DNS valide.
Listez les URL publiques, canonicals, plans de site, ressources et intégrations qui dépendent de chaque nom. Déterminez lesquelles changent de cible et lesquelles doivent rester intactes.
Pour une migration WordPress, complétez avec la checklist de migration WordPress : fichiers, base, HTTPS, formulaires, cache et retour arrière.
Préparer la nouvelle origine avant le DNS
Copiez fichiers et base de manière cohérente, configurez le domaine attendu, le certificat et les redirections. Testez la nouvelle origine sans modifier la résolution publique, par une méthode locale ou une URL de prévisualisation contrôlée.
Vérifiez accueil, administration, médias, formulaires, recherche, parcours commerciaux, tâches planifiées et intégrations. Neutralisez les sorties externes si la copie n’est pas encore la production.
La cible doit répondre pour le vrai nom de domaine et présenter le bon certificat au moment de la bascule. Un test par adresse IP seule ne prouve pas ce comportement.
Comprendre le TTL
Le TTL est attaché à une réponse mise en cache. Le réduire juste avant la bascule ne vide pas les caches qui ont déjà conservé l’ancienne valeur avec un TTL long.
Google suggère un TTL conservateur de quelques heures au moins une semaine avant un changement d’hébergement. Cette indication n’est pas universelle : adaptez-la à la politique DNS, au volume et au risque.
Après stabilisation, remontez le TTL à la valeur d’exploitation choisie. Un TTL très bas permanent augmente les requêtes et ne garantit pas l’absence de cache intermédiaire.
Traiter IPv4 et IPv6 ensemble
Un domaine peut publier un enregistrement A pour IPv4 et AAAA pour IPv6. Modifier uniquement A alors qu’AAAA pointe encore vers l’ancienne origine produit des résultats différents selon le réseau du visiteur.
Testez les deux familles si elles sont publiées. Si la nouvelle origine ne prend pas en charge IPv6, choisissez explicitement la stratégie au lieu de laisser un enregistrement obsolète.
Vérifiez également les noms www et racine depuis plusieurs résolveurs autorisés.
Préserver le courrier et les TXT
Les enregistrements MX dirigent le courrier ; SPF, DKIM et DMARC utilisent généralement TXT. Une migration du site n’autorise pas à les remplacer par les valeurs par défaut d’une nouvelle zone.
Si les e-mails restent au même endroit, conservez leurs enregistrements exactement selon la documentation du service. Testez réception, envoi et authentification après tout changement d’autorité DNS.
Ne publiez pas les sélecteurs, jetons ou valeurs complètes comme exemple réel. Utilisez des noms fictifs dans la documentation publique.
Vérifier les CNAME et l’apex
Un CNAME alias un nom vers un autre nom et ne doit généralement pas coexister avec d’autres données au même libellé. La racine du domaine a des contraintes spécifiques ; certains fournisseurs proposent des mécanismes d’aplatissement.
Comprenez ce que l’interface crée réellement. Un champ intitulé « cible » peut produire un A dynamique, un alias propriétaire ou un CNAME. Vérifiez avec une requête DNS externe.
Évitez les chaînes d’alias longues et surveillez la cible finale, notamment lors d’un changement de CDN.
Intégrer DNSSEC au plan
DNSSEC ajoute une chaîne de validation entre la zone signée et un enregistrement DS publié via le parent. Lors d’un changement de fournisseur DNS, une incohérence entre nouvelles clés et ancien DS peut rendre le domaine invalide pour les résolveurs validateurs.
Suivez la procédure des opérateurs concernés, vérifiez la chaîne et ne supprimez ou n’ajoutez pas un DS par intuition. Séparez ce travail du simple changement d’une adresse web lorsque possible.
Conservez les détails de clés hors de la publication publique.
Planifier la fenêtre de bascule
Choisissez une période où les responsables du site, du DNS et des fonctions métier sont disponibles. Terminez une dernière synchronisation, figez les changements si nécessaire et notez l’heure exacte.
Modifiez le plus petit nombre d’enregistrements. Capturez les valeurs avant et après dans le dossier privé. Vérifiez la réponse autoritaire immédiatement, puis plusieurs résolveurs et réseaux à mesure que les caches expirent.
Ne concluez pas après un seul ordinateur : son cache local peut masquer l’état réel.
Garder deux origines pendant la transition
Certains visiteurs atteindront encore l’ancienne origine. Maintenez-la accessible et cohérente pendant une durée définie. Pour un site qui reçoit des commandes ou contenus, préparez la synchronisation ou une fenêtre de lecture seule pour éviter deux bases actives divergentes.
Surveillez les journaux et les indicateurs des deux côtés sans publier leurs détails. La diminution du trafic ancien est un meilleur signal qu’une estimation abstraite de « propagation terminée ».
Arrêtez l’ancienne origine seulement lorsque le risque résiduel est accepté et la restauration reste possible.
Définir le retour arrière
Le retour DNS consiste généralement à restaurer les valeurs précédentes. Il subit lui aussi les caches ; ce n’est pas un bouton instantané. Définissez donc à l’avance le seuil : erreurs, transactions impossibles, certificat, données divergentes ou performance critique.
Conservez l’ancienne origine fonctionnelle et les valeurs prêtes. Décidez qui prend la décision et comment les changements intervenus depuis la bascule seront réconciliés.
Un retour technique sans plan de données peut perdre des commandes ou des publications.
Surveiller après la bascule
Contrôlez résolution A/AAAA, HTTP, HTTPS, certificat, redirections, canonicals, robots, plan de site, administration, formulaires et fonctions métier. Surveillez les erreurs et le trafic de recherche.
Assurez-vous que la vérification Search Console et la mesure restent en place. Pour une migration sans changement d’URL, les pages doivent conserver leurs URLs publiques et leurs signaux.
Documentez les écarts et leur résolution. Remontez le TTL après stabilisation et fermez proprement l’ancienne infrastructure.
Ordre de migration DNS recommandé
- Cartographier registrar, autorité DNS et hébergement.
- Exporter et vérifier toute la zone.
- Séparer site, domaine, DNS et e-mail.
- Préparer puis tester la nouvelle origine.
- Réduire le TTL suffisamment tôt si prévu.
- Préparer dernière synchronisation et retour arrière.
- Modifier uniquement les enregistrements nécessaires.
- Vérifier autorité, résolveurs, IPv4, IPv6 et HTTPS.
- Surveiller les deux origines et les fonctions métier.
- Stabiliser, remonter le TTL et fermer l’ancien service.
Les erreurs à éviter
- Remplacer toute la zone pour changer l’hébergement web.
- Confondre transfert de domaine et bascule DNS.
- Oublier AAAA alors que A a été modifié.
- Réduire le TTL quelques minutes avant le changement.
- Copier le site sans tester le vrai nom et le certificat.
- Supprimer MX ou TXT parce qu’ils ne semblent pas liés au web.
- Couper l’ancienne origine avant l’expiration des caches observés.
- Publier les IP, captures de zone ou détails d’autorité réels.
Checklist DNS migration site web
- [ ] Le registrar et les serveurs autoritaires sont identifiés.
- [ ] La zone complète est exportée et vérifiée.
- [ ] Les services web, mail et sous-domaines sont séparés.
- [ ] La nouvelle origine fonctionne avec le vrai nom et HTTPS.
- [ ] A et AAAA sont traités explicitement.
- [ ] Le TTL a été préparé assez tôt.
- [ ] DNSSEC possède une procédure validée si actif.
- [ ] L’ancienne origine reste disponible pendant la transition.
- [ ] Les seuils et valeurs de retour sont prêts.
- [ ] Résolution, recherche et fonctions métier sont surveillées.
Questions fréquentes
Que faut-il préparer avant une migration DNS ?
Un plan DNS migration site web commence par l’inventaire de la zone, des services dépendants, des autorités et des valeurs de retour. Testez ensuite la nouvelle origine avec le vrai nom d’hôte avant de modifier le moindre enregistrement public.
Faut-il transférer le domaine pour changer d’hébergement ?
Non. Une opération DNS migration site web peut modifier uniquement les enregistrements web tout en conservant le registrar, les serveurs de noms et le courrier. Séparer ces responsabilités réduit le risque et facilite le retour arrière.
Combien de temps faut-il conserver l’ancienne origine ?
Pendant une bascule DNS migration site web, conservez l’ancienne origine au moins jusqu’à ce que les TTL observés soient expirés et que les parcours critiques soient stables sur plusieurs résolveurs. La durée dépend de la zone réelle et des caches en circulation.
Comment vérifier la réussite de la bascule ?
La validation DNS migration site web doit couvrir autorité, A, AAAA, HTTPS, redirections, formulaires, recherche et services métier. Surveillez les deux origines et gardez des seuils de retour explicites jusqu’à la stabilisation.
Conclusion
Une stratégie DNS migration site web fiable ne repose pas sur l’idée vague de propagation. Elle repose sur une zone inventoriée, une cible déjà testée, des caches anticipés, un changement minimal et une surveillance des deux origines.
En séparant DNS, domaine, site et e-mail, vous réduisez fortement le rayon d’une erreur et rendez le retour possible. Pour choisir l’environnement cible avec les mêmes exigences de responsabilité, consultez choisir un hébergement WordPress.