Changer d’hébergeur WordPress ne consiste pas à déplacer un dossier puis à attendre que le site réapparaisse. Il faut transférer plusieurs éléments, vérifier qu’ils fonctionnent ensemble, puis orienter le trafic vers le nouvel environnement au bon moment.

Une migration bien préparée ne garantit pas une interruption nulle. Elle permet en revanche de réduire les risques, de savoir ce qui doit être contrôlé et de réagir si le site ne se comporte pas comme prévu.

Commencer par cartographier ce qui va réellement changer

Avant toute manipulation, identifiez les responsabilités de chaque service. L’hébergeur fournit l’espace serveur et les ressources nécessaires au fonctionnement du site. Le registrar gère le nom de domaine. Les DNS indiquent vers quels serveurs orienter le trafic. WordPress, lui, repose notamment sur des fichiers et une base de données.

Ces éléments peuvent être gérés au même endroit, mais ce n’est pas obligatoire. Le domaine peut être enregistré chez un prestataire, le site hébergé chez un autre et les e-mails administrés par un troisième. Changer d’hébergeur web ne déplace donc pas automatiquement la messagerie.

Pour les e-mails, notez où sont hébergées les boîtes, relevez les enregistrements MX ainsi que les autres paramètres utiles, et vérifiez si les boîtes doivent être migrées séparément. Préparez la conservation des enregistrements concernés et testez la réception comme l’envoi avant et après la modification DNS. Une zone DNS modifiée trop largement peut perturber la messagerie, même si le transfert du site s’est déroulé correctement.

Réunissez aussi les accès à l’ancien hébergement, au nouveau, au registrar, à la base de données et aux outils de sauvegarde. Faites l’inventaire des extensions, des versions de PHP, des tâches planifiées, des certificats SSL, des comptes e-mail et des services externes utilisés par le site : paiement, réservation, statistiques, CDN ou envoi de messages.

Cette étape paraît administrative, mais elle évite une erreur fréquente : commencer le transfert alors qu’une personne ne possède pas l’accès nécessaire pour modifier les DNS, récupérer une sauvegarde ou vérifier un service critique.

1. Sauvegarder, puis vérifier que la sauvegarde sert vraiment

Une sauvegarde complète doit comprendre au minimum les fichiers WordPress et la base de données. Les fichiers contiennent notamment le cœur du site, les extensions, les thèmes et les médias. La base contient les contenus, les réglages, les comptes et d’autres données indispensables au fonctionnement du site.

Conservez cette sauvegarde dans un emplacement distinct de l’ancien hébergement et vérifiez qu’elle est exploitable. Un fichier créé sans erreur n’est pas nécessairement une restauration réussie. Lorsque le contexte le permet, testez la restauration sur un environnement séparé ou demandez à l’intervenant de démontrer que les deux parties peuvent être réutilisées.

Une sauvegarde WordPress ne suffit pas : elle ne remplace ni la copie vers le nouvel hébergement, ni les tests, ni la synchronisation des dernières données.

2. Préparer le nouvel hébergement avant la bascule

Le nouvel environnement doit être prêt avant de modifier les DNS. Selon la méthode retenue, vous pouvez installer WordPress puis importer les fichiers et la base de données, utiliser un outil de migration ou vous appuyer sur l’intervention du nouvel hébergeur. Les étapes exactes dépendent des accès disponibles, du type d’hébergement et de l’outil choisi.

Les méthodes fondées sur l’export puis l’import du site sont courantes. Certains tutoriels décrivent également l’installation préalable de WordPress sur le nouveau serveur, suivie de l’import du contenu, comme ce parcours présenté par Bluehost ou cet exemple de procédure chez HODI.host. Ce sont des exemples de méthode, pas des règles universelles : un plugin peut avoir des limites de taille, de compatibilité ou de transfert.

Avant la bascule, copiez le site sur le nouvel hébergement et prévoyez une adresse de prévisualisation ou un autre moyen de test. Évitez de vous contenter d’un écran d’installation réussi. Il faut pouvoir consulter la version transférée dans des conditions proches de la production.

Contrôlez notamment :

• la connexion à l’administration WordPress ;
• la page d’accueil, les pages internes et les contenus récents ;
• les images, les fichiers téléchargeables et les médias ;
• les permaliens et les liens internes ;
• les extensions indispensables et leurs réglages ;
• les formulaires et les e-mails transactionnels ;
• les paiements, réservations ou autres fonctions critiques ;
• les tâches planifiées, les certificats SSL et les connexions aux services tiers.

Le nouvel environnement doit aussi utiliser des versions compatibles avec le site. Une version différente de PHP, une extension absente ou une tâche planifiée non recréée peuvent provoquer un dysfonctionnement qui n’apparaissait pas lors de la simple copie des fichiers.

