Sur un site WordPress qui fonctionne depuis des années, la sécurité ne se gagne pas avec une “grosse nouveauté”, elle se gagne avec des décisions modestes et répétées. Parmi les plus efficaces, il y a souvent quelque chose de très concret: revoir ce qui tourne dans la base de données, puis réduire ce qui n’a plus de raison d’exister.
Supprimer des tables inutiles et nettoyer certains composants peut sembler purement technique. En réalité, cela touche directement à la surface d’attaque. Chaque table, chaque champ, chaque mécanisme de compatibilité représente une surface potentielle, ne serait-ce que parce qu’il faut comprendre comment l’applicatif y accède. Plus votre installation est “propre”, plus le nombre de chemins possibles baisse, et plus les erreurs de configuration ont de chances d’être détectées tôt.
Dans cet article, je vous propose une approche pragmatique du durcissement WordPress centrée sur la base de données: identifier les tables qui ne servent plus, évaluer le risque avant de supprimer, puis appliquer des mesures qui réduisent la complexité sans casser le site.
Le lien entre tables et surface d’attaque
Quand on parle de sécurité WordPress, on pense aux plugins, aux permissions serveur, aux thèmes et à la gestion des comptes. C’est logique, mais la base de données a aussi son rôle.
Une base de données “gonflée” fait rarement mieux les choses pour trois raisons.
La première, c’est l’augmentation des chemins applicatifs. Si des tables sont présentes, le code peut (au moins théoriquement) y faire des requêtes, même si ce n’est plus utilisé dans l’interface. Dans un monde parfait, le code ne ferait jamais ce genre de choses, mais dans le monde réel, on trouve des requêtes conditionnelles, des backdoors anciennes jamais activées, des compatibilités qui traînent.
La deuxième raison, c’est la probabilité d’actions inattendues. Plus vous avez de structures, plus il est https://gardewp.fr/securite-wordpress/ facile de laisser passer une configuration qui donne trop de latitude à un plugin, à un thème, ou à un script d’automatisation.
La troisième raison, c’est l’audit. Quand la base contient beaucoup de “bruit”, il devient plus coûteux de vérifier ce qui existe vraiment, ce qui est cohérent, et ce qui est optionnel. Un audit plus lent finit souvent par être moins complet, donc moins utile.
Nettoyer des tables inutiles n’est pas une garantie absolue contre une faille applicative, mais c’est un levier de durcissement WordPress réaliste: vous réduisez l’ampleur de ce qu’un acteur malveillant pourrait exploiter, et vous simplifiez la maintenance.
D’abord, distinguer “inutiles” de “dangereuses”
Le piège classique, c’est de confondre une table “orpheline” et une table qui a un usage discret.
Par exemple, certaines tables appartiennent à des modules que vous n’utilisez plus, mais qui restent actifs via un plugin “muet”. D’autres tables servent à des caches, des historiques, ou des mécanismes de restauration. Supprimer trop tôt peut casser un workflow: export, migration, planification d’articles, logs internes, ou même un plugin qui est “désactivé” mais pas supprimé.
Dans la vraie vie, j’ai vu des sites où le propriétaire avait supprimé des éléments de cache en croyant nettoyer. Deux semaines plus tard, une fonctionnalité d’export échouait. La cause était une table de support que le plugin attendait, même si elle n’était pas alimentée. Le problème n’était pas dramatique, mais il a fallu replonger dans l’historique et le temps perdu a dépassé le gain initial.
Donc, avant de toucher aux tables, vous avez besoin d’un critère. Pas juste “elle a l’air inutile”, mais une hypothèse vérifiable.
Voici une manière de raisonner sans se raconter d’histoires.
Vous pouvez classer les tables en trois catégories.
La catégorie 1, c’est “tables WordPress de cœur”. Elles sont stables: wp options, wpposts, wp postmeta, wpusers, etc. On ne touche pas.
La catégorie 2, c’est “tables nécessaires à la version ou à des fonctionnalités actives”. Celles-ci sont à conserver.
La catégorie 3, c’est “tables de plugins ou d’extensions supprimés, ou clairement vides depuis longtemps, sans dépendance connue”. Celles-ci sont les candidates.
Le but est de passer de “candidats” à “conservables avec certitude”, puis seulement ensuite envisager la suppression.
Observer la base sans casser la prod
Avant de supprimer quoi que ce soit, je recommande une phase d’observation.
D’abord, listez les tables existantes et leur taille. Une table “vide” n’est pas toujours inutile, mais une table volumineuse ou remplie d’anciennes données est souvent un meilleur candidat. C’est particulièrement vrai si vous avez récemment désinstallé des plugins. Les désinstallations proprement faites suppriment parfois tout, mais ce n’est pas systématique.
Ensuite, regardez les références applicatives. Les tables de plugins ont souvent des noms prévisibles, comme wp wpformsentries (exemple générique), ou wp smushxxxx. Cela dit, il faut rester prudent: certains plugins créent des tables sans préfixe évident, ou utilisent des structures génériques.
Enfin, validez l’état fonctionnel du site. Un site qui n’a pas de problème apparent peut quand même cacher une dépendance. Donc, testez les flux que vous utilisez vraiment: connexion, création d’un brouillon, publication, sauvegarde de médias, formulaires, exports, synchro mail, et tâches planifiées. Si ces flux ne déclenchent pas d’erreurs après votre nettoyage, c’est bon signe.
Il existe un dernier point d’observation qui vaut de l’or: les journaux.
Si votre hébergement ou votre stack centralise des logs, cherchez les erreurs de requêtes SQL. Même une seule erreur récurrente peut révéler qu’une partie du code tente encore d’accéder à une table. Dans ce cas, la table n’est pas “inutilisée”, elle est “accédée avec un mauvais contexte” ou “non alimentée”.
Construire un inventaire des tables “suspectes”
Une approche efficace consiste à faire un inventaire par cycles.
Cycle 1: tables qui correspondent à des plugins ou modules supprimés. On peut souvent inférer la correspondance en comparant le nom de la table et le nom de l’extension. Si vous n’avez plus l’extension dans l’administration, ni dans le dossier, ni dans votre politique d’update, la table est candidate. Mais encore une fois, confirmez avec les logs et avec une recherche rapide dans le code.
Cycle 2: tables vides ou quasi vides depuis longtemps. Si une table ne contient que quelques lignes anciennes, et qu’aucune requête ne la sollicite, vous êtes plus proche d’un cas “orphelin”. La notion de “depuis longtemps” dépend de votre rythme. Sur un site e-commerce, quelques semaines peuvent être significatives. Sur un blog personnel, plusieurs mois peuvent être tolérables.
Cycle 3: tables dont le schéma ne correspond à rien d’actuel. Certains plugins changent de structure à des versions différentes. Vous pouvez vous retrouver avec une ancienne table laissée en place après migration. Le code pointe vers la nouvelle structure, l’ancienne devient une relique.
Le durcissement ne consiste pas à tout supprimer “par principe”. Il consiste à supprimer ce qui ne contribue plus au fonctionnement, tout en évitant de casser ce qui est silencieusement utilisé.
Vérifier avant suppression: dépendances, cohérence et sauvegarde
La suppression d’une table est un geste irréversible à l’échelle applicative. Elle doit être traitée comme une opération de maintenance avec un plan.
Je vous conseille trois garde-fous avant d’attaquer la moindre suppression.
Premièrement, faites une sauvegarde complète, pas juste un export partiel de la base. Un export SQL peut manquer certains éléments selon la méthode, et une restauration incomplète peut vous piéger. Une sauvegarde fichier plus base est idéale.
Deuxièmement, isolez un environnement de test si possible. Même un staging simple, avec la même version PHP et la même version de WordPress, permet de valider rapidement. Sans staging, vous pouvez limiter le risque en planifiant l’intervention sur une fenêtre courte, avec un monitoring strict et un rollback préparé.
Troisièmement, gardez une trace de ce que vous supprimez. Le meilleur “durcissement” est celui que vous pouvez expliquer. Notez le nom de la table, sa taille, le plugin présumé, et la date. Si un incident survient plus tard, cette trace vous fera gagner des heures.
Voici une courte checklist, pensée pour éviter les erreurs de base:
- Vérifier la présence effective du plugin ou du composant supposé dépendre de la table Contrôler les logs d’erreurs SQL sur les jours précédant la maintenance Confirmer que le schéma de la table ne correspond pas à une fonctionnalité active Prévoir une sauvegarde restaurable, testée en relisant son existence Faire les tests fonctionnels après suppression, au minimum sur les flux essentiels
Cette liste ne remplace pas une analyse, mais elle réduit les oublis fréquents.
Cas typiques de tables inutiles, et comment décider
Les tables inutiles ne se présentent pas toujours comme “vides”. Parfois, elles sont remplies d’historiques, mais aucun code actuel n’y touche.
Tables de caches et de pré-calculs
Certains plugins génèrent des caches en base. Si vous utilisez déjà un système de cache externe (par exemple un cache applicatif et un cache serveur), ces tables peuvent ne plus servir. Le risque ici, ce n’est pas seulement casser la performance. C’est aussi d’oublier qu’une purge était déclenchée par un cron qui s’attend à une structure.
Dans ce cas, la suppression doit être accompagnée d’un test des tâches planifiées. WordPress utilise WP-Cron, mais beaucoup de sites forcent une exécution côté serveur. Si le cron ne tourne pas correctement après votre changement, le plugin peut rester en mode dégradé.
Tables d’historiques et de logs
Certains plugins d’audit ou de conformité écrivent des logs en base. Même si vous n’utilisez plus l’interface, le plugin peut rester actif en tâche de fond. C’est rare si vous avez désinstallé le plugin correctement, mais ça arrive.
Les logs en base sont parfois une bonne chose, mais ils peuvent devenir un problème de surface d’attaque, surtout si des données sensibles s’y accumulent. Si votre plugin est encore actif, la meilleure action peut être la rétention, pas la suppression.
Tables d’anciens modèles de formulaires
Les formulaires sont un bon exemple. Un plugin peut passer d’un schéma à un autre entre deux versions majeures. Si vous mettez à jour régulièrement, vous devriez garder une seule structure. Mais sur des sites qui ont été “trimballés” entre versions, on trouve parfois des tables historiques.
Le critère le plus robuste est simple: est-ce que les formulaires consultent ces tables? Cherchez le nom de la table dans le code du plugin. S’il n’apparaît plus, et que les logs ne montrent aucune requête, la table est candidate.
Tables associées à un échange de données externe
Certains plugins d’intégration à des services tiers (webhooks, marketing, CRM léger) stockent des files d’attente, des confirmations, ou des états. Si vous migrez ensuite vers une autre solution, ces tables restent parfois.
Là, la suppression est sensible. Même si vous ne voyez plus rien dans l’interface, un processus asynchrone peut utiliser encore ces tables. Avant de supprimer, vous devez comprendre si vous avez des traitements en arrière-plan qui attendent ces données.
Réduire aussi la complexité du “chemin d’exécution”
Supprimer une table, c’est bien. Mais le durcissement WordPress passe aussi par la réduction des chemins d’accès.
Réduisez les composants qui provoquent des requêtes inutiles, même sans supprimer leur table. Par exemple, désactivez ou supprimez les plugins qui ne sont plus requis. Ensuite, assurez-vous que le plugin est vraiment “désinstallé”, pas seulement désactivé.
Sur WordPress, “désactivé” et “supprimé” ne veulent pas dire la même chose. Beaucoup d’extensions gardent leurs tables tant qu’elles ne sont pas supprimées via le mécanisme d’uninstall. C’est précisément le point qui rend votre base plus large que nécessaire.
Une action souvent sous-estimée consiste à standardiser votre procédure de retrait. Quand vous décidez qu’un plugin n’a plus d’utilité, documentez la procédure, vérifiez l’impact, puis supprimez et uninstallez proprement, si le plugin le permet.
Méthode pratique: suppression avec contrôle
Je vais rester volontairement général sur la mécanique exacte, parce que les commandes varient beaucoup selon le moteur de base, l’outil utilisé et les permissions. Mais la méthode de décision est la même.
Vous identifiez la table candidate. Vous validez l’absence de dépendance. Vous supprimez, ou mieux, vous mettez en retrait d’abord.
“Mettre en retrait” peut vouloir dire déplacer la table ou la renommer temporairement si votre process le permet. Sur certains systèmes, renommer la table permet de détecter immédiatement des erreurs de requête sans détruire l’historique. Si le site ne génère aucun souci pendant une période courte, vous pouvez confirmer et supprimer.
Cette stratégie est utile sur les sites où vous ne pouvez pas reproduire facilement l’environnement, ou où vous n’avez pas de staging.
Une autre stratégie consiste à exporter la table avant suppression, pour restaurer si besoin. Même si vous avez une sauvegarde globale, un export ciblé accélère la restauration. Je l’ai utilisé plus d’une fois quand une opération s’est révélée plus risquée que prévu. Cela dit, gardez en tête que l’export doit aussi préserver le schéma, pas seulement le contenu.
Réduire le risque lié aux anciens plugins
La surface d’attaque ne vient pas seulement des tables, elle vient aussi des versions obsolètes.
Nettoyer des tables inutiles sans traiter les plugins obsolètes ressemble à repeindre une pièce où les fenêtres restent ouvertes. Dans la pratique, les deux actions se renforcent.
Si vous avez une base qui contient des traces de plugins désinstallés, c’est souvent le signe que la stratégie de retrait n’a pas été systématique. Vous pouvez rattraper cela en auditeur.
Regardez la liste des extensions installées et identifiez celles qui sont en “désactivé”. Ensuite, vérifiez si elles restent présentes en code. Si vous avez supprimé le dossier, mais que les tables restent, vous avez le scénario typique de tables orphelines.
Le durcissement WordPress gagne à être traité comme un cycle. Tous les mois, ou à chaque relance de maintenance, vous vérifiez les plugins et leur santé. Cela évite que de nouvelles tables “fantômes” s’accumulent.
Signaux à surveiller pendant et après la maintenance
La suppression de tables peut avoir des effets tardifs, pas seulement immédiats. Un flux peut être rare, déclenché par un formulaire spécifique, ou par un cron.
Pour éviter les surprises, surveillez quelques signaux.
Voici les signaux les plus utiles que j’ai observés dans mes interventions:
- erreurs 500 liées à des requêtes SQL dans les logs applicatifs pages de formulaire qui affichent des données vides, ou qui ne soumettent pas comportements “bizarres” sur les tâches planifiées (reprises, purges, sync) hausse brutale de requêtes vers wp-admin ou des tentatives de login lenteurs soudaines sur des pages censées être stables, souvent liées à un fallback en code
Si vous voyez plusieurs de ces signes, stoppez. Une restauration partielle ou un rollback est plus rentable que “continuer à corriger” sans comprendre.
Quand il vaut mieux ne pas supprimer
Il y a des cas où supprimer une table est une mauvaise idée, même si elle paraît “inutile”.
Si vous êtes en train de migrer, par exemple vers un autre plugin, une table peut être utilisée comme source de vérité pendant la migration. Supprimer “pour alléger” peut casser la migration en cours.
Si votre site utilise une conformité ou une politique de rétention, supprimer certains logs en base peut aussi être contraire à votre cadre, même si c’est utile. La sécurité n’est pas seulement technique, c’est aussi gouvernance.
Enfin, si vous n’avez pas un moyen fiable de restaurer, vous vous exposez à un risque disproportionné. Sur un site critique, la suppression doit être précédée d’un plan de rollback testé.
Dans ces cas, la meilleure action peut être la purge de contenu, pas la suppression structurelle. Ou alors, limiter l’accès à ces tables via les patterns applicatifs, en désactivant ce qui les interroge.
Réduction de surface: au-delà des tables
Une base de données propre améliore la sécurité, mais vous pouvez aller plus loin sans complexifier.
Visez une réduction globale de la surface d’attaque en combinant ces leviers, sans multiplier les réglages au hasard.
D’abord, vérifiez les permissions: comptes WordPress, rôle des utilisateurs, et comptes inutiles. Ensuite, renforcez la séparation entre l’utilisateur de la base et les privilèges. L’idée, c’est que l’applicatif n’ait pas besoin de permissions excessives.
Ensuite, faites attention à la mise à jour de PHP, aux versions WordPress, et aux plugins. Une faille exploitée passe rarement par une table “inutilisée” seule. Plus souvent, elle passe par un plugin vulnérable qui interagit avec des données.
En pratique, un schéma sain ressemble à ceci: base clarifiée, plugins épurés, et environnement serveur cohérent. C’est la somme de petites réductions qui finit par compter.
La question qui revient: comment savoir si une table est vraiment “inutile”?
La réponse honnête, c’est qu’il n’y a pas un bouton magique.
Il y a trois niveaux de confiance.
Confiance faible: table orpheline supposée, sans logs, sans recherche de code. Là, vous gagnez à faire une mise en retrait plutôt qu’une suppression.
Confiance moyenne: table associée à un plugin désinstallé, code ne fait plus référence à la table, et logs ne montrent plus de requêtes. Ici, la suppression est raisonnable avec sauvegarde et tests.
Confiance élevée: table non référencée dans le code, aucune requête observée pendant un cycle complet (incluant les crons), et tests fonctionnels couvrent les workflows liés. Là, vous pouvez supprimer plus sereinement.
La plupart des situations réelles se rangent dans “confiance moyenne”, et c’est déjà un bon niveau tant que vous appliquez rigueur et rollback.
Un scénario concret, typique sur des sites qui évoluent
Imaginez un site WordPress qui a utilisé un plugin de formulaires pendant deux ans. Le plugin a été remplacé par une autre solution, mais quelqu’un a simplement désactivé l’ancienne extension. Quelques semaines plus tard, la base a des tables spécifiques à l’ancien plugin. Vous ne les voyez pas dans l’interface, mais elles restent.
En examinant la base, vous trouvez une table qui contient surtout des données anciennes, aucune nouvelle entrée depuis longtemps. Vous vérifiez les logs, aucune erreur SQL n’apparaît et il n’y a pas de requêtes actives vers cette structure.
Vous procédez à un test prudent: vous mettez la table en retrait, vous déclenchez les flux de soumission du nouveau formulaire, vous vérifiez les tâches planifiées, et vous surveillez le trafic et les erreurs. Si tout reste stable sur une fenêtre raisonnable, vous supprimez définitivement.
Le gain de sécurité vient de la baisse de complexité et de la réduction des chemins potentiels. Le gain de maintenance vient du fait qu’au prochain audit, vous ne partez pas d’un paysage rempli de reliques.
Ce genre de scénario n’est pas spectaculaire, mais il est très fréquent. Et justement parce qu’il est fréquent, il mérite une procédure.
Choisir la bonne cadence de maintenance
Le durcissement WordPress se fait rarement en une fois. En base, les tables inutiles s’accumulent avec chaque plugin installé, modifié, désinstallé, puis oublié.
Une cadence réaliste dépend de la taille de l’équipe et du rythme d’évolution. Sur un site géré par une seule personne, une vérification trimestrielle des plugins et un inventaire des tables candidates peut être un bon compromis.
Sur un site avec plusieurs contributeurs, plus de mises à jour, et plus d’automatisation, une revue mensuelle est plus confortable. Pas pour tout supprimer, mais pour détecter tôt les anomalies.
Si vous attendez que la base soit trop grosse, vous multipliez le temps d’analyse et vous augmentez le risque d’erreurs.
Ce que je ferais en premier, si je devais commencer ce durcissement maintenant
Sans connaître votre contexte exact, je prioriserais la clarté et la réduction du doute.
Je commencerais par un inventaire: tables, tailles, correspondance probable avec plugins. Ensuite, je vérifierais les erreurs SQL et les requêtes pendant un cycle normal. À partir de là, je choisirais un petit périmètre de suppression ou de mise en retrait, sur une table candidate à confiance moyenne.
Je testerais les flux essentiels et je surveillerais 24 à 72 heures, selon votre trafic. Ensuite, seulement si tout est stable, je passerais à la suite.
Le but n’est pas de “nettoyer tout d’un coup”. Le but est de rendre la base plus simple, sans créer un nouveau sujet.
Dernier point: durcir, c’est aussi documenter
Quand vous supprimez des tables, vous modifiez un état qui ne se voit pas dans l’administration WordPress. Cette invisibilité est trompeuse: vous pourriez être la seule personne à savoir ce qui a été retiré.
Documentez vos actions, même brièvement. Un fichier interne avec la date, la table, la raison de suppression, et la fenêtre de test vous sauvera si un plugin revient, si un audit est demandé, ou si vous changez de prestataire.
La sécurité, ce n’est pas seulement l’exploit. C’est la capacité à reprendre la main rapidement, sans repartir de zéro.
Si vous voulez, vous pouvez me donner le résultat de votre inventaire (noms des tables, préfixe, taille approximative, et plugins associés présumés). Je pourrai vous aider à prioriser les candidats et à estimer le niveau de risque pour chacune, sans vous faire faire une suppression à l’aveugle.