Plugin anti-spam WordPress : sans CAPTCHA ni Akismet

Ouvrez l’onglet Commentaires d’un site WordPress laissé sans protection deux semaines, et vous savez ce qui vous attend : des dizaines de messages vantant des produits douteux, des liens vers des pharmacies imaginaires, des « Great post! » suivis d’une URL louche. La réponse classique consiste à punir tout le monde — CAPTCHA à déchiffrer, cases à cocher, feux tricolores à identifier. Il existe une approche plus élégante : tendre aux robots un piège que vos visiteurs ne verront jamais. C’est ce qu’on appelle un honeypot, et c’est le pari du module Anti-Spam de Blaminhor Essentials.

L’essentiel

• Un honeypot est un champ de formulaire invisible pour les humains : un bot le remplit, la soumission est rejetée. Zéro friction pour vos visiteurs.
• Le module protège cinq portes d’entrée natives — commentaires (y compris connecté), connexion, inscription, mot de passe oublié — plus Contact Form 7 et WPForms.
• Tout est local : contrairement à Akismet, aucun commentaire ni aucune adresse IP ne part vers un cloud tiers pour analyse.
• Les récidivistes sont freinés par un blocage temporaire par IP — sans jamais stocker l’IP en clair (empreinte SHA-256 salée, transients auto-expirants).
• Sur le formulaire de connexion, le module est « fail-open » : dans le doute, il laisse passer — un humain légitime n’est jamais enfermé dehors.

Pourquoi les CAPTCHA sont-ils devenus un mauvais marché ?

Un CAPTCHA fait payer aux humains le travail de filtrage des robots : chaque grille d’images coûte des secondes, de la frustration et des conversions, pendant que les bots modernes équipés de résolveurs automatiques passent de mieux en mieux. Vous dégradez l’expérience de 100 % de vos visiteurs pour un filtre de moins en moins étanche.

Le problème s’est aggravé sur trois fronts. D’abord l’efficacité : les fermes de résolution et les modèles de vision résolvent aujourd’hui la plupart des défis visuels — l’écart entre l’humain et la machine, sur lequel reposait toute l’idée, se referme. Ensuite la conversion : chaque étape ajoutée à un formulaire fait abandonner une partie des visiteurs, et un CAPTCHA est l’étape la plus hostile qui soit. Enfin la conformité : reCAPTCHA transmet des données de navigation à Google avant même que le visiteur ait consenti à quoi que ce soit — la CNIL classe sa version invisible parmi les dispositifs nécessitant un consentement préalable, ce qui en fait un problème RGPD à part entière sur un site européen.

Le honeypot prend le problème à l’envers : au lieu de demander aux humains de prouver qu’ils n’ont rien d’une machine, il laisse les machines prouver qu’elles n’ont rien d’humain. Personne ne remplit un champ qu’il ne voit pas… sauf un script qui remplit tout.

Comment un champ invisible arrête-t-il les bots ?

Le module ajoute au formulaire un champ que les feuilles de style rendent invisible et inatteignable pour un visiteur : s’il revient rempli, c’est qu’un robot a rempli le formulaire champ par champ, et la soumission est rejetée avant tout traitement. Le visiteur humain, lui, ne voit strictement rien — ni case, ni question, ni délai.

Ce piège de base est complété par des contrôles qui ne demandent, eux non plus, aucune action au visiteur :

• Le délai de soumission. Un humain met plusieurs secondes à écrire un commentaire ; un bot poste le formulaire en quelques centaines de millisecondes. Soumettre trop vite est un aveu.
• Le blocage temporaire des récidivistes. Après plusieurs tentatives de spam confirmées depuis la même adresse, le module bloque cette adresse pour une durée limitée — la mécanique mérite sa propre section, car elle est faite autrement qu’ailleurs.
• Le journal de spam. Chaque tentative interceptée est consignée, pour que vous puissiez vérifier ce qui est bloqué — et constater que ce ne sont pas vos lecteurs.

En pratique, cette combinaison arrête l’écrasante majorité du spam, parce que l’écrasante majorité du spam est automatisée. Soyons honnêtes sur la limite : un humain payé pour poster des liens passera, comme il passerait un CAPTCHA qu’il résout par définition. Aucun outil ne filtre la mauvaise foi humaine ; on filtre l’industrialisation.

Pourquoi préférer un anti-spam local à Akismet ou CleanTalk ?

Parce qu’un anti-spam cloud fonctionne en expédiant chaque soumission — texte, adresse IP, email — vers des serveurs tiers pour analyse, ce qui crée un transfert de données personnelles à documenter, et une dépendance : sans le service, plus de filtre. Un honeypot local prend sa décision sur votre serveur, et vos données n’en sortent pas.

Akismet, installé par défaut avec WordPress, illustre bien le marché implicite : le filtrage est excellent, mais chaque commentaire part avec l’IP de son auteur chez Automattic, et la gratuité s’arrête où commence l’usage commercial — un site professionnel doit payer. CleanTalk suit la même logique cloud avec les mêmes implications. Ce n’est pas un scandale, c’est un modèle ; simplement, sur un site soumis au RGPD, ce modèle a un coût administratif (registre des traitements, information des personnes) que peu de propriétaires de sites ont réellement provisionné.

