Changer d’hébergeur sans coupure : l’ordre des opérations

Un site e-commerce qui affiche une page blanche pendant 48 heures, c’est en moyenne 2 à 5 % de chiffre d’affaires mensuel envolé, sans compter l’impact sur le référencement. Pourtant, migrer un site web et changer d’hébergeur sans la moindre interruption est tout à fait réalisable, à condition de respecter un ordre précis d’opérations. Ce guide détaille chaque étape, du choix du nouvel hébergeur jusqu’à la résiliation de l’ancien, pour que la transition reste invisible aux yeux de vos visiteurs.

Pourquoi la migration fait peur (et pourquoi elle ne devrait pas)

La plupart des propriétaires de sites repoussent le changement d’hébergeur par crainte d’une coupure. Cette inquiétude est compréhensible : un site inaccessible, c’est une perte de visiteurs, de revenus et potentiellement de positions dans les résultats de recherche. Google indique d’ailleurs dans sa documentation sur l’exploration qu’un serveur indisponible de façon prolongée peut entraîner une désindexation temporaire des pages concernées.

La réalité, c’est que la coupure n’est jamais obligatoire. Elle survient uniquement quand on modifie les DNS avant d’avoir préparé le nouveau serveur, ou quand on résilie l’ancien hébergement trop tôt. En suivant l’ordre des opérations que je détaille ici, j’ai migré plus de 80 sites en agence sans une seule interruption visible pour les utilisateurs finaux.

Le principe est simple : pendant toute la durée de la propagation DNS, les deux hébergements fonctionnent en parallèle. L’ancien continue de servir les visiteurs qui n’ont pas encore reçu la nouvelle adresse IP, tandis que le nouveau prend progressivement le relais. C’est cette cohabitation temporaire qui garantit le zéro coupure.

Les prérequis avant de lancer la migration

Avant de toucher au moindre fichier, plusieurs éléments doivent être réunis. Les négliger, c’est s’exposer à des allers-retours inutiles le jour J.

Choisir le bon hébergeur cible

Si vous n’avez pas encore arrêté votre choix, je vous recommande de consulter mon guide pour choisir un hébergeur web selon les cinq critères techniques qui comptent. La version de PHP, le type de stockage (SSD NVMe de préférence), la localisation des serveurs et le support technique sont des points décisifs. Pour un site WordPress standard, un hébergement mutualisé suffit dans la majorité des cas. Si votre trafic dépasse 50 000 visites mensuelles, envisagez un VPS : j’ai détaillé les différences dans l’article sur le choix entre mutualisé, VPS ou dédié.

Rassembler les accès nécessaires

Voici la liste des accès à vérifier avant de commencer :

• Panel de l’ancien hébergeur (cPanel, Plesk ou interface propriétaire) pour exporter fichiers et bases de données
• Accès FTP ou SSH à l’ancien serveur pour copier les fichiers volumineux
• Panel du nouvel hébergeur pour importer et configurer
• Gestionnaire DNS du nom de domaine (souvent chez le registrar, parfois chez l’hébergeur)
• Identifiants de la base de données : nom, utilisateur, mot de passe, hôte

Un point souvent oublié : vérifiez que votre nom de domaine n’est pas verrouillé chez l’ancien hébergeur. Si le registrar et l’hébergeur sont la même entité, un changement d’hébergeur ne nécessite pas de transfert de domaine. Il suffit de modifier les serveurs DNS ou les enregistrements A. Pour les mots de passe d’accès à ces différents panneaux, pensez à les mettre à jour si nécessaire avant la migration.

Réaliser une sauvegarde complète

C’est la règle d’or : ne jamais commencer une migration sans sauvegarde vérifiée. Téléchargez sur votre poste local une copie de tous les fichiers du site (via FTP ou le gestionnaire de fichiers) et un export SQL de chaque base de données. Cette sauvegarde locale constitue votre filet de sécurité en cas de problème sur l’un ou l’autre des serveurs.

Copier les fichiers et la base de données sur le nouvel hébergeur

