Nettoyer la base de données : révisions, transients et tables orphelines

Une base de données WordPress de 500 Mo alors que le site ne contient que 80 articles et quelques pages : la situation est plus courante qu’on ne le croit. Révisions empilées depuis des années, transients expirés jamais purgés, tables abandonnées par d’anciens plugins, ces résidus alourdissent chaque requête SQL et finissent par ralentir l’ensemble du site. Avant de chercher un plugin de cache ou de changer d’hébergeur, il suffit souvent de nettoyer et optimiser la base de données WordPress pour récupérer entre 30 et 70 % d’espace inutilement occupé.

Pourquoi la base de données grossit silencieusement

WordPress stocke tout dans une base MySQL structurée autour de 12 tables par défaut. Au fil du temps, trois types de données parasites s’accumulent sans que l’administrateur s’en rende compte.

Le premier coupable, ce sont les révisions d’articles. Chaque fois que vous enregistrez un brouillon ou mettez à jour un article publié, WordPress crée une copie complète dans la table wp_posts. Un article modifié 40 fois au fil des mois contient donc 40 révisions, chacune avec son contenu intégral, ses métadonnées associées dans wp_postmeta et ses éventuelles relations de taxonomie. Sur un site de 200 articles actifs, cela représente facilement plusieurs milliers de lignes inutiles.

Le deuxième problème vient des transients. Ce mécanisme de cache interne à WordPress permet aux plugins et thèmes de stocker temporairement des données dans la table wp_options. En théorie, un transient a une date d’expiration. En pratique, beaucoup de plugins mal codés créent des transients sans expiration, ou WordPress ne nettoie pas systématiquement ceux qui ont expiré. Résultat : la table wp_options se remplit de lignes fantômes et, comme cette table est chargée en mémoire à chaque requête via le mécanisme autoload, chaque ligne supplémentaire ralentit le site.

Le troisième facteur concerne les tables orphelines. Lorsque vous désinstallez un plugin, WordPress devrait supprimer les tables que ce plugin avait créées. Mais la plupart des plugins ne le font pas, ou seulement partiellement. Après quelques années d’essais de différents plugins de formulaires, de sliders, de statistiques ou de SEO, votre base peut contenir une vingtaine de tables inutilisées qui occupent de l’espace et compliquent les sauvegardes. Si votre site est devenu lent, la base de données fait partie des premiers éléments à vérifier.

Sauvegarder avant toute intervention

Avant de supprimer quoi que ce soit, une sauvegarde complète de la base de données est non négociable. Un mauvais clic ou une requête SQL mal formulée peut rendre le site inaccessible en quelques secondes.

La méthode la plus fiable consiste à exporter la base via phpMyAdmin, accessible depuis le panneau de contrôle de votre hébergeur. Sélectionnez votre base, cliquez sur « Exporter », choisissez le format SQL et conservez le fichier .sql sur votre machine locale. Pour un site dont la base pèse moins de 100 Mo, l’export prend quelques secondes.

Si vous disposez d’un accès SSH, la commande mysqldump est encore plus rapide :

mysqldump -u utilisateur -p nom_base > sauvegarde_20260813.sql

Cette sauvegarde vous servira de filet de sécurité. En cas de problème, il suffit de réimporter le fichier pour restaurer l’état exact de la base. Pour un site e-commerce ou un site avec beaucoup de contenu, vérifiez que votre espace disque est suffisant pour stocker l’export. Pensez également à versionner vos fichiers si vous prévoyez des modifications de code en parallèle.

Supprimer les révisions d’articles inutiles

Les révisions sont la source numéro un de gonflement de la base de données WordPress. Voici comment les identifier et les supprimer proprement.

Mesurer l’ampleur du problème

Connectez-vous à phpMyAdmin et exécutez cette requête pour compter les révisions :

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

Si le chiffre dépasse 1 000, le nettoyage vaut clairement le coup. J’ai vu des sites de contenu afficher plus de 15 000 révisions pour seulement 300 articles publiés.

Supprimer les révisions via SQL

La requête suivante supprime toutes les révisions et leurs métadonnées associées :

DELETE a, b, c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

Sur un site avec 8 000 révisions, cette opération peut libérer entre 50 et 200 Mo d’espace. L’exécution prend généralement moins de 10 secondes.

Conserver un nombre limité de révisions

Plutôt que de supprimer toutes les révisions, vous pouvez garder les 3 ou 5 dernières par article pour conserver un historique utile. L’approche la plus simple passe par WP-CLI, que je détaille dans la section dédiée plus bas.

