Quand on parle de “spam”, on pense vite aux formulaires, aux commentaires et à ce fameux flot de liens qui remonte dans la modération. Sauf que dans WordPress, le spam a aussi une autre maison: la base de données. Et c’est souvent là que se joue la différence entre un site “nettoyé” et un site “recontaminé” au prochain afflux.
J’ai vu des cas où tout semblait propre côté interface: plus de commentaires à supprimer, aucun compte suspect, aucun plugin douteux visible. Puis le backend a commencé à ralentir. Les pages prenaient une seconde de plus, parfois davantage, et surtout l’espace disque gonflait. En creusant un peu, on retrouvait des dizaines de milliers d’entrées liées à des formulaires, des transients, des brouillons, des requêtes ping ou des enregistrements “fourre-tout” déposés via des requêtes qui finissaient quand même par être stockées.
La désinfection WordPress ne se limite donc pas à supprimer ce qui se voit. Elle consiste aussi à reprendre la main sur ce qui s’écrit, se stocke et s’exécute.
Comprendre d’où vient le spam stocké dans la base
Le spam dans WordPress ne naît pas toujours avec l’intention de se faire repérer. Souvent, c’est un enchaînement de petites failles, de manque de contrôle ou de configurations trop permissives qui permet à un bot de déposer du contenu, puis de déclencher des mécanismes qui enregistrent des données.
Les vecteurs les plus fréquents que j’ai rencontrés (ou qui reviennent souvent dans des tickets) ressemblent à ceci.
D’abord, les formulaires. Contact, inscription, recherche, formulaires additionnels via des plugins. Un bot peut envoyer des requêtes avec des champs inventés, contourner une validation trop légère, puis provoquer une écriture en base. Même si aucun message n’apparaît publiquement, il peut être stocké dans une table dédiée ou via des options.
Ensuite, la section commentaires et les métadonnées associées. WordPress a des comportements internes qui conservent des états, des traces, parfois des “auteurs” et des éléments liés au modérateur. Un volume élevé peut dégrader les performances, même si tu supprimes régulièrement les commentaires visibles.
Puis il y a les brouillons, les “pending”, les restes de tentatives d’inscription et les lignes qui ne devraient pas exister. Un script malveillant peut créer des contenus en statut “draft” ou “pending”, soit pour contourner une modération, soit pour préparer une réutilisation plus tard.
Enfin, certains plugins créent des données qu’ils appellent “fonctionnelles” mais qui peuvent devenir un bac à spam. Quelques exemples: des logs d’activité, des statistiques, des caches ou des files d’attente. Quand le site se fait frapper par des requêtes automatisées, ces tables peuvent exploser.
Ce que la base de données raconte, sans mentir
Le nettoyage “au feeling” se paie. La bonne approche consiste à diagnostiquer avant d’effacer. Je garde en tête une règle simple: si tu supprimes à l’aveugle, tu risques de casser des fonctionnalités légitimes, de perdre des données utiles (tickets, tickets de support, formulaires archivés) ou de rater le vrai point d’entrée.
Concrètement, avant toute désinfection WordPress orientée base de données, je fais trois vérifications.
Premièrement, l’observation côté performance. Si le site ralentit sans raison évidente, une base gonflée est un candidat sérieux. Une table énorme, une requête qui s’emballe, ou des index qui ne suffisent plus se voient.
Deuxièmement, la cohérence de ce qui est “en trop”. Si tu vois 50 000 commentaires en attente mais que tu n’as presque pas de trafic, il y a un bot. Si tu vois des transients qui se multiplient, c’est parfois une boucle.
Troisièmement, le lien avec une source. Une IP d’origine claire, un pattern d’URL dans les logs, un pic juste après une mise à jour ou une activation de plugin. La base ne fait pas tout. Elle conserve, mais elle ne raconte pas toujours la scène complète.
La méthode la plus sûre: isoler, sauvegarder, puis traiter
Tu veux traiter le spam, mais tu veux aussi éviter la catastrophe classique: nettoyer, puis découvrir que le site ne fonctionne plus ou que tu as supprimé des données importantes.
Le socle de travail reste le même, que tu utilises phpMyAdmin, un client MySQL comme DBeaver, ou des commandes via SSH. Je commence toujours par une sauvegarde complète de la base et, si possible, des fichiers. Ensuite, je limite l’impact.
Dans les environnements de production, le piège le plus sournois est le verrouillage. Supprimer des volumes importants de lignes peut provoquer des ralentissements le temps de l’exécution, voire des timeouts sur certains hébergeurs. Quand j’ai eu un cas critique, on a dû découper la suppression en tranches et surveiller les temps d’exécution, sinon le serveur prenait trop de charge.
La logique de traitement que je privilégie ressemble à ceci: d’abord, réduire ou bloquer la source (anti-spam, règles côté formulaire, durcissement), ensuite nettoyer la base des éléments déjà déposés, enfin vérifier qu’il n’y a plus de reproduction. Sinon tu nettoies pendant que le site continue à se remplir.
Bloquer avant de supprimer: le vrai travail de désinfection
La désinfection WordPress qui tient dans la durée commence par arrêter les dépôts. Si tu ne changes rien, la base continue à se remplir et tu recommences à chaque semaine.
J’ai tendance à penser en “couches”.
La première couche, c’est la validation côté serveur. Les formulaires doivent valider les champs attendus, rejeter les requêtes sans cohérence, limiter les tailles de champs et surtout empêcher l’envoi de valeurs vides ou incohérentes. Un filtre simple peut déjà réduire drastiquement les écritures.
La deuxième couche, c’est la friction. CAPTCHA, honeypot (un champ caché que les bots remplissent), limitation du nombre d’essais. Il faut trouver un équilibre. Trop strict et tu chasses les utilisateurs légitimes, pas assez strict et tu laisses passer les scripts.
La troisième couche, c’est la protection réseau ou l’anti-bot. Parfois c’est côté CDN, parfois via un WAF, parfois via un plugin. L’important n’est pas le nom du produit, c’est la capacité à reconnaître le comportement automatisé.
La quatrième couche, c’est la discipline plugin. Si un plugin de formulaire écrit en base à chaque requête, alors il doit être configuré correctement et mis à jour. Je me méfie tout particulièrement des plugins abandonnés ou de ceux qui ont une logique de stockage trop permissive.
Quand la source est stoppée, tu peux nettoyer sans courir après le robinet.
Où se cache le spam dans WordPress (et comment le reconnaître)
Sans faire un cours de théorie, il est utile de savoir que WordPress n’a pas une seule “table spam”. Selon les plugins et les cas, les éléments se retrouvent dans différentes zones.
Pour le cœur de WordPress, les commentaires sont un point central. Les entrées en statut “spam” ou “unapproved” peuvent s’accumuler. Même quand tu supprimes les commentaires visibles, certaines métadonnées ou auteurs liés peuvent rester.
Pour les contenus créés par des bots, tu peux retrouver des posts en statut “draft”, “pending” ou “auto-draft”. Il y a aussi des cas où des entités sont créées puis supprimées partiellement, mais des traces demeurent.
Pour les formulaires, tout dépend du plugin. Certains stockent dans des tables dédiées, d’autres convertissent une soumission en “post” ou en “comment” interne, d’autres encore stockent directement dans wp_options ou des tables temporaires. C’est pour ça que deux sites identiques en apparence peuvent avoir une base différente.
Un signe récurrent, c’est l’écart entre le volume de soumissions légitimes et le volume de lignes “sales”. Si ton activité habituelle est de quelques dizaines par semaine et que tu vois des milliers de lignes par jour sans campagne en cours, tu as un bot ou une faille de validation.
Nettoyer proprement: stratégies efficaces sans casser le site
Nettoyer la base ne veut pas dire “tout supprimer”. Il faut trier.
Je commence par comprendre ce qui est effaçable sans risque. Par exemple, un spam de commentaires en statut spam est généralement supprimable sans impact sur du contenu légitime. À l’inverse, certaines tables de formulaires peuvent contenir des enregistrements dont tu as besoin pour le suivi.
Une pratique saine consiste à échantillonner avant de lancer un nettoyage. Regarder quelques enregistrements représentatifs: champs typiques, dates, auteurs, contenu, structure des données. Ce n’est pas seulement pour vérifier, c’est pour repérer les faux positifs. Un formulaire de type “newsletter” peut être spamé, mais le plugin peut enregistrer aussi des demandes légitimes qui ressemblent à du spam si tu as mis des mots-clés trop agressifs.
Ensuite, je procède par suppression ciblée et progressive. Sur un hébergement partagé ou dans des environnements sensibles, une suppression massive peut déclencher des délais. J’ai déjà vu des suppressions lourdes provoquer des “Too many connections” sur le serveur MySQL, surtout si d’autres tâches tournaient en parallèle.
Quand je décide d’effacer des volumes importants, je préfère une approche qui limite l’impact:
- d’abord supprimer ou vider ce qui est manifestement du spam et isolé, ensuite réduire la place restante, enfin optimiser la base si nécessaire.
L’optimisation, ce n’est pas toujours utile immédiatement, et ça dépend du moteur et de l’hébergement. Mais si tu as une base très fragmentée, un recalcul ou une maintenance peut améliorer les temps de requête. Il faut être prudent: certains hébergeurs n’autorisent pas certaines opérations, et un mauvais choix peut créer une fenêtre de downtime.
Une procédure pragmatique pour traiter la base
Je propose un enchaînement qui marche bien en pratique, sans prétendre à une recette universelle.
D’abord, tu mets le site en sécurité contre la reproduction. Même si tu nettoies, un bot peut continuer. Donc tu actives une protection côté formulaire et tu durcis l’accès au backend si ce n’est pas déjà fait. Tu surveilles aussi les logs pour vérifier que l’activité diminue.
Ensuite, tu fais un inventaire minimal de ce qui grossit. Tu regardes les tables concernées par le spam. Sur WordPress, c’est souvent autour des commentaires, du contenu (posts) et des tables de plugins de formulaires ou d’anti-spam.
Puis tu fais un test sur un échantillon. Tu choisis une requête de suppression ciblée basée sur le statut, la date ou une caractéristique claire. Tu exécutes une fois en petit volume, tu vérifies que rien d’utile ne disparaît et que le site reste stable.
Enfin, tu automatises le reste de manière graduelle, par tranches. Une fois que la base se calme, tu surveilles pendant quelques jours. C’est souvent dans la phase de “surveillance” que tu repères un plugin qui continue à écrire des données sur une boucle.
Voici un petit rappel de logique, pas une liste de commandes.
La suppression doit correspondre à un critère qui fait sens. Statut de commentaire, statut de contenu, présence d’éléments incohérents, date avant un https://gardewp.fr/ événement, ou appartenance à un formulaire spécifique. Si tu supprimes sur un motif trop large, tu finis par enlever autre chose.
Points d’attention que je n’ignore plus
Le premier piège, c’est les faux positifs. Certains plugins anti-spam marquent du contenu légitime comme indésirable si tu as activé des règles trop strictes. Si tu supprimes sans audit, tu perds des demandes ou des messages.
Le deuxième piège, c’est le “spam qui n’en a pas l’air”. Parfois les bots déposent des contenus dont la forme est peu visible, mais qui occupent de la place et déclenchent des traitements. Par exemple, ils génèrent des transients ou des événements.
Le troisième piège, ce sont les dépendances. Une suppression de ligne peut laisser des références cassées. Si une table de plugin conserve des relations, supprimer sans comprendre peut produire des erreurs discrètes. Dans le doute, je préfère supprimer uniquement ce qui est strictement sans relation ou ce qui est isolé par le plugin.
Le quatrième piège, c’est la sécurité. Le nettoyage ne remplace pas la correction de la faille. Si le bot passe par un endpoint exposé ou par une fonctionnalité non protégée, la base grossira à nouveau.
Cas pratiques: trois scénarios typiques
1) Commentaires en masse, “spam” et “unapproved”
Quand le problème vient des commentaires, tu vois souvent une croissance rapide autour des commentaires et de leurs métadonnées. Le site peut rester “utilisable”, mais la base se met à chauffer.
J’ai traité plusieurs cas où les commentaires en attente s’accumulaient alors que la modération était active. Le point commun était une configuration de protection insuffisante sur le formulaire d’ajout de commentaire, parfois couplée à une règle trop souple dans le plugin anti-spam. Une fois le réglage corrigé, le volume a chuté. Le nettoyage a ensuite été fait en ciblant uniquement les statuts spam et non validés, puis en surveillant.
2) Brouillons et contenus “pending” créés automatiquement
Ici, la base reflète une tentative d’injection ou de création. Tu peux repérer des contenus avec des titres répétitifs, des contenus incomplets, des auteurs “fantômes”, ou des URL internes qui n’ont aucun sens.
La tentation est de supprimer tout ce qui n’a pas l’air normal. Le risque, c’est de confondre une création automatique légitime (certains systèmes génèrent des brouillons) avec du bot. Je préfère alors recouper avec une plage de dates après une mise à jour ou une activation de plugin. Une “fenêtre” peut limiter le nettoyage à ce qui s’est produit quand le souci a commencé.
3) Plugins de formulaires: tables dédiées qui grossissent
Sur certains sites, l’anti-spam classique ne suffit pas, car le plugin de formulaire enregistre de façon interne, même quand il rejette côté affichage. Résultat: tu ne vois pas forcément le spam, mais la base se remplit.
Dans ce scénario, j’ai souvent résolu le problème en deux étapes: changer la configuration du plugin pour rejeter plus tôt et moins écrire en base, puis nettoyer la table dédiée par tranches. Le bénéfice, ce n’est pas seulement la suppression. C’est aussi la réduction du futur coût, puisque le plugin ne stocke plus ce que tu n’as de toute façon pas vocation à conserver.
Réduire le risque: règles de maintenance et garde-fous
Une fois le nettoyage fait, l’erreur courante est de relâcher la vigilance. Le spam revient sous d’autres formes, et parfois même sous une forme plus discrète.
Je mets donc en place des garde-fous simples, réalistes.
D’abord, des limites de débit sur les formulaires. Même des règles modestes réduisent drastiquement l’écriture en base.
Ensuite, une surveillance de la taille des tables concernées. Si une table grossit brutalement sans raison, c’est un indicateur précoce. Tu ne veux pas attendre que le site devienne lent.
Puis, la mise à jour. Un plugin de formulaire ou un plugin anti-spam obsolète peut créer des comportements exploités par les bots. La mise à jour n’est pas glamour, mais c’est souvent là que se trouve le verrou.
Enfin, la sauvegarde régulière et testée. Pas juste “faire une sauvegarde”. Tester la restauration à un rythme adapté à ton risque. Une restauration qui échoue coûte plus cher que le temps passé à vérifier.
Quand il faut aller plus loin que le nettoyage
Il y a des cas où la désinfection WordPress dépasse le simple “suppression des entrées”. Si tu observes une réécriture constante, des éléments créés même après suppression, ou des erreurs liées à des hooks et des actions, c’est qu’un mécanisme continue à s’exécuter.
Dans ce contexte, je regarde plusieurs choses avant de retenter un nettoyage massif:
- quels endpoints reçoivent le plus de requêtes dans les logs, si des comptes utilisateurs ont été créés (même sans contenu visible), si des thèmes ou plugins contiennent des modifications suspectes, si des fichiers ont été changés récemment, si des tâches planifiées ont été ajoutées.
Le spam dans la base peut être la conséquence, pas la cause. Une cause typique, ce sont des accès compromis ou une exploitation de fonctionnalités.
Et quand on suspecte un accès compromis, je ne me contente pas de nettoyer. Je fais aussi une remise à plat des accès, des identifiants, des sessions, puis je surveille. Le nettoyage devient alors une étape parmi d’autres.
Un mot sur les outils: plugins de désinfection et requêtes SQL
Les plugins de nettoyage et d’anti-spam peuvent aider, mais ils ont leurs limites. Certains suppriment proprement des éléments connus, d’autres déclenchent des traitements lourds. Dans les environnements où la base est déjà fragilisée, un plugin qui parcourt des centaines de milliers de lignes peut devenir un facteur de risque à lui seul.
À l’inverse, les requêtes SQL sont puissantes. Mais la puissance exige de la discipline: comprendre ce que tu supprimes, vérifier les critères, et préférer des suppressions ciblées et progressives.
Mon approche préférée est souvent hybride: utiliser un plugin pour la détection et la catégorisation quand c’est fiable, puis valider et compléter en nettoyage manuel sur des plages spécifiques. Cela réduit les surprises.
Suivre l’impact après la désinfection
Après une désinfection WordPress axée sur la base, je fais un suivi qui ressemble à une petite enquête continue.
Je vérifie que le backend répond mieux, que les requêtes lourdes diminuent, et que la source de spam ne regénère pas des milliers de lignes en quelques heures.
Je regarde aussi la qualité des données restantes. Si des vrais messages ont été supprimés, même une petite proportion, ça se voit rapidement avec les utilisateurs et les équipes support. Et si les demandes arrivent encore, je corrige la couche de blocage, pas seulement la couche de suppression.
Le bon signe, c’est quand tu n’as plus besoin de “rattraper” dans l’urgence. Le site redevient stable et prévisible.
Ce que je ferais différemment la prochaine fois
À force d’avoir nettoyé des bases gonflées, tu finis par repérer des patterns récurrents.
Souvent, le premier tri doit se faire avant d’effacer. Tuer sans analyser coûte plus cher. Ensuite, le blocage doit précéder la suppression. Si tu supprimes et que la source continue, tu perds du temps et tu fatigues la base.
Enfin, tu veux une stratégie qui traite la cause sans faire de bruit excessif côté utilisateurs. Le spam est automatisé, mais les utilisateurs légitimes ne le sont pas. Un anti-spam trop agressif peut te coûter des formulaires et de la confiance.
Si tu veux une règle simple pour garder le cap: chaque fois que tu fais une suppression massive dans WordPress, assure-toi d’avoir aussi réduit la reproduction. Sinon, tu nettoies la surface, et le reste continue de se former sous la couche visible.