Anti-spam des formulaires PrestaShop : CAPTCHA et blocage des bots

Le formulaire de contact reçoit des messages qui parlent de crypto-monnaies, de liens douteux ou de services « SEO » en anglais. Les inscriptions créent des comptes aux adresses invraisemblables. La newsletter accumule des adresses qui n’ont jamais demandé à la recevoir. Pourtant, un CAPTCHA était activé. Le problème est là : un CAPTCHA protège l’affichage du formulaire, pas son traitement. Un robot qui envoie directement une requête POST au contrôleur de contact, d’inscription ou de newsletter ne charge jamais le widget et dépose son message.

Anti-spam formulaires : CAPTCHA et blocage des bots place un contrôle côté serveur devant chaque formulaire protégé. L’envoi est examiné au début de la requête, avant que PrestaShop ou le module du formulaire ne le traite : un envoi refusé ne crée aucun compte, n’envoie aucun message, n’inscrit personne à la newsletter et ne publie aucun avis. Le module fonctionne sans compte tiers ni clé par défaut ; un CAPTCHA externe reste un choix, formulaire par formulaire.

Ce guide explique ce que fait le module, comment l’installer, réussir une première configuration et l’utiliser au quotidien.

Points forts :

• Une protection à l’envoi : jeton signé, champ piège, durée minimale et doublons, vérifiés avant le traitement du formulaire
• Des limites qui tiennent : fenêtre glissante par adresse IP et par e-mail, bannissement temporaire, listes de blocage et d’autorisation
• Le CAPTCHA de votre choix par formulaire : reCAPTCHA v2/v3, Cloudflare Turnstile, hCaptcha ou Friendly Captcha, avec test des clés
• De la visibilité : mode observation, tableau de bord sur 30 jours, journal des refus avec motif et outil « Tester ma protection »
• Vos formulaires : les sept formulaires natifs, des règles par contrôleur et une API PHP pour les modules tiers

Découvrir le module et ses formules

---

Présentation

Pourquoi un CAPTCHA ne suffit pas

Un CAPTCHA classique s’exécute dans le navigateur du visiteur. Il demande une action, vérifie un jeton ou calcule un score, puis laisse partir le formulaire. Un robot qui connaît l’URL du contrôleur n’a pas besoin de navigateur : il envoie les champs attendus directement au serveur. Le widget n’est jamais chargé, le jeton n’est jamais demandé, et le message arrive. C’est particulièrement vrai pour les formulaires de contact, d’inscription et de newsletter, dont les contrôleurs sont publics et faciles à identifier.

Les modules gratuits couvrent souvent un seul fournisseur et quelques formulaires. Ils n’offrent ni limite d’envoi, ni journal, ni moyen de vérifier qu’un thème ou un module tiers affiche bien les champs de protection. Quand le spam revient, il ne reste que le message dans la boîte de réception, sans explication.

Ce que fait le module

Le module s’accroche au tout début du traitement d’une requête, une fois le client, la boutique et la langue connus, mais avant que le formulaire ne soit traité. Il reconnaît l’envoi d’un formulaire protégé à son contrôleur et à son champ de soumission, puis applique ses contrôles dans un ordre fixe : exemptions, liste de blocage IP, bannissement actif, champ piège, jeton et durée minimale, limite par adresse IP, contrôles de l’e-mail (liste de blocage, limite, domaine jetable, MX), doublons, puis CAPTCHA si le formulaire en a un.

Le premier contrôle qui échoue décide de la réponse. Un envoi refusé est arrêté avant le code natif : rien n’est créé, rien n’est envoyé, rien n’est publié. Le visiteur voit un message explicite, ou le message générique que vous avez rédigé, et les valeurs qu’il avait saisies restent dans le formulaire. Les tentatives refusées sont comptées et journalisées avec leur motif.

Ce que le module ne fait pas

Le module ne filtre jamais la commande elle-même : ni le panier, ni le paiement, ni la confirmation, ni les adresses. Le formulaire client de la commande peut être protégé, avec des seuils volontairement larges et sans durée minimale, pour ne pas perdre une vente. Il ne remplace pas un pare-feu applicatif, ne bloque pas une page entière et ne promet pas zéro spam : un spammeur humain peut toujours remplir un formulaire correctement. Enfin, il vous aide à limiter les données collectées, mais ne certifie pas votre conformité au RGPD et ne remplace pas un conseil juridique.

