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_html

Vérifiez que WP-CLI détecte bien l’installation :

wp core is-installed

Créez ensuite un dossier pour les sauvegardes :

mkdir -p ~/backups

Exportez la base avec un nom de fichier daté :

wp db export ~/backups/wordpress-db-$(date +%Y-%m-%d-%H%M%S).sql

Enfin, vérifiez que le fichier existe bien :

ls -lh ~/backups/wordpress-db-*.sql

Sur un gros site, vous pouvez aussi compresser l’export :

gzip ~/backups/wordpress-db-*.sql

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 check

Cette 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 repair

En 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-readable

Pour 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;
"

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 --expired

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 --all

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=count

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 --force

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 );

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=count

Pour les supprimer :

wp post delete $(wp post list --post_status=auto-draft --format=ids) --force

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 --force

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 --force

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' );
"

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;
"

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=1

Pour supprimer les transients expirés de WooCommerce :

wp wc tool run clear_expired_transients --user=1

Selon 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;
"

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=20

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 optimize

Cette 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 );

Vous pouvez ensuite ouvrir cette URL :

https://example.com/wp-admin/maint/repair.php

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-readable

Ou 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;
"

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 optimize

Sur un WooCommerce, ajoutez une vérification des outils disponibles :

wp wc tool list --user=1

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

Report a typo