Changer d’hébergeur, c’est copier les fichiers, les données et la messagerie d’un site web sur le serveur d’un nouvel hébergeur, les tester, puis faire pointer le nom de domaine vers ce serveur. Menée dans cet ordre, la migration de site web évite toute interruption de service et tout recul dans les moteurs de recherche.
- Ouvrir l’hébergement web chez le nouveau prestataire et garder l’ancien, qui reste le filet de secours.
- Transférer le site internet et ses données, puis le tester sur le nouveau serveur avant que le public y arrive.
- Abaisser le TTL du DNS quelques jours avant, basculer, surveiller une semaine, puis seulement résilier.
Pourquoi quitter son hébergeur actuel ?
Un changement d’hébergeur part presque toujours d’un service qui ne suit plus le site. Les motifs les plus courants tiennent en quelques catégories : des pages qui ralentissent quand le trafic monte, une bande passante ou un espace de stockage bridés, un support technique qui répond en plusieurs jours, une version de PHP ancienne que le prestataire tarde à mettre à jour, ou une hausse de tarif au renouvellement de l’offre. Un projet qui grandit en est un autre : une boutique en ligne n’a pas les besoins d’un site vitrine, et l’hébergement mutualisé choisi au lancement devient étroit. Le besoin peut aussi venir du stockage des données : un hébergeur situé hors de l’Union européenne complique le respect du RGPD pour un site qui collecte des informations sur ses clients.
Avant de partir, il vaut la peine de poser la question à l’hébergeur actuel. Un passage à une formule supérieure chez le même prestataire évite tout déménagement, et certains problèmes de lenteur viennent du site lui-même (extensions trop nombreuses, images lourdes, absence de cache) plutôt que du serveur. Si le diagnostic montre que la limite vient bien de l’infrastructure ou de la qualité de service, la migration se justifie, et la méthode décrite ici s’applique quelle que soit la taille du projet.
Un site confié à une agence web suit le même chemin, avec une étape de plus : vérifier qui détient les accès à l’hébergement, au domaine et à la gestion DNS. En pratique, il arrive que le compte soit au nom de l’agence ; demandez ces informations par écrit avant de lancer la migration, pour que le transfert ne dépende pas d’un tiers indisponible.
Choisir le nouvel hébergeur avant de toucher à l’ancien
Le prestataire d’arrivée se choisit d’après ce que le site utilise réellement, pas d’après la page d’accueil de l’offre. Relevez chez l’ancien hébergeur, généralement dans le panneau cPanel ou l’espace client, la version de PHP, les modules activés (GD, Imagick, intl, cURL), le moteur SQL et sa version, l’espace disque occupé et le nombre d’adresses de messagerie. Le nouvel environnement doit offrir au moins l’équivalent, sinon une partie du site cessera de fonctionner le jour de la bascule.
Trois points font gagner un temps précieux pendant la migration. Le premier est un outil de migration fourni par l’hébergeur : beaucoup proposent de migrer gratuitement un site WordPress ou une boîte mail depuis un autre prestataire, sur simple demande. Le deuxième est l’accès SSH, qui permet de copier et décompresser une archive en quelques minutes au lieu de transférer des milliers de fichiers un par un. Le troisième est la messagerie : certaines offres l’incluent, d’autres la facturent à part, ce qui change l’organisation du déménagement. Les comparatifs du blog consacré aux formules d’hébergement aident à situer mutualisé, VPS et cloud selon le trafic attendu.
Souscrivez ensuite la nouvelle formule sans résilier l’ancienne. Les deux hébergements cohabitent quelques jours : c’est cette période de recouvrement qui rend la migration réversible.
L’inventaire de ce qui déménage, élément par élément
L’inventaire de l’hébergement actuel évite l’oubli qui se découvre trois semaines plus tard. Un hébergement ne se résume pas aux fichiers du site : il porte aussi des réglages invisibles depuis le navigateur, configurés une fois puis oubliés. Ouvrez l’espace client de l’ancien hébergeur et notez chaque service actif, puis comparez la liste au tableau suivant.
| Élément | Où le trouver | Conséquence d’un oubli |
|---|---|---|
| Fichiers du site | Dossier www ou public_html, par client FTP | Images manquantes, thème cassé |
| Base de données | phpMyAdmin ou export en ligne de commande | Contenus, comptes et commandes absents |
| Boîtes de messagerie | Panneau mail, accès IMAP | Historique des échanges perdu |
| Tâches planifiées (cron) | Section dédiée du panneau | Relances, exports ou nettoyages qui ne tournent plus |
| Zone DNS complète | Gestionnaire du domaine | Sous-domaines muets, vérifications SPF ou Google perdues |
| Redirections et règles .htaccess | Racine du site, panneau de l’hébergeur | Anciennes URL en 404, liens entrants perdus |
Ajoutez à cette liste les comptes FTP secondaires donnés à un prestataire, les certificats installés à la main et les sous-domaines de test. Chaque ligne cochée devient une étape de la migration de votre site, à suivre dans l’ordre du tableau.
Garder son nom de domaine ou le transférer ?
Garder son nom de domaine chez l’ancien registraire reste la solution la plus simple : seule sa destination change, par la modification des enregistrements DNS ou des serveurs de noms. Un site qui déménage en gardant son nom ne perd ni ses liens entrants ni ses adresses e-mail, et aucun délai administratif ne s’ajoute.
Le transfert du domaine vers le nouvel hébergeur se justifie quand l’ancien contrat lie le nom à l’offre d’hébergement, ou pour regrouper toutes les factures chez un seul prestataire. La procédure demande trois gestes : retirer le verrouillage de transfert dans l’espace client, demander le code d’autorisation (appelé code AUTH, EPP ou authinfo selon l’extension), puis saisir ce code chez le registraire qui accueille le domaine. Pour un .com, la politique de transfert de l’ICANN prévoit que le registraire peut refuser le transfert dans les 60 jours qui suivent la création du domaine ou un précédent transfert, et le transfert ajoute une année d’abonnement. Pour un .fr, l’AFNIC applique la même logique de code authinfo fourni par le registraire sortant.
Du point de vue du calendrier, mieux vaut ne pas mener le transfert du domaine et le changement d’hébergement le même jour : on déménage d’abord le site, on transfère le domaine ensuite, une fois tout stabilisé.
Copier les fichiers de votre site et la base de données
Le transfert de site internet se fait en deux parties distinctes : le code et les médias d’un côté, les données de l’autre. Pour le code, un client FTP comme FileZilla, en SFTP de préférence, télécharge le dossier complet sur votre ordinateur avant de l’envoyer sur le nouveau serveur. Avec un accès SSH, une archive compressée côté ancien serveur se récupère d’un seul tenant, ce qui réduit la copie d’une après-midi à quelques minutes pour un site lourd.
Les données s’exportent depuis phpMyAdmin au format SQL, puis s’importent dans une nouvelle base. Il faut d’abord la créer dans le panneau d’arrivée, avec son propre utilisateur et son mot de passe. Il reste à reporter ces identifiants dans le fichier de configuration du site : wp-config.php pour WordPress (le « config php » que cherchent souvent les utilisateurs), configuration.php pour Joomla, un fichier .env pour Laravel ou Symfony.
Un site WordPress se migre aussi par une extension (Duplicator, All-in-One WP Migration, Migrate Guru) qui emballe le site en un paquet, puis le déploie et réécrit les URL internes. Les réglages à contrôler une fois installé, du cache à la version de PHP, sont détaillés dans le guide pour choisir un hébergement WordPress adapté. Si le nom de domaine change pendant la migration, un rechercher-remplacer sérialisé dans la base reste nécessaire, sinon les anciennes adresses restent inscrites dans les options et les contenus.
Tester le site sur le nouveau serveur avant la bascule
Le test sur le nouveau serveur se fait avant que le DNS ne change, pour que les visiteurs ne voient jamais une version cassée. La méthode la plus sûre consiste à modifier le fichier hosts de votre ordinateur (C:\Windows\System32\drivers\etc\hosts sous Windows, /etc/hosts sous macOS et Linux) en y ajoutant une ligne qui associe le nom de domaine à l’adresse IP du nouveau serveur. Votre navigateur affiche alors la nouvelle copie, pendant que le reste du monde voit toujours l’ancienne.
Parcourez ensuite les pages qui font vivre le site : formulaire de contact, panier et paiement en mode test, espace membre, recherche interne, envoi des courriels automatiques. Vérifiez que chaque fonction marche correctement, que les images s’affichent et que les journaux d’erreur du nouvel hébergement restent vides. Les défauts typiques sont des chemins absolus vers l’ancien dossier, une extension PHP manquante ou une limite de mémoire plus basse. Corrigez-les maintenant : chaque correction faite à ce stade évite une panne visible le jour J.
Domaine, e-mails et référencement : les inquiétudes avant la bascule
Peut-on changer d’hébergeur sans perdre son référencement ?
Un changement d’hébergeur ne fait pas perdre de positions si les URL restent identiques et si le site reste accessible pendant toute l’opération. Google suit le domaine, pas l’adresse IP du serveur. Les reculs observés viennent d’une longue coupure, d’URL modifiées sans redirections 301, d’un fichier robots.txt de préproduction recopié par erreur ou d’un temps de réponse dégradé. Surveillez la Search Console les semaines suivantes, rubrique des pages indexées et statistiques d’exploration.
Comment garder ses adresses e-mail pendant la migration ?
Les adresses e-mail restent intactes tant que les enregistrements MX pointent vers le serveur de messagerie qui les héberge. Si la messagerie reste chez l’ancien prestataire, recopiez à l’identique les MX et les entrées SPF, DKIM et DMARC dans la nouvelle zone. Si elle déménage, créez d’abord les boîtes chez le nouvel hébergeur, copiez chaque message par IMAP (imapsync ou l’outil de l’hébergeur), puis modifiez les MX. Prévenez chaque utilisateur pour qu’il reconfigure son logiciel, Outlook ou Thunderbird, et son téléphone avec les nouvelles informations de connexion.
Combien de temps dure un changement d’hébergeur ?
Pour un site vitrine, la préparation et la copie tiennent souvent en une demi-journée, et la propagation DNS prend de quelques minutes à 48 heures selon le TTL réglé. Une boutique ou un site avec beaucoup de données demande davantage : prévoyez une semaine entre l’ouverture du nouvel hébergement et la résiliation de l’ancien, période de surveillance comprise.
Basculer le DNS le jour J
La bascule DNS est le moment où le nom de domaine commence à pointer vers le nouveau serveur. Chaque enregistrement porte une durée de vie, le TTL, pendant laquelle les résolveurs gardent l’ancienne réponse en cache : avec un TTL de 86 400 secondes, soit une journée, une partie des visiteurs verrait l’ancien serveur jusqu’au lendemain. Abaissez-le à 300 secondes deux jours avant la date prévue, et le changement se propagera presque partout en quelques minutes.
Le jour venu, gelez les modifications sur l’ancien site (commandes, commentaires, inscriptions), faites un dernier export SQL et importez-le chez le prestataire d’arrivée. Modifiez ensuite les enregistrements A et AAAA, ou les serveurs de noms si la zone déménage elle aussi. Le rôle de chaque type d’entrée, du A au TXT en passant par le CNAME, est expliqué dans le décryptage des enregistrements A, CNAME, MX et TXT. Choisissez un créneau calme : un mardi matin plutôt qu’un vendredi soir, quand le support technique des deux prestataires répond encore.
Une fois la propagation constatée, avec un outil en ligne de vérification DNS ou la commande dig, remettez un TTL plus long, jusqu’à une journée, pour alléger les requêtes sur le serveur DNS.
Surveiller la semaine suivante, puis résilier l’ancien hébergement
La semaine qui suit la bascule sert à confirmer que le site fonctionne correctement chez le nouvel hébergeur. Consultez chaque jour les journaux du serveur web à la recherche de pages en 404 ou en 500, testez les formulaires et vérifiez que le HTTPS couvre toutes les variantes du domaine, avec et sans www. Le certificat qui active le HTTPS doit souvent se réémettre chez le nouveau prestataire, Let’s Encrypt ou payant, car il ne suit pas toujours la copie des fichiers.
Gardez l’ancien hébergement actif au moins sept jours. Ce délai laisse les derniers caches DNS se vider et permet de vérifier qu’aucun courriel n’arrive encore sur l’ancienne boîte. Avant de résilier, pensez à sauvegarder une dernière fois l’ensemble, code, données et messagerie : si une donnée manque dans trois mois, c’est là qu’elle se retrouvera. Résiliez enfin en respectant le préavis prévu au contrat, et supprimez les accès FTP ou SSH que vous aviez ouverts pour la migration.
