Une base de données WordPress finit toujours par prendre du poids. C’est normal : les contenus évoluent, les extensions enregistrent des options, WooCommerce ajoute des commandes, les tâches planifiées s’accumulent, les transients expirent, et certains plugins laissent parfois quelques miettes derrière eux.
En 2026, optimiser une base WordPress ne consiste plus à lancer un script magique qui répare tout en un clic. La bonne méthode est plus simple et beaucoup plus fiable : sauvegarder, mesurer, identifier les tables lourdes, nettoyer ce qui doit l’être, puis optimiser seulement lorsque cela a du sens.
Le meilleur outil pour ce travail reste WP-CLI. Il permet de piloter WordPress depuis le terminal, avec des commandes propres, scriptables et adaptées aux sites modernes.
Avant toute chose : sauvegarder la base WordPress
Avant de vérifier, réparer, nettoyer ou optimiser une base de données, commencez toujours par une sauvegarde. C’est rapide, propre, et cela évite les sueurs froides.
Placez-vous à la racine de votre site WordPress :
cd /home/www/example.com/public_htmlVérifiez que WP-CLI détecte bien l’installation :
wp core is-installedCréez ensuite un dossier pour les sauvegardes :
mkdir -p ~/backupsExportez la base avec un nom de fichier daté :
wp db export ~/backups/wordpress-db-$(date +%Y-%m-%d-%H%M%S).sqlLangage du code : JavaScript (javascript)Enfin, vérifiez que le fichier existe bien :
ls -lh ~/backups/wordpress-db-*.sqlLangage du code : JavaScript (javascript)Sur un gros site, vous pouvez aussi compresser l’export :
gzip ~/backups/wordpress-db-*.sqlLangage du code : JavaScript (javascript)La sauvegarde n’est pas une formalité. C’est votre bouton “retour arrière”. Et dans une base WordPress, ce bouton vaut de l’or.
Vérifier l’état de la base
Une fois la sauvegarde créée, commencez par vérifier l’état des tables :
wp db checkCette commande vérifie les tables de la base à partir des identifiants présents dans wp-config.php. Si tout va bien, elle retourne une série de lignes indiquant que les tables sont correctes.
Si une table présente une erreur, vous pouvez tenter une réparation :
wp db repairEn revanche, ne lancez pas wp db repair par habitude. Sur les installations modernes, les tables WordPress utilisent normalement InnoDB. Les réparations de type REPAIR TABLE concernaient surtout les anciennes tables MyISAM. Donc, aujourd’hui, on répare lorsqu’un diagnostic indique un problème réel.
Identifier les tables les plus lourdes
Avant de nettoyer, il faut savoir ce qui prend de la place. WP-CLI permet d’afficher rapidement la taille des tables :
wp db size --tables --human-readablePour trier les tables par taille réelle directement depuis MySQL, utilisez cette requête :
wp db query "
SELECT
table_name AS table_name,
ROUND( ( data_length + index_length ) / 1024 / 1024, 2 ) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC
LIMIT 20;
"Langage du code : PHP (php)Cette commande affiche les vingt tables les plus lourdes. C’est souvent là que l’on trouve les vrais coupables : wp_postmeta, wp_options, wp_actionscheduler_actions, wp_actionscheduler_logs, les tables de statistiques, les logs de sécurité, ou les anciennes tables de plugins désinstallés.
À ce stade, l’objectif n’est pas encore de supprimer. L’objectif est de comprendre. Une base saine se nettoie avec un scalpel, pas avec une tronçonneuse.
Supprimer les transients expirés
Les transients permettent à WordPress et aux extensions de stocker des données temporaires. Ils servent souvent à mettre en cache des réponses d’API, des fragments de données ou des calculs coûteux.
Avec le temps, certains transients expirés peuvent rester en base, notamment dans la table wp_options. Vous pouvez les supprimer proprement avec WP-CLI :
wp transient delete --expiredLangage du code : JavaScript (javascript)C’est la commande la plus prudente. Elle supprime seulement les transients déjà expirés.
Si vous voulez vider tous les transients, utilisez :
wp transient delete --allLangage du code : JavaScript (javascript)Cette deuxième commande peut provoquer une petite charge temporaire, car WordPress et les extensions devront reconstruire leurs caches. Sur un site de production, commencez donc par --expired.
Nettoyer les révisions WordPress
Les révisions d’articles et de pages sont utiles. Elles permettent de revenir à une version précédente d’un contenu. Cependant, sur un site ancien, elles peuvent représenter plusieurs milliers de lignes.
Commencez par compter les révisions :
wp post list --post_type=revision --format=countLangage du code : PHP (php)Si le nombre est raisonnable, inutile de toucher. Si la table contient des années de révisions inutiles, vous pouvez les supprimer par lots :
wp post list --post_type=revision --format=ids --posts_per_page=500 | xargs -r wp post delete --forceLangage du code : JavaScript (javascript)Pour éviter que les révisions ne s’accumulent trop vite à l’avenir, ajoutez une limite dans wp-config.php :
define( 'WP_POST_REVISIONS', 10 );Langage du code : JavaScript (javascript)Dix révisions par contenu suffisent largement pour la plupart des sites. Cela conserve un historique utile sans transformer la base en grenier numérique.
Nettoyer les brouillons automatiques et les contenus à la corbeille
WordPress crée aussi des brouillons automatiques. Ils sont pratiques pendant l’édition, mais ils peuvent s’accumuler sur les sites très actifs.
Pour compter les brouillons automatiques :
wp post list --post_status=auto-draft --format=countLangage du code : PHP (php)Pour les supprimer :
wp post delete $(wp post list --post_status=auto-draft --format=ids) --forceLangage du code : JavaScript (javascript)Sur un gros site, supprimez plutôt par lots :
wp post list --post_status=auto-draft --format=ids --posts_per_page=500 | xargs -r wp post delete --forceLangage du code : JavaScript (javascript)Vous pouvez également vider les contenus présents dans la corbeille :
wp post list --post_status=trash --format=ids --posts_per_page=500 | xargs -r wp post delete --forceLangage du code : JavaScript (javascript)Là encore, ne supprimez pas par réflexe. Vérifiez d’abord ce que vous avez, puis agissez.
Surveiller la table wp_options
La table wp_options mérite une attention particulière. Elle contient les réglages WordPress, les options de plugins, certains caches, les transients, et surtout les options chargées automatiquement à chaque requête.
Ces options autoloadées peuvent impacter les performances si leur volume devient trop important. Pour mesurer leur taille totale :
wp db query "
SELECT
ROUND( SUM( LENGTH( option_value ) ) / 1024 / 1024, 2 ) AS autoload_mb
FROM wp_options
WHERE autoload IN ( 'yes', 'on', 'auto-on', 'auto' );
"Langage du code : PHP (php)Pour afficher les plus grosses options autoloadées :
wp db query "
SELECT
option_name,
ROUND( LENGTH( option_value ) / 1024 / 1024, 2 ) AS size_mb,
autoload
FROM wp_options
WHERE autoload IN ( 'yes', 'on', 'auto-on', 'auto' )
ORDER BY LENGTH( option_value ) DESC
LIMIT 20;
"Langage du code : PHP (php)Depuis WordPress 6.6, la valeur autoload n’est plus seulement limitée aux anciens yes et no. On peut aussi rencontrer des valeurs comme on, off, auto, auto-on ou auto-off. La requête ci-dessus en tient compte.
Ne supprimez jamais une option à l’aveugle. Si une option semble énorme, identifiez d’abord l’extension qui l’a créée. Ensuite seulement, décidez si vous devez la nettoyer, la désactiver de l’autoload, ou corriger le plugin responsable.
Nettoyer les sessions WooCommerce expirées
Sur un site WooCommerce, la base grossit plus vite. C’est normal : commandes, clients, paniers, sessions, tâches planifiées, webhooks, logs, métadonnées produit… WooCommerce travaille beaucoup.
Commencez par lister les outils WooCommerce disponibles en WP-CLI :
wp wc tool list --user=1Langage du code : PHP (php)Pour supprimer les transients expirés de WooCommerce :
wp wc tool run clear_expired_transients --user=1Selon votre version de WooCommerce, d’autres outils peuvent être disponibles pour nettoyer les sessions clients ou régénérer certaines données. Préférez ces outils intégrés aux requêtes SQL maison. WooCommerce connaît sa propre structure de données, autant le laisser tenir le balai.
Contrôler Action Scheduler
Action Scheduler est utilisé par WooCommerce et par de nombreuses extensions pour gérer les tâches planifiées. Sur un site actif, ses tables peuvent vite devenir volumineuses.
Vérifiez d’abord la taille des tables Action Scheduler :
wp db query "
SELECT
table_name,
ROUND( ( data_length + index_length ) / 1024 / 1024, 2 ) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
AND table_name LIKE '%actionscheduler%'
ORDER BY size_mb DESC;
"Langage du code : PHP (php)Vous pouvez ensuite consulter l’état des actions planifiées si les commandes Action Scheduler sont disponibles :
wp action-scheduler action list --status=failed --per-page=20
wp action-scheduler action list --status=pending --per-page=20
wp action-scheduler action list --status=complete --per-page=20Langage du code : PHP (php)Si les actions terminées s’accumulent, utilisez les commandes prévues par Action Scheduler ou les outils WooCommerce disponibles sur votre site. Évitez de vider les tables à la main, surtout sur une boutique en production.
Sur WooCommerce, ces tables racontent souvent l’histoire du site : paiements, abonnements, relances, webhooks, emails, synchronisations. On lit avant d’effacer.
Optimiser la base après un vrai nettoyage
Une fois les données inutiles supprimées, vous pouvez optimiser les tables :
wp db optimizeCette commande lance une optimisation des tables de la base WordPress. Elle peut être utile après une suppression importante de données, par exemple après le nettoyage massif de logs, de révisions ou de tables très volumineuses.
En revanche, elle n’a pas besoin d’être lancée toutes les semaines sur tous les sites. Sur MySQL avec InnoDB, OPTIMIZE TABLE peut reconstruire les tables et les index. Cela peut donc consommer des ressources. Lancez-la plutôt pendant une période calme, notamment sur un site WooCommerce actif.
Activer l’outil de réparation WordPress sans WP-CLI
Si vous n’avez pas accès à WP-CLI, WordPress possède un outil intégré de réparation et d’optimisation. Il se déclenche via une constante à ajouter temporairement dans wp-config.php :
define( 'WP_ALLOW_REPAIR', true );Langage du code : JavaScript (javascript)Vous pouvez ensuite ouvrir cette URL :
https://example.com/wp-admin/maint/repair.phpLangage du code : JavaScript (javascript)WordPress proposera deux actions : réparer la base, ou réparer et optimiser la base.
Une fois l’opération terminée, supprimez immédiatement cette ligne de wp-config.php. Cet outil ne demande pas d’authentification lorsqu’il est activé, car il sert aussi aux cas où la base empêche l’accès à l’administration.
C’est une bonne roue de secours. Toutefois, sur un serveur correctement administré, WP-CLI reste plus précis et plus confortable.
Ce qu’il ne faut pas automatiser aveuglément
Automatiser une maintenance WordPress peut être utile. Mais il ne faut pas automatiser n’importe quoi.
Un bon cron peut sauvegarder la base, enregistrer la taille des tables, signaler une croissance anormale, ou supprimer certains caches expirés. En revanche, un cron qui lance repair et optimize sur toute la base chaque semaine n’est pas une bonne pratique.
La réparation doit répondre à une erreur. L’optimisation doit suivre un vrai nettoyage. Le monitoring, lui, peut tourner régulièrement.
Par exemple, vous pouvez surveiller la taille globale de la base :
wp db size --human-readableOu enregistrer les plus grosses tables dans un rapport :
wp db query "
SELECT
table_name,
ROUND( ( data_length + index_length ) / 1024 / 1024, 2 ) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC
LIMIT 20;
"Langage du code : PHP (php)C’est beaucoup plus utile qu’un nettoyage automatique trop agressif. Une bonne maintenance ne fait pas du bruit. Elle donne de la visibilité.
Checklist de maintenance WordPress 2026
Voici une séquence saine pour vérifier et optimiser une base WordPress moderne :
cd /home/www/example.com/public_html
wp core is-installed
mkdir -p ~/backups
wp db export ~/backups/wordpress-db-$(date +%Y-%m-%d-%H%M%S).sql
wp db check
wp db size --tables --human-readable
wp transient delete --expired
wp db query "
SELECT
table_name AS table_name,
ROUND( ( data_length + index_length ) / 1024 / 1024, 2 ) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC
LIMIT 20;
"
wp db optimizeLangage du code : PHP (php)Sur un WooCommerce, ajoutez une vérification des outils disponibles :
wp wc tool list --user=1Langage du code : PHP (php)Puis lancez uniquement les outils pertinents pour votre site. Sur une boutique, chaque table peut avoir un rôle opérationnel. On évite donc les grands gestes héroïques. Ils finissent rarement bien.
Conclusion
Optimiser une base WordPress en 2026 demande moins de magie et plus de méthode. WP-CLI fournit tout ce qu’il faut : exporter, vérifier, mesurer, nettoyer, réparer si nécessaire, puis optimiser après un vrai ménage.
La meilleure stratégie tient en une règle simple : ne touchez jamais une base sans sauvegarde, et ne nettoyez jamais sans diagnostic.
Avec cette approche, vous gardez une base WordPress plus légère, plus lisible et plus facile à maintenir. Et surtout, vous évitez de confondre optimisation et roulette russe SQL.
Sources
- Documentation officielle WP-CLI : wp db
- Documentation officielle WP-CLI : wp db export
- Documentation officielle WP-CLI : wp db check
- Documentation officielle WP-CLI : wp db optimize
- Documentation WordPress : WP_ALLOW_REPAIR
- Documentation MySQL : OPTIMIZE TABLE
- Documentation WooCommerce : Action Scheduler