Le tableau de bord : envois acceptés et bloqués, taux de blocage et courbe sur 30 jours.

Fonctionnalités

Contrôles à l’envoi

Chaque formulaire protégé reçoit un jeton signé, un champ piège invisible et une durée minimale de remplissage.

• Jeton signé : construit à partir du formulaire, de la boutique et de l’heure, il expire après 12 heures par défaut. Un formulaire resté ouvert trop longtemps est rafraîchi à la première interaction, sans que le visiteur ait à recharger la page.
• Champ piège : caché hors de l’écran, jamais accessible au clavier, avec un nom tiré au hasard à l’installation. Un robot qui remplit tous les champs le remplit aussi.
• Durée minimale : de 0 à 30 secondes selon le formulaire. Les valeurs par défaut vont de 1 seconde pour la connexion à 3 secondes pour le contact, l’inscription et les avis ; la commande reste à 0.
• Doublons : un contenu identique renvoyé dans la fenêtre configurée est refusé. Seuls les envois acceptés enregistrent une empreinte, donc une correction après un refus passe.
• Filet de sécurité : tant qu’un formulaire n’a jamais transmis les champs du module, l’absence de jeton est journalisée sans bloquer. Le tableau de bord signale la situation et l’outil de test permet de vérifier la page. Dès qu’un envoi valide a été vu, l’absence de jeton est refusée.

CAPTCHA par formulaire

Quand vous voulez une vérification supplémentaire, choisissez un fournisseur pour un formulaire donné :

• Google reCAPTCHA v2, en case à cocher ou invisible
• Google reCAPTCHA v3, avec un seuil de score réglable
• Cloudflare Turnstile
• hCaptcha, en version normale, compacte ou invisible
• Friendly Captcha

Vous saisissez vos propres clés, le module ne les affiche jamais en retour, et un bouton de test vérifie qu’elles sont acceptées et que le domaine est autorisé. Par défaut, le script du fournisseur n’est chargé que sur les pages qui contiennent un formulaire protégé par ce fournisseur, au premier contact avec le formulaire : aucune page sans formulaire ne paie le coût du script.

Deux réglages encadrent le comportement :

• Si le fournisseur est injoignable, vous choisissez de laisser passer l’envoi, qui est journalisé comme non contrôlé, ou de le refuser.
• Le consentement peut être demandé avant le chargement du script, avec le module Cookies RGPD ou un autre outil exposant une API de consentement. Sans accord, le formulaire reste protégé par les contrôles natifs, ou affiche un message si vous avez choisi de demander l’accord.

Les CAPTCHA externes ont leurs propres conditions et leur propre politique de confidentialité. C’est à vous de les mentionner dans votre politique et de choisir le consentement adapté.

Limites, listes et bannissements

Chaque envoi compte dans une fenêtre glissante par adresse IP et par adresse e-mail, avec des seuils réglables par formulaire. Au-delà du seuil, l’envoi est refusé et une marque est enregistrée. Après trois marques en 24 heures, l’adresse est bannie pendant une heure sur tous les formulaires protégés ; ces valeurs sont réglables, et un bannissement peut être levé depuis le back-office. La navigation reste toujours possible : le module ne bloque jamais une page.

Les listes acceptent des adresses IPv4 et IPv6, des plages CIDR, des adresses e-mail, des domaines et des motifs avec joker. Vous pouvez ajouter une entrée à la main, importer un CSV et exporter les listes. Une adresse présente à la fois dans la liste de blocage et dans la liste d’autorisation est autorisée : la liste d’autorisation l’emporte.

Le module fournit aussi une liste de domaines jetables, que vous pouvez compléter ou réduire, et un contrôle MX facultatif avec cache pour vérifier qu’un domaine peut recevoir du courrier.

Journal, tableau de bord et test

Le tableau de bord résume les envois acceptés, bloqués, observés, non contrôlés et exemptés, le taux de blocage, une courbe sur 30 jours, le détail par formulaire et par motif, et les adresses les plus bloquées.

