Réserver

Optimiser la base de données WordPress : la méthode complète

par Francis Rozange | Oct 2, 2026 | Performance

Stacked glass drawers, some overflowing, one being put back in order

Au printemps 2025, une optimisation de performance de WooCommerce a rempli la base de données de certaines boutiques de millions de tâches en attente. Sur l’une d’elles, la file d’attente comptait sept millions de tâches en attente, toutes du même type. Le correctif a été fusionné en moins de quatre heures et publié le lendemain, mais les tables gonflées sont restées.

La base de données d’un site WordPress grossit rarement d’un coup. Elle s’alourdit d’options chargées à chaque visite, de transients oubliés, de révisions accumulées, de métadonnées orphelines et, sur une boutique, de sessions et de tâches planifiées. Un jour, l’administration ralentit, la Santé du site s’inquiète, ou l’hébergeur signale un dépassement d’espace.

Ce guide propose une méthode dans l’ordre : sauvegarder et mesurer, puis traiter chaque source de poids, les options chargées automatiquement, les transients, les révisions, les métadonnées, WooCommerce, et enfin le stockage lui-même, avec les outils adaptés et une routine d’entretien.

Avant de toucher à la base : sauvegarder et mesurer

Exporter, puis vérifier que la sauvegarde se restaure

Toute opération de nettoyage commence par une exportation complète de la base, idéalement testée sur une copie du site. Avec WP-CLI, une commande suffit, et la sauvegarde doit être rangée hors du dossier public du site :

wp db export ~/avant-nettoyage.sql

Une sauvegarde n’a de valeur que si elle se restaure. Notre comparatif des plugins de sauvegarde WordPress détaille les outils qui le permettent sans ligne de commande.

Travailler sur une copie

Les nettoyages les plus lourds, suppression de révisions en masse, conversion de tables, reconstruction, se testent d’abord sur une copie du site. Vous y mesurez le gain réel, le temps nécessaire et l’espace disque consommé, puis vous appliquez la même séquence en production, à une heure creuse. Sur une boutique, choisissez un moment sans commandes en cours.

Mesurer avant d’agir

La Santé du site affiche la taille de la base dans son onglet Informations, rubrique des répertoires et tailles. WP-CLI donne le détail table par table, ce qui désigne immédiatement les coupables :

wp db size --tables --human-readable

Notez ces chiffres. Ils serviront à vérifier que chaque nettoyage a eu l’effet attendu, et à repérer une table qui regrossit.

Les options chargées automatiquement : le premier suspect

Ce que chaque requête charge

La table des options contient les réglages du site et des plugins. Une partie d’entre eux est chargée automatiquement, en un seul bloc, à chaque affichage de page, qu’ils servent ou non. Un plugin qui y range un gros réglage, ou un plugin désinstallé qui y a laissé ses données, alourdit donc chaque visite.

Ce bloc passe aussi par le cache d’objets quand il en existe un. Chez WordPress VIP, qui utilise Memcached, un objet ne peut pas dépasser un mégaoctet : un bloc d’options trop lourd y provoque une erreur. Notre guide du cache d’objets Redis explique ce mécanisme.

Ce qu’ont changé WordPress 6.6 et 6.7

Le cœur lui-même a longtemps été concerné. En 2023, une correction de WordPress 6.4 a dû traiter un transient interne du cœur, sans date d’expiration et donc chargé automatiquement, qui atteignait environ 2 Mo sur un site comptant trente plugins.

WordPress 6.6, en juillet 2024, a changé la règle : une option ajoutée sans consigne explicite n’est plus chargée automatiquement si elle dépasse 150 000 octets. La colonne de chargement accepte de nouvelles valeurs, on, off, auto, auto-on et auto-off, et WordPress 6.7 a rendu obsolètes les anciennes valeurs yes et no.

Un piège demeure : cette règle ne nettoie pas les options existantes. Une option déjà enregistrée en yes ou en on continue d’être chargée automatiquement, même si elle grossit au-delà de la limite.

