Quick-Tutoriel.com Network & System Admin.
Une migration de site se prépare en une semaine et se joue en dix minutes : celles qui suivent le changement d’enregistrement DNS. Dans la plupart des incidents que nous traitons, le nouveau serveur était prêt. C’est la bascule qui ne l’était pas.
Voici les cinq contrôles que nous faisons systématiquement avant de toucher à une zone DNS. Aucun n’est spectaculaire ; tous évitent une soirée perdue.
Contrôle d’un serveur avant la bascule DNS.
1. Le TTL a été abaissé au moins 24 heures avant
C’est la première erreur, et la plus coûteuse. Un enregistrement A avec un TTL de 86 400 secondes reste en cache chez les résolveurs pendant une journée entière. Vous basculez à 14 h : une partie de vos visiteurs continue d’arriver sur l’ancien serveur jusqu’au lendemain, et les deux environnements divergent — commandes d’un côté, stock de l’autre.
La veille, passez le TTL à 300 secondes. Attendez l’expiration de l’ancien TTL. Puis basculez. Vous pourrez revenir en arrière en cinq minutes si nécessaire, et cette capacité de retour est ce qui distingue une migration d’un pari.
2. Le nouveau serveur répond au bon nom, pas seulement à son IP
Un serveur qui affiche votre site quand on l’appelle par son adresse IP ne prouve rien. Il faut tester avec le nom d’hôte réel : c’est ce que le navigateur enverra, et c’est ce que le serveur utilisera pour choisir le bon VirtualHost et le bon certificat.
La méthode de terrain reste le fichier hosts : une ligne, 203.0.113.10 www.monsite.fr, et votre poste voit le nouveau serveur sans que personne d’autre ne soit concerné. Attention à trois détails qui font perdre du temps : le nom avec et sans www sont deux entrées distinctes, le fichier n’accepte ni joker ni numéro de port, et il faut vider le cache DNS local après modification. La procédure complète, système par système, est détaillée dans notre guide du fichier hosts.
3. Le certificat TLS est en place et valide
Un certificat émis pour le mauvais nom, ou qui expire dans trois jours, transforme une bascule réussie en incident visible par tous. Deux points à contrôler : la chaîne complète (pas seulement le certificat feuille) et la présence du nom exact utilisé, www compris.
Testez depuis l’extérieur, pas depuis le serveur : openssl s_client -connect 203.0.113.10:443 -servername www.monsite.fr affiche la chaîne réellement servie, et un curl -I https://www.monsite.fr –resolve www.monsite.fr:443:203.0.113.10 vous donne le code de réponse sans toucher au DNS.
4. Les données sont à jour, pas seulement copiées
Un site, c’est un dossier de fichiers et une base. La copie des fichiers se fait souvent bien ; la base est le point faible. Trois questions à trancher avant la bascule :
Serveur dédié : la cible de la bascule.
- La base a-t-elle été exportée après l’arrêt des écritures, ou acceptez-vous de perdre les commandes passées entre-temps ?
- Les comptes, les tâches planifiées et les clés d’API pointent-ils vers le bon environnement ?
- Les envois de courriel partent-ils du nouveau serveur sans casser les enregistrements SPF et DKIM ?
Si le site prend des commandes, la bonne réponse est une fenêtre de maintenance courte, pas une synchronisation « à peu près ».
5. Le retour arrière est écrit
Avant de cliquer, écrivez les trois lignes de la procédure de retour : quel enregistrement remettre à quelle valeur, qui a les droits sur la zone, combien de temps avant que ce soit visible. Une migration sans plan de retour n’est pas une migration, c’est un engagement.
Le contrôle final : mesurer, pas supposer
Une fois la bascule faite, la question n’est pas « est-ce que ça marche chez moi » — votre cache local vous mentira — mais « est-ce que ça arrive chez les autres ». Les résolveurs publics ne se mettent pas à jour au même rythme : un vérificateur de propagation, qui interroge plusieurs résolveurs dans plusieurs régions, donne en une minute ce qu’un dig local ne dira jamais. C’est exactement le rôle de notre outil de suivi de propagation DNS.
Un dernier réflexe : ne supprimez pas l’ancien serveur avant 72 heures. Les enregistrements MX, les sous-domaines oubliés et les intégrations d’un partenaire se rappellent à vous au pire moment.
Bertrand Demarcq dirige DEMARCQ.NET, société d’infogérance de serveurs Linux fondée en 1996 : exploitation, sécurité, haute disponibilité et migrations pour des PME, e-commerçants et éditeurs de plateformes.