Comment l’activer sur votre site en deux minutes ?

Installez Blaminhor Essentials, activez le module Anti-Spam, cochez les formulaires à protéger — c’est tout : il n’y a ni clé d’API à créer, ni compte à ouvrir, ni service à connecter.

1. Installez Blaminhor Essentials et activez le module Anti-Spam (le plugin est modulaire : chaque module désactivé ne charge aucun code).
2. Choisissez les surfaces à protéger : commentaires, connexion, inscription, mot de passe oublié — et, s’ils sont installés, Contact Form 7 et WPForms sont couverts par la même case.
3. Activez le blocage temporaire par IP si vous voulez freiner les récidivistes, et réglez la fenêtre de blocage.
4. Ouvrez le journal de spam après quelques jours : vous y verrez ce qui a été intercepté, avec la raison du rejet.

J’ai activé le module sur un site de test pour réaliser ces captures : de l’installation au journal qui enregistre sa première tentative interceptée, le parcours complet tient en moins de deux minutes, chronomètre en main. La différence avec un anti-spam cloud se voit surtout à ce qu’il n’y a pas : pas d’inscription, pas de clé, pas de quota.

Un mot sur la protection du formulaire de connexion, parce que le choix est contre-intuitif : le module y est volontairement « fail-open » — en cas de signal ambigu, il laisse passer. Un spam qui passe se supprime en un clic ; un administrateur enfermé dehors, c’est une soirée perdue. Les anti-spam qui verrouillent agressivement la connexion génèrent plus de tickets de support qu’ils n’arrêtent d’attaques.

Et les adresses email affichées sur votre site ?

Le spam ne vient pas que des formulaires : les robots moissonneurs parcourent vos pages pour aspirer les adresses email écrites en clair, qui finissent dans des bases de spam revendues. Le module protège aussi cette surface-là : un shortcode [email] et un bloc Gutenberg affichent l’adresse encodée, illisible pour un moissonneur, parfaitement cliquable pour un humain.

C’est le compagnon naturel de la page Contact : vous affichez [email protected] pour vos lecteurs, et les scripts qui ratissent le HTML ne récoltent qu’une bouillie encodée. Une adresse jamais moissonnée est une adresse qui ne reçoit pas de spam — le meilleur filtre reste celui dont on n’a pas besoin.

Le comparatif en un tableau

Critère	CAPTCHA (reCAPTCHA, Turnstile)	Anti-spam cloud (Akismet, CleanTalk)	Module Anti-Spam Blaminhor Essentials
Friction visiteur	Grilles, cases, défis	Aucune	Aucune
Données envoyées à un tiers	Oui (avant consentement pour reCAPTCHA)	Oui (contenu + IP)	Non — tout est local
Prix	Gratuit (avec quota)	Payant en usage commercial	Gratuit
Formulaires couverts	Selon intégration	Commentaires surtout	Commentaires, connexion, inscription, mot de passe oublié, CF7, WPForms
Risque de blocage d’un humain	Réel (échec au défi)	Faux positifs possibles	Fail-open sur la connexion
Stockage d’IP	Chez le tiers	Chez le tiers	Jamais en clair (SHA-256 salé, transients)

Quelles limites faut-il connaître avant de choisir ?

Trois, et je préfère les écrire moi-même : le spam humain passe, le CGNAT rend le blocage d’IP imprécis, et un honeypot ne remplace pas une protection de connexion complète contre la force brute.

Le spam posté à la main par des opérateurs payés à la tâche franchit tous les pièges automatiques — c’est vrai ici comme partout, modération humaine requise. Le blocage par IP, temporaire par conception, peut effleurer des utilisateurs partageant une adresse d’opérateur mobile ; c’est précisément pourquoi il expire seul et épargne la connexion. Enfin, le honeypot filtre les bots de spam ; une attaque par force brute ciblée sur vos mots de passe relève d’une autre défense — limitation de tentatives et authentification à deux facteurs — qui dépasse le rôle d’un anti-spam.

Un spam qu’on ne voit plus, des visiteurs qu’on ne dérange plus

Le meilleur anti-spam est celui que ni vos lecteurs ni vous ne remarquez : pas de grille d’images à l’entrée, pas de dossier « en attente » qui déborde, pas de facture qui arrive quand le site devient professionnel. Un champ invisible, des contrôles de bon sens, et vos données qui restent chez vous.

Le module Anti-Spam est l’un des modules gratuits de Blaminhor Essentials, le plugin modulaire que je construis pour remplacer la pile de plugins mono-fonction — activez ce qui vous sert, ignorez le reste. Et si votre premier réflexe sécurité est plutôt la porte d’entrée elle-même, commencez par comprendre comment fonctionne la connexion à WordPress : on protège mieux ce qu’on comprend.