Le journal des tentatives bloquées donne, pour chaque refus, le formulaire, le motif, la date, l’adresse masquée ou hachée et le domaine e-mail. Vous pouvez bloquer une adresse ou une plage, autoriser une adresse, bloquer un domaine ou lever un bannissement en un clic, puis exporter le journal en CSV. La purge est automatique au bout de 30 jours par défaut.

L’outil Tester ma protection lit la page du formulaire comme un visiteur, vérifie que les champs, le jeton et le script sont présents, envoie un envoi direct sans champs pour vérifier qu’il est refusé, et contrôle les clés du fournisseur choisi. Le résultat reste affiché jusqu’au test suivant.

Chaque refus est expliqué (champ piège, envoyé trop vite, liste de blocage) et peut être traité en un clic.

Formulaires couverts, règles et API

Le module protège les sept formulaires natifs de PrestaShop : contact, création de compte, connexion, formulaire client de la commande, mot de passe oublié, newsletter et avis produits. La création de compte pendant la commande est incluse, avec les seuils propres au formulaire client.

Pour les formulaires d’autres modules, deux solutions :

• Une règle par contrôleur, avec le nom du formulaire, la page ou le contrôleur ciblé, le champ qui marque l’envoi et, si besoin, sa valeur, le champ e-mail, les champs de contenu pour les doublons et le format de réponse attendu (page ou JSON). Vous pouvez créer jusqu’à 20 règles par boutique. Une règle prête à l’emploi couvre les alertes de disponibilité de ps_emailalerts.
• L’API PHP, documentée dans le README du module, pour qu’un module appelle les champs de protection et les contrôles depuis son propre code. Le formulaire apparaît ensuite dans la liste avec le nom du module appelant.

Les éléments de la commande sont exclus : le panier, le paiement, la confirmation, les adresses et les contrôleurs de paiement ne peuvent pas être filtrés par une règle.

Un mode, un CAPTCHA et des limites pour chaque formulaire, y compris les règles d’autres modules.

Options et exemptions

La vérification de l’e-mail à l’inscription est désactivée par défaut. Quand elle est activée, l’inscription sur la page de création de compte reçoit un lien signé et expirant ; le compte reste en attente tant que le lien n’est pas confirmé, peut demander un nouveau lien, et ne peut pas se connecter avant confirmation. La boutique ne retient jamais un compte si elle n’envoie pas d’e-mails ou si l’envoi échoue, et un compte en attente reste librement accessible si le module est désactivé ou si la licence expire.

Les employés connectés au back-office, les robots des moteurs de recherche vérifiés par DNS, les groupes de clients que vous exemptez, les adresses de la liste d’autorisation, les clients connectés selon le formulaire et les tâches planifiées ne sont pas contrôlés. Ces exemptions se règlent dans la configuration, sauf les adresses autorisées qui se gèrent dans les listes.

Multiboutique, langues et licence

Réglages, formulaires, règles, journal et statistiques sont propres à chaque boutique ; les entrées de listes peuvent être propres à une boutique ou partagées. L’interface et les messages existent en français, anglais, espagnol, italien et polonais. Les thèmes Classic et Hummingbird fonctionnent sans modification, aucun fichier de thème n’est écrit et aucun override n’est créé. La désinstallation conserve les données par défaut, avec une option pour les supprimer.

Le module fonctionne avec une licence WePresta valide. Sans licence valide, il se désactive : les formulaires ne sont plus contrôlés, aucun CAPTCHA n’est affiché et rien n’est journalisé, donc le spam peut revenir. Vos réglages, listes et journal sont conservés, et le module se réactive dès que la licence est valide.

Installation

1. Vérifiez les prérequis : PrestaShop 1.7.8, 8.0+ ou 9.0+, PHP 7.4 ou plus récent.
2. Installez le module depuis le gestionnaire de modules, avec l’archive ZIP fournie, ou copiez son dossier dans modules/ puis installez-le depuis la liste des modules.
3. À l’installation, les sept formulaires natifs sont créés pour chaque boutique en mode Protégé, sans CAPTCHA externe, avec leurs seuils par défaut. La liste de domaines jetables est ajoutée et les tables du module sont créées.
4. Ouvrez la page Configurer du module et activez votre licence WePresta. Tant que la licence n’est pas valide, le module reste désactivé et les formulaires ne sont pas contrôlés.
5. Planifiez la tâche quotidienne de maintenance, par l’adresse indiquée dans la configuration ou par la ligne de commande fournie. Elle purge le journal, les compteurs et les bannissements expirés.
6. Vérifiez les droits de vos employés : consultation, gestion et données sont trois droits distincts, contrôlés côté serveur.