Le contrôle de la Santé du site

Depuis WordPress 6.6, la Santé du site signale un problème critique quand le total des options chargées automatiquement dépasse 800 000 octets. Ce seuil est une alerte, réglable par un filtre, pas une limite technique.

Auditer avec la bonne requête

Beaucoup de guides récents utilisent encore une requête qui ne compte que la valeur yes. Depuis 6.6, elle sous-estime le total. La commande WP-CLI wp option list --autoload=on a le même défaut : elle ignore les valeurs auto et auto-on, pourtant chargées. Voici une requête juste, à adapter au préfixe de vos tables :

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bytes DESC LIMIT 20;

Face à une grosse option, désactivez son chargement automatique plutôt que de la supprimer : c’est réversible, et cela suffit à alléger chaque requête. WP-CLI le fait sans toucher à la valeur :

wp option set-autoload nom_de_l_option off

Les données laissées par les plugins

Désinstaller un plugin ne supprime pas toujours ses options : beaucoup en laissent derrière eux, parfois chargées automatiquement. Felix Arntz, contributeur du cœur, résume la bonne pratique pour les développeurs : une option qui ne sert que dans des circonstances particulières ne doit pas être chargée automatiquement. Pour repérer les restes, triez les options par préfixe : la plupart des plugins nomment leurs réglages avec leur propre préfixe, ce qui permet de les rattacher à un plugin installé ou disparu.

Le plugin Performance Lab, de l’équipe performance de WordPress, ajoute à la Santé du site un tableau des options les plus lourdes, avec un bouton pour désactiver leur chargement. AAA Option Optimizer observe quelles options sont réellement utilisées pendant la navigation, avec une limite : son auteur conseille une semaine d’observation, et une option utilisée une fois par mois par une tâche planifiée paraîtra alors inutile.

Les transients : un cache qui s’installe

Expiration et chargement automatique

Les transients sont des données temporaires que les plugins stockent avec une durée de vie. Un détail du code compte beaucoup : un transient créé avec une expiration n’est pas chargé automatiquement, mais un transient créé sans expiration l’est, et n’expire jamais. Ce sont ces derniers qui alourdissent le bloc d’options.

Un transient expiré est supprimé quand on le lit, et une tâche quotidienne supprime les autres. Mais cette tâche n’est programmée qu’après une visite de l’administration, et ne fait rien quand un cache d’objets externe est actif : les transients vivent alors dans le cache, plus dans la base.

Purger sans casser

WP-CLI distingue deux opérations. La première supprime les transients expirés, sans risque. La seconde supprime tous les transients, ce qui force les plugins à recalculer leurs données, avec un ralentissement passager :

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

La documentation le rappelle : la durée d’un transient est un maximum, pas un minimum. Un plugin bien écrit ne doit jamais supposer qu’un transient est encore là.

Les transients d’une boutique

WooCommerce range de nombreux calculs dans des transients : produits associés, prix, compteurs. Ses outils, dans l’onglet Outils de la page État de WooCommerce, proposent de supprimer les transients expirés de tout le site, ou de vider ses propres transients de boutique, qui se reconstruisent ensuite. Le second outil sert après une importation massive de produits ou un changement de règles de prix, pas en entretien courant.

Révisions, brouillons automatiques et corbeille

Limiter les révisions

Par défaut, WordPress conserve un nombre illimité de révisions pour chaque contenu. Sur un site éditorial actif, elles finissent par peser lourd dans les tables des articles et de leurs métadonnées. Une constante, dans wp-config.php, fixe un plafond :

define( 'WP_POST_REVISIONS', 3 );

Attention, ce plafond ne supprime rien immédiatement. Les révisions en trop d’un article ne sont élaguées qu’au prochain enregistrement de cet article. La corbeille se vide automatiquement au bout de trente jours par défaut.

Sauvegardes automatiques et brouillons

