La migration technique s’est déroulée sans le moindre problème apparent : nouveau serveur provisionné, site copié, base de données transférée, tests de fonctionnement validés, enregistrement DNS mis à jour vers la nouvelle IP en fin de matinée. Et pourtant, l’après-midi même, un client signale qu’il ne voit toujours pas les changements récents publiés sur son site, tandis qu’un collègue de la même agence, sur un autre réseau, les voit parfaitement.
Le diagnostic est presque toujours le même dans ce genre de situation : ce n’est pas la migration qui a échoué, c’est le TTL (Time To Live) de l’enregistrement DNS qui n’avait pas été abaissé suffisamment à l’avance. Ce détail, souvent négligé car invisible tant qu’il ne pose pas problème, explique à lui seul pourquoi une partie des visiteurs continue de charger l’ancien serveur pendant des heures après la bascule officielle.
Ce que représente concrètement le TTL
Chaque enregistrement DNS porte une valeur de TTL, exprimée en secondes, qui indique aux résolveurs DNS (ceux des fournisseurs d’accès, des box internet, des systèmes d’exploitation) combien de temps ils sont autorisés à conserver la réponse en mémoire cache avant de la revérifier auprès du serveur faisant autorité. Un TTL de 86400 secondes, soit 24 heures, signifie qu’un résolveur ayant interrogé le domaine juste avant la bascule peut continuer à répondre avec l’ancienne IP pendant une journée complète, sans jamais revérifier entre-temps.
exemple.fr. 86400 IN A 198.51.100.10 ; ancienne IP, TTL de 24h
Pourquoi ce délai varie autant d’un visiteur à l’autre
Le comportement réel dépend de plusieurs couches de cache empilées, chacune avec sa propre logique : le cache du système d’exploitation du visiteur, celui du résolveur DNS de son fournisseur d’accès, et parfois un cache supplémentaire au niveau de la box internet elle-même. Certains résolveurs respectent scrupuleusement le TTL annoncé, d’autres appliquent un TTL minimum ou maximum interne qui ignore partiellement la valeur d’origine, ce qui explique pourquoi deux visiteurs sur deux réseaux différents peuvent voir des résultats totalement différents au même instant.
| Type de résolveur | Comportement typique observé |
|---|---|
| Résolveur public (Google, Cloudflare) | Respecte généralement le TTL annoncé |
| Résolveur d’un FAI grand public | Peut appliquer un TTL minimum interne supérieur |
| Cache local du système d’exploitation | Variable selon la configuration |
La bonne séquence, plusieurs jours avant la migration
# J-3 : abaisser le TTL de l'enregistrement A à une valeur courte
exemple.fr. 300 IN A 198.51.100.10 ; ancienne IP, TTL abaissé à 5 minutes
# Jour J : une fois le nouveau serveur validé, changer l'IP
exemple.fr. 300 IN A 203.0.113.20 ; nouvelle IP, TTL toujours court
# J+3, une fois la bascule confirmée stable : remonter le TTL
exemple.fr. 86400 IN A 203.0.113.20 ; retour à un TTL longCe cycle en trois temps est la méthode qui aurait évité l’incident sur ce dossier : abaisser le TTL plusieurs jours avant la migration, le temps que l’ancien TTL long expire naturellement dans tous les caches existants, puis effectuer la bascule d’IP pendant que le TTL court est en vigueur, ce qui limite la propagation à quelques minutes plutôt qu’à une journée entière. Le TTL n’est remonté à sa valeur habituelle qu’une fois la nouvelle configuration confirmée stable.
Vérifier la propagation sans deviner
Plutôt que d’attendre des retours clients contradictoires, des outils de vérification DNS distribués permettent d’interroger simultanément des résolveurs situés dans différentes régions et chez différents fournisseurs, pour objectiver l’état réel de la propagation plutôt que de se fier à un seul test local qui peut donner une fausse impression de bascule complète.
- Interroger l’enregistrement depuis plusieurs résolveurs publics distincts (pas uniquement celui configuré sur la machine de test).
- Vérifier la valeur de TTL restante annoncée dans la réponse, pas seulement l’IP retournée.
- Garder les deux serveurs (ancien et nouveau) fonctionnels et synchronisés pendant toute la période de transition, pas seulement le nouveau.
Le TTL est le seul paramètre de la migration qui doit être modifié avant l’incident, jamais après : une fois qu’un résolveur a mis en cache une réponse pour 24 heures, aucune action côté serveur ne peut raccourcir ce délai a posteriori.
Garder les deux environnements vivants pendant la transition
Cette exigence de TTL court explique aussi pourquoi une migration bien menée ne coupe jamais l’ancien serveur le jour même de la bascule DNS : tant que la propagation n’est pas confirmée complète sur un échantillon représentatif de résolveurs, l’ancien serveur doit continuer à répondre normalement, avec des données synchronisées si possible, pour que les visiteurs encore orientés vers l’ancienne IP ne tombent pas sur un serveur éteint.
En résumé
Une migration de serveur techniquement parfaite peut malgré tout laisser une partie des visiteurs bloqués sur l’ancien site pendant des heures si le TTL DNS n’a pas été abaissé plusieurs jours à l’avance. Ce réglage, invisible tant qu’il ne cause pas de problème, mérite une ligne dédiée dans toute checklist de migration, bien avant le jour de la bascule elle-même.