Première configuration

Après l’installation, ne passez pas directement en protection sur tous les formulaires. Le module est livré avec des seuils raisonnables, mais votre boutique a ses habitudes.

1. Activez la licence et vérifiez que l’état du module est bien « Activé » sur le tableau de bord.
2. Passez les formulaires en observation avec « Tout observer ». Tous les contrôles s’exécutent, rien n’est refusé, et le journal enregistre ce qui aurait été bloqué.
3. Laissez tourner quelques jours, puis ouvrez le journal et le tableau de bord : les motifs vous disent si le blocage viserait des robots ou des clients. Vérifiez en particulier les adresses partagées par plusieurs visiteurs, comme celles d’une entreprise ou d’un opérateur mobile.
4. Testez la page de chaque formulaire avec « Tester ma protection ». Le test confirme la présence des champs, du jeton et du script, et vérifie qu’un envoi direct sans champs est refusé.
5. Passez en protection formulaire par formulaire, en commençant par le contact et la newsletter, puis l’inscription, la connexion et les avis. Laissez la commande à ses seuils larges.
6. Ajoutez un CAPTCHA seulement si nécessaire, sur un formulaire exposé, après avoir saisi vos clés et vérifié le test. Commencez par une variante invisible pour ne pas ajouter de friction.
7. Réglez les listes : ajoutez les adresses de vos partenaires et de vos outils de supervision dans la liste d’autorisation avant de serrer les limites.
8. Vérifiez la tâche planifiée : sans elle, le journal et les compteurs ne sont pas purgés et les bannissements expirés restent en place.
9. Mettez à jour votre politique de confidentialité si vous activez un CAPTCHA externe, et mentionnez le fournisseur choisi.

Utilisation au quotidien

Le tableau de bord est la vue d’ensemble : nombre d’envois acceptés et bloqués, taux de blocage, formulaires les plus visés, motifs les plus fréquents et adresses les plus bloquées. Un pic de blocage sur un formulaire se repère immédiatement.

Le journal des tentatives bloquées est la vue d’action. Pour chaque refus, vous pouvez bloquer l’adresse ou sa plage, autoriser l’adresse, bloquer le domaine e-mail ou lever un bannissement. Ces actions sont immédiates et s’appliquent à tous les formulaires protégés de la boutique. Le journal peut être exporté en CSV pour une analyse plus poussée, et purgé selon la durée de conservation choisie.

La page Formulaires montre, pour chaque formulaire, son mode, son fournisseur de CAPTCHA, sa durée minimale, ses limites, la date du dernier envoi et l’état des champs vus. Un formulaire qui n’a jamais vu les champs du module est signalé : c’est souvent le signe qu’un thème ou un module dessine le formulaire autrement, et le filet de sécurité évite alors de perdre des messages pendant que vous corrigez.

La page Listes regroupe les listes d’adresses IP, d’adresses e-mail, les domaines jetables et les bannissements actifs. L’import CSV accepte un fichier UTF-8 avec les colonnes value et note, dans la limite de 10 000 lignes et 2 Mo ; le rapport indique les lignes ajoutées, déjà présentes et refusées.

La page Comptes à vérifier apparaît quand la vérification d’e-mail est active ou qu’un compte est en attente. Elle permet de renvoyer un lien, de confirmer ou de supprimer un compte en attente.

La page Journal des actions trace les actions des employés : réglages modifiés, formulaires changés, listes importées, bannissements levés. Utile quand plusieurs personnes administrent la boutique.

Cas d’usage

Un formulaire de contact saturé de messages

Le formulaire de contact reçoit chaque nuit des messages identiques, souvent en anglais, avec un lien. Le CAPTCHA du thème ne change rien : les robots postent directement. Le module refuse les envois sans jeton, remplit le champ piège et bloque les adresses qui insistent. Le journal montre le motif de chaque refus et permet de bloquer une plage entière en un clic.

Des inscriptions qui créent des comptes fantômes