C’est l’étape la plus longue, mais aussi la plus sûre : elle ne touche à rien sur l’ancien serveur. Votre site reste accessible normalement pendant toute cette phase.

Transférer les fichiers du site

Trois méthodes principales s’offrent à vous :

• FTP/SFTP : avec un client comme FileZilla, connectez-vous à l’ancien serveur, téléchargez tous les fichiers, puis uploadez-les sur le nouveau. Pour un site de moins de 2 Go, c’est la méthode la plus simple.
• SSH + rsync : si les deux serveurs proposent un accès SSH, la commande rsync -avz copie les fichiers directement de serveur à serveur. C’est la méthode la plus rapide pour les sites volumineux.
• Archive ZIP via le panel : la plupart des panels permettent de compresser le dossier du site en une archive, de la télécharger, puis de la décompresser sur le nouveau serveur.

Quelle que soit la méthode choisie, vérifiez que les permissions des fichiers sont correctes après le transfert. Sur un hébergement Linux classique, les dossiers doivent être en 755 et les fichiers en 644.

Migrer la base de données

Pour les sites WordPress, Joomla, PrestaShop ou tout CMS utilisant MySQL/MariaDB :

1. Exportez la base via phpMyAdmin (format SQL, encodage UTF-8)
2. Créez une nouvelle base de données sur le nouvel hébergeur avec un utilisateur dédié
3. Importez le fichier SQL dans la nouvelle base via phpMyAdmin ou en ligne de commande avec mysql -u utilisateur -p nom_base < export.sql
4. Mettez à jour le fichier de configuration du CMS (wp-config.php pour WordPress, configuration.php pour Joomla) avec les nouveaux identifiants de base de données

Pour les bases volumineuses (plus de 100 Mo), l’import via phpMyAdmin peut échouer à cause des limites de taille. Privilégiez alors l’import en SSH ou demandez à votre nouvel hébergeur d’augmenter temporairement la limite upload_max_filesize.

Cas particulier : WordPress avec un plugin de migration

Des extensions comme Duplicator, All-in-One WP Migration ou UpdraftPlus automatisent le processus. Elles créent un package contenant fichiers et base de données, qu’il suffit d’installer sur le nouveau serveur. C’est pratique pour les sites de taille modeste, mais attention aux limites de taille imposées par les versions gratuites (souvent 512 Mo). Pour les sites plus lourds, la méthode manuelle reste plus fiable.

Préparer la bascule DNS sans coupure

C’est ici que se joue la réussite de la migration. La gestion des DNS est le point technique le plus délicat, mais il n’a rien de sorcier une fois qu’on comprend le mécanisme.

Comprendre le TTL et la propagation

Le TTL (Time To Live) est la durée pendant laquelle les serveurs DNS intermédiaires gardent en cache l’adresse IP associée à votre nom de domaine. Un TTL de 3600 signifie que les résolveurs DNS conservent l’ancienne IP pendant 1 heure avant de vérifier s’il y a eu un changement. Selon les recommandations de l’IANA, la propagation complète à l’échelle mondiale peut prendre jusqu’à 48 heures, même si en pratique elle se fait souvent en 4 à 12 heures.

Abaisser le TTL 48 heures avant

La technique clé : 48 heures avant la bascule, connectez-vous à votre gestionnaire DNS et abaissez le TTL de tous les enregistrements concernés (A, AAAA, CNAME, MX) à 300 secondes (5 minutes). Ainsi, le jour de la migration, les caches DNS se mettront à jour en quelques minutes au lieu de plusieurs heures.

Voici la séquence à suivre :

1. J-2 : abaisser le TTL à 300 secondes
2. J-0 : modifier l’enregistrement A pour pointer vers la nouvelle adresse IP
3. J+2 : une fois la propagation terminée, remonter le TTL à 3600 secondes

Ne pas confondre DNS et transfert de domaine

Changer d’hébergeur ne signifie pas forcément transférer son nom de domaine. Si votre domaine est enregistré chez un registrar indépendant (Gandi, OVH Domaines, Namecheap), vous n’avez qu’à modifier les enregistrements DNS. Le transfert de domaine n’est nécessaire que si vous souhaitez regrouper domaine et hébergement chez le même prestataire, et il implique un délai supplémentaire de 5 à 7 jours.

