Changer d'hébergeur fait souvent peur : peur de perdre des données, de casser le site, de couper les e-mails ou de chuter dans Google. Pourtant, une migration de site bien préparée se fait sans interruption visible pour les visiteurs. J'en ai réalisé de nombreuses, dont récemment le transfert complet de plusieurs dizaines de sites vers un nouveau serveur. Voici la méthode que j'applique.
Pourquoi changer d'hébergeur
Les raisons sont variées : performances insuffisantes, version de PHP dépassée, sécurité douteuse, support peu réactif, tarifs qui augmentent, ou simplement besoin d'un environnement plus moderne. Quelle que soit la motivation, la méthode reste la même.
Étape 1 : faire l'inventaire complet
Avant de déplacer quoi que ce soit, il faut savoir exactement ce que l'on déplace. Pour chaque site, je liste :
- Les fichiers du site et les fichiers envoyés par les utilisateurs (médias, documents) ;
- La ou les bases de données ;
- Les tâches planifiées qui tournent sur le serveur ;
- Les e-mails : boîtes, redirections, envois automatiques du site ;
- Les enregistrements DNS de la zone du domaine ;
- Les certificats, les accès protégés et les règles de redirection.
Étape 2 : préparer le nouvel environnement
Le nouveau serveur est configuré à l'identique de l'ancien sur les points qui comptent : version de PHP, extensions, réglages de mémoire, modules du serveur web. C'est aussi le moment d'améliorer ce qui doit l'être : sécurité, sauvegardes automatiques, surveillance.
Étape 3 : copier et tester avant la bascule
Je copie les fichiers et la base de données sur le nouveau serveur, puis je teste le site sans toucher au DNS, en forçant temporairement mon poste à interroger le nouveau serveur. On vérifie ainsi chaque page importante, les formulaires, l'espace d'administration et les paiements, pendant que les visiteurs continuent d'utiliser l'ancien site.
Cette étape est aussi l'occasion d'un contrôle de sécurité : lors de migrations, j'ai déjà découvert des fichiers malveillants cachés depuis des années sur d'anciens hébergements. Mieux vaut ne migrer que du code sain.
Étape 4 : réduire la durée de cache DNS
Quelques jours avant la bascule, je réduis la durée de mise en cache des enregistrements DNS. Ainsi, le jour J, le changement d'adresse est pris en compte en quelques minutes partout dans le monde, au lieu de plusieurs heures.
Étape 5 : la bascule
Le jour de la migration de site, je fais une dernière synchronisation des données qui ont changé depuis la copie, notamment la base de données, puis je modifie les enregistrements DNS. Pendant la courte période de transition, certains visiteurs arrivent encore sur l'ancien serveur : pour un site avec des commandes ou des inscriptions, on peut passer l'ancien site en lecture seule pendant ce laps de temps.
Étape 6 : vérifier après la migration
Une fois le DNS propagé, je contrôle les certificats HTTPS, l'envoi des e-mails, les tâches planifiées, les redirections et les journaux d'erreurs. Côté référencement, la Search Console de Google permet de vérifier qu'aucune erreur d'exploration n'apparaît dans les jours qui suivent. Une migration qui conserve les mêmes adresses n'a aucun impact négatif sur le SEO, et peut même l'améliorer si le nouveau serveur est plus rapide.
Étape 7 : conserver l'ancien hébergement quelque temps
Je recommande de garder l'ancien hébergement actif une à deux semaines après la bascule, le temps de s'assurer que rien n'a été oublié. Ce n'est qu'ensuite qu'on résilie, après une dernière sauvegarde complète archivée.
Mon conseil
Une migration de site réussie repose à 80 % sur la préparation. Ne la planifiez jamais un vendredi soir ni pendant votre période d'activité la plus forte, et exigez de votre prestataire un inventaire écrit et un plan de retour en arrière. Avec cette rigueur, changer d'hébergeur devient une formalité, et souvent l'occasion de gagner en vitesse et en sécurité.
