Migrer un site sans coupure : la procédure réelle, étape par étape
Changer un site d'hébergement sans coupure ne tient pas à un outil miracle, mais à un ordre d'opérations. Trois horloges différentes doivent être maîtrisées avant la bascule : la durée de vie des enregistrements DNS, la cohérence des données et la validité du certificat. Voici la séquence qui fonctionne, et les points où les migrations échouent en pratique.
Ce que veut dire sans coupure, et ce que cela ne veut pas dire
Sans coupure signifie qu'aucune requête d'un visiteur n'aboutit à une erreur pendant l'opération : la même adresse répond, avant comme après, avec un contenu valide et un certificat accepté par le navigateur. Cela ne veut pas dire que rien ne bouge : une courte fenêtre en lecture seule, un formulaire momentanément indisponible ou un délai de quelques minutes sur une commande sont acceptables si le visiteur ne rencontre pas de page d'erreur, et si le site annonce la gêne à l'avance.
Trois mécanismes ont chacun leur propre temps de réaction. Les enregistrements DNS restent en cache chez les résolveurs pendant la durée de vie annoncée, le certificat TLS doit être émis pour le nouveau serveur avant que le trafic n'arrive, et les données doivent être copiées puis synchronisées jusqu'à l'instant de la bascule. Une migration se prépare donc en jours, pas en heures : la partie technique de la bascule dure quelques minutes, la préparation prend plusieurs jours.
Baisser le TTL avant tout le reste
Le TTL d'un enregistrement est un entier de 32 bits exprimé en secondes, qui indique combien de temps un résolveur peut garder la réponse en cache avant de la redemander (RFC 1035, glossaire TTL de MDN). Un TTL d'une journée signifie qu'un visiteur peut encore être envoyé vers l'ancien serveur vingt-quatre heures après la bascule. La première opération consiste donc à abaisser ce TTL, souvent à 300 secondes, puis à attendre au moins la durée de l'ancien TTL avant de toucher aux adresses.
Cette attente n'est pas une garantie absolue. La recommandation RFC 8767 autorise un résolveur à servir des données périmées lorsque les serveurs faisant autorité sont injoignables, et suggère un plafond de sept jours. Un résolveur qui applique ce mécanisme peut donc répondre avec l'ancienne adresse au-delà du TTL annoncé. En pratique, on garde l'ancien hébergement en service, avec son certificat valide, pendant plusieurs jours après la bascule : c'est la seule protection contre les caches qui traînent.
Copier les données sans perdre les écritures
Un site vitrine se copie comme un dossier ; un site avec une base de données se copie comme un ensemble cohérent. Exporter une base pendant que les visiteurs écrivent produit un instantané partiel : commandes à moitié enregistrées, contenus liés à des fichiers qui ne sont pas encore copiés. Les moteurs transactionnels permettent un export cohérent en une seule transaction, ce que documente l'option single-transaction de mysqldump dans la base de connaissances MariaDB comme dans le manuel MySQL.
La copie se fait en deux temps. D'abord une copie complète à froid ou à chaud, sans interrompre le service, pendant que l'ancien serveur continue de répondre. Ensuite un delta : les fichiers modifiés depuis le début de la copie et les écritures en base survenues entre-temps, appliqués pendant une courte fenêtre où le site passe en lecture seule. Cette fenêtre se mesure en minutes, pas en heures, et se prépare à l'avance avec un script testé sur un environnement de recette.
Avoir le certificat avant de basculer
Un certificat ne s'obtient pas en une seconde au moment de la bascule. La validation HTTP-01 de Let's Encrypt impose de servir un jeton sur le port 80 de l'adresse pointée par le nom, et le client ACME suit les redirections jusqu'à dix niveaux, uniquement vers http ou https sur les ports 80 et 443, sans vérifier le certificat rencontré en chemin (documentation officielle des types de validation). Tant que le DNS pointe vers l'ancien serveur, c'est lui qui répond à la validation.
Deux méthodes évitent ce piège. La première consiste à utiliser une validation DNS-01, qui ne passe pas par le serveur web et peut donc être réalisée avant la bascule. La seconde consiste à préparer le certificat sur le nouveau serveur avec une validation HTTP effectuée depuis l'ancien, par redirection temporaire du chemin de validation. Dans les deux cas, le certificat et sa chaîne complète sont en place et testés avant que la première requête de visiteur n'arrive sur la nouvelle machine.
Tester le nouveau serveur sans toucher au DNS
Il est inutile de modifier le DNS pour vérifier que le nouveau serveur répond correctement. L'outil en ligne de commande curl accepte l'option resolve, qui force la résolution d'un nom et d'un port vers une adresse donnée sans passer par le résolveur système : la requête part vers la nouvelle machine, avec le nom d'origine, donc avec le bon hôte virtuel et le bon certificat. C'est le contrôle le plus proche de la réalité avant la bascule.
La vérification porte sur autre chose que la page d'accueil. On contrôle les redirections, les en-têtes de sécurité, la chaîne de certificat, l'accès aux fichiers statiques, le fonctionnement des formulaires et l'authentification. On compare aussi les tailles de page et les codes de réponse avec l'ancien serveur, page par page, à partir du plan du site. Un site qui répond en 200 sur sa page d'accueil mais en 404 sur ses articles n'est pas prêt.
La bascule : l'ordre des opérations compte
La bascule commence par le gel des écritures et le delta de données, se poursuit par le changement de l'enregistrement A vers la nouvelle adresse, et se termine par le contrôle depuis plusieurs résolveurs. On ne supprime rien sur l'ancien serveur à ce moment : il reste en place, répond encore, et sert de filet. Son certificat doit rester valide et son contenu ne doit pas être modifié, sinon un visiteur encore dirigé vers lui verrait une version différente du site.
Pendant les heures qui suivent, on surveille les journaux des deux machines et on compare le nombre de requêtes reçues de part et d'autre : tant que l'ancien serveur reçoit du trafic, une partie des résolveurs n'a pas encore pris le changement. Le TTL reste bas jusqu'à ce que ce trafic retombe à un niveau négligeable, puis on le remonte pour ne pas imposer une résolution fréquente à tous les visiteurs.
Ce qui casse encore après la bascule
Les pannes de migration les plus fréquentes ne concernent pas le site lui-même. Les tâches planifiées restées sur l'ancien serveur continuent d'écrire dans une base qui n'est plus celle du site ; les chemins absolus inscrits dans un fichier de configuration désignent des dossiers qui n'existent pas sur la nouvelle machine ; les règles de réécriture propres à un serveur web ne sont pas reprises par un autre ; les extensions absentes d'une version de PHP changent le comportement d'un formulaire.
La messagerie mérite une vérification séparée : les enregistrements MX, les mécanismes d'authentification des envois et les comptes eux-mêmes ne suivent pas la migration du site. Un site migré dont le formulaire de contact n'envoie plus rien reste en ligne mais perd ses demandes. Enfin, les listes d'adresses IP autorisées dans un pare-feu ou dans une interface d'administration doivent être mises à jour avec l'adresse de la nouvelle machine, sinon les accès techniques se ferment au moment même où on en a besoin.
Le retour arrière et la clôture
Un retour arrière se prépare avant la bascule, pas pendant l'incident. Sa forme la plus simple reste la modification de l'enregistrement A vers l'ancienne adresse, possible en quelques minutes tant que le TTL est bas et que l'ancien serveur a conservé sa copie des données. Il faut donc savoir, à tout moment, à quelle heure remonte la dernière copie utilisable et ce que le site aurait perdu si l'on repartait de là.
La clôture se fait par écrit : date et heure de la bascule, adresse des deux serveurs, durée du gel des écritures, contrôles effectués et leurs résultats, date prévue d'arrêt de l'ancien hébergement. Ce document évite la question la plus coûteuse, celle qui revient trois mois plus tard : cette sauvegarde que personne n'a supprimée, contient-elle encore la version en service, ou l'ancienne ?