Changer d'hébergeur sans coupure : le guide de migration
Par L'équipe Atlas Hoster5 min de lecture
Auditer l'existant avant de bouger
Changer d'hébergeur commence par un inventaire complet, pas par un déménagement. Listez ce que vous possédez : le site (fichiers et base de données), les comptes e-mail et leur contenu, les noms de domaine et leurs enregistrements DNS, les certificats SSL, et tout service annexe (sous-domaines, redirections, tâches planifiées). Notez aussi les identifiants d'accès et les contacts qui détiennent le domaine.
Cet audit révèle souvent des éléments oubliés : une ancienne adresse e-mail de relance, un sous-domaine de test, une redirection, un certificat à renouveler. Mieux vaut les découvrir avant la bascule qu'après, quand l'ancien hébergeur a déjà tout coupé. Consacrez à cet inventaire le temps nécessaire : c'est lui qui évite la plupart des pertes.
Choisir le bon moment
Une migration n'est jamais neutre pour un site en production. Choisissez une période de faible trafic, idéalement un week-end ou des heures creuses, et jamais en pleine campagne commerciale. Gardez sous la main les accès à l'ancien hébergeur : vous en aurez besoin jusqu'à la fin.
L'objectif n'est pas d'aller vite, mais de ne rien perdre. Une migration préparée se déroule en quelques heures ; une migration précipitée se paie en jours de dépannage. Si possible, planifiez aussi une procédure de repli : savoir revenir en arrière en cas de problème est aussi important que d'aller de l'avant. Prévenez en amont les parties prenantes (équipes internes, partenaires) qui pourraient être surprises par une éventuelle perturbation. Une communication claire évite les alertes inutiles le jour J.
DNS, e-mails, bases : ce qui doit suivre
Trois éléments doivent être transférés de manière coordonnée : le site, les e-mails et le DNS. Le DNS est l'annuaire qui indique où trouver votre domaine ; c'est lui qui oriente les visiteurs vers le bon serveur et les messages vers la bonne messagerie. Si vous oubliez les e-mails, votre site fonctionnera mais vos boîtes resteront vides. Si vous oubliez la base de données, votre site affichera une coquille vide.
Les enregistrements DNS sont mis en cache, et la durée de ce cache correspond au TTL (Time to Live). Un TTL long signifie qu'une modification met plus de temps à se propager partout. C'est pourquoi la bonne pratique consiste à baisser le TTL de vos enregistrements à l'avance, pour que la bascule se propage rapidement le moment venu. Consultez notre guide pour changer les DNS de votre domaine.
La bascule sans coupure
La bascule se prépare en plusieurs temps. D'abord, copiez vos fichiers et votre base de données vers le nouvel hébergeur pendant que l'ancien continue d'assurer le service. Testez ensuite le nouveau site en le prévisualisant localement ou via une URL temporaire, sans changer le DNS public. Une fois le nouveau site validé et le TTL préalablement abaissé, basculez le DNS vers le nouvel hébergeur.
Pendant la propagation, certains visiteurs verront encore l'ancien serveur et d'autres le nouveau. Pour éviter tout écart, gardez l'ancien site en ligne quelques jours, le temps que la propagation soit complète, puis coupez-le proprement. C'est ce chevauchement qui rend la transition transparente pour l'utilisateur final.
Vérifier après migration
Après la bascule, vérifiez méthodiquement : le site répond sur le nouveau serveur, le certificat SSL est valide, les formulaires et le paiement fonctionnent, les e-mails partent et arrivent, et les anciennes adresses restent accessibles. Testez depuis plusieurs réseaux et sur mobile.
Une vérification systématique transforme une migration réussie en migration confirmée. C'est aussi le moment de faire une sauvegarde complète du nouvel environnement, pour partir sur une base saine. Notez ce qui a été vérifié : en cas de doute ultérieur, vous saurez ce qui a déjà été contrôlé. Gardez cette liste de contrôle : elle servira aussi à la prochaine migration.
Changer d'hébergeur : les pièges à éviter
Les pièges les plus courants : oublier les e-mails dans le plan de migration, basculer sans avoir baissé le TTL à l'avance, couper l'ancien hébergement trop tôt, négliger de tester la restauration de la base, et ne pas vérifier le certificat SSL après coup. Un autre écueil classique est de perdre l'accès à l'ancien compte avant d'avoir tout récupéré.
Avant de commencer, faites une copie de sauvegarde de tout ce que vous déplacez : c'est votre filet de sécurité si la bascule rencontre un imprévu. Si vous transférez aussi votre nom de domaine, consultez notre guide sur le transfert de domaine.
Une migration bien menée ne se voit pas : vos visiteurs ne remarquent rien et vos données arrivent intactes. Pour choisir le bon point d'arrivée, lisez notre guide choisir un hébergement web, notre article sur le transfert de domaine et celui sur les SLA.
Atlas Hoster prend en charge la migration des fichiers, des bases et des e-mails depuis un cPanel existant ou tout autre hébergement : demandez un devis.
Le compte à rebours d'une migration
Pour résumer, une migration sans coupure suit toujours le même ordre :
- Inventorier et sauvegarder.
- Baisser le TTL des enregistrements DNS à l'avance.
- Copier les fichiers et la base sur le nouvel hébergeur, puis tester.
- Basculer le DNS, puis les enregistrements MX des e-mails.
- Vérifier le bon fonctionnement, puis résilier l'ancien service.
Gardez cette liste sous la main : elle rassure les parties prenantes et sert de trame à la migration. Si la bascule révèle un problème, un plan de repli vous permet de revenir en arrière en quelques minutes plutôt qu'en plusieurs jours.
FAQ
Combien de temps dure la propagation DNS ? Cela dépend du TTL de vos enregistrements et du cache des résolveurs. En baissant le TTL à l'avance, la bascule se propage en quelques minutes à quelques heures.
Mes e-mails risquent-ils d'être perdus pendant la migration ? Pas si vous créez les boîtes sur le nouvel hébergeur avant de basculer les enregistrements MX, et si vous gardez l'ancien service actif pendant la transition.
Puis-je migrer sans aucune coupure ? Oui, en préparant le nouvel environnement en parallèle et en ne basculant le DNS qu'une fois tout testé. Une courte fenêtre de propagation reste inévitable, mais elle n'interrompt pas le service.