Une migration d’hébergement se passe bien quand le nouveau serveur est prêt et testé avant que le domaine ne pointe dessus. La coupure vient presque toujours d’un oubli : la messagerie, un certificat, une tâche planifiée ou un délai DNS mal anticipé. Cette méthode suit l’ordre qui évite ces oublis.
Les points à retenir
- Faites l’inventaire de tout ce qui dépend de l’ancien hébergeur, messagerie et DNS compris, avant de copier quoi que ce soit.
- Testez le site sur le nouveau serveur avec le fichier hosts, avant de modifier le DNS.
- Baissez le TTL du DNS à l’avance et gardez l’ancien hébergement actif quelques jours après la bascule.
1. Faire l’inventaire
Notez la plateforme et sa version, la version de PHP, les extensions PHP nécessaires, la taille du site et de la base, ainsi que les tâches planifiées (cron). Repérez où se trouve la zone DNS du domaine : chez le registrar, chez l’ancien hébergeur ou chez un tiers comme Cloudflare. C’est là que se fera la bascule.
Vérifiez ensuite où est hébergée la messagerie. Si les adresses e-mail du domaine sont fournies par l’ancien hébergeur, résilier le compte coupe les e-mails. Conservez les enregistrements MX d’origine, ou migrez les boîtes séparément avec leur propre calendrier.
2. Préparer le nouvel environnement et copier le site
Sur le nouvel hébergement, installez une configuration équivalente : même version majeure de PHP (ou plus récente, après vérification des extensions), mêmes modules, mêmes limites de mémoire et de temps d’exécution. Copiez les fichiers par SFTP ou rsync, puis exportez la base de données et importez-la sur le nouveau serveur. Pour WordPress, des extensions comme Duplicator ou All-in-One WP Migration automatisent l’opération.
Mettez ensuite à jour les identifiants de base de données dans le fichier de configuration du site (wp-config.php pour WordPress), car ils sont propres à chaque hébergement.
- rsync -avz utilisateur@ancien-serveur:/chemin/du/site/ ./site/ : copie les fichiers en conservant les droits.
- mysqldump -u utilisateur -p nom_base > base.sql, puis mysql -u utilisateur -p nom_base < base.sql sur le nouveau serveur.
3. Tester avant de toucher au DNS
Le fichier hosts de votre ordinateur indique à votre navigateur que le nom de domaine correspond à l’adresse IP du nouveau serveur, sans rien changer pour les autres internautes. Ajoutez une ligne avec l’adresse IP donnée par le nouvel hébergeur.
Videz ensuite le cache du navigateur et parcourez le site : pages, formulaires, connexion à l’administration, images, redirections et certificat HTTPS. Supprimez la ligne ajoutée quand les tests sont terminés, sinon votre ordinateur continuera de pointer vers le nouveau serveur même si la bascule échoue.
- Ligne à ajouter : 203.0.113.10 exemple.fr www.exemple.fr (remplacez par l’adresse IP réelle et votre domaine).
- Linux et macOS : fichier /etc/hosts. Windows : C:\Windows\System32\drivers\etc\hosts, à modifier en administrateur.
4. Baisser le TTL du DNS avant la bascule
Le TTL (Time To Live) d’un enregistrement DNS indique pendant combien de secondes un résolveur peut garder sa valeur en mémoire. Avec un TTL de 86 400 secondes (24 heures), une partie des visiteurs continue d’être envoyée vers l’ancien serveur pendant une journée après votre changement.
Au moins aussi longtemps à l’avance que l’ancien TTL, passez celui des enregistrements A, AAAA et CNAME du site à une valeur basse, par exemple 300 secondes. Une fois la migration terminée et stable, vous pourrez le remonter pour réduire le nombre de requêtes DNS.
5. Basculer et contrôler
Choisissez un moment de faible trafic. Si le site reçoit des commandes ou des messages, passez l’ancien serveur en mode maintenance, faites une dernière copie de la base, importez-la sur le nouveau serveur, puis modifiez les enregistrements DNS. Sans ce dernier import, les commandes passées pendant la préparation n’existeraient que sur l’ancien serveur.
Le certificat HTTPS doit être prêt sur le nouveau serveur au moment de la bascule. Avec Let’s Encrypt, la validation par fichier exige que le domaine pointe déjà vers le serveur : demandez le certificat par validation DNS ou importez l’ancien. Contrôlez ensuite la propagation.
- dig +short exemple.fr : adresse renvoyée par votre résolveur habituel.
- dig +short exemple.fr @8.8.8.8 : adresse renvoyée par le résolveur public de Google.
- curl -I https://exemple.fr : affiche le code de réponse et échoue si le certificat n’est pas accepté.
6. Garder l’ancien hébergement quelques jours
Ne résiliez pas l’ancien hébergement le jour de la bascule. Gardez-le actif au moins aussi longtemps que l’ancien TTL, et plutôt quelques jours à deux semaines selon le site, le temps de découvrir un oubli : un fichier, une tâche planifiée, un e-mail. Laissez-y le site en mode maintenance ou en lecture seule pour qu’aucun message ni aucune commande ne s’y enregistre par erreur.
Surveillez ensuite le nouveau serveur pendant quelques jours : journaux d’erreurs, réception des e-mails du formulaire, exécution des tâches planifiées, rapport d’indexation dans Search Console. Remontez le TTL quand tout est stable.
Et pour votre site ?
Une migration préparée suit toujours le même fil : inventaire, copie, test, bascule, contrôle. Si vous envisagez un changement d’hébergeur, l’expertise hébergement de Serein peut reprendre cette liste avec vous avant toute décision.
Préparer une migration d’hébergement