Nettoyer la base de données WordPress pour un site rapide
Révisions, transients expirés, méta orphelines, cron morts : la base WordPress gonfle en silence. Voici comment nettoyer chaque catégorie — et l'automatiser.
Personne ne décide de faire gonfler sa base de données WordPress — ça arrive tout seul. Vous modifiez un article vingt fois, et WordPress en garde silencieusement vingt copies. Un plugin supprimé il y a un an a laissé ses tâches planifiées tourner dans le vide. Des entrées de cache expirées qui étaient censées s’effacer d’elles-mêmes ne l’ont jamais fait. J’ai ouvert des bases de sites vieux d’un an où le contenu utile était une erreur d’arrondi à côté du superflu. Voici exactement ce qui s’accumule, ce qu’on peut supprimer sans risque, et comment garder tout ça propre sans y penser.
L’essentiel
- L’encombrement classique : révisions, brouillons automatiques, commentaires en corbeille ou en spam, transients expirés, méta orphelines, méta dupliquées, cache oEmbed et événements cron morts.
- Le Database Optimizer affiche la taille de votre base et un comptage pour chaque catégorie nettoyable avant que vous ne touchiez à quoi que ce soit — et vous laisse nettoyer chacune indépendamment.
- Les révisions sont plafonnées, pas effacées : vous choisissez combien en conserver (5 par défaut), donc votre historique d’édition récent survit.
- Le nettoyage ne peut pas être annulé, alors sauvegardez d’abord — si le module Backup est actif, l’optimiseur vous le rappelle.
- Programmez-le quotidien, deux fois par jour ou hebdomadaire et il tourne discrètement via le cron de WordPress ; les commentaires en attente de modération sont exclus par défaut, pour n’en perdre jamais un vrai.
Qu’est-ce qui encombre vraiment votre base de données WordPress ?
L’essentiel est invisible tant qu’on ne va pas voir. Voici ce qu’un site typique accumule, et pourquoi chaque élément existe :
- Les révisions d’articles — WordPress enregistre une copie complète à chaque clic sur Mettre à jour. Une page modifiée cinquante fois traîne cinquante révisions.
- Les brouillons automatiques — cliquer sur Ajouter crée une ligne de brouillon même si vous ne tapez pas un mot.
- Les articles et commentaires en corbeille — le contenu supprimé reste en base tant que la corbeille n’est pas vidée.
- Les commentaires spam — interceptés et rangés, mais ils s’empilent si vous ne les videz pas.
- Les transients expirés — des valeurs mises en cache temporairement, censées s’auto-supprimer, qui ne l’ont pas fait.
- Les métadonnées orphelines — des méta d’articles, de commentaires, de termes et d’utilisateurs dont l’objet parent n’existe plus.
- Les métadonnées dupliquées — la même clé de méta stockée plusieurs fois dans les méta d’articles, de commentaires ou d’utilisateurs.
- Le cache oEmbed — des aperçus d’intégrations que WordPress met en cache dans postmeta, souvent longtemps après la disparition de l’intégration.
- Les événements cron morts — des tâches planifiées laissées par des plugins que vous avez supprimés depuis, qui continuent de se déclencher dans le vide.
Cette dernière paire — méta dupliquées et cron morts — est justement là où la plupart des outils de « nettoyage » s’arrêtent, et ce sont souvent les contributeurs les plus sournois sur un vieux site.
Voici chaque catégorie en un coup d’œil — ce que c’est, et si on peut la supprimer sans risque :
| Catégorie de données | Ce que c’est | Suppression sans risque ? |
|---|---|---|
| Révisions d’articles | Une copie complète enregistrée à chaque clic sur Mettre à jour | Oui — plafonnées, pas effacées (5 conservées par défaut) |
| Brouillons automatiques | Une ligne de brouillon créée d’un simple clic sur Ajouter | Oui |
| Articles et commentaires en corbeille | Du contenu supprimé qui traîne encore dans la corbeille | Oui |
| Commentaires spam | Des commentaires interceptés et classés en spam | Oui |
| Transients expirés | Des valeurs en cache censées s’auto-supprimer | Oui |
| Métadonnées orphelines | Des méta d’articles, commentaires, termes ou utilisateurs sans parent | Oui |
| Métadonnées dupliquées | La même clé de méta stockée plus d’une fois | Oui |
| Cache oEmbed | Des aperçus d’intégrations mis en cache dans postmeta | Oui |
| Événements cron morts | Des tâches planifiées laissées par des plugins supprimés | Oui |
| Commentaires en attente de modération | De vrais commentaires pas encore relus | Non — exclus par défaut |
Comment nettoyer une base WordPress, catégorie par catégorie ?
Nettoyer une base de données WordPress en sécurité, c’est vider chaque type d’encombrement indépendamment, plutôt que de faire confiance à un bouton unique « tout supprimer ». Activez le module Database Optimizer de Blaminhor Essentials : sa vue d’ensemble affiche la taille de votre base et un comptage en direct pour chaque catégorie — révisions, brouillons, spam, transients, méta orphelines et dupliquées, cache oEmbed et cron morts — chacune avec son propre bouton Nettoyer, pour voir le problème avant d’agir dessus.
Chaque catégorie comptée séparément, chacune avec son propre bouton Nettoyer — c’est vous qui décidez exactement ce qui part et ce qui reste.
Chaque catégorie se nettoie indépendamment. Vous n’êtes jamais contraint à un bouton « tout nettoyer » auquel vous ne faites pas confiance ; videz le spam aujourd’hui, laissez les révisions tranquilles, revenez pour les transients plus tard. Deux détails comptent :
- Les révisions sont plafonnées, pas supprimées. Vous choisissez combien en garder — cinq par défaut — donc vous purgez l’arriéré sans perdre votre historique d’édition récent.
- Les commentaires en attente de modération sont protégés. L’optimiseur laisse les commentaires en attente intacts par défaut et vous indique qu’ils n’ont pas été comptés : un commentaire légitime que vous n’avez pas encore relu ne disparaît jamais dans un nettoyage.
Optimiser les tables récupère-t-il vraiment de l’espace disque ?
Parfois — et c’est là que beaucoup de conseils sont tout simplement faux. Après la suppression de lignes, MySQL ne rend pas toujours l’espace. Sur les anciennes tables MyISAM, lancer OPTIMIZE TABLE récupère réellement cet espace libéré, et l’optimiseur le présente comme un surplus récupérable.
Sur les tables InnoDB modernes — le format par défaut de WordPress aujourd’hui — c’est différent : l’espace « libre » que MySQL annonce est pré-alloué et géré par le moteur, et OPTIMIZE TABLE ne peut généralement pas le rendre au système d’exploitation. L’optimiseur choisit donc délibérément de ne pas compter l’espace libre InnoDB comme un surplus, parce que promettre un gain disque qu’il ne peut pas livrer ne serait que du bruit. Sur un site InnoDB, le vrai gain vient de la suppression des lignes superflues elles-mêmes — des tables plus légères et des requêtes plus rapides — pas de la chasse à un compteur de mégaoctets. C’est un détail, mais c’est la différence entre un outil honnête et un outil qui gonfle ses propres chiffres.
Peut-on le régler une fois et l’oublier ?
Oui — et c’est tout l’intérêt. Activez le nettoyage planifié et choisissez une cadence : quotidienne, deux fois par jour ou hebdomadaire (hebdomadaire est la valeur par défaut). À partir de là, il tourne en arrière-plan via le cron de WordPress, en vidant les catégories que vous avez activées, sans que vous leviez le petit doigt. Le Database Optimizer affiche même un résumé sur votre tableau de bord quand l’encombrement s’accumule, avec un nettoyage en un clic juste à côté.
À quelle fréquence faut-il nettoyer ?
Pour la plupart des sites, hebdomadaire ou mensuel suffit à garder les choses propres, sans aucun inconvénient. Si vous tenez un blog multi-auteurs très actif ou une boutique WooCommerce qui génère commandes et révisions toute la journée, penchez vers la fréquence la plus élevée. L’objectif n’est pas d’être obsédé par une base impeccable — c’est d’empêcher l’encombrement de jamais s’installer. Réglez le planning une fois, et laissez-le travailler.
Une base propre se marie naturellement avec les autres fondamentaux de la performance : une fois les tables allégées, le cache et l’optimisation front-end apportent le gain de vitesse visible que vos visiteurs ressentent vraiment.
Database Optimizer est l’un des plus de 20 outils de Blaminhor Essentials — gratuit et open source sur WordPress.org.
Télécharger Blaminhor Essentials
– blaminhor
FAQ
Nettoyer la base de données WordPress rend-il vraiment le site plus rapide ?
Oui, de deux façons : des tables plus petites signifient des requêtes plus légères, et supprimer des milliers de lignes périmées (surtout dans wp_postmeta et wp_options) réduit le travail que WordPress effectue à chaque chargement de page. Le gain est maximal sur les vieux sites jamais nettoyés ; sur un site bien entretenu, il s'agit surtout d'empêcher l'encombrement de revenir.
Est-ce sans danger de nettoyer ma base de données WordPress ?
Oui, à condition de faire une sauvegarde d'abord et de comprendre chaque catégorie. Les éléments classiques comme les révisions, le spam et les transients expirés peuvent être supprimés sans risque. La seule catégorie à ne pas toucher, ce sont les commentaires en attente de modération, que le Database Optimizer exclut par défaut. Créez toujours une sauvegarde avant un nettoyage, car l'opération ne peut pas être annulée.
Puis-je nettoyer ma base WordPress sans plugin (phpMyAdmin/SQL) ?
C'est possible, avec phpMyAdmin et du SQL — par exemple en supprimant les lignes dont le post_type vaut « revision ». Mais les requêtes brutes ne pardonnent rien : une clause WHERE mal écrite et vous perdez du vrai contenu, sans confirmation ni retour arrière. Sauvegardez d'abord, et honnêtement, un outil qui prévisualise les comptages est bien plus sûr pour la plupart des gens.
Comment limiter ou réduire les révisions d'articles dans WordPress ?
Ajoutez « define('WP_POST_REVISIONS', 5); » dans wp-config.php pour plafonner le nombre de copies que WordPress conserve par article, ou mettez la valeur à false pour désactiver complètement les révisions. Cela empêche les nouvelles de s'accumuler ; pour effacer celles déjà stockées, il faut quand même un nettoyage. Le Database Optimizer plafonne les révisions plutôt que d'effacer votre historique récent.
Pourquoi ma base de données WordPress est-elle si volumineuse ?
Souvent, c'est la table wp_options. Les plugins y stockent leurs réglages avec « autoload » à yes, si bien que WordPress les charge tous à chaque page — parfois des mégaoctets que vous n'utilisez jamais. Les transients expirés et les métadonnées orphelines s'empilent par-dessus. Élaguer les données autoloadées inutiles et les lignes périmées, c'est là que le vrai poids disparaît.
Le nettoyage de la base va-t-il supprimer mes articles ou mon contenu ?
Non. Un nettoyage bien fait cible l'encombrement — révisions, spam, transients expirés, lignes orphelines — jamais vos articles publiés, vos pages ou vos commentaires approuvés. Le Database Optimizer laisse même intacts, par défaut, les commentaires en attente de modération. La seule vraie protection reste toutefois une sauvegarde avant de lancer l'opération, car elle ne peut pas être annulée.
Commentaires