Les inscriptions automatisées polluent la liste clients et faussent les statistiques. Le module applique la durée minimale, la limite par IP et par e-mail, la liste de domaines jetables et, si besoin, le contrôle MX. La vérification d’e-mail à l’inscription empêche un compte non confirmé de se connecter.

Une newsletter qui perd ses abonnés

Des inscriptions massives à la newsletter peuvent déclencher des plaintes et abîmer la délivrabilité. La limite par adresse et par e-mail, les doublons et les listes de blocage réduisent le volume, tandis que la liste d’autorisation protège les adresses de vos partenaires.

Des avis produits noyés sous le spam

Le formulaire d’avis est exposé et les robots le connaissent. Le module le protège comme les autres, avec une durée minimale de 3 secondes et une fenêtre de doublons de 60 minutes par défaut. Le script du module désactive le champ piège vide pour que le formulaire d’avis continue de fonctionner avec son script natif.

Un module métier avec son propre formulaire

Un module de devis, de rappel ou d’alerte de disponibilité a son propre formulaire et son propre contrôleur. Une règle par contrôleur suffit pour le protéger sans toucher à son code ; sinon, l’API PHP permet au module d’appeler les contrôles depuis son propre code.

Une agence qui gère plusieurs boutiques

Chaque boutique garde ses réglages, ses formulaires, ses listes, son journal et ses statistiques. Une agence peut ainsi appliquer la même politique sans mélanger les données clients, et vérifier boutique par boutique ce qui est réellement bloqué.

Prérequis et limites

• PrestaShop 1.7.8, 8.0+ et 9.0+, sur les thèmes Classic et Hummingbird ; PHP 7.4 ou plus récent.
• Aucun compte payant n’est obligatoire : la protection native fonctionne sans clé ni abonnement. Les fournisseurs de CAPTCHA sont facultatifs et demandent leurs propres clés ; Cloudflare Turnstile demande un compte Cloudflare.
• Une tâche planifiée quotidienne est recommandée pour la purge du journal, des compteurs et des bannissements expirés ; la maintenance peut aussi se déclencher au premier accès au back-office du module ou au premier envoi contrôlé de la journée.
• Les vérifications de CAPTCHA, le contrôle MX et la vérification des robots de moteurs de recherche utilisent des appels réseau sortants. Sans réseau, le comportement choisi pour le fournisseur s’applique et un contrôle MX en échec laisse passer l’envoi.
• Le module ne peut pas promettre zéro spam : il réduit fortement les envois automatisés et fournit les moyens de voir et d’ajuster. Un spammeur humain peut toujours passer.
• Une limite trop stricte peut gêner des visiteurs derrière une même adresse. Utilisez le mode observation, les listes d’autorisation et les exemptions avant de serrer les seuils.
• Le module aide à limiter les données collectées, mais ne certifie pas la conformité au RGPD et ne remplace pas un conseil juridique. Les CAPTCHA externes ont leurs propres conditions et politique de confidentialité, à mentionner dans la vôtre.

FAQ

Faut-il retirer le CAPTCHA déjà présent dans mon thème ?

Le module ne retire pas un CAPTCHA ajouté par votre thème. Vous pouvez le laisser, mais évitez de cumuler deux CAPTCHA visibles sur le même formulaire : cela ajoute de la friction sans bénéfice. Si vous configurez un fournisseur dans le module, son script peut s’ajouter à celui du thème ; vérifiez le rendu sur la boutique avant d’activer.

Le module peut-il bloquer une commande ?

Non. Le module ne filtre jamais la commande elle-même : ni le panier, ni le paiement, ni la confirmation, ni les adresses. Seul le formulaire client de la commande peut être contrôlé, avec des seuils larges et sans durée minimale. Les éléments de la commande sont exclus des règles.

Mon formulaire est personnalisé, est-ce compatible ?

Oui, de deux façons. Une règle par contrôleur décrit le champ qui marque l’envoi et le format de réponse attendu, sans modifier le code du module tiers. L’API PHP permet au module tiers d’appeler les champs de protection et les contrôles depuis son propre code. Un formulaire qui ne passe pas par un contrôleur PrestaShop identifiable ne peut pas être protégé par une règle.

Faut-il un compte chez un fournisseur de CAPTCHA ?

