Combien d’espace disque un simple article de blog occupe-t-il réellement, une fois republié une dizaine de fois au fil des relectures ? Sur un hébergement mutualisé au quota généreux, la question ne se pose jamais vraiment. Sur une offre bas de gamme limitée à quelques centaines de mégaoctets pour la base de données, elle devient centrale : c’est souvent la table wp_posts, et non les fichiers médias, qui se révèle responsable d’un quota atteint sans explication apparente.
Le mécanisme en cause n’a rien d’un bug : il s’agit du système de révisions, présent dans le cœur de WordPress depuis des années, qui enregistre l’historique des modifications d’un contenu. Ce mécanisme rend service en permettant de revenir à une version antérieure, mais il s’accumule silencieusement, sans purge automatique par défaut, jusqu’à devenir le premier poste de consommation d’espace sur un quota serré.
Ce que crée réellement une révision dans la base
Chaque révision n’est pas une simple différence par rapport à la version précédente : c’est une copie complète de l’article, stockée comme une ligne à part entière dans la table wp_posts, avec son propre identifiant et un type de contenu revision. Un article de deux mille mots enregistré vingt fois au fil de ses relectures occupe donc, en révisions seules, l’équivalent de vingt fois son propre poids en base de données.
Deux mécanismes distincts génèrent ces lignes : l’enregistrement automatique, déclenché toutes les AUTOSAVE_INTERVAL secondes par l’éditeur pendant la rédaction, et la révision explicite créée à chaque clic sur « Mettre à jour ». Sur un article travaillé pendant une heure avec de nombreuses pauses, l’enregistrement automatique seul peut générer plusieurs dizaines de révisions avant même la première publication.
Pourquoi ce mécanisme devient visible plus tôt sur un mutualisé bas de gamme
Sur un hébergement disposant de plusieurs gigaoctets pour la base de données, quelques milliers de lignes de révisions passent totalement inaperçues. Sur une offre d’entrée de gamme, où le quota alloué à MySQL se compte parfois en dizaines de mégaoctets seulement, le même volume de révisions peut représenter une part significative de l’espace disponible, en particulier sur un site géré par plusieurs rédacteurs qui republient fréquemment leurs brouillons.
Un état des lieux rapide, exécuté via WP-CLI, donne une mesure concrète du phénomène sur un site donné :
wp post list --post_type=revision --format=countIl n’est pas rare, sur un site actif depuis plusieurs années sans purge, que ce compteur dépasse largement le nombre d’articles réellement publiés, parfois dans un rapport de dix contre un.
Le rôle de AUTOSAVE_INTERVAL dans l’accumulation
La constante AUTOSAVE_INTERVAL, définissable dans wp-config.php, contrôle la fréquence de l’enregistrement automatique de l’éditeur. Sa valeur par défaut, soixante secondes, signifie qu’une session de rédaction d’une heure peut à elle seule produire jusqu’à soixante enregistrements automatiques, avant même de compter les révisions manuelles liées aux mises à jour explicites de l’article :
define( 'AUTOSAVE_INTERVAL', 120 ); // secondes entre deux enregistrements automatiquesDoubler cet intervalle ne supprime pas le problème, mais réduit mécaniquement le rythme d’accumulation pendant les longues sessions de rédaction, sans affecter la possibilité de revenir à une version antérieure du contenu.
La constante WP_POST_REVISIONS, souvent ignorée
Le nombre de révisions conservées par article se règle également via la constante WP_POST_REVISIONS, absente de nombreuses installations parce que sa valeur par défaut, illimitée, ne pose problème que lorsque le quota disque devient contraignant :
define( 'WP_POST_REVISIONS', 5 ); // conserve au maximum 5 révisions par articleUne valeur fixée à false désactive entièrement le mécanisme, ce qui supprime tout filet de sécurité en cas d’erreur de rédaction ; une valeur numérique raisonnable, entre trois et dix selon les usages de l’équipe éditoriale, conserve un historique utile sans laisser la table grossir indéfiniment.
Un mécanisme distinct de sa purge
Comprendre pourquoi les révisions s’accumulent ne dit pas encore comment nettoyer celles déjà présentes en base : cette purge, qu’elle passe par une commande WP-CLI dédiée ou par une extension de nettoyage, relève d’une opération distincte, traitée séparément de ce mécanisme d’accumulation.
Un quota disque serré ne crée pas de nouveaux problèmes : il rend simplement visibles, bien plus tôt, des mécanismes que les hébergements généreux masquent pendant des années.
En résumé
Sur un hébergement mutualisé au quota limité, la table wp_posts gonfle souvent bien avant la médiathèque, portée par un mécanisme de révisions qui enregistre une copie complète de chaque article à intervalle régulier, par défaut toutes les soixante secondes pendant la rédaction. Ajuster AUTOSAVE_INTERVAL et WP_POST_REVISIONS dès la mise en service d’un site limite l’accumulation future, même si le nettoyage des révisions déjà présentes reste une étape à part entière.