Vérifier que tout fonctionne sur le nouveau serveur

Avant de toucher aux DNS, vous devez vous assurer que le site tourne parfaitement sur le nouvel hébergement. C’est une étape que beaucoup sautent, et c’est la première cause de coupure lors d’une migration.

Tester via le fichier hosts

Sur votre poste, modifiez le fichier hosts pour forcer votre navigateur à résoudre votre domaine vers la nouvelle IP. Sous Windows, le fichier se trouve à C:\Windows\System32\drivers\etc\hosts. Sous macOS et Linux, c’est /etc/hosts. Ajoutez une ligne comme :

203.0.113.42 monsite.fr www.monsite.fr

Remplacez 203.0.113.42 par l’adresse IP de votre nouvel hébergement. Vous pourrez alors naviguer sur votre site comme si la migration DNS était déjà faite, sans affecter les autres visiteurs.

Points de contrôle obligatoires

Parcourez méthodiquement ces éléments :

• Page d’accueil : affichage correct, pas d’erreur PHP
• Pages intérieures : au moins 5 pages représentatives
• Formulaires de contact : envoi d’un message test
• Espace client ou connexion : test de login
• Certificat SSL : vérifiez que le HTTPS fonctionne (Let’s Encrypt ou certificat dédié)
• Redirections : testez les redirections 301 existantes
• Cron jobs : reconfigurez les tâches planifiées si nécessaire
• E-mails : si vos adresses e-mail dépendent de l’hébergeur, configurez-les sur le nouveau serveur

N’oubliez pas de supprimer la ligne ajoutée dans le fichier hosts une fois les tests terminés.

Le certificat SSL : un piège fréquent

Si vous utilisez Let’s Encrypt, le certificat ne peut être généré que lorsque le domaine pointe déjà vers le serveur. Certains hébergeurs comme o2switch ou PlanetHoster proposent un pré-provisionnement SSL ou un certificat temporaire. Si ce n’est pas le cas, vous pouvez utiliser la validation DNS de Let’s Encrypt (au lieu de la validation HTTP) pour obtenir le certificat avant que le domaine ne pointe vers le nouveau serveur. C’est un détail technique qui évite les alertes “connexion non sécurisée” pendant la propagation.

Basculer les DNS et surveiller la propagation

Le moment est venu. Si vous avez bien suivi les étapes précédentes, cette phase est la plus simple.

Modifier les enregistrements DNS

Connectez-vous à votre gestionnaire DNS et modifiez l’enregistrement A pour qu’il pointe vers l’adresse IP du nouvel hébergeur. Si votre site utilise IPv6, mettez également à jour l’enregistrement AAAA. Pour les sous-domaines gérés par des CNAME, adaptez-les en conséquence.

Attention aux enregistrements MX : si vos e-mails sont hébergés au même endroit que le site, vous devez reconfigurer les MX pour pointer vers le nouveau serveur mail. Si vous utilisez un service externe (Google Workspace, Microsoft 365, Zoho Mail), les MX restent inchangés.

Surveiller la propagation en temps réel

Utilisez un outil de vérification DNS pour suivre la propagation dans différentes régions du monde. Le site whatsmydns.net permet de visualiser en temps réel quels serveurs DNS ont déjà basculé vers la nouvelle IP. Pendant cette période :

• Ne modifiez rien sur l’ancien serveur ni sur le nouveau
• Ne résiliez pas l’ancien hébergement
• Surveillez les logs d’erreur du nouveau serveur
• Vérifiez que les deux serveurs reçoivent du trafic (c’est normal pendant la propagation)

Synchroniser les données de dernière minute

Si votre site reçoit des commandes, des commentaires ou des inscriptions pendant la propagation, certaines données atterriront sur l’ancien serveur. Pour un site e-commerce, c’est critique. Deux solutions :