Non. Les contrôles natifs, le jeton, le champ piège, la durée minimale, les limites et les listes fonctionnent sans aucun compte. Un compte n’est nécessaire que si vous choisissez un fournisseur externe, et chaque fournisseur a ses propres conditions.

Mes clients derrière une adresse partagée vont-ils être bloqués ?

Une adresse partagée par plusieurs visiteurs peut atteindre la limite plus vite qu’une adresse individuelle. C’est pour cette raison que le mode observation, les seuils par formulaire et la liste d’autorisation existent. Commencez par observer, vérifiez les envois qui auraient été bloqués, puis ajustez la limite ou ajoutez l’adresse à la liste d’autorisation si nécessaire.

Où sont stockées les données et combien de temps ?

Dans les tables du module, sur votre serveur. Le journal conserve le formulaire, le motif, la date, l’adresse masquée ou une empreinte hachée et le domaine e-mail, jamais l’adresse complète en clair par défaut. La purge est automatique après 30 jours par défaut, avec une durée réglable. Les hooks RGPD permettent d’exporter ou d’effacer les données, et la désinstallation conserve les données sauf si vous demandez leur suppression.

Que se passe-t-il si la licence expire ?

Le module se désactive : les formulaires ne sont plus contrôlés, aucun CAPTCHA n’est affiché et rien n’est journalisé, donc le spam peut revenir. Vos réglages, listes et journal sont conservés, et le module se réactive dès que la licence est valide. La boutique reste accessible dans tous les cas.

Le module garantit-il zéro spam ?

Non, et aucun module ne peut le promettre. Il réduit fortement les envois automatisés en arrêtant les requêtes qui n’ont pas chargé la page ou qui ne respectent pas les contrôles, et il vous donne les moyens de voir ce qui est bloqué et d’ajuster. Un spammeur humain peut toujours remplir un formulaire correctement ; le module ne remplace ni la modération ni votre politique de confidentialité.

Support

Pour toute aide, contactez-nous depuis votre espace client WePresta ou par e-mail à mail@wepresta.shop, selon l’option de support de votre formule.

Changelog

Version 1.0.0

• Contrôlez chaque envoi côté serveur avant que PrestaShop ne traite le formulaire : jeton signé, champ piège, durée minimale et doublons.
• Protégez les sept formulaires natifs dès l’installation, sans compte tiers ni clé : contact, création de compte, connexion, commande, mot de passe, newsletter et avis.
• Limitez les envois par adresse IP et par adresse e-mail avec une fenêtre glissante réglable par formulaire, et bannissez temporairement les adresses qui insistent.
• Gérez des listes de blocage et d’autorisation pour les adresses IPv4 et IPv6, les plages CIDR, les e-mails, les domaines et les motifs avec joker, avec import et export CSV.
• Fournissez une liste de domaines jetables et un contrôle MX facultatif avec cache.
• Choisissez un CAPTCHA par formulaire : reCAPTCHA v2/v3, Cloudflare Turnstile, hCaptcha ou Friendly Captcha, avec test des clés et comportement défini si le fournisseur est injoignable.
• Demandez le consentement avant le chargement du script du fournisseur, avec le module Cookies RGPD ou une API de consentement.
• Observez les envois sans les refuser, puis activez la protection formulaire par formulaire.
• Suivez les envois acceptés, bloqués, observés, non contrôlés et exemptés, le taux de blocage et une courbe sur 30 jours.
• Consultez le journal des tentatives bloquées avec motif, adresse masquée et domaine e-mail, agissez en un clic et exportez en CSV.
• Testez la page d’un formulaire avec « Tester ma protection » : champs, jeton, script et envoi direct sans champs.
• Ajoutez une règle par contrôleur pour un formulaire d’un autre module, avec une règle prête pour ps_emailalerts, ou utilisez l’API PHP.
• Vérifiez facultativement l’e-mail à l’inscription avec un lien signé et expirant, sans retenir un compte si l’envoi échoue.
• Exemptez les employés, les robots de moteurs de recherche vérifiés, les groupes de clients, les adresses autorisées, les clients connectés et les tâches planifiées.
• Travaillez en multiboutique, en français, anglais, espagnol, italien et polonais, sur les thèmes Classic et Hummingbird.
• Utilisez le module sur PrestaShop 1.7.8, 8.0+ et 9.0+ avec PHP 7.4 minimum.

Découvrir le module et ses formules