La base de données WordPress est le cœur discret du site: elle conserve les contenus, les réglages, les comptes utilisateurs et une grande partie de ce que le tableau de bord affiche ensuite. Quand un site ralentit, qu’une migration tourne mal ou qu’un réglage disparaît, le problème vient très souvent de là. Ici, je vais vous montrer ce qu’elle contient, comment l’examiner sans risque, comment la sauvegarder correctement et dans quels cas il faut la nettoyer ou la faire évoluer.
Ce qu’il faut retenir avant d’intervenir
- WordPress stocke son contenu dans une base SQL, pas dans les fichiers du thème ou des extensions.
- Le fichier wp-config.php contient les informations de connexion et le préfixe des tables.
- Les tables les plus utiles à connaître sont wp_posts, wp_postmeta, wp_options, wp_users et wp_comments.
- Pour une migration ou un dépannage, wp search-replace est souvent plus sûr qu’un remplacement manuel.
- Une sauvegarde n’a de valeur que si vous savez la restaurer.
- Les tables personnalisées ne se justifient que pour des données qui ne rentrent pas proprement dans le schéma natif.
Ce que WordPress stocke vraiment dans sa base
Je commence toujours par remettre les choses à leur place: WordPress n’enregistre pas seulement des articles et des pages. Il stocke aussi les réglages du site, les comptes, les commentaires, les menus, les catégories, les métadonnées des contenus et, selon les extensions, une quantité variable de données supplémentaires. La base de données WordPress est donc moins un simple stockage qu’un système de mémoire centrale.
La recommandation officielle actuelle de WordPress repose sur une pile moderne: PHP 8.3 ou plus, et MariaDB 10.6+ ou MySQL 8.0+. Ce point compte, parce qu’une base ancienne ou mal maintenue peut créer des lenteurs, des incompatibilités et des problèmes de sécurité qui se voient d’abord dans l’administration avant de se voir côté visiteurs.
Un autre réflexe utile consiste à distinguer les fichiers du site et la base. Les images restent dans le dossier des médias, tandis que la base conserve surtout les références, les paramètres et les relations entre les données. C’est précisément cette séparation qui explique pourquoi une sauvegarde complète doit toujours couvrir les deux côtés. Une fois ce rôle compris, la vraie question devient: quelles tables regarder en priorité?
Les tables qui méritent vraiment votre attention
Je ne conseille à personne de mémoriser toutes les tables par cœur. En pratique, quelques-unes suffisent pour diagnostiquer 80 % des cas. Le préfixe n’est pas forcément wp_, donc je vérifie toujours la valeur réelle dans wp-config.php avant de manipuler quoi que ce soit.
| Table | Ce qu’elle contient | Pourquoi elle compte |
|---|---|---|
| wp_posts | Articles, pages, pièces jointes et contenus personnalisés | C’est la colonne vertébrale du contenu. Si un site “disparaît” visuellement, je regarde souvent ici en premier. |
| wp_postmeta | Champs personnalisés liés aux contenus | Indispensable pour les thèmes avancés, les constructeurs et beaucoup d’extensions. |
| wp_options | Réglages du site, thème actif, extensions actives, valeurs globales | Une table souvent sous-estimée, mais qui grossit vite et peut ralentir un site si elle est mal gérée. |
| wp_users et wp_usermeta | Comptes, rôles, préférences, métadonnées utilisateur | Utile dès qu’un accès admin, un rôle ou une migration de comptes pose problème. |
| wp_comments et wp_commentmeta | Commentaires et données associées | Pratique pour dépanner un flux de modération ou nettoyer du spam qui s’accumule. |
| wp_terms, wp_term_taxonomy, wp_term_relationships | Catégories, étiquettes et relations entre contenus et taxonomies | Essentiel si les catégories semblent cassées, incomplètes ou incohérentes après une importation. |
Le bon réflexe, pour moi, n’est pas de tout ouvrir au hasard, mais de relier chaque symptôme à une table probable. Quand on sait où vivent les données, on peut intervenir avec les bons outils plutôt qu’à l’aveugle.
Accéder à la base sans la casser
Pour consulter ou modifier une base, j’utilise trois approches selon le contexte. phpMyAdmin reste pratique pour explorer visuellement et exporter rapidement. Adminer est une alternative légère quand l’hébergement le propose. Et WP-CLI devient vite le meilleur choix dès qu’il faut travailler vite, de manière répétable, ou sur plusieurs requêtes.
Pour les opérations de maintenance, WP-CLI a un avantage net: il s’appuie sur les identifiants déjà présents dans wp-config.php et propose des commandes utiles comme wp db tables, wp db export, wp db check ou wp search-replace. Cette dernière commande est particulièrement précieuse lors d’une migration d’URL, parce qu’elle gère les données sérialisées et propose un --dry-run pour vérifier avant d’écrire.
Quand je développe un thème ou une extension, j’évite de taper des requêtes SQL brutes partout. Je passe plutôt par $wpdb et par les API WordPress, parce que cela réduit les erreurs de syntaxe, respecte le préfixe des tables et limite les dégâts en cas d’évolution du site. Les requêtes directes restent utiles, mais elles demandent plus de discipline, surtout dès qu’une donnée sérialisée est en jeu. Avant de modifier quoi que ce soit, je préfère sécuriser le terrain avec une copie exploitable.
Sauvegarder avant toute modification
Je ne touche jamais à une base en production sans export préalable. Le plus simple consiste à faire une sauvegarde complète des tables, puis à la stocker hors du serveur: disque local, espace externe ou coffre de sauvegarde de l’hébergeur. L’idée n’est pas seulement de “posséder un fichier”, mais de pouvoir revenir en arrière sans improviser.
Avec phpMyAdmin, une exportation rapide suffit souvent pour une intervention ponctuelle. Avec WP-CLI, wp db export est plus propre pour automatiser la tâche ou l’intégrer à un script de maintenance. Dans les deux cas, je garde une règle simple: si la modification touche au contenu, aux identifiants, aux URLs ou aux réglages globaux, la sauvegarde doit précéder l’action, pas la suivre.
Je recommande aussi un test de restauration, même minimal. Une sauvegarde jamais testée reste une hypothèse rassurante. Pour un site éditorial actif, je vise au moins une fréquence régulière adaptée au rythme de publication, et je renforce la cadence avant une mise à jour majeure, une migration ou un nettoyage de tables. Quand la copie est prête, on peut enfin nettoyer ce qui alourdit vraiment le site.
Nettoyer et optimiser sans casser les données
Une base WordPress se dégrade rarement d’un coup. Le plus souvent, elle s’alourdit par petites couches: révisions trop nombreuses, commentaires indésirables, transients expirés, options de plugins qui s’accumulent, ou tables laissées derrière par une extension désinstallée. Le vrai problème n’est pas seulement la taille; c’est aussi la qualité des données et la charge qu’elles imposent à chaque requête.
| Symptôme | Cause probable | Action prudente |
|---|---|---|
| Le tableau de bord devient lent | wp_options trop lourde ou options autoloadées excessives | Examiner les options chargées à chaque requête et supprimer les valeurs manifestement obsolètes. |
| Les articles accumulent beaucoup d’historique | Révisions conservées sans limite utile | Réduire l’accumulation de révisions et nettoyer l’historique ancien après sauvegarde. |
| La migration casse des liens ou des chemins | Remplacement manuel incomplet | Passer par wp search-replace avec une vérification préalable. |
| La base garde des tables inutiles | Extensions supprimées sans nettoyage | Identifier les tables propres à l’extension avant toute suppression définitive. |
Deux précautions valent ici plus que les promesses de n’importe quel outil automatique. D’abord, ne modifiez pas à la main une donnée sérialisée sans savoir exactement ce que vous faites: une simple chaîne peut contenir une structure entière. Ensuite, n’effacez pas une table “parce qu’elle semble vide” si vous n’avez pas vérifié son lien avec une extension ou une fonctionnalité active. Après ce tri, il reste un dernier cas où il faut changer de logique: quand les données ne rentrent plus dans le schéma natif.
Quand il faut sortir du schéma standard
Le schéma par défaut suffit dans la plupart des cas: articles, pages, médias, utilisateurs, commentaires, taxonomies et champs additionnels. Pour beaucoup de projets, les custom post types et les métadonnées font parfaitement le travail. Je n’ai donc aucune envie de créer une table sur mesure “par principe”.
En revanche, dès qu’une donnée a sa propre logique métier, sa propre volumétrie et son propre cycle de vie, une table dédiée devient souvent plus saine. C’est typiquement le cas pour des commandes e-commerce, des réservations, des journaux d’événements, des données de suivi ou des structures très relationnelles qui ne se lisent pas bien dans wp_postmeta. Une table personnalisée peut alors améliorer la lisibilité, la performance et la maintenance.
Dans un plugin, je privilégie la création de cette table à l’activation, avec register_activation_hook, le préfixe fourni par $wpdb->prefix et le couple de caractères adapté via get_charset_collate(). Et j’utilise dbDelta() quand il faut créer ou faire évoluer le schéma sans réécrire toute la logique. Le revers est clair: plus on s’éloigne du modèle natif, plus il faut assumer les mises à jour, les exports, les imports et les tests de compatibilité. Avant d’ouvrir phpMyAdmin sur un vrai site, je garde encore quelques vérifications simples en tête.
Mes vérifications rapides avant d’ouvrir phpMyAdmin
-
Je confirme le préfixe réel des tables dans
wp-config.phpavant toute requête ou export ciblé. - Je note le contexte de l’intervention: migration, nettoyage, réparation ou simple lecture.
- Je fais un export complet avant tout remplacement, suppression ou optimisation.
- Je teste d’abord en copie quand l’opération touche les URLs, les rôles ou les données sérialisées.
- Je laisse l’API WordPress faire le travail dès qu’elle couvre le besoin, au lieu de forcer du SQL direct.
Si vous retenez une seule chose, gardez celle-ci: une bonne gestion de la base, ce n’est pas seulement savoir où cliquer, c’est savoir quand intervenir, avec quel outil et dans quel ordre. C’est ce qui fait la différence entre un site WordPress stable et une base difficile à maintenir au premier imprévu.
