Gérer les DNS lors d'une migration : guide complet

La gestion des DNS est l'étape la plus critique — et la plus mal comprise — d'une migration de site web. Une erreur dans les enregistrements DNS peut rendre votre site inaccessible, couper votre messagerie, ou faire coexister deux versions contradictoires de votre site pendant des heures. Et contrairement à une erreur de code que vous pouvez corriger instantanément, une erreur DNS peut mettre jusqu'à 48 heures à se propager et à se résoudre.

Ce guide explique le fonctionnement des DNS de manière accessible, détaille chaque type d'enregistrement que vous devrez manipuler, et fournit un protocole précis pour gérer la bascule DNS lors d'une migration sans interruption de service.

Comprendre le fonctionnement des DNS

Le DNS (Domain Name System) est souvent comparé à un annuaire téléphonique d'Internet. Quand un utilisateur tape votresite.fr dans son navigateur, celui-ci ne sait pas où se trouve votre serveur. Il interroge le système DNS pour obtenir l'adresse IP correspondante — par exemple 203.0.113.42. Cette traduction nom de domaine vers adresse IP est la fonction fondamentale du DNS.

La chaîne de résolution DNS

La résolution DNS suit une chaîne de serveurs. Le navigateur interroge d'abord son cache local (si le site a été visité récemment, la réponse est déjà en mémoire). Si le cache est vide, la requête est envoyée au résolveur DNS du fournisseur d'accès Internet (FAI) ou du service DNS configuré (Google DNS 8.8.8.8, Cloudflare 1.1.1.1). Ce résolveur consulte son propre cache, puis, si nécessaire, interroge les serveurs racine, puis les serveurs du TLD (.fr, .com), et enfin les serveurs de noms autoritaires qui détiennent la configuration DNS de votre domaine. La réponse remonte la chaîne et est mise en cache à chaque niveau.

Le concept de TTL

Le TTL (Time To Live) est une valeur en secondes attachée à chaque enregistrement DNS. Elle indique combien de temps les résolveurs intermédiaires peuvent garder la réponse en cache avant de la rafraîchir. Un TTL de 3600 (1 heure) signifie que si un résolveur a mis en cache votre enregistrement, il ne vérifiera pas les mises à jour pendant une heure. Un TTL de 86400 (24 heures) signifie qu'après un changement, certains visiteurs verront encore l'ancienne adresse IP pendant 24 heures. C'est pourquoi le TTL est la variable clé à maîtriser lors d'une migration.

Registrar vs. hébergeur DNS