Purger les transients expirés et orphelins

La table wp_options est l’une des plus sollicitées de WordPress. Chaque chargement de page déclenche une requête qui récupère toutes les lignes où autoload vaut « yes ». Plus cette table contient de lignes, plus cette requête prend du temps.

Identifier les transients problématiques

Exécutez cette requête pour compter les transients dans votre base :

SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '%_transient_%';

Un site sain contient entre 50 et 200 transients. Si vous en trouvez plus de 1 000, le nettoyage est urgent. Certains plugins de réseaux sociaux ou de statistiques créent des centaines de transients qui ne sont jamais purgés.

Supprimer les transients expirés

WordPress stocke les transients en deux lignes : une pour la valeur, une pour le timestamp d’expiration. Pour supprimer uniquement les transients expirés :

DELETE FROM wp_options
WHERE option_name LIKE '%_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Puis supprimez les valeurs orphelines correspondantes :

DELETE FROM wp_options
WHERE option_name LIKE '%_transient_%'
AND option_name NOT LIKE '%_transient_timeout_%'
AND option_name NOT IN (
  SELECT REPLACE(option_name, '_timeout', '')
  FROM (SELECT option_name FROM wp_options WHERE option_name LIKE '%_transient_timeout_%') AS t
);

Après cette purge, vérifiez le poids de la table wp_options. Si elle dépasse 5 Mo, analysez les lignes restantes : il peut s'agir de données de configuration abandonnées par d'anciens plugins. L'impact sur la vitesse est souvent immédiat, car ces données participent au même type de mécanisme de cache que celui du navigateur, côté serveur.

Détecter et supprimer les tables orphelines

Chaque plugin WordPress peut créer ses propres tables dans la base de données. Le problème survient quand le plugin est désactivé puis supprimé : ses tables restent en place dans 90 % des cas.

Lister toutes les tables de la base

Dans phpMyAdmin, la liste des tables s'affiche automatiquement. Les 12 tables natives de WordPress commencent toutes par votre préfixe (généralement wp_) suivi de noms standards : wp_posts, wp_postmeta, wp_options, wp_users, wp_usermeta, wp_comments, wp_commentmeta, wp_terms, wp_termmeta, wp_term_taxonomy, wp_term_relationships, wp_links.

Toute table qui ne figure pas dans cette liste est soit créée par un plugin actif, soit orpheline. Pour distinguer les deux, croisez la liste avec vos plugins actuellement actifs.

Supprimer une table orpheline

Une fois identifiée, la suppression se fait avec une simple commande SQL :

DROP TABLE wp_yoast_seo_links;
DROP TABLE wp_yoast_seo_meta;

Faites attention : la commande DROP TABLE est irréversible. Assurez-vous que le plugin correspondant n'est plus installé et que vous avez une sauvegarde récente. En cas de doute sur l'hébergeur à utiliser pour ces opérations, consultez les critères à vérifier pour choisir un hébergeur adapté.

Optimiser les tables MySQL après nettoyage

Supprimer des lignes dans MySQL ne libère pas automatiquement l'espace disque. Les données supprimées laissent des « trous » dans les fichiers de la base, ce que MySQL appelle la fragmentation. Pour récupérer cet espace, il faut optimiser les tables.

La commande OPTIMIZE TABLE

Dans phpMyAdmin, sélectionnez les tables concernées, puis choisissez « Optimiser la table » dans le menu déroulant. En SQL direct :

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments, wp_commentmeta;

Cette commande verrouille temporairement la table pendant l'opération. Sur un site à fort trafic, planifiez l'optimisation pendant les heures creuses. Pour une table wp_posts de 200 Mo, l'opération dure entre 5 et 30 secondes selon les performances du serveur.

Résultats attendus

Après un nettoyage complet suivi d'une optimisation, j'ai constaté en moyenne les résultats suivants sur une dizaine de sites clients :

• Taille de la base réduite de 40 à 65 %
• Temps de réponse des requêtes SQL amélioré de 15 à 25 %
• Durée de sauvegarde automatique divisée par 2 en moyenne
• Temps de chargement des pages back-office réduit de 0,3 à 0,8 seconde

Ces gains s'ajoutent à ceux obtenus en travaillant sur d'autres aspects de la performance, comme la minification des fichiers CSS et JS ou la compression des images au format WebP.

Comparatif des plugins de nettoyage de base de données

Si vous n'êtes pas à l'aise avec les requêtes SQL directes, plusieurs plugins permettent de nettoyer la base depuis l'interface d'administration WordPress. Voici un comparatif des solutions les plus fiables.

