On pense avoir tout prévu avant de déplacer un site : le contenu, la base, le thème, les extensions. Et pourtant, les migrations WordPress qui se passent mal partagent presque toujours le même point commun : des fichiers qu’on croyait secondaires et qu’on n’a pas sauvegardés. Certains vivent hors de wp-content, dans des recoins que les plugins de sauvegarde classiques ignorent sans prévenir. Une migration se prépare comme un déménagement : on ne compte pas seulement les cartons qu’on voit, mais aussi ceux qu’on a oubliés dans le garage.
Les fichiers hors wp-content que personne ne sauvegarde
Quand on lance un plugin de sauvegarde, l’attention se concentre sur wp-content : les thèmes, les extensions, les médias. Mais un WordPress qui tourne depuis plusieurs années accumule des fichiers ailleurs, à la racine du serveur ou dans des dossiers laissés par d’anciens scripts.
Un fichier de vérification pour Google Search Console, un sitemap généré à la main, un .htaccess avec des redirections spécifiques, parfois même un dossier de polices auto-hébergées. Ces éléments ne pèsent rien, mais leur absence après migration casse des fonctionnalités discrètes que l’on ne remarque qu’une fois le site en production.
Le réflexe à prendre ? Ouvrir le gestionnaire de fichiers du serveur et explorer la racine avant de lancer quoi que ce soit. Noter ce qui s’y trouve et se demander, pour chaque fichier, s’il a été créé par WordPress ou par une intervention manuelle. Ce qui a été ajouté à la main ne sera pas recréé par une réinstallation propre du CMS. C’est là que les surprises commencent, souvent des semaines après le déménagement.
Les tables personnalisées de la base de données
La base de données WordPress contient toutes les publications, commentaires, liens et autres contenus du site. C’est une évidence que tout le monde connaît, mais on oublie qu’elle peut aussi abriter des tables ajoutées par des plugins, des scripts de suivi ou des développeurs. Ces tables ne portent pas toujours le préfixe standard wp_ et certains outils de sauvegarde les excluent silencieusement si leur configuration par défaut filtre ce qui ne ressemble pas à du WordPress natif.
Avant une migration, il faut donc ouvrir phpMyAdmin et parcourir la liste complète des tables. Si vous voyez des noms inhabituels, notez-les. Une table de réservations, un historique de votes, des données de formulaire : tout cela constitue du contenu que vos visiteurs ont produit.
Le perdre revient à effacer une partie de l’activité du site. WordPress.org recommande un plan de sauvegarde complet comprenant le site WordPress, la base de données et la mise en place de sauvegardes automatiques ; un conseil qui prend tout son sens quand on découvre l’étendue réelle de ce que la base contient.
Et au-delà des tables elles-mêmes, il y a la question de l’encodage et des options stockées. Une migration vers un serveur avec une version différente de MySQL ou MariaDB peut modifier subtilement le comportement de certaines requêtes. On ne le voit pas immédiatement, mais un site qui rame ou des pages qui mettent du temps à charger après migration trouvent parfois leur explication dans ces détails invisibles. Sur ce point, voir aussi notre article sur wordpress ralentit maintenance.
Le test de restauration, l’étape que tout le monde saute
Une sauvegarde qui n’a jamais été restaurée est une promesse non tenue. XT DESIGN WEB, dans un article publié le 31 mars 2025 par Xavier Taillebois, recommande de faire une sauvegarde complète et testée avant une migration ou un changement de nom de domaine. Testée, c’est le mot qui fait la différence.
La plupart des gens lancent la sauvegarde, voient que le fichier se crée, et passent à autre chose. Sauf que les archives corrompues existent, plus souvent qu’on ne le croit, et elles ne se manifestent qu’au moment où l’on en a désespérément besoin.
Le test n’a pas besoin d’être spectaculaire. Il suffit de créer un sous-domaine temporaire, d’y déposer la sauvegarde, et de lancer la restauration comme si de rien n’était. Si le site s’affiche, si la base répond, si les réglages principaux sont là, alors on peut respirer. Cette opération prend une heure et élimine une grande partie du risque. Sur un hébergement mutualisé, elle se fait sans toucher au site en production, et franchement, c’est une heure bien investie.
Ce qui change quand les contenus sont publiés souvent
La fréquence des sauvegardes dépend de la fréquence de publication des contenus, indique WordPress.org. Un blog qui publie une fois par mois n’a pas les mêmes besoins qu’une boutique qui enregistre des commandes toutes les heures. Avant une migration, cette distinction devient critique : si des données sont créées pendant que la sauvegarde tourne, elles risquent de ne pas être incluses dans l’archive finale.
Pour un site actif, il faut donc coupler la sauvegarde manuelle de pré-migration avec une mise en maintenance temporaire, ou au moins suspendre les écritures pendant la durée de l’export. Un site e-commerce qui continue de prendre des commandes pendant qu’on copie sa base produit une archive incohérente, où certaines tables sont plus récentes que d’autres. Le résultat, après restauration, c’est un site qui semble fonctionner mais qui perd des transactions ou des commentaires. Ces incohérences silencieuses sont parmi les plus difficiles à corriger une fois la migration terminée.
WordPress.org conseille de sauvegarder la base de données régulièrement, et toujours avant de faire une mise à jour. Ce réflexe s’applique doublement aux migrations : la mise à jour vers un nouveau serveur est une mise à jour à grande échelle, qui touche chaque fichier et chaque ligne de la base. Sans sauvegarde fraîche et complète, on joue avec l’intégralité de son travail éditorial.
La fin du chantier commence avant le déménagement
Une migration WordPress réussie se décide avant même de toucher au premier fichier. Explorer la racine du serveur, lister les tables inhabituelles, tester réellement la restauration : ces trois gestes prennent moins de temps qu’une journée de dépannage après coup. Les outils automatiques simplifient beaucoup de choses, mais ils créent aussi une fausse confiance en laissant croire que tout est couvert alors que des angles morts persistent.
Les hébergeurs comme 007hebergementweb.com accompagnent souvent ces opérations, mais leur support ne remplacera jamais une archive que vous avez vous-même vérifiée. Qu’est-ce qui vous coûtera le plus cher, une heure de test aujourd’hui ou une semaine de reconstruction après la migration ?
