Une migration d'hébergement mal préparée se voit immédiatement : le site affiche une erreur pendant plusieurs heures, les emails rebondissent, et les visiteurs tombent parfois sur l'ancien contenu, parfois sur rien du tout. Pourtant, avec la bonne séquence d'opérations, il est possible de faire disparaître cette coupure aux yeux de vos visiteurs, même si techniquement plusieurs étapes se chevauchent en coulisses.
Pourquoi une migration « classique » provoque une coupure
L'erreur la plus fréquente consiste à couper l'ancien hébergement avant que le nouveau soit prêt, ou à changer les enregistrements DNS avant d'avoir vérifié que tout fonctionne sur la nouvelle machine. Entre le moment où l'ancien site s'arrête et celui où le nouveau devient pleinement accessible à tous les visiteurs, il existe une fenêtre où une partie du trafic atterrit nulle part. Cette fenêtre n'est pas obligatoire : elle est le résultat d'un ordre d'opérations mal pensé, pas d'une contrainte technique incontournable.
Faire cohabiter l'ancien et le nouvel hébergement
La bonne pratique consiste à copier l'intégralité du site (fichiers et base de données) vers le nouvel environnement sans toucher au site en production. Le nouveau site est alors testé via une adresse IP temporaire, un sous-domaine de test ou une modification locale du fichier hosts de votre ordinateur, qui permet de visualiser le résultat final sans que les autres visiteurs ne soient affectés. C'est le moment de vérifier les formulaires, les emails transactionnels, les certificats SSL et les performances, dans des conditions proches du réel.
Abaisser le TTL avant de toucher au DNS
Quelques jours avant la bascule, on réduit volontairement le TTL (la durée de mise en cache) des enregistrements DNS concernés, par exemple à 300 secondes. Cette précaution garantit que lorsque l'enregistrement sera réellement modifié, les résolveurs DNS à travers le monde rafraîchiront leur cache beaucoup plus vite qu'avec un TTL par défaut de plusieurs heures. C'est l'étape la plus souvent négligée, alors qu'elle conditionne la rapidité de toute la bascule.
La bascule : synchronisation finale puis changement DNS
Le jour J, une dernière synchronisation des fichiers et surtout de la base de données est effectuée pour capturer les commandes, commentaires ou inscriptions survenues depuis la copie initiale. Le DNS est alors modifié pour pointer vers le nouvel hébergement, mais l'ancien serveur reste actif et accessible pendant toute la fenêtre de propagation, généralement entre quelques minutes et quelques heures selon le TTL appliqué. Les deux versions coexistent un court moment, ce qui absorbe en douceur les visiteurs dont le résolveur DNS n'a pas encore rafraîchi son cache.
Le cas particulier des emails
Les enregistrements MX, qui dirigent les emails, suivent la même logique de TTL réduit et peuvent être basculés séparément des enregistrements du site, à un moment choisi en dehors des heures de forte activité. Garder temporairement l'ancienne messagerie active pendant la propagation évite tout email perdu entre les deux systèmes.
Une fois la bascule DNS effectuée et l'ancien serveur désactivé, quelques vérifications s'imposent avant de clore réellement le dossier. Ouvrez le site depuis plusieurs réseaux différents (connexion mobile, autre fournisseur d'accès) pour confirmer que la propagation est bien terminée partout, pas seulement depuis votre propre poste. Testez chaque formulaire, chaque intégration de paiement et chaque envoi d'email automatique, car ce sont les fonctions qui dépendent le plus souvent d'une configuration serveur précise, susceptible de différer légèrement de l'ancien environnement. Vérifiez également que le certificat SSL du nouveau serveur est actif et reconnu par les navigateurs, et que les éventuels webhooks ou intégrations tierces pointent vers la bonne adresse. Ce n'est qu'après ce contrôle complet, généralement réalisé entre 24 et 72 heures après la bascule, que l'ancien hébergement peut être résilié en toute sécurité, sans risque de perdre un accès de secours en cas de problème imprévu.
Combien de temps avant la bascule faut-il abaisser le TTL ?
Idéalement 24 à 48 heures avant la migration, pour que l'ancien TTL élevé ait fini de s'effacer des caches avant même que le changement réel n'intervienne.
Faut-il mettre le site en mode maintenance pendant la synchronisation finale ?
Seulement pendant les quelques minutes de la dernière copie de base de données, pour éviter qu'une commande ou un commentaire ne soit créé entre l'export et l'import. Le reste de la migration se déroule sans aucune interruption visible.
Chaque migration a ses particularités selon le CMS, le volume de données et la présence ou non d'une base de données active (e-commerce, formulaires). Si vous préparez un changement d'hébergeur, l'équipe de VSP TECH prend en charge cette méthode de bout en bout : demandez un devis ou passez par le formulaire de contact pour planifier la bascule vers un serveur VPS ou un hébergement partagé sans que vos visiteurs ne s'en rendent compte.