• Mode maintenance partiel : désactivez temporairement les formulaires de commande sur l’ancien serveur et affichez un message invitant à réessayer dans quelques minutes
• Resynchronisation : après propagation complète, exportez les données récentes de l’ancien serveur et importez-les dans le nouveau

Pour un blog ou un site vitrine, ce problème ne se pose généralement pas.

Comparatif des méthodes de migration

Selon la taille de votre site, votre niveau technique et votre CMS, la méthode optimale varie. Voici un comparatif pour vous aider à choisir.

La migration assistée par l’hébergeur mérite un commentaire. De nombreux prestataires comme Hostinger, o2switch ou PlanetHoster proposent un service de migration gratuit à la souscription. Leur équipe technique s’occupe de tout : copie des fichiers, import de la base, configuration DNS. C’est l’option idéale si vous ne souhaitez pas mettre les mains dans le technique.

Pour les développeurs qui travaillent avec des environnements conteneurisés, la migration Docker est la plus propre. L’ensemble de l’environnement (serveur web, PHP, base de données) est encapsulé dans des conteneurs reproductibles. Il suffit de déployer les mêmes images sur le nouveau serveur. Si ce sujet vous intéresse, il est utile de maîtriser les bases de Node.js et des outils modernes de déploiement.

Après la migration : la checklist de clôture

La migration n’est terminée que lorsque tous les points suivants sont validés. J’utilise cette liste pour chaque migration que je réalise.

Les 12 points de vérification post-migration

1. Propagation DNS complète : vérifiez sur whatsmydns.net que toutes les régions pointent vers la nouvelle IP
2. Certificat SSL actif : le cadenas apparaît dans le navigateur, pas d’avertissement de sécurité
3. Toutes les pages chargent : parcourez le sitemap XML pour identifier les erreurs 404 ou 500
4. Formulaires fonctionnels : envoyez un formulaire test et vérifiez la réception
5. E-mails opérationnels : envoyez et recevez un e-mail test sur chaque adresse
6. Redirections 301 actives : testez les anciennes URL qui doivent rediriger
7. Google Search Console : vérifiez qu’aucune erreur d’exploration n’apparaît dans les 48 h suivantes
8. Google Analytics / Matomo : confirmez que le tracking fonctionne sur le nouveau serveur
9. Tâches cron : vérifiez que les sauvegardes automatiques et les tâches planifiées tournent
10. Performances : mesurez le temps de chargement avec GTmetrix ou PageSpeed Insights
11. Sauvegardes automatiques : configurez les sauvegardes sur le nouvel hébergeur
12. Ancien hébergement : gardez-le actif 7 à 14 jours, puis résiliez

Ne pas résilier trop tôt

C’est l’erreur la plus courante. On pense que la migration est terminée, on résilie l’ancien hébergement, et on découvre le lendemain que certains visiteurs étaient encore routés vers l’ancien serveur. Résultat : page blanche. La règle est simple : attendez au minimum 7 jours après la bascule DNS avant de résilier. Pour les sites à forte audience internationale, comptez plutôt 14 jours.

Mettre à jour les mots de passe

Profitez de la migration pour renouveler les mots de passe d’accès au panel d’hébergement, au FTP, à la base de données et à l’administration du CMS. C’est une bonne pratique de sécurité. Si vous utilisez des services Google liés à votre site, pensez à mettre à jour votre mot de passe Google par la même occasion. Pour votre poste de travail, un changement de mot de passe Windows régulier reste également recommandé.

Informer Google du changement

La Google Search Console propose un outil de changement d’adresse dans les paramètres. Si votre URL ne change pas (ce qui est le cas quand on garde le même domaine), cet outil n’est pas nécessaire. En revanche, vérifiez dans les jours suivants qu’aucune erreur d’exploration n’est remontée. Un pic d’erreurs 5xx indiquerait un problème de configuration sur le nouveau serveur.

Pour les sites qui misent sur le référencement naturel, la stabilité du serveur est un facteur indirect de classement. Un hébergeur plus performant peut même avoir un impact positif sur vos positions grâce à un meilleur temps de réponse serveur (TTFB).