Vous migrez un site, tout semble fonctionner correctement de votre côté, puis les messages commencent à affluer. Certains visiteurs voient le nouveau site, d’autres accèdent encore à l’ancien, et quelques-uns signalent des erreurs que vous ne parvenez absolument pas à reproduire.
Quand ça arrive, c’est facile de rejeter la faute sur l’hébergeur ou sur la migration elle-même. Mais le plus souvent, la vraie cause, c’est le DNS (pas parce qu’il est défectueux, mais parce qu’il fait exactement ce pour quoi il a été conçu).
Les mises à jour DNS ne se font pas toutes en même temps. Elles dépendent de plusieurs niveaux de mise en cache et de résolveurs en dehors de votre environnement d’hébergement, c’est pourquoi les migrations peuvent sembler imprévisibles même lorsque le site est prêt.
Ce guide explique ce que le DNS contrôle réellement, pourquoi la propagation se comporte différemment selon les personnes, et comment planifier une migration pour que le DNS soit une dernière étape maîtrisée plutôt qu’une source de temps d’arrêt ou de confusion.
Ce que fait réellement le DNS
Le DNS répond à une question très précise : vers où ce domaine doit-il pointer ?
Quand quelqu’un saisit votre domaine dans un navigateur, le DNS traduit ce nom en une adresse IP. Cette adresse IP indique au navigateur vers quel serveur se connecter. Le DNS ne charge pas les pages et ne se soucie pas de ce qui tourne sur le serveur. Il se contente de gérer la recherche.
Pour que cette recherche fonctionne de manière fiable, le DNS est divisé en plusieurs éléments distincts, chacun ayant un rôle bien défini.
- Registre de domaine : c’est auprès de votre registar que vous achetez et renouvelez votre domaine. Il n’héberge pas votre site et ne contrôle pas le trafic. Du point de vue du DNS, sa principale responsabilité est de pointer le domaine vers les bons serveurs de noms.
- Fournisseur DNS faisant autorité : c’est le service qui stocke vos enregistrements DNS et fournit la réponse finale lorsque l’Internet demande où votre domaine doit être résolu. Des fournisseurs comme Cloudflare ou votre plateforme d’hébergement remplissent souvent ce rôle.
- Serveurs de noms : les serveurs de noms indiquent à Internet quel fournisseur DNS fait autorité pour votre domaine. Ils ne contiennent pas eux-mêmes de données ni de configuration du site. Ils acheminent simplement les requêtes DNS vers le bon endroit.
- Enregistrements DNS (A, AAAA, CNAME) : ces enregistrements définissent où va le trafic. Les enregistrements A pointent un domaine vers une adresse IPv4, les enregistrements AAAA vers une adresse IPv6, et les enregistrements CNAME redirigent un domaine vers un autre.
Ensemble, ces enregistrements déterminent quel serveur les visiteurs atteignent lorsqu’ils chargent votre site.
Tout aussi important est ce que le DNS ne fait pas. Le DNS ne sert pas de fichiers, ne déplace pas de bases de données, ne synchronise pas de contenu et ne gère pas de certificats SSL. Il n’intervient jamais sur votre environnement d’hébergement.
Une fois cette limite clairement établie, le reste du processus de migration devient beaucoup plus facile à appréhender.
Ce qui change lors d’une migration de site et ce qui reste inchangé
L’une des raisons pour lesquelles le DNS suscite tant de confusion lors des migrations est que seule une petite partie de la configuration change réellement. Le reste reste exactement comme avant, même si le site lui-même est transféré vers un environnement entièrement nouveau.
Lors d’une migration de site classique, quelques éléments changent généralement.
- L’adresse IP change presque toujours, car le site se trouve désormais sur un serveur différent. C’est la mise à jour liée au DNS la plus courante et celle qui, en fin de compte, indique au trafic où aller.
- L’environnement d’hébergement change également. Cela inclut le serveur, l’infrastructure et la plateforme sur lesquels ton site est hébergé. Bien que cela affecte les performances et la stabilité, cela est distinct du DNS et doit être entièrement prêt avant toute mise à jour DNS.
- Dans de nombreux cas, certains enregistrements DNS spécifiques changent. Les enregistrements A ou AAAA sont mis à jour pour pointer vers la nouvelle adresse IP. Parfois, ce sont les enregistrements CNAME qui sont modifiés, selon la configuration du site.
En même temps, plusieurs éléments restent généralement inchangés.
- Le nom de domaine ne change pas. Les visiteurs continuent de saisir la même URL, et rien concernant l’adresse publique ne doit être mis à jour.
- Les serveurs de noms restent également les mêmes, sauf si vous changez intentionnellement de fournisseur DNS. La plupart des migrations ne nécessitent aucun changement de serveur de noms, même lorsque le fournisseur d’hébergement change.
C’est pourquoi le DNS est presque toujours la dernière étape d’une migration. vous construisez et vérifiez d’abord le nouvel environnement, puis vous mettez à jour le DNS une fois que tout est prêt à recevoir du trafic.
Considérer le DNS comme une étape finale plutôt que comme une tâche précoce réduit l’incertitude, limite l’exposition aux risques et permet d’éviter beaucoup plus facilement les temps d’arrêt.
La propagation DNS et pourquoi elle est imprévisible
La propagation DNS ne signifie pas qu’Internet « met à jour » votre domaine d’un seul coup. Elle décrit le temps nécessaire pour que les modifications DNS soient détectées, mises en cache et réutilisées sur de nombreux systèmes indépendants.
Quand quelqu’un visite votre site, sa requête ne va pas directement à votre fournisseur DNS à chaque fois. Elle passe généralement par un résolveur récursif, souvent géré par un FAI, un réseau d’entreprise ou un service public comme Google ou Cloudflare. Ce résolveur demande une réponse au fournisseur DNS faisant autorité, puis stocke le résultat pour une utilisation ultérieure.
Une fois qu’un résolveur a mis en cache une réponse DNS, il continue d’utiliser cette réponse jusqu’à l’expiration du cache. C’est là que l’imprévisibilité entre en jeu. Différents résolveurs mettent en cache les données DNS pour des durées variables. Certains respectent scrupuleusement les valeurs TTL. D’autres appliquent leurs propres limites ou réutilisent les données mises en cache plus longtemps que prévu.
De plus, les caches des navigateurs et des systèmes d’exploitation peuvent stocker les résultats DNS localement. Même si l’enregistrement DNS global a été mis à jour, l’appareil d’un utilisateur peut continuer à utiliser une réponse plus ancienne jusqu’à ce que le cache local soit vidé ou arrive à expiration.
Cette mise en cache à plusieurs niveaux explique pourquoi deux personnes situées à des endroits différents peuvent voir des versions différentes du même site au même moment. Un résolveur dispose de la nouvelle adresse IP. Un autre pointe toujours vers l’ancien serveur.
La règle courante des « 24 à 48 heures » simplifie à l’extrême ce qui se passe réellement. De nombreux utilisateurs voient les mises à jour en quelques minutes. D’autres peuvent ne pas les voir avant bien plus longtemps, selon le comportement de leur résolveur et de leurs caches locaux.
Le TTL et comment il aide à éviter les temps d’arrêt
Le TTL, ou Time to Live, contrôle la durée pendant laquelle les réponses DNS sont mises en cache avant qu’un résolveur ne demande de nouvelles informations. Ça ne force pas les mises à jour à se faire plus vite, mais ça limite la durée pendant laquelle des informations obsolètes peuvent être réutilisées.
Chaque enregistrement DNS a sa propre valeur TTL, mesurée en secondes. Si un enregistrement a un TTL de 300, les résolveurs peuvent réutiliser cette réponse pendant cinq minutes maximum avant de vérifier à nouveau. Un TTL de 86.400 permet une mise en cache pendant une journée entière.
C’est pourquoi il est important de réduire le TTL avant une migration. Si les résolveurs détiennent déjà des réponses DNS à courte durée de vie, ils se rafraîchissent plus fréquemment lorsque vous modifiez les enregistrements. Cela réduit la période pendant laquelle les visiteurs pourraient être redirigés vers l’ancien serveur après le changement.
Pour la plupart des migrations, un TTL compris entre 300 et 600 secondes offre un bon compromis. C’est suffisamment court pour limiter les délais de propagation sans imposer de charge inutile à l’infrastructure DNS.
Un TTL trop bas peut causer des problèmes. Des TTL extrêmement courts ne garantissent pas des mises à jour instantanées, et certains résolveurs ignorent les valeurs anormalement faibles. D’autres peuvent limiter le débit des requêtes ou se rabattre de toute façon sur les données mises en cache. Réduire le TTL à la dernière minute est une autre erreur courante. Si les caches contiennent déjà des enregistrements à longue durée de vie, la modification du TTL ne les affectera pas tant que ces caches n’auront pas expiré.
L’approche la plus sûre est de bien choisir le moment. Réduis le TTL au moins 24 heures avant la migration, vérifie que la nouvelle valeur est bien active, et ce n’est qu’alors que vous planifiez le changement DNS.
Un calendrier de migration DNS sans risque (étape par étape)
Une migration DNS sans heurts privilégie l’enchaînement des étapes plutôt que la rapidité. Lorsque chaque étape se déroule dans le bon ordre, le DNS devient un changement contrôlé plutôt qu’un jeu de devinettes. Voici comment procéder pour réussir :
1. Préparer le nouvel environnement d’hébergement
Configurez entièrement le nouveau site avant de toucher au DNS. Cela inclut l’installation des dépendances, la configuration de la mise en cache, la mise en place des redirections et la vérification des performances.
Testez le site à l’aide d’une URL temporaire ou d’un fichier hosts local afin de pouvoir le consulter comme si le DNS pointait déjà vers le nouveau serveur. Assure-toi que les certificats SSL sont prêts et valides, surtout si le HTTPS est obligatoire. Le DNS ne doit jamais être l’étape où vous découvrez des problèmes de configuration.
Vous pouvez facilement modifier les informations DNS dans MyKinsta en vous rendant sur votre tableau de bord, en cliquant sur DNS puis sur Ajouter votre premier nom de domaine.
2. Réduire le TTL à l’avance
Réduisez les valeurs TTL des enregistrements DNS concernés bien avant la migration. Idéalement, faîtes-le au moins 24 heures avant le changement prévu.
Après avoir modifié le TTL, vérifiez que la nouvelle valeur est bien effective à l’aide d’outils de recherche DNS. Cela garantit que les résolveurs commencent à mettre en cache des réponses à durée de vie plus courte avant que tout changement d’IP n’ait lieu.
3. Geler les modifications risquées
Suspendez les modifications de contenu, les commandes e-commerce et les soumissions de formulaires si le site s’appuie sur une seule base de données. Le DNS ne transfère pas les données, donc les modifications apportées à l’ancien site après le snapshot de migration peuvent être perdues.
La plupart des problèmes liés aux données lors d’une migration proviennent d’écritures qui se chevauchent, pas de retards DNS. Geler les modifications élimine ce risque.
4. Mettre à jour les enregistrements DNS
Modifiez uniquement les enregistrements qui doivent être mis à jour, généralement les enregistrements A, AAAA ou CNAME pointant vers le site. Évitez de modifier des enregistrements non concernés pendant cette même fenêtre. Vous pouvez également ajuster ces informations dans MyKinsta. Sur la même page DNS que précédemment, faîtes défiler vers le bas jusqu’aux enregistrements DNS et sélectionnez Ajouter un enregistrement DNS pour ajouter ces informations manuellement.
Vérifiez bien les adresses IP, les types d’enregistrements et les noms d’hôte pour éviter les conflits. Une fois la mise à jour effectuée, vérifiez les modifications à l’aide de requêtes DNS directes plutôt qu’en vous contentant de tester via le navigateur.
Vous pouvez également effectuer une analyse automatique des enregistrements DNS en cliquant sur « Démarrer l’analyse » sous « Analyse automatique ».
5. Surveiller la propagation en temps réel
Suivez la résolution DNS depuis plusieurs régions pour confirmer que le trafic atteint bien le nouveau serveur. Attendez-toi à des résultats mitigés pendant le déploiement. C’est normal.
Le succès ne signifie pas que tout le monde se met à jour instantanément. Ça signifie que le nouveau trafic est systématiquement redirigé vers la bonne destination, sans erreur ni interruption.
Suivre cette séquence permet de garder le DNS prévisible. Chaque étape limite les risques, réduit l’incertitude et prévient les temps d’arrêt causés par des changements précipités ou qui se chevauchent.
D’où viennent généralement les temps d’arrêt et comment les éviter
Quand une interruption survient pendant une migration, on accuse souvent le DNS. En pratique, la cause profonde se trouve généralement ailleurs.
Les problèmes de DNS ont tendance à être simples et binaires : un enregistrement pointe vers le bon endroit ou pas. La plupart des pannes proviennent de décalages entre le DNS, l’hébergement et l’application elle-même.
- Une erreur d’adresse IP est un point de défaillance courant. Une simple faute de frappe ou une valeur obsolète envoie le trafic vers le mauvais serveur, ce qui ressemble à une interruption de service même si le DNS fonctionne correctement.
- Des enregistrements DNS manquants ou incomplets provoquent des symptômes similaires. Les enregistrements de messagerie, les sous-domaines www ou les enregistrements de vérification sont parfois oubliés lors des modifications, ce qui entraîne des pannes partielles ou des dysfonctionnements.
- Le décalage SSL est une autre cause fréquente. Le DNS peut pointer vers le nouveau serveur, mais le certificat n’est pas installé ou ne couvre pas encore le bon domaine. Les navigateurs bloquent alors l’accès, ce que les utilisateurs perçoivent comme une panne.
- La mise en cache peut aussi vous jouer des tours. Le contenu mis en cache ou les redirections peuvent encore pointer vers l’ancien serveur après les mises à jour DNS, surtout si les proxies inversés ou les couches CDN ne sont pas alignés sur le nouvel environnement.
La méthode la plus fiable pour éviter ces problèmes est le chevauchement. Garde l’ancien et le nouvel environnement actifs en même temps, pleinement fonctionnels, jusqu’à ce que le trafic se soit clairement déplacé. Lorsque les deux serveurs peuvent traiter les requêtes en toute sécurité, la propagation DNS devient bien moins risquée.
Comment l’hébergement infogéré réduit les risques liés au DNS
L’hébergement infogéré peut réduire les risques liés à la migration en s’assurant que le nouvel environnement est parfaitement prêt avant les changements DNS. La plupart des plateformes gérées fournissent des URL de staging ou temporaires, des piles de serveurs préconfigurées et des vérifications de compatibilité SSL, afin que le nouveau site puisse être testé de bout en bout pendant que l’ancien site continue de servir les visiteurs.
L’assistance à la migration joue également un rôle. Des équipes expérimentées valident les enregistrements DNS, confirment les attributions d’IP et surveillent les erreurs de configuration courantes qui provoquent des pannes. Au lieu de deviner si un problème se situe au niveau du DNS, du SSL ou de l’application, les problèmes sont identifiés et résolus plus tôt dans le processus.
Kinsta organise les migrations de manière à ce que le chevauchement des environnements soit la norme. L’ancien site continue de gérer le trafic pendant que le nouveau site est préparé et vérifié. Lorsque les mises à jour DNS ont lieu, les deux côtés sont prêts à traiter les requêtes.
Les mythes sur le DNS qui provoquent une panique inutile
Une grande partie du stress lié à la migration provient d’idées sur le DNS qui semblent raisonnables mais qui sont inexactes. Clarifier ces points permet de réagir plus sereinement lorsque les mises à jour ne se font pas instantanément.
« Les changements DNS sont instantanés. »
Les mises à jour DNS ne se propagent pas sur Internet en temps réel. Elles sont prises en compte à mesure que les caches expirent et que les résolveurs actualisent leurs données. Même une modification parfaitement configurée se déploie progressivement.
« Si le site est en panne, c’est que le DNS ne fonctionne pas. »
La plupart des temps d’arrêt liés à la migration ne sont pas du tout causés par le DNS. Les erreurs SSL, les erreurs de configuration des serveurs ou les problèmes d’application sont souvent perçus comme des pannes de DNS, car les utilisateurs ne parviennent pas à charger le site.
« Vider le cache résout le problème de propagation. »
Vider le cache du navigateur peut aider un utilisateur à voir le nouveau site, mais ça ne change pas ce que les résolveurs ou les FAI ont mis en cache. La propagation se fait selon leur calendrier, pas le tien.
« Il faut changer les serveurs de noms à chaque migration. »
Les changements de serveurs de noms ne sont nécessaires que lors du changement de fournisseur DNS. La plupart des migrations de sites fonctionnent parfaitement sans toucher aux serveurs de noms.
Si vous devez effectuer des changements, vous pouvez accéder aux serveurs de noms Kinsta dans MyKinsta sous DNS > Modifier les serveurs de noms chez votre registraire.
Le DNS se comporte rarement de manière imprévisible parce qu’il est défectueux. Il se comporte de manière prévisible selon des règles faciles à mal interpréter. Connaître ces règles élimine une grande partie de la panique qui entoure les migrations.
Check-list post-migration : que faire une fois que le DNS est opérationnel
Une fois les modifications DNS en place, le travail n’est pas terminé. L’objectif est désormais de confirmer que le trafic atteint bien le nouvel environnement et que rien ne plante en silence en arrière-plan.
- Commencez par vérifier que le trafic arrive bien sur le nouveau serveur : consultez les journaux du serveur, les analyses ou les tableaux de bord d’hébergement pour vous assurer que les requêtes arrivent à la bonne adresse IP et dans le bon environnement. Un trafic mixte est normal au début, mais il devrait progressivement se diriger entièrement vers le nouveau site.
- Vérifiez le SSL et les redirections : assurez-vous que les certificats sont valides pour tous les domaines attendus et que les redirections HTTP vers HTTPS et les redirections héritées fonctionnent comme prévu. Les erreurs de certificat ou les boucles de redirection n’apparaissent souvent qu’une fois que le trafic réel arrive.
- Surveillez les journaux et les taux d’erreur : soyez attentif aux pics de 404, d’erreurs 500 ou de requêtes bloquées. Ces signaux révèlent souvent des problèmes de configuration qui n’étaient pas visibles pendant les tests.
- Une fois le trafic stabilisé, rétablissez les valeurs TTL normales : des TTL plus longues réduisent le volume de requêtes DNS et améliorent l’efficacité du résolveur. Cette étape est souvent oubliée, mais elle est importante pour la stabilité à long terme.
- Supprimez les environnements hérités en toute sécurité : n’éteignez pas l’ancien serveur tant que vous n’êtes pas sûr qu’il ne reçoit plus de trafic significatif. Une courte période de chevauchement empêche les défaillances marginales de se transformer en pannes.
Cette dernière étape transforme une mise à jour DNS réussie en une migration propre et stable.
Les temps d’arrêt pendant la migration sont généralement facultatifs
Les temps d’arrêt pendant une migration de site sont généralement le résultat de changements précipités, de chevauchements de responsabilités ou du fait de considérer le DNS comme quelque chose qui doit être « réparé » sous pression.
Les migrations les plus sûres privilégient la préparation plutôt que la rapidité. L’hébergement, la configuration des applications et le SSL sont validés en premier. Le DNS est mis à jour en dernier, avec des attentes réalistes concernant la propagation et la mise en cache.
Avec un workflow et un support adaptés, les migrations de sites n’ont pas besoin d’être stressantes ou risquées. Et lorsque les changements DNS interviennent sur un environnement stable et géré, comme les services d’hébergement infogérés fournis par Kinsta, les temps d’arrêt appartiennent au passé.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
