# Nettoyer une base WordPress après des années d’extensions

> Tables orphelines, options auto-chargées surchargées, révisions accumulées : ce qu’une base vieillissante contient réellement et comment la nettoyer sans casser un plugin encore actif.

- Source canonique : [https://allaux.fr/wordpress-woocommerce/mise-a-jour/nettoyer-base-donnees](https://allaux.fr/wordpress-woocommerce/mise-a-jour/nettoyer-base-donnees)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Commencez par mesurer, pas par supprimer : listez les entrées de wp_options dont autoload vaut yes et triez-les par taille, c’est ce qui est chargé à chaque requête. Purgez ensuite les transitoires expirés, puis limitez les révisions en fixant WP_POST_REVISIONS dans wp-config.php. Les tables laissées par une extension désinstallée ne se suppriment qu’après avoir vérifié qu’aucun plugin actif ne les écrit encore.

## Ce que contient réellement une base après des années d’usage

Un site WordPress de plusieurs années, passé par de nombreuses extensions installées puis désinstallées, accumule dans sa base des éléments que personne n’a jamais nettoyés. Les extensions bien conçues suppriment leurs propres tables à la désinstallation ; beaucoup ne le font pas, et laissent des tables orphelines qui continuent d’exister sans qu’aucun code actif ne les lise. La table wp_posts accumule aussi les révisions de contenu : chaque enregistrement automatique ou sauvegarde manuelle d’un article crée une nouvelle ligne, jamais purgée par défaut. Les transients, un mécanisme de cache temporaire stocké dans wp_options, expirent logiquement mais restent souvent en base bien après leur expiration si rien ne les purge.

Les métadonnées orphelines suivent la même logique : quand un article, un produit ou un client est supprimé, les lignes correspondantes de wp_postmeta ou wp_usermeta ne le sont pas toujours en même temps, surtout si la suppression est passée par une requête directe en base plutôt que par l’interface WordPress. Ces lignes orphelines n’affichent jamais rien, mais elles gonflent la base sans raison.

Le point le plus coûteux en performance est souvent le moins visible : les options marquées autoload dans wp_options. Ce sont des réglages que WordPress charge intégralement en mémoire à chaque chargement de page, quel que soit le besoin réel de cette page. Sur un site ancien, cette table peut atteindre plusieurs mégaoctets d’options autoload, chargés à chaque requête même sur une simple page produit qui n’en a besoin d’aucune.

## Comment je nettoie une base WordPress vieillissante

1. **Sauvegarde complète de la base** — Avant toute suppression, une sauvegarde de la base entière, restaurable indépendamment des fichiers du site.
2. **Identification des tables orphelines** — Je compare la liste complète des tables de la base aux préfixes des extensions réellement actives sur le site. Une table dont le préfixe ne correspond à aucun plugin installé, actif ou non, est un candidat à la suppression.
3. **Purge des révisions et des transients expirés** — Je supprime les révisions de contenu au-delà d’un nombre raisonnable conservé par article, et les transients dont la date d’expiration est dépassée.
4. **Mesure des options autoload avant et après** — Je relève la taille totale des options marquées autoload avant intervention, puis je vérifie sa réduction après nettoyage. C’est l’indicateur le plus direct de l’effet réel du nettoyage sur la performance.
5. **Vérification fonctionnelle** — Je contrôle que chaque extension active fonctionne normalement après la purge, en particulier celles qui utilisaient des transients pour leur propre cache.

## Le point de non-retour

> Supprimer une table sans être certain qu’aucune extension active ne la référence encore est le point de non-retour de cette opération. Une extension peut créer sa table à l’installation mais continuer à la lire même si son plugin frère paraît inactif, ou la recréer silencieusement au prochain chargement sans qu’on s’en rende compte tout de suite. En cas de doute sur une table, je la laisse en place ou je la renomme plutôt que de la supprimer directement.

## Comment je vérifie le résultat

> Comparaison de la taille de la base et du poids des options autoload avant et après, temps de chargement d’une page type, et absence d’erreur dans le journal pendant les jours suivant le nettoyage. Sur un site ancien, la réduction du volume autoload est souvent l’indicateur le plus parlant à montrer, bien plus qu’un simple gain de mégaoctets sur la taille totale de la base.

## Pages liées

- **Site WordPress lent** — Les causes les plus fréquentes de lenteur sur un site WordPress ou une boutique WooCommerce, base de données comprise. ([/wordpress-woocommerce/site-lent](/wordpress-woocommerce/site-lent))
- **Sauvegarder une boutique avant une intervention** — Ce qu’une sauvegarde doit couvrir avant une opération sur la base de données pour rester réversible. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Vider le cache WordPress** — La différence entre cache de page, cache d’objet et transients, et comment les vider sans tout casser. ([/guides/vider-cache-wordpress](/guides/vider-cache-wordpress))
- **Glossaire : migration** — Le vocabulaire technique utilisé sur ces pages, expliqué simplement. ([/glossaire/migration](/glossaire/migration))

## FAQ

### Pourquoi les options autoload ralentissent-elles vraiment le site ?

Parce qu’elles sont toutes chargées en mémoire à chaque requête, y compris sur des pages qui n’en ont besoin d’aucune. Plus leur volume total augmente, plus chaque chargement de page paie ce coût, même pour un simple affichage de page produit.

### Comment repérer une table orpheline sans risque de casser un plugin actif ?

Je croise la liste des tables de la base avec les préfixes des extensions réellement installées, actives ou non. Une table sans plugin correspondant, ni actif ni désactivé, est un bon candidat, mais je vérifie toujours avant suppression plutôt que de me fier uniquement au nom.

### Faut-il supprimer toutes les révisions de contenu ?

Non, je conserve un nombre raisonnable de révisions récentes par article pour garder un historique utile, et je purge seulement l’accumulation ancienne qui ne sert plus à personne.

### Un nettoyage de base peut-il casser une extension active ?

Oui, si une table ou des transients supprimés sont encore lus par une extension active. C’est pour cette raison que la vérification fonctionnelle après nettoyage porte en priorité sur les extensions qui utilisaient un cache ou une table dédiée.

### À quelle fréquence faut-il nettoyer une base WordPress ?

Il n’y a pas de fréquence universelle : ça dépend du nombre d’extensions installées puis retirées au fil du temps et du volume de contenu. Un contrôle une à deux fois par an suffit sur la plupart des sites actifs.