L’éditeur enregistre automatiquement le contenu en cours toutes les soixante secondes par défaut, un intervalle réglable avec la constante AUTOSAVE_INTERVAL. Chaque utilisateur n’a qu’une sauvegarde automatique par contenu, remplacée à chaque fois, et une tâche quotidienne de WordPress supprime les brouillons automatiques, créés à l’ouverture d’un nouveau contenu, au bout de sept jours. Les principaux plugins de nettoyage les traitent avec les révisions, et la corbeille se règle avec EMPTY_TRASH_DAYS.

Supprimer par l’API plutôt qu’en SQL

Pour supprimer toutes les révisions existantes, y compris les plus récentes, passez par WP-CLI, qui utilise les fonctions de WordPress et efface aussi les métadonnées et les caches associés :

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

Une suppression en SQL brut laisse des métadonnées orphelines derrière elle. Notre sélection de commandes WP-CLI essentielles détaille ces commandes.

Les métadonnées orphelines

Les compter

Une métadonnée orpheline est rattachée à un contenu qui n’existe plus. Une jointure suffit à les compter, la même que celle qu’utilise le plugin WP-Optimize :

SELECT COUNT(*) FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Les faux orphelins

Toutes les données qui paraissent orphelines ne le sont pas. WP-Sweep le reconnaît dans sa propre documentation : Polylang et WPML stockent des données qu’il prend pour des orphelines. Sur un site multilingue, protégez leurs clés avant tout nettoyage. Sur une boutique passée au stockage des commandes haute performance, les anciennes métadonnées de commandes se nettoient avec la commande wp wc hpos cleanup all de WooCommerce, une fois le mode de compatibilité désactivé, pas avec un outil générique.

WooCommerce : sessions et file d’attente

La table des sessions

WooCommerce garde les paniers des visiteurs dans une table de sessions : deux jours pour un visiteur, sept jours pour un client connecté par défaut. Une tâche planifiée la nettoie toutes les douze heures, par Action Scheduler depuis la version 10.1 et par petits lots depuis 10.3. Une durée de session de plus de trente jours est acceptée, mais WooCommerce l’inscrit dans ses journaux comme un risque pour les performances.

L’outil « Effacer les sessions clients », dans l’onglet Outils de la page État de WooCommerce, vide toute la table : tous les paniers en cours, y compris ceux des clients connectés, disparaissent. Ce n’est jamais un geste d’entretien courant.

Le nettoyage automatique depuis WooCommerce 10.1

WooCommerce 10.1, en août 2025, a confié à Action Scheduler ses tâches de nettoyage qui passaient auparavant par les tâches planifiées de WordPress : sessions expirées, commandes non payées, journaux. Ces nettoyages dépendent donc du bon fonctionnement de la file d’attente. Sur une boutique passée au stockage des commandes haute performance, les commandes vivent dans des tables dédiées, ce que détaille notre guide de HPOS pour WooCommerce.

La file d’attente Action Scheduler

WooCommerce et de nombreux plugins confient leurs tâches de fond à Action Scheduler, une bibliothèque qui stocke chaque tâche dans ses propres tables. Les tâches terminées ou annulées sont purgées au bout de trente et un jours. Avant la version 4.0, livrée avec WooCommerce 11.0 en août 2026, les tâches en échec n’étaient jamais purgées : elles le sont désormais au bout de trois mois.

Avant de nettoyer, regardez ce que contient la file, tâche par tâche et statut par statut :

SELECT hook, status, COUNT(*) AS n
FROM wp_actionscheduler_actions
GROUP BY hook, status ORDER BY n DESC LIMIT 20;
Un tapis sans fin de jetons de verre qui s'accumulent plus vite qu'on ne les retire

Le cas réel : WooCommerce 9.8 et les sept millions de tâches

