TTL 300

Niveau intermédiaire

Transférer un site sans une minute de coupure : le déroulé heure par heure

Une migration se joue sur le DNS. La préparation la veille, l'ordre des opérations le jour J, et la bascule invisible pour vos visiteurs.

Copier les fichiers et la base de données est la partie facile d'une migration. Ce qui casse un transfert, c'est le moment de bascule : pendant quelques heures, une partie de vos visiteurs atterrit sur l'ancien serveur, l'autre sur le nouveau. Si les deux sont vivants et acceptent des données, vous perdez des commandes et des messages sans jamais le savoir.

La méthode ci-dessous supprime ce trou. Elle repose entièrement sur le TTL, et elle se prépare la veille.

J moins 2 : abaisser le TTL

C'est l'étape que tout le monde saute, et la seule qui rende la bascule instantanée.

Dans la zone DNS actuelle, passez le TTL des enregistrements concernés (A, AAAA, les CNAME du site, et les MX si le courrier bouge aussi) à 300 secondes.

Ne changez rien d'autre. Puis attendez la durée de l'ancien TTL, en entier. Si votre TTL était à 86400, il faut vraiment attendre une journée : les caches détiennent encore l'ancienne valeur avec l'ancienne durée, et rien ne peut accélérer ça.

À la fin de cette attente, tous les résolveurs du monde savent qu'ils doivent revérifier votre domaine toutes les cinq minutes. Vous avez acheté votre bascule instantanée.

J moins 1 : monter le nouveau site et le tester par l'IP

Installez fichiers et base sur le nouvel hébergeur, sans toucher au DNS.

Pour le tester avant la bascule, modifiez le fichier hosts de votre machine : il court-circuite le DNS pour vous seul.

# Windows : C:\Windows\System32\drivers\etc\hosts
# macOS et Linux : /etc/hosts
203.0.113.10   votredomaine.fr www.votredomaine.fr

Vous naviguez alors sur le nouveau serveur avec le vrai nom de domaine, pendant que le reste du monde reste sur l'ancien. C'est le seul moyen de vérifier les liens absolus, les certificats et les chemins d'images sans rien casser.

Testez le formulaire de contact et le tunnel de commande à ce moment-là. Une base migrée dont les identifiants sont restés ceux de l'ancien serveur ne se voit qu'en essayant d'écrire dedans.

Jour J : passer l'ancien serveur en lecture seule

Avant de toucher au DNS, empêchez l'ancien site d'accepter la moindre écriture. Sinon, pendant la période de bascule, une commande passée par un visiteur encore dirigé vers l'ancien serveur atterrira dans une base que vous n'emporterez pas.

Selon la plateforme : mode maintenance, désactivation du tunnel de commande, ou fermeture des formulaires. Puis faites la dernière synchronisation de la base, celle qui compte.

Jour J : la bascule

Changez l'enregistrement A vers la nouvelle IP. Avec un TTL à 300, la modification est visible partout en cinq minutes.

Vérifiez sans attendre, en interrogeant deux résolveurs publics :

nslookup votredomaine.fr 1.1.1.1
nslookup votredomaine.fr 8.8.8.8

S'ils rendent tous deux la nouvelle adresse, c'est fait.

Jour J plus 1 : le certificat, puis le TTL

Le certificat HTTPS se génère après la bascule, jamais avant : l'autorité de certification vérifie que le domaine pointe bien vers le serveur qui demande le certificat. Tant que le DNS n'a pas basculé, la demande échoue, et c'est normal.

Une fois le site stable, remontez le TTL à 3600 ou plus.

Ne débranchez pas l'ancien serveur tout de suite

Gardez-le allumé une semaine, en lecture seule. Deux raisons concrètes : quelques caches exotiques traînent au-delà de toute logique, et surtout, c'est votre porte de retour si un problème apparaît au troisième jour.

Un ancien serveur résilié le soir même est la décision qu'on regrette le plus.

L'ordre, en une ligne

TTL bas, site monté et testé par hosts, ancien site en lecture seule, dernière synchro, bascule DNS, certificat, TTL remonté, ancien serveur gardé une semaine.

Chaque étape sautée se paie en données perdues, pas en temps gagné. Si vous préférez confier la bascule, c'est ce que je fais à partir de 59 €, sans coupure et avec le retour arrière préparé.