WP-Optimize reste le choix le plus polyvalent. Il combine nettoyage de base, compression d'images et mise en cache dans un seul outil. Pour un nettoyage ponctuel sans garder de plugin actif en permanence, WP-Sweep fait le travail efficacement : installez-le, lancez le nettoyage, puis désinstallez-le.

Mon conseil : évitez de laisser un plugin de nettoyage actif en permanence si vous n'utilisez pas sa fonction de planification. Chaque plugin actif ajoute du poids au chargement, ce qui est paradoxal quand l'objectif est d'alléger le site. Cette logique rejoint celle que j'explique dans l'article sur les causes réelles d'un site lent.

WP-CLI : la méthode rapide sans plugin

WP-CLI est l'interface en ligne de commande officielle de WordPress. Si votre hébergeur propose un accès SSH (la plupart des offres VPS et dédiées le font), c'est la méthode la plus efficace pour nettoyer la base sans installer de plugin.

Supprimer toutes les révisions

wp post delete $(wp post list --post_type='revision' --format=ids) --force

Cette commande liste tous les posts de type « revision » puis les supprime définitivement. Sur un site avec 5 000 révisions, l'exécution prend moins de 30 secondes.

Purger les transients

wp transient delete --expired
wp transient delete --all

La première commande supprime uniquement les transients expirés. La seconde purge tous les transients, y compris ceux encore valides. Utilisez la seconde avec précaution : certains plugins devront recréer leurs données en cache, ce qui peut provoquer un léger ralentissement temporaire.

Optimiser les tables

wp db optimize

Simple, direct, efficace. Cette commande exécute un OPTIMIZE TABLE sur l'ensemble des tables de la base WordPress. Si vous hésitez entre un hébergement mutualisé et un VPS pour bénéficier de ces outils, la différence est expliquée dans le comparatif mutualisé, VPS ou dédié.

Vérifier l'état de la base

wp db check

Cette commande vérifie l'intégrité de toutes les tables et signale les éventuelles corruptions. À exécuter systématiquement après un nettoyage massif.

Prévenir l'accumulation future

Nettoyer la base une fois ne suffit pas si les mêmes mécanismes d'accumulation restent en place. Voici les réglages préventifs à mettre en œuvre.

Limiter les révisions dans wp-config.php

Ajoutez cette ligne dans votre fichier wp-config.php, avant la ligne /* That's all, stop editing! */ :

define('WP_POST_REVISIONS', 5);

Ce réglage limite à 5 le nombre de révisions conservées par article. WordPress supprimera automatiquement les plus anciennes au-delà de cette limite. Vous pouvez ajuster le chiffre selon vos besoins : 3 pour un blog personnel, 5 à 10 pour un site éditorial avec plusieurs rédacteurs.

Pour désactiver complètement les révisions (déconseillé sauf cas spécifique) :

define('WP_POST_REVISIONS', false);

Allonger l'intervalle d'enregistrement automatique

Par défaut, WordPress enregistre un brouillon automatique toutes les 60 secondes. Cet intervalle peut être augmenté :

define('AUTOSAVE_INTERVAL', 300);

Avec 300 secondes (5 minutes), vous réduisez considérablement le nombre de sauvegardes automatiques sans compromettre la sécurité de votre contenu.

Vider la corbeille plus rapidement

WordPress conserve les éléments supprimés dans la corbeille pendant 30 jours par défaut. Pour réduire ce délai à 7 jours :

define('EMPTY_TRASH_DAYS', 7);

Désinstaller proprement les plugins

Avant de supprimer un plugin, vérifiez s'il propose une option de nettoyage dans ses réglages. Certains plugins comme Yoast SEO ou WooCommerce offrent une option « supprimer toutes les données à la désinstallation » qu'il faut activer avant de procéder à la suppression. Sans cette étape, les tables orphelines resteront dans la base.

Planifier un nettoyage régulier

Définissez un calendrier de maintenance selon l'activité du site :

• Site actif (publications quotidiennes, e-commerce) : nettoyage mensuel
• Site modéré (quelques articles par semaine) : nettoyage trimestriel
• Site vitrine (rarement modifié) : nettoyage semestriel

La documentation officielle WordPress sur l'optimisation recommande également de maintenir la version de PHP à jour, ce qui améliore les performances des requêtes SQL. Si ce n'est pas encore fait, consultez le guide pour mettre à jour la version de PHP sur votre hébergement.