L’incident de WooCommerce 9.8, au printemps 2025, est documenté heure par heure sur GitHub et sur les forums de WordPress.org. Il montre comment une file d’attente, qui est une table comme une autre, peut faire gonfler une base plus vite que n’importe quel nettoyage.

Une optimisation de performance

En février 2025, un développeur de WooCommerce propose de ne calculer les produits associés qu’une fois par jour, et de déplacer la suppression de leurs transients vers une tâche en arrière-plan, pour ne plus bloquer l’enregistrement d’un produit. La modification sort avec WooCommerce 9.8.0, en avril 2025.

Le défaut tient en une ligne : chaque enregistrement de produit ou changement de stock programme une nouvelle tâche, sans vérifier qu’une tâche identique attend déjà. Sur un catalogue actif, la table des tâches d’Action Scheduler explose.

Le 29 avril 2025

Ce matin-là, une équipe qui gère plusieurs boutiques ouvre un ticket : la table de la file d’attente a atteint des millions de lignes, dont sept millions de tâches en attente pour cette seule suppression de transients sur certaines boutiques. Revenir à la version 9.7.1 fait disparaître le problème, et le ticket renvoie vers sept discussions du forum décrivant le même symptôme.

L’équipe de WooCommerce répond en un peu plus d’une heure et identifie la modification en cause. Peu après, un développeur reconnaît le défaut : rien n’empêchait de programmer des tâches en double. Le correctif ajoute une mémoire des produits déjà programmés dans la requête et une recherche d’une tâche identique avant d’en créer une nouvelle. Il est fusionné le jour même, et WooCommerce 9.8.3 sort le 30 avril.

Le correctif ne vide pas les tables

Les semaines suivantes montrent la limite d’un correctif : il arrête la production de nouvelles tâches, mais ne nettoie pas celles qui existent. En mai, une boutique sud-africaine de quarante mille produits, pourtant déjà en 9.8.4, signale encore quinze mille tâches en retard et une charge serveur très élevée, puis revient à la version 9.7.1 parce que la situation l’affecte financièrement.

L’échantillon que l’équipe examine montre des tâches programmées le 10 avril, avant le correctif, et déjà exécutées ; le propriétaire découvre ensuite d’autres soucis de MySQL, et l’équipe juge le lien avec la file non démontré.

Dès le 28 avril, la veille du ticket, le propriétaire d’une petite boutique, à peine 177 produits mais 759 variations, décrivait sur le forum de WordPress.org une charge processeur élevée qu’il attribuait à ces mêmes tâches. Il a neutralisé l’appel en cause dans le code et fait d’autres réglages sur son site ; deux jours plus tard, sa charge processeur était retombée. Même un petit catalogue pouvait être touché, pour peu que ses stocks bougent souvent.

Le 23 mai 2025, sur le forum anglophone de WooCommerce, une boutique hébergée chez OVH, pourtant déjà en version 9.8.4, signale que sa base passe de 190 Mo à 1 Go en trois jours, à cause des tables de la file et de leurs journaux. Son propriétaire vidait les tables à la main dans phpMyAdmin, puis a programmé un nettoyage quotidien. Le support a orienté vers le correctif et suspecté un conflit de plugin, sans conclusion définitive.

La réponse de fond

Ce type de problème, des tables de file qui grossissent sans limite, a nourri la version 4.0 d’Action Scheduler, en juin 2026 : purge automatique des tâches en échec au bout de trois mois et nettoyage quotidien dédié. Elle est livrée avec WooCommerce 11.0, le 4 août 2026.

Ce qu’il faut en retenir

Une file d’attente est une table, et un producteur sans limite la remplit plus vite que tout nettoyage. Ce gonflement échappait aux outils courants : la version gratuite de WP-Optimize ne nettoie pas les tables d’Action Scheduler. Diagnostiquez par tâche et par statut avant de supprimer quoi que ce soit.