3. Tester avant de toucher aux DNS

La prévisualisation permet de vérifier le site avant que les visiteurs soient envoyés vers le nouveau serveur. Les détails varient selon l’hébergeur : sous-domaine temporaire, fichier hosts, URL de test ou environnement de préproduction. L’important est de disposer d’un accès permettant de tester sans remplacer immédiatement la version publique.

Testez les parcours plutôt que les seules pages visibles. Envoyez un formulaire, vérifiez la réception du message, ouvrez une session utilisateur si le site en propose une, effectuez un parcours de réservation ou de paiement dans les conditions prévues, et contrôlez les médias ajoutés récemment.

Pour les e-mails, comparez les paramètres avant la migration et vérifiez que le nouveau site utilise les bons services d’envoi. La messagerie des boîtes et les e-mails envoyés par WordPress ne reposent pas nécessairement sur la même configuration.

Cette logique de test vaut aussi pour les évolutions courantes : une modification importante ne devrait pas être testée directement sur le site en production. Une migration est précisément le moment où un environnement de vérification devient utile.

4. Synchroniser les dernières données avant la bascule

Entre la copie initiale et le changement DNS, le site public peut continuer à recevoir des formulaires, des commandes, des réservations, des commentaires ou de nouveaux comptes. La copie préparée quelques heures plus tôt n’intègre pas forcément ces changements.

Il faut donc définir un second temps de transfert : synchroniser les fichiers modifiés et la base de données, ou prévoir une courte période durant laquelle les écritures sont suspendues si l’activité et la solution technique le permettent. La méthode dépend du site et de l’outil utilisé. Elle doit surtout préserver les données apparues depuis la première copie.

Ne lancez pas la bascule sans savoir quelle version contient les dernières données. Un site peut sembler fonctionnel tout en ayant perdu une commande ou un formulaire récent.

5. Modifier les DNS au moment prévu

La bascule consiste généralement à modifier les enregistrements DNS concernés pour qu’ils pointent vers le nouvel environnement. Il peut s’agir de l’adresse principale du site ou d’autres enregistrements selon la configuration. Ne remplacez pas toute la zone par défaut du nouvel hébergeur sans comparer les entrées existantes : les e-mails et certains services externes peuvent dépendre d’enregistrements qui doivent rester en place.

Choisissez une fenêtre de changement adaptée à l’activité du site et à la disponibilité de la personne qui pourra intervenir en cas de problème. Si c’est pertinent pour votre configuration, le TTL peut être abaissé suffisamment en amont afin de limiter la durée pendant laquelle certains résolveurs conservent l’ancienne information. Cela ne rend pas la propagation instantanée et ne permet pas de fixer une durée universelle.

Conservez les anciennes informations jusqu’à la fin des contrôles. Un retour arrière peut être envisagé si le nouveau site présente une erreur bloquante, à condition que l’ancien environnement soit encore disponible et que les données aient été maîtrisées entre-temps.

6. Contrôler le site après le changement

Après la modification DNS, vérifiez progressivement que les visiteurs atteignent bien le nouvel hébergement. Contrôlez la résolution du domaine, l’accès en HTTPS et la présence d’un certificat valide. Ouvrez plusieurs pages, connectez-vous à l’administration et examinez les journaux d’erreurs du serveur et de WordPress.

Refaites ensuite les tests fonctionnels : formulaire, réception et envoi d’e-mails, paiement, réservation, création de compte et téléchargement de fichiers. Vérifiez aussi les tâches planifiées, les connexions aux services externes, les statistiques et les sauvegardes désormais réalisées sur le nouvel hébergeur.

Ne supprimez pas immédiatement l’ancien hébergement. Gardez-le le temps nécessaire pour observer le fonctionnement du site et confirmer que les dernières données sont bien présentes au bon endroit. La durée dépend du site, de son activité et de la configuration ; elle ne peut pas être déduite d’une règle générale.

Quand interrompre la bascule

Avant de modifier les DNS, définissez les problèmes qui justifieraient un arrêt : base incomplète, erreurs PHP bloquantes, formulaire inutilisable, paiement défaillant, certificat absent ou messagerie perturbée. Si l’un de ces cas apparaît, ne cherchez pas à masquer le symptôme en production. Revenez à l’état précédent si cela reste possible, documentez ce qui a été modifié et corrigez sur le nouvel environnement.

Une migration maîtrisée repose moins sur un plugin miracle que sur une séquence claire : cartographier les services, sauvegarder et vérifier, préparer le nouvel hébergement, tester, synchroniser, basculer les DNS puis contrôler. Le changement d’hébergeur devient alors une opération planifiée, avec des responsabilités identifiées et une solution de repli plutôt qu’un pari fait sur une simple copie de WordPress.