Il est important de distinguer le registrar (le bureau d'enregistrement où vous avez acheté votre domaine — OVH, Gandi, Namecheap) de l'hébergeur DNS (le service qui gère votre zone DNS). Souvent, c'est le même prestataire. Mais vous pouvez très bien acheter votre domaine chez Gandi et déléguer la gestion DNS à Cloudflare pour bénéficier de ses fonctionnalités (proxy, CDN, firewall). Dans ce cas, les modifications DNS se font chez Cloudflare, pas chez Gandi. Identifiez clairement où se gère votre zone DNS avant de commencer la migration.

Les types d'enregistrements DNS

Lors d'une migration, vous manipulerez principalement six types d'enregistrements. Chacun a un rôle précis et des implications différentes en cas d'erreur.

Enregistrement A

L'enregistrement A associe un nom de domaine à une adresse IPv4. C'est l'enregistrement le plus fondamental : votresite.fr A 203.0.113.42. Lors d'une migration, modifier l'enregistrement A revient à rediriger votre domaine vers la nouvelle adresse IP du serveur. Vous aurez généralement un enregistrement A pour le domaine nu (votresite.fr) et un pour le sous-domaine www (www.votresite.fr), soit directement en A soit via un CNAME.

Enregistrement AAAA

L'enregistrement AAAA est l'équivalent IPv6 de l'enregistrement A. Il associe un nom de domaine à une adresse IPv6 (128 bits). Si votre nouvel hébergeur fournit une adresse IPv6 (de plus en plus courant), ajoutez un enregistrement AAAA en parallèle de l'enregistrement A. Les navigateurs modernes préfèrent IPv6 quand c'est disponible, ce qui peut améliorer la latence pour les utilisateurs connectés en IPv6.

Enregistrement CNAME

Le CNAME (Canonical Name) crée un alias d'un nom de domaine vers un autre. Par exemple, www.votresite.fr CNAME votresite.fr signifie que www.votresite.fr pointe vers la même adresse que votresite.fr. Le CNAME est pratique car si vous changez l'IP de l'enregistrement A, le CNAME suit automatiquement. Attention : un CNAME ne peut pas coexister avec d'autres enregistrements sur le même nom — c'est pourquoi vous ne pouvez pas mettre un CNAME sur le domaine nu si vous avez aussi des enregistrements MX (certains hébergeurs DNS contournent cette limitation avec des enregistrements ALIAS ou ANAME).

Enregistrement MX

Les enregistrements MX (Mail eXchange) définissent les serveurs de messagerie pour votre domaine. Ils sont critiques lors d'une migration : une erreur dans les MX coupe la réception de vos emails. Chaque enregistrement MX a une priorité (un nombre : 10, 20, 30) — le serveur avec la priorité la plus basse est essayé en premier. Lors d'une migration, si votre messagerie ne change pas de serveur, ne touchez pas aux enregistrements MX. Si elle migre aussi, planifiez la bascule MX séparément (voir notre article sur la migration de messagerie).

Enregistrement TXT

Les enregistrements TXT stockent du texte libre et sont utilisés principalement pour l'authentification : SPF (liste des serveurs autorisés à envoyer des emails), DKIM (clé publique de signature email), DMARC (politique de traitement des emails non authentifiés), vérification de propriété (Google Search Console, services tiers). Lors d'une migration, vérifiez que tous vos enregistrements TXT sont reproduits sur le nouvel hébergeur DNS ou conservés si vous ne changez pas de gestionnaire DNS.

Enregistrement NS

Les enregistrements NS (Name Server) délèguent la gestion DNS de votre domaine à des serveurs de noms spécifiques. Si vous changez d'hébergeur DNS (par exemple, passer de la gestion DNS OVH à Cloudflare), vous modifierez les enregistrements NS chez votre registrar. Ce changement a un impact global : toute votre zone DNS est désormais gérée par les nouveaux serveurs de noms. C'est un changement à ne faire que si vous migrez effectivement votre gestion DNS, pas seulement votre site web.

Préparer la migration DNS

La préparation DNS commence bien avant la migration effective. Les erreurs les plus coûteuses sont celles commises par précipitation — une zone DNS mal documentée, un enregistrement oublié, un TTL non réduit à l'avance.

Documenter la zone DNS actuelle

Avant toute modification, exportez ou copiez l'intégralité de votre zone DNS actuelle. Chaque enregistrement doit être documenté : type, nom, valeur, TTL. Cette sauvegarde est votre filet de sécurité — en cas de problème, vous pourrez restaurer la configuration d'origine. La plupart des panneaux de contrôle (cPanel, Plesk, Cloudflare) permettent d'exporter la zone en fichier texte. Si ce n'est pas possible, faites des captures d'écran de chaque enregistrement.

Identifier les enregistrements à modifier

Tous les enregistrements ne doivent pas être modifiés lors d'une migration. Si seul le site web migre (pas la messagerie), seuls les enregistrements A (et éventuellement AAAA et CNAME) sont concernés. Les enregistrements MX, SPF, DKIM et DMARC restent inchangés. Dressez la liste précise des enregistrements à modifier, avec l'ancienne et la nouvelle valeur pour chacun. Revérifiez deux fois — une erreur dans un enregistrement MX peut couper votre messagerie.

Préparer le site sur le nouveau serveur

Avant de toucher aux DNS, votre site doit être entièrement fonctionnel sur le nouveau serveur. Testez-le en accédant directement via l'adresse IP du nouveau serveur ou via un fichier hosts modifié sur votre poste. Vérifiez que toutes les pages s'affichent correctement, que les formulaires fonctionnent, que le certificat SSL est installé et prêt. La bascule DNS ne doit intervenir que quand le nouveau site est 100% opérationnel.

Réduire le TTL avant la migration

La réduction du TTL est l'étape préparatoire la plus importante et la plus souvent oubliée. Elle détermine la vitesse à laquelle le changement DNS sera effectif pour tous vos visiteurs.

Pourquoi réduire le TTL

Si votre TTL actuel est de 86400 secondes (24 heures), cela signifie qu'après votre changement DNS, certains résolveurs continueront à servir l'ancienne adresse IP pendant jusqu'à 24 heures. Pendant cette période, certains visiteurs verront l'ancien site et d'autres le nouveau — une situation ingérable si les deux sites ne sont pas synchronisés. En réduisant le TTL à 300 secondes (5 minutes), la propagation est quasi immédiate après le changement.

Quand réduire le TTL

La réduction du TTL doit être effectuée au minimum 48 heures avant la migration, et idéalement 72 heures avant. Pourquoi ? Parce que le TTL actuel (disons 24h) est celui qui est en cache chez tous les résolveurs. Même si vous changez le TTL à 300 secondes maintenant, les résolveurs qui ont mis en cache l'ancien TTL ne vérifieront pas avant l'expiration de ce cache (jusqu'à 24h). Deux jours de marge garantissent que l'ancien TTL a expiré partout.

Comment procéder

Connectez-vous à votre gestionnaire DNS et modifiez le TTL de chaque enregistrement que vous allez changer lors de la migration. Passez-le à 300 secondes (5 minutes). Ne descendez pas en dessous de 300 secondes — certains résolveurs ignorent les TTL trop courts. Vérifiez que le changement est effectif avec la commande dig votresite.fr +short (qui affiche aussi le TTL dans le résultat détaillé avec dig votresite.fr). Notez l'heure du changement — c'est à partir de ce moment que le compteur de 48h commence.

Après la migration : remonter le TTL

Une fois la migration terminée et vérifiée (48 à 72 heures après la bascule DNS), remontez le TTL à une valeur standard : 3600 secondes (1 heure) ou 86400 secondes (24 heures). Un TTL bas génère davantage de requêtes DNS, ce qui augmente légèrement la latence pour vos visiteurs et la charge sur les serveurs de noms. Un TTL de 3600 est un bon compromis entre réactivité et performance.

Basculer les DNS

Le moment de la bascule est arrivé. Le site est prêt sur le nouveau serveur, le TTL a été réduit depuis plus de 48 heures, vous avez la liste précise des enregistrements à modifier. Voici le protocole à suivre.

Choisir le bon moment

Basculez les DNS pendant une période de faible trafic — typiquement un vendredi soir, un samedi matin, ou en dehors des heures de bureau si votre audience est principalement professionnelle. Évitez les périodes critiques : lancements marketing, événements, périodes de soldes pour les e-commerces. Prévoyez au moins 2 heures de disponibilité après la bascule pour surveiller et intervenir si nécessaire.

Modifier les enregistrements

Connectez-vous à votre gestionnaire DNS et modifiez les enregistrements selon votre liste préparée. Modifiez l'enregistrement A (et AAAA si applicable) pour pointer vers la nouvelle adresse IP. Si vous utilisez un CNAME pour www, vérifiez qu'il pointe vers le bon domaine. Si la messagerie migre aussi, modifiez les enregistrements MX, SPF et DKIM. Faites toutes les modifications d'un coup — n'étalez pas les changements sur plusieurs heures.

Garder l'ancien serveur actif

Ne résiliez pas et ne coupez pas l'ancien serveur immédiatement. Pendant la propagation, certains visiteurs seront encore dirigés vers l'ancien serveur par des résolveurs dont le cache n'a pas expiré. L'ancien serveur doit continuer à servir votre site correctement pendant au moins 24 à 48 heures après la bascule. Pour un e-commerce, c'est critique — des commandes passées sur l'ancien serveur après la bascule seraient perdues si le serveur est déjà éteint.

Vérifier la propagation

Après la bascule, vous devez vérifier que les changements se propagent correctement à travers le monde. La propagation n'est pas instantanée — elle dépend du TTL en cache chez les différents résolveurs.

Outils de vérification

whatsmydns.net est l'outil de référence pour suivre la propagation DNS en temps réel. Entrez votre domaine, sélectionnez le type d'enregistrement (A, MX, TXT) et visualisez la résolution depuis des dizaines de serveurs DNS répartis dans le monde. Chaque serveur affiche la valeur qu'il voit — ancienne ou nouvelle. En quelques minutes après la bascule (grâce au TTL réduit), la majorité des serveurs devraient afficher la nouvelle adresse IP. dig en ligne de commande permet de vérifier la résolution depuis un serveur DNS spécifique : dig @8.8.8.8 votresite.fr A interroge directement Google DNS.

Vérifier le site web

Après avoir confirmé que la propagation est en cours, vérifiez que votre site fonctionne correctement sur le nouveau serveur. Testez les pages principales, les formulaires, les fonctionnalités e-commerce, les redirections, le certificat SSL. Videz le cache de votre navigateur (ou utilisez une navigation privée) pour vous assurer de voir le site servi par le nouveau serveur. Vérifiez les en-têtes HTTP avec les DevTools pour confirmer que les réponses viennent bien du bon serveur.

Vérifier la messagerie

Si vous avez modifié les enregistrements MX, testez immédiatement l'envoi et la réception d'emails. Envoyez un email depuis votre domaine vers une adresse externe (Gmail, Outlook.com) et vérifiez qu'il arrive correctement et qu'il n'est pas classé en spam. Faites l'opération inverse — envoyez un email depuis une adresse externe vers votre domaine. Utilisez Mail-Tester pour vérifier que l'authentification SPF, DKIM et DMARC fonctionne depuis le nouveau serveur.

Surveiller pendant 48 heures

Les premières 48 heures après la bascule sont critiques. Surveillez votre site avec un outil de monitoring (StatusCake, UptimeRobot, Pingdom) pour détecter toute interruption. Vérifiez les logs du nouveau serveur pour confirmer que le trafic arrive bien. Surveillez aussi les logs de l'ancien serveur — si du trafic y arrive encore après 24 heures, c'est que la propagation est incomplète pour certains résolveurs. Ne résiliez l'ancien hébergement qu'après avoir confirmé que tout le trafic est basculé.