# La valeur DNS à baisser deux jours avant le déménagement

> Baisser le TTL à 300 secondes ne sert qu'une fois l'ancienne valeur expirée : calendrier de J-3 à J+2, vérification par dig et cas des serveurs de noms.


*Ou : le cache n'oublie que ce qu'on lui a permis d'oublier.*

La réponse courte : baissez le TTL des enregistrements que vous allez modifier, en général A, AAAA et MX, à 300 ou 600 secondes selon le minimum accepté par votre panneau, et faites-le au moins une ancienne valeur de TTL avant la bascule. Si le TTL actuel vaut 86 400 secondes, soit 24 heures, deux jours d'avance laissent une marge confortable ; Google, dans sa [page sur le changement d'hébergement](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes?hl=fr), conseille même de l'abaisser au moins une semaine avant. C'est le réglage qui rend [le déménagement de votre site](/guides/hebergement-web/changer-hebergeur-migration/) presque instantané pour les visiteurs.

La raison tient en une ligne : un résolveur qui a mis une réponse en cache avec l'ancien TTL la garde jusqu'au bout de ce délai, quoi que vous changiez ensuite. Baisser le TTL la veille revient à demander à quelqu'un qui a noté votre adresse pour 24 heures de la vérifier toutes les cinq minutes, mais seulement à partir de demain.

## TTL DNS avant une migration : le calendrier de J-3 à J+2

Le TTL, pour « Time To Live », est la durée en secondes pendant laquelle une réponse DNS peut rester en cache. Infomaniak le résume dans sa [FAQ sur le TTL et la propagation](https://www.infomaniak.com/fr/support/faq/2563/comprendre-le-ttl-et-temps-de-propagation?utm_term=67f2b039d38a3) : avec un TTL de 86 400 secondes, une modification ne prend effet qu'une fois ce délai écoulé. La même page prévient que certains fournisseurs d'accès ignorent parfois le TTL et gardent les informations plus longtemps. Le calendrier ci-dessous suppose un ancien TTL d'un jour au plus.

| Moment | Action | Vérification |
|---|---|---|
| J-3 | Relever le TTL actuel des enregistrements A, AAAA, MX et du `www` ; le baisser à 300 ou 600 secondes | Le serveur qui fait autorité renvoie la nouvelle valeur |
| J-2 et J-1 | Laisser expirer l'ancien TTL ; finir la copie et les tests | Un résolveur public renvoie un TTL de 300 ou 600 au plus |
| J | Modifier les enregistrements A et AAAA, puis MX si les mails déménagent | Le résolveur public renvoie la nouvelle adresse dans les minutes qui suivent |
| J+1 | Surveiller les journaux de l'ancien serveur ; synchroniser une dernière fois les mails | Le trafic de l'ancien serveur tend vers zéro |
| J+2 | Remonter le TTL à la valeur par défaut de votre hébergeur DNS | Moins de requêtes vers les serveurs de noms |

Si l'ancien TTL dépasse un jour, décalez le premier jalon d'autant. Le TTL ne s'applique qu'aux enregistrements que vous touchez : inutile de baisser celui d'un enregistrement TXT qui ne bouge pas.

### La vérification par dig, avant de croire le panneau

Un panneau d'administration affiche ce que vous avez saisi, pas ce que le monde voit. La commande `dig`, disponible sous macOS et Linux, montre le TTL dans la deuxième colonne de la réponse :

```bash
# La valeur publiée par le serveur qui fait autorité sur la zone
dig +noall +answer exemple.be A @ns1.votre-hebergeur-dns.example

# Le TTL restant dans le cache d'un résolveur public, qui décroît à chaque appel
dig +noall +answer exemple.be A @1.1.1.1
```

Le premier appel doit renvoyer 300 dès que la zone est enregistrée. Le second renvoie le temps qu'il reste au résolveur avant de redemander : s'il affiche encore une valeur de l'ordre de 80 000, le cache date d'avant votre réglage, et la bascule attendra. Le jour J, répétez le second appel : une fois la zone publiée par le serveur qui fait autorité, la nouvelle adresse doit apparaître dans les cinq ou dix minutes.

![Illustration : une rangée de bougies éteintes de hauteurs décroissantes, dont une seule brûle encore](/images/baisser-ttl-avant-migration-bougies.original.webp "Chaque cache garde sa réponse jusqu'à la fin de son TTL : baisser la valeur la veille ne rallume rien.")

Une bascule réussie se prépare aussi côté site. Le TTL baissé ne sert à rien si la copie n'a pas été vérifiée, et l'ordre logique consiste à tester d'abord par le fichier hosts ou l'adresse temporaire, puis à basculer. La méthode est décrite dans [le test du site migré avant le changement DNS](/guides/hebergement-web/changer-hebergeur-migration/tester-site-avant-bascule-dns/).

### Les MX, l'enregistrement qu'on oublie de préparer

Le site n'est pas seul à déménager. Si les boîtes mail changent aussi d'hébergeur, l'enregistrement MX, qui désigne le serveur recevant le courrier, suit le même calendrier : TTL baissé à J-3, modification le jour J. Pendant la propagation, une partie des messages arrive encore sur l'ancien serveur, d'où la synchronisation finale de J+1. L'ordre entre copie des boîtes, bascule des MX et dernière synchronisation est détaillé dans [la migration des e-mails sans perte](/guides/hebergement-web/changer-hebergeur-migration/migrer-boites-mail-sans-perte/).

### Les serveurs de noms, le délai que vous ne réglez pas

Changer les serveurs de noms du domaine, plutôt que quelques enregistrements, déplace toute la zone chez le nouvel hébergeur. Cette fois, le TTL qui compte n'est pas le vôtre : c'est celui de la délégation, fixé par le registre de l'extension. Relevé le 12 novembre 2026 avec `dig` sur les serveurs de chaque registre, pour un domaine de chaque extension, il valait 86 400 secondes pour le .be et le .eu, 3 600 secondes pour le .fr et le .ch, et 172 800 secondes, soit deux jours, pour le .com. L'Afnic indique, dans sa page sur [la gestion d'un nom de domaine](https://www.afnic.fr/noms-de-domaine/tout-savoir/gerer-son-nom-de-domaine/), qu'un tel changement, pour un .fr, est totalement propagé en une dizaine d'heures en moyenne. Pendant ce temps, les anciens serveurs de noms doivent continuer à répondre, ce qui suppose que l'ancienne zone existe encore. Le choix entre modifier les enregistrements et changer les serveurs de noms est expliqué dans [la conservation du domaine en changeant d'hébergeur](/guides/hebergement-web/changer-hebergeur-migration/changer-hebergeur-garder-domaine/).


---

Cette page contient des liens d'affiliation. Si tu souscris via ces liens, je peux toucher une commission sans coût supplémentaire pour toi. Mon avis reste indépendant et s'appuie sur mon expérience de client de plusieurs hébergeurs, sur leur documentation officielle et sur les tarifs vérifiés à la date de rédaction.