Corrigez d’abord la source, en mettant à jour, puis nettoyez : nettoyer d’abord, c’est voir la table se remplir à nouveau. Nettoyez par la commande dédiée, qui supprime aussi les journaux, plutôt que dans phpMyAdmin, qui laisse des lignes orphelines. Et ne supprimez jamais les tâches en attente à l’aveugle : elles contiennent des renouvellements d’abonnements, des courriels, des webhooks.

wp action-scheduler clean --status=complete,failed,canceled --before='31 days ago'

InnoDB, OPTIMIZE TABLE et index

Convertir les tables MyISAM restantes

WordPress ne fixe pas de moteur de stockage : ses tables prennent celui du serveur, InnoDB sur les versions récentes de MySQL et MariaDB. Les très vieux sites gardent parfois des tables MyISAM, qu’une requête sur le schéma de la base permet de repérer. La conversion vers InnoDB demande de l’espace disque pour l’ancienne et la nouvelle table, et une sauvegarde préalable.

Cette requête liste les tables qui utilisent encore MyISAM, et la commande suivante en convertit une, après sauvegarde :

SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE() AND ENGINE = 'MyISAM';

ALTER TABLE wp_exemple ENGINE=InnoDB;

InnoDB gère mieux les écritures simultanées et la reprise après incident, deux qualités qui comptent sur une boutique ou un site très fréquenté.

Ce que fait vraiment OPTIMIZE

Sur InnoDB, OPTIMIZE TABLE ne défragmente pas au sens habituel : il reconstruit la table. Supprimer des lignes ne réduit pas la taille du fichier ; la reconstruction rend l’espace au système quand chaque table a son propre fichier, le réglage par défaut. C’est utile après une grosse suppression, rarement le reste du temps, et cela demande assez d’espace libre pour la copie. WP-CLI lance cette opération sur toute la base :

wp db optimize

La page d’optimisation de la documentation officielle conseille encore de régler le cache de requêtes de MySQL. Ce conseil est dépassé : MySQL 8.0 a supprimé ce cache, et MariaDB le désactive par défaut parce qu’il tient mal la charge sur les serveurs multicœurs.

L’outil de réparation intégré

WordPress propose une page de réparation et d’optimisation de la base, activée par la constante WP_ALLOW_REPAIR. La documentation prévient que, tant que la constante est active, cette page est accessible sans être connecté. Activez-la le temps de l’opération, puis retirez-la aussitôt.

Les index

Le cœur ajoute des index au fil des versions : un index sur la colonne de chargement des options en 5.3, un index sur les articles par type, statut et auteur en 6.9, pour les sites qui comptent beaucoup de contenus. Le plugin gratuit Index WP MySQL For Speed ajoute des index plus performants aux tables de métadonnées et d’options. S’il est désactivé sans avoir retiré ses index, ces index restent en place.

Plugins ou WP-CLI : quel outil pour quel travail

WP-Optimize, de l’équipe d’UpdraftPlus, installé sur plus d’un million de sites, nettoie révisions, brouillons, corbeille, commentaires indésirables, transients expirés et métadonnées orphelines, avec des nettoyages programmés. Sa version Premium commence à 49 dollars par an pour deux sites au moment où nous écrivons.

Advanced Database Cleaner montre options, métadonnées, tâches planifiées et tables avant toute suppression, avec leur taille et leur mode de chargement. La détection de l’origine des données orphelines et le nettoyage d’Action Scheduler sont réservés à sa version payante, à partir de 39 dollars par an pour un site au moment où nous écrivons.

WP-Sweep, gratuit, supprime par les fonctions de WordPress plutôt que par des requêtes brutes, et propose des commandes WP-CLI ; attention à son incompatibilité déclarée avec Polylang et WPML. Query Monitor, enfin, ne supprime rien mais repère les requêtes lentes, en double ou en erreur, et les plugins qui les génèrent.

Repérer les requêtes lentes

Nettoyer la base ne corrige pas une requête mal écrite. Query Monitor, installé sur une copie ou activé ponctuellement en production, signale les requêtes lentes et les requêtes répétées, et indique le plugin ou le thème qui les déclenche. C’est souvent là que se trouve le vrai gain : un plugin qui interroge la table des métadonnées sans index peut coûter plus que des milliers de révisions.

Pour une personne à l’aise avec la ligne de commande, WP-CLI couvre presque tout, avec un avantage : chaque commande s’écrit, se relit et se rejoue.

Tableau récapitulatif

Problème Symptôme Geste sûr Risque
Options chargées trop lourdes Alerte de la Santé du site Désactiver le chargement automatique Supprimer une option encore utilisée
Transients accumulés Table des options qui grossit Supprimer les expirés Ralentissement après une purge totale
Révisions Tables des articles volumineuses Plafond et suppression par WP-CLI Perte d’un historique utile
Métadonnées orphelines Table des métadonnées lourde Compter, puis nettoyer avec un outil Faux orphelins multilingues
File Action Scheduler Tables de tâches énormes Mettre à jour, puis nettoyer par statut Supprimer des tâches en attente
Espace disque non rendu Fichiers qui ne rétrécissent pas OPTIMIZE après une grosse suppression Manque d’espace pour la copie

Une routine d’entretien

Chaque mois, comparez la taille des tables à vos chiffres de référence, consultez la Santé du site et le contenu de la file Action Scheduler sur une boutique. Supprimez les transients expirés et les révisions au-delà de votre plafond. Chaque trimestre, auditez les options chargées automatiquement et les données laissées par les plugins désinstallés.

Ces tâches dépendent aussi du bon fonctionnement des tâches planifiées de WordPress, qui déclenchent les nettoyages automatiques. Notre checklist de maintenance WordPress intègre cette routine au reste de l’entretien du site.

Questions fréquentes

Faut-il optimiser les tables chaque semaine ?

Non. Sur InnoDB, l’optimisation reconstruit la table et n’apporte quelque chose qu’après une suppression importante. Une optimisation hebdomadaire consomme des ressources sans bénéfice mesurable.

Faut-il supprimer les options d’un plugin désinstallé ?

Oui, si vous êtes certain que le plugin ne sera pas réinstallé et que l’option lui appartient bien. En cas de doute, désactivez d’abord son chargement automatique : le gain est le même, et le retour en arrière possible.

Faut-il convertir toutes les tables en InnoDB ?

Oui, pour les tables d’un site WordPress récent, sauf contrainte particulière de l’hébergeur. Faites-le sur une copie d’abord, avec une sauvegarde, et vérifiez l’espace disque disponible, puisque la conversion recrée chaque table.

Combien de révisions garder ?

Trois à dix suffisent pour la plupart des sites. Un site éditorial avec plusieurs relecteurs peut en garder davantage. L’essentiel est de fixer un plafond, puisque la valeur par défaut est illimitée.

Un cache d’objets dispense-t-il de nettoyer la base ?

Non. Il masque une partie de la charge, mais les options chargées automatiquement transitent toujours par lui, et les tables continuent de grossir. Avec un cache externe, seuls les transients quittent la base : révisions, métadonnées et tables de file restent à surveiller.

Peut-on vider les tables d’Action Scheduler ?

Pas entièrement. Les tâches en attente sont du travail à venir. Supprimez les tâches terminées, annulées ou en échec au-delà d’un certain âge, avec la commande dédiée, et laissez les tâches en attente.

Conclusion

Optimiser une base WordPress tient moins de la technique que de la méthode : sauvegarder, mesurer, comprendre d’où vient le poids, corriger la source, puis nettoyer avec des outils qui passent par WordPress. Les commandes les plus spectaculaires, vider une table, optimiser chaque semaine, sont rarement les plus utiles.

L’incident de WooCommerce 9.8 le rappelle : la base grossit souvent à cause d’un comportement, pas d’un oubli. Regardez ce qui la remplit avant de la vider, et installez une routine qui vous préviendra la prochaine fois.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier