Hébergement web

Comment migrer votre site vers un nouvel hébergeur sans interruption

Par la rédaction de DealPortalMis à jour le 6 nov. 2026Lecture : 15 min
Deux serveurs reliés par une flèche, avec des cartons de déménagement au premier plan
Nous pouvons percevoir une commission si vous achetez via nos liens. Cela n'affecte ni le prix que vous payez ni ce que nous écrivons. Comment nous gagnons de l'argent

Migrer un site vers un nouvel hébergeur peut sembler risqué, mais avec un plan clair, c'est une opération tranquille et prévisible. L'astuce consiste à construire et tester la nouvelle copie pendant que l'ancienne continue d'accueillir les visiteurs, puis à faire pointer votre domaine vers le nouveau serveur seulement ensuite. Ce guide détaille tout le processus pour un petit site classique, avec WordPress comme exemple principal, et aborde en termes généraux les sites statiques et les sites PHP sur mesure.

Choisir le bon moment et faire l'inventaire de l'existant

Parmi les bonnes raisons de changer d'hébergeur, on trouve des lenteurs ou des pannes à répétition, une offre qui ne correspond plus à votre trafic, des fonctionnalités manquantes comme une version de PHP récente ou des outils de préproduction, un support médiocre, ou un prix de renouvellement qui a grimpé au-delà de la valeur du service. Parmi les mauvaises raisons, on trouve une seule mauvaise après-midi ou une offre alléchante que vous n'avez pas comparée sérieusement. Si vous hésitez encore, notre guide sur comment choisir un hébergement web explique quoi regarder, et celui sur les prix de renouvellement de l'hébergement explique pourquoi le coût change souvent après la première période.

Choisissez une période calme pour la migration. Pour la plupart des sites, cela veut dire un soir de semaine ou un week-end à faible trafic, et jamais la semaine d'une grosse promotion, d'un lancement ou d'une campagne. Prévoyez quelques jours de marge, même si le travail réel ne prend que deux heures environ.

Avant de toucher à quoi que ce soit, notez tout ce que fait votre hébergeur actuel pour vous. Les sites dépendent souvent d'éléments que personne ne se rappelle avoir configurés. Voici un inventaire simple à remplir.

ÉlémentÀ noter
FichiersDossier racine du site, médias téléversés, thèmes, extensions, fichiers situés hors de la racine web
Bases de donnéesNoms, utilisateurs, tailles, et application qui utilise chacune d'elles
E-mailBoîtes aux lettres, redirections, alias, répondeurs automatiques, et lieu réel d'hébergement des e-mails
Tâches cronTâches planifiées, leur fréquence et les scripts qu'elles exécutent
Enregistrements DNSA, AAAA, CNAME, MX, TXT (dont SPF et autres enregistrements de vérification), et tous les autres
SSLType de certificat, noms d'hôte couverts, et fonctionnement du renouvellement
Paramètres du serveurVersion de PHP, limites de mémoire, règles de redirection, fichiers de configuration personnalisés

Exportez votre zone DNS actuelle sous forme de texte ou prenez des captures d'écran de chaque enregistrement. Cette seule étape évite plus de paniques après migration que toute autre. Vérifiez aussi si l'enregistrement de votre domaine et votre hébergement sont chez la même entreprise. Si vous ne voyez pas bien comment ces deux éléments s'articulent, noms de domaine et hébergement explique la relation entre les deux.

Sauvegarder, construire le nouveau site et le tester en privé

Faites une sauvegarde complète des fichiers et des bases de données, et conservez-la ailleurs que chez l'ancien hébergeur, par exemple sur votre ordinateur et à un deuxième endroit. Ne vous fiez pas uniquement aux sauvegardes automatiques de l'hébergeur, car vous pourriez perdre l'accès si le compte est fermé. Vérifiez que la sauvegarde s'ouvre réellement. Une sauvegarde que vous n'avez jamais restaurée n'est qu'un espoir.

Configurer le nouvel hébergeur

Créez le compte ou l'offre, ajoutez votre domaine comme site ou domaine additionnel, et choisissez la même version majeure de PHP que celle de votre site aujourd'hui, ou une version plus récente dont vous avez déjà confirmé qu'elle est compatible avec votre code. Créez une base de données vide et un utilisateur de base de données avec un mot de passe robuste. Ne modifiez pas encore le DNS. À ce stade, le nouvel hébergeur est une pièce vide qui attend vos meubles.

Copier les fichiers et la base de données

Téléversez vos fichiers via SFTP ou avec le gestionnaire de fichiers du panneau de contrôle. Le SFTP est préférable au FTP simple, car il chiffre votre identifiant de connexion. Pour un gros site, compressez le dossier en une seule archive, téléversez-la, puis décompressez-la sur le serveur, ce qui est bien plus rapide que d'envoyer des milliers de petits fichiers.

Exportez ensuite votre base de données depuis l'ancien hébergeur et importez-la sur le nouveau. Pour WordPress, il y a deux méthodes courantes. Vous pouvez utiliser une extension de migration qui regroupe fichiers et base de données, ou le faire à la main : copier les fichiers, importer la base de données, puis modifier le fichier wp-config.php avec le nouveau nom de base, l'utilisateur et le mot de passe. Un site statique n'a besoin que des fichiers. Un site PHP sur mesure a besoin des fichiers, de la base de données, et d'un examen attentif de tout fichier de configuration qui contient des chemins, des identifiants ou des clés d'API.

Tester avant de basculer

Vérifiez maintenant la nouvelle copie pendant que le public voit encore l'ancienne. Il existe deux méthodes fiables.

  • Modifier votre fichier hosts. Sur votre propre ordinateur, ajoutez une ligne qui associe votre nom de domaine à l'adresse IP du nouveau serveur. Votre navigateur charge alors la nouvelle copie, alors que tous les autres voient toujours l'ancienne. Supprimez cette ligne une fois terminé.
  • Utiliser une URL temporaire. Beaucoup d'hébergeurs fournissent une adresse de prévisualisation pour les nouveaux comptes. C'est plus simple, mais certaines applications, dont WordPress, peuvent vous rediriger vers le vrai domaine, c'est pourquoi la méthode du fichier hosts est généralement plus propre.

Pendant les tests, parcourez la page d'accueil, quelques pages internes, la recherche, les formulaires, les connexions, le paiement si vous en avez un, et les galeries d'images. Envoyez un formulaire de contact de test et vérifiez que l'e-mail arrive. Cherchez les images cassées, les avertissements de contenu mixte et les pages d'erreur. Comparez la nouvelle copie à l'ancienne côte à côte.

Réduire le TTL, geler les modifications et basculer le DNS

Le DNS est le système qui transforme votre nom de domaine en adresse de serveur. Chaque enregistrement DNS a un TTL (« time to live », durée de vie), qui indique aux autres réseaux combien de temps ils peuvent garder la réponse en mémoire avant de redemander. Si votre TTL est de vingt-quatre heures, certains visiteurs peuvent continuer à aller vers l'ancien serveur pendant jusqu'à un jour après votre bascule.

Au moins deux jours avant la migration, réduisez le TTL de vos enregistrements principaux à une valeur courte, par exemple cinq minutes. Il faut le faire tôt, car l'ancien TTL long doit d'abord expirer partout. Le réduire une heure avant la bascule ne sert presque à rien.

Geler les modifications de contenu

Une fois votre copie finale réalisée, arrêtez les modifications sur l'ancien site. Un blog peut simplement suspendre les publications. Une boutique est plus délicate, car les commandes passées sur l'ancien serveur après votre copie finale de la base de données n'existeront pas sur le nouveau. Pour les boutiques, les sites d'adhésion et les forums, prévoyez une courte fenêtre de maintenance, faites la copie finale de la base de données au début de celle-ci, et évitez les commandes pendant l'intervalle. Faites ensuite une dernière synchronisation des fichiers et de la base de données vers le nouvel hébergeur, puis un dernier test rapide.

Basculer les enregistrements

Vous avez deux façons de faire pointer votre domaine vers le nouvel hébergeur.

  • Modifier l'enregistrement A (et AAAA s'il est utilisé) chez votre fournisseur DNS actuel pour qu'il pointe vers l'adresse IP du nouveau serveur. Le reste de votre DNS, y compris les e-mails, reste exactement tel quel. C'est l'option la plus sûre pour la plupart des gens.
  • Modifier les serveurs de noms chez votre registrar pour que le nouvel hébergeur gère tout le DNS. C'est propre, mais ne le faites qu'après avoir recréé chez le nouvel hébergeur chaque enregistrement de votre inventaire, en particulier les enregistrements MX et TXT. Des enregistrements manquants sont la cause habituelle des e-mails perdus après une migration.

Combien de temps prend vraiment la propagation

On dit souvent que le DNS prend jusqu'à 48 heures, mais c'est une habitude fondée sur le pire des cas, pas une règle. Rien ne se diffuse réellement depuis votre fournisseur DNS. Des milliers de résolveurs dans le monde conservent chacun leur propre réponse en cache, et chacun ne la rafraîchit que lorsque son minuteur arrive à échéance. Avec un TTL court défini à l'avance, la plupart des visiteurs atteignent le nouveau serveur en quelques minutes à quelques heures. Les changements de serveurs de noms peuvent prendre plus de temps, car le niveau du registre a son propre cache, et certains fournisseurs d'accès gardent les réponses plus longtemps qu'ils ne le devraient. C'est pourquoi l'ancien hébergeur doit rester actif pendant la transition. Certaines personnes verront l'ancien site, d'autres le nouveau, et les deux doivent fonctionner.

Vous pouvez suivre l'avancement avec des outils publics de consultation DNS qui interrogent de nombreux emplacements, ou avec une commande de requête DNS sur votre machine. N'oubliez pas que votre ordinateur et votre routeur mettent aussi des réponses en cache, donc tester depuis un téléphone en données mobiles peut donner un second avis utile.

Gérer les e-mails, le SSL et les URL

E-mails et enregistrements MX

Les e-mails sont la partie la plus souvent oubliée. Commencez par savoir où ils sont hébergés. S'ils sont chez votre ancien hébergeur web, vous devez aussi déplacer les boîtes aux lettres, y compris les messages stockés. Créez les mêmes boîtes chez le nouvel hébergeur, puis copiez les anciens messages avec un outil de transfert IMAP, ou en ajoutant les deux comptes dans un logiciel de messagerie et en y glissant les dossiers. Continuez d'envoyer et de recevoir sur l'ancien serveur jusqu'à ce que la copie soit terminée.

Les enregistrements MX indiquent au monde entier où livrer votre courrier. Si vous ne changez que l'enregistrement A, le MX reste intact et le courrier continue d'arriver là où il arrive aujourd'hui. Si vous changez les serveurs de noms, copiez les enregistrements MX à l'identique, ainsi que les enregistrements TXT SPF, DKIM et DMARC, qui aident vos messages à éviter les dossiers de spam. Si vos e-mails sont chez un fournisseur de messagerie distinct, ne touchez pas du tout à ses enregistrements. En cas de doute, envoyez des messages de test dans les deux sens le jour même.

Certificats SSL

Le cadenas de sécurité exige un certificat valide sur le nouveau serveur. La plupart des hébergeurs peuvent émettre un certificat automatique gratuit, mais ils ont généralement besoin que le domaine pointe déjà vers eux, donc l'émission ne réussira parfois qu'après la bascule DNS. Prévoyez une courte fenêtre et déclenchez la demande dès que les enregistrements changent. Certains hébergeurs permettent d'installer un certificat à l'avance, ce qui évite une interruption. Une fois le certificat actif, vérifiez que chaque page se charge en HTTPS sans avertissement de contenu mixte, et que les adresses HTTP redirigent vers HTTPS.

Redirections et URL

Gardez vos URL identiques autant que possible. Si l'adresse web d'une page change, ajoutez une redirection permanente de l'ancienne adresse vers la nouvelle pour que les visiteurs et les moteurs de recherche la suivent. Reprenez vos règles de redirection, qui se trouvent souvent dans un fichier caché appelé .htaccess ou dans la configuration du serveur. Vérifiez aussi que la version préférée de votre domaine, avec ou sans www, se comporte comme avant. Si vous changez aussi le nom de domaine lui-même, c'est un projet distinct qui mérite son propre plan.

Surveiller après la bascule et garder un plan de retour en arrière

Pendant les premiers jours, surveillez le site de près. Chargez régulièrement les pages clés, testez les formulaires et le paiement, et consultez les journaux d'erreurs du serveur. Installez un outil gratuit de surveillance de disponibilité si vous n'en avez pas déjà un. Vérifiez que les tâches planifiées s'exécutent, car les tâches cron sont faciles à oublier. Pour WordPress, assurez-vous que les articles programmés sont publiés et que les extensions de sauvegarde fonctionnent. Recréez des sauvegardes chez le nouvel hébergeur et vérifiez que vos outils d'analyse et la Search Console remontent toujours des données.

Votre plan de retour en arrière est simple parce que vous l'avez préparé. L'ancien site fonctionne toujours et vos enregistrements DNS d'origine sont sauvegardés. Si quelque chose de grave se casse et ne peut pas être corrigé rapidement, remettez les anciennes valeurs dans les enregistrements. Grâce au TTL court, le retour se propage lui aussi rapidement. Décidez à l'avance ce qui est considéré comme grave, par exemple un paiement qui échoue ou des e-mails qui n'arrivent pas, afin de ne pas en débattre sous pression.

Gardez l'ancienne offre pendant une courte période de chevauchement, généralement une à deux semaines, et plus longtemps si vous avez des doutes sur le courrier ou un cycle de facturation mensuel. Ne la résiliez pas le jour même. Avant de la résilier, faites une dernière sauvegarde, vérifiez qu'il n'y reste plus de courrier, et assurez-vous que rien, comme un sous-domaine ou un petit projet annexe, n'en dépend encore. Vérifiez aussi si l'enregistrement de votre domaine était inclus dans l'ancienne offre, pour ne pas le perdre par accident.

Erreurs courantes et quand demander de l'aide

  • Oublier les e-mails. Le courrier s'arrête parce que les enregistrements MX ou TXT n'ont pas été copiés.
  • Laisser le TTL élevé. La bascule traîne alors pendant des heures, voire des jours.
  • Sauter le test. Les problèmes apparaissent devant vos clients au lieu d'être découverts en privé.
  • Résilier trop tôt l'ancienne offre. Vous supprimez votre filet de sécurité alors que le DNS n'est pas encore stabilisé.
  • Modifier les deux copies. Le contenu ajouté sur l'ancien site pendant la migration est perdu.
  • Ne pas sauvegarder les enregistrements DNS. On ne peut pas reconstruire ce qu'on n'a pas noté.
  • Ignorer les versions de PHP et des logiciels. Une ancienne extension peut ne plus fonctionner sur une version de serveur plus récente.

Beaucoup d'hébergeurs proposent un service de migration gratuit, généralement pour les nouveaux clients qui déplacent un site standard. Cela vaut la peine d'en profiter pour les sites WordPress simples, car cela fait gagner du temps et les techniciens l'ont fait de nombreuses fois. Posez d'abord quelques questions. Le service couvre-t-il les fichiers, les bases de données et les e-mails ? Combien de sites ou de boîtes aux lettres sont inclus ? Testeront-ils le site avant la bascule, et aurez-vous une prévisualisation ? L'ancien site est-il laissé intact ? Qui s'occupe du DNS, et que se passe-t-il en cas de problème ? Y a-t-il des limites de taille, de code personnalisé ou d'applications particulières ? Obtenez les réponses par écrit dans la mesure du possible.

Envisagez une aide professionnelle payante si vous gérez une boutique avec des commandes en cours, un système d'adhésion ou de réservation, une grosse base de données, du code sur mesure que personne dans votre équipe n'a écrit, ou une configuration e-mail compliquée. Un indépendant ou une agence peut aussi être un choix judicieux quand une interruption vous coûterait plus cher que leurs honoraires. Même si vous faites appel à quelqu'un, gardez votre propre inventaire et vos sauvegardes, et gardez le contrôle de votre compte de domaine.

Exemple de calendrier de migration

  1. Une semaine avant : Décidez de migrer, choisissez le nouvel hébergeur, et terminez votre inventaire des fichiers, bases de données, e-mails, tâches cron, DNS et SSL.
  2. Trois à cinq jours avant : Exportez la zone DNS, faites des sauvegardes complètes, et vérifiez qu'elles se restaurent.
  3. Trois jours avant : Réduisez à quelques minutes le TTL de vos enregistrements DNS principaux.
  4. Deux jours avant : Configurez le nouvel hébergeur, copiez les fichiers et la base de données, et mettez à jour la configuration.
  5. Un jour avant : Testez via le fichier hosts ou une URL temporaire, et corrigez les problèmes.
  6. Jour de la bascule, début : Gelez les modifications de contenu, faites une dernière synchronisation des fichiers et de la base de données, et lancez un test rapide.
  7. Jour de la bascule, milieu : Mettez à jour l'enregistrement A ou les serveurs de noms, puis demandez le certificat SSL.
  8. Le même jour : Vérifiez que les e-mails circulent toujours dans les deux sens, et que le HTTPS et les redirections fonctionnent.
  9. Jours un à trois : Surveillez la disponibilité, les journaux, les formulaires, les tâches cron et les statistiques. Dégelez le contenu quand vous êtes confiant.
  10. Jours sept à quatorze : Faites une dernière sauvegarde depuis l'ancienne offre, vérifiez que rien n'en dépend, et résiliez-la. Remettez le TTL à une valeur normale.

Liste de contrôle avant et après la bascule

Avant la bascule

  • Inventaire rédigé : fichiers, bases de données, e-mails, tâches cron, enregistrements DNS, SSL.
  • Zone DNS exportée et enregistrée en dehors de l'ancien hébergeur.
  • Sauvegardes complètes réalisées, stockées à deux endroits et restaurées en test.
  • TTL réduit au moins deux jours avant la bascule.
  • Nouvel hébergeur configuré avec une version de PHP identique ou compatible.
  • Fichiers et base de données copiés, configuration mise à jour.
  • Site testé via le fichier hosts ou une URL temporaire, y compris les formulaires et les connexions.
  • Plan e-mail défini, boîtes aux lettres créées, anciens messages copiés.
  • Gel du contenu planifié et annoncé à toutes les personnes qui modifient le site.
  • Plan de retour en arrière rédigé, avec les valeurs DNS d'origine à portée de main.

Après la bascule

  • Le domaine se charge depuis le nouveau serveur sur plusieurs réseaux et appareils.
  • Le HTTPS fonctionne sur chaque page, et HTTP redirige vers HTTPS.
  • Les e-mails s'envoient et se reçoivent, et les enregistrements SPF, DKIM et DMARC sont en place.
  • Les formulaires, le paiement, la recherche et les connexions fonctionnent.
  • Les redirections et la préférence avec ou sans www se comportent comme avant.
  • Les tâches cron et les tâches planifiées s'exécutent.
  • La surveillance de disponibilité et les sauvegardes sont actives chez le nouvel hébergeur.
  • TTL remonté une fois la situation stable.
  • Ancienne offre conservée une à deux semaines, puis résiliée après une dernière sauvegarde.

Un mot de transparence : DealPortal peut percevoir une commission si vous achetez via certains liens de notre site, ce qui ne change ni le prix que vous payez ni les conseils que nous donnons.

Points clés à retenir

  • Construisez et testez d'abord la nouvelle copie en privé, avec le fichier hosts ou une URL temporaire, pendant que l'ancien site continue de fonctionner.
  • Réduisez votre TTL DNS au moins deux jours à l'avance, et sauvegardez une copie de chaque enregistrement DNS avant de changer quoi que ce soit.
  • Traitez les e-mails comme une tâche à part entière : déplacez les boîtes aux lettres, copiez les enregistrements MX, SPF, DKIM et DMARC, et testez dans les deux sens.
  • La propagation est généralement rapide avec un TTL court, mais certains visiteurs verront l'ancien site pendant un moment, donc n'éteignez jamais l'ancien trop tôt.
  • Gardez l'ancienne offre une à deux semaines et ayez un plan de retour en arrière écrit.
  • Utilisez un service de migration gratuit pour les sites simples, et faites appel à un professionnel pour les boutiques, le code sur mesure ou tout cas où une interruption coûterait cher.