Le commercial promet une migration week-end « sans coupure ». Le TTL de l'enregistrement A est encore à 86400 depuis des années. Vendredi 18 h : nouvelle adresse IP activée dans la zone. Samedi midi : 40 % du trafic sur l'ancien hébergeur, 60 % sur le nouveau — sessions cassées, webhooks partenaires moitié sur chaque IP. Le support parle de « propagation DNS lente » — en réalité, TTL non préparé.
Le TTL (Time To Live) indique aux résolveurs combien de temps mettre en cache votre réponse DNS. Migrer sans gestion du TTL, c'est promettre l'instantané alors que la physique du cache impose d'attendre l'ancien TTL partout.
Cycle de migration conscient du TTL
- J-7 à J-2 : baisser le TTL à 300 s sur les enregistrements A/AAAA/CNAME migrés.
- Attendre l'ancien TTL maximum (souvent 24 h si valeur 86400).
- Préparer la nouvelle origine (sync contenu, certificat TLS, tests via fichier hosts).
- Cutover : changer IP ou CNAME vers la nouvelle origine.
- Surveiller le trafic mixte deux à vingt-quatre heures.
- J+7 : remonter le TTL à une valeur modérée (3600) si souhaité.
| TTL avant | Attente min avant cutover | Fenêtre mixte typique |
|---|---|---|
| 86400 (24 h) | 24 h | jusqu'à 24 h |
| 3600 (1 h) | 1 h | 1–4 h |
| 300 (5 min) | 5–15 min | 15–60 min |
Baisser le TTL le jour J ne raccourcit pas ce qui est déjà en cache ailleurs.
Apex, www et courriels
www : CNAME vers nouveau load balancer — relativement simple.
Apex @ : ALIAS du fournisseur ou enregistrement A — pas de CNAME RFC sur apex nu.
MX : migrer le mail séparément — TTL MX bas si changement ; risque de perte de messages si oublié.
Documentez la différence entre TTL minimum SOA et TTL des enregistrements — confusion fréquente en migration.
Tests avant cutover public
Le fichier /etc/hosts ou curl --resolve permet de tester la nouvelle origine sans toucher au DNS public.
Checklist : certificat valide sur le nouveau host, sessions externalisées, webhooks avec nouvelle IP autorisée.
Dual-run : ancien et nouveau en parallèle avec monitoring comparant le taux d'erreur.
Pour le contexte DNS général, voir DNS pour débutants.
Communication aux parties prenantes
Une migration mal annoncée génère des tickets « le site ne marche pas chez moi » alors que le DNS progresse normalement. Prévenez l'équipe support, les partenaires avec webhooks et les clients B2B avant le cutover — avec une fenêtre honnête, pas une promesse d'instantané.
Une page de statut interne ou externe pendant la bascule évite que chaque résolveur lent soit interprété comme une panne totale. Briefez le support : « vider le cache DNS » côté client ne résout pas un TTL de 86400 encore actif chez un FAI tiers.
Documentez l'ancienne et la nouvelle IP, la date/heure du cutover et le contact technique chez l'hébergeur — utile si un partenaire doit whitelister la nouvelle origine sous quarante-huit heures.
Le sommet : migration « instantanée » vendue, TTL oublié
Voici ce qu'aucun outil ne peut promettre.
Préparer une migration = chronologie TTL + tests hosts + plan apex/MX — pas seulement upload des fichiers sur le nouveau VPS.
Décider et avancer sans angle mort
Avant le week-end de bascule :
- Baissez le TTL à 300 s quarante-huit heures minimum avant le jour J.
- Testez la résolution depuis plusieurs résolveurs publics et le FAI local.
- Exécutez le cutover avec monitoring actif sur les deux origines.
- Surveillez le pourcentage de trafic sur la nouvelle origine — objectif 95 % sous quatre heures si TTL préparé.
- Remontez le TTL une semaine après stabilisation.
- Traitez MX et apex dans un plan séparé du www si le mail est critique.
Comparez les hébergeurs et leurs outils DNS via l'annuaire et le comparateur.
Questions fréquentes
Combien de temps avant migration baisser le TTL ?
Au moins une fois l'ancien TTL maximum avant le jour J ; 300 secondes est une valeur courante pour les enregistrements migrés.
TTL 300 suffit-il toujours ?
Pour un cutover oui ; prévoyez tout de même une à vingt-quatre heures de trafic mixte selon les résolveurs.
Apex domain et migration ?
ALIAS ou enregistrement A — pas de CNAME classique sur l'apex. Plan distinct du sous-domaine www.
Comment vérifier propagation ?
dig depuis plusieurs résolveurs ; un flush local ne prouve rien pour le reste du monde.
Une migration DNS réussie se prépare dans le TTL — pas dans le discours du commercial.