Comment bloquer le spam des formulaires PrestaShop : CAPTCHA et bots

Votre formulaire de contact reçoit chaque nuit des messages identiques, en anglais, avec un lien. Les inscriptions créent des comptes aux adresses invraisemblables, et la newsletter accumule des adresses qui n’ont jamais rien demandé. Un CAPTCHA est pourtant actif. Le plus souvent, il ne protège que l’affichage du formulaire : un robot qui envoie une requête POST directement au contrôleur ne le charge jamais. Ce guide montre comment reprendre la main côté serveur, quels formulaires protéger, comment régler le module sans perdre de clients et lire ce qui est refusé.

Pourquoi le spam passe-t-il encore alors qu’un CAPTCHA est actif ?

Parce qu’un CAPTCHA protège l’affichage du formulaire, pas son traitement. Un robot qui connaît l’adresse du contrôleur envoie les champs attendus directement au serveur, sans navigateur et sans widget.

Les contrôleurs de contact, d’inscription et de newsletter sont publics et faciles à identifier. Une requête POST bien formée suffit : le widget n’est jamais chargé et le message arrive dans la boîte. Des boutiques reçoivent donc encore du spam avec un reCAPTCHA actif.

Quels formulaires le module protège-t-il ?

Le module Anti-spam formulaires : CAPTCHA et blocage des bots protège les sept formulaires natifs de PrestaShop : contact, création de compte, connexion, formulaire client de la commande, mot de passe oublié, inscription à la newsletter et avis produits.

À l’installation, ces sept formulaires passent en mode Protégé, sans CAPTCHA externe. La page Formulaires les liste avec leur mode, leur CAPTCHA, leur durée minimale, leurs limites, la date du dernier envoi et l’état Champs dans la page. Le bouton Modifier ouvre les réglages d’un formulaire ; Tout protéger et Tout observer changent le mode de toute la liste.

Pour les formulaires d’autres modules, deux solutions. Une règle cible un contrôleur, avec le champ qui marque l’envoi et le format de réponse attendu ; le bouton Ajouter une règle la crée, dans la limite de 20 règles par boutique. Une règle prête à l’emploi couvre les Alertes de disponibilité des produits (ps_emailalerts). L’API PHP, documentée, permet à un module d’appeler les contrôles depuis son propre code.

La commande elle-même n’est jamais filtrée : ni le panier, ni le paiement, ni la confirmation, ni les adresses. La page d’identité et la réinitialisation du mot de passe ne sont pas protégées non plus.

Pour qui ce module est fait

• Une boutique qui reçoit du spam sur le contact, l’inscription ou la newsletter malgré un CAPTCHA déjà installé.
• Une boutique qui veut voir ce qui est refusé, et pourquoi, au lieu de constater les dégâts dans sa boîte mail.
• Une agence qui gère plusieurs boutiques et veut régler la protection boutique par boutique.

Pour qui il ne l’est pas

• Une boutique sans formulaire exposé : il n’y aurait rien à protéger.
• Un marchand qui cherche un pare-feu applicatif ou une protection contre les attaques par déni de service : ce n’est pas le rôle du module.
• Un marchand qui attend zéro spam : aucun module ne peut le promettre, et un spammeur humain peut remplir un formulaire correctement.

Comment installer et régler la protection pas à pas ?

Installez le module, activez la licence, laissez d’abord tous les formulaires en observation, puis passez en protection formulaire par formulaire après avoir lu le journal.

1. Vérifiez les prérequis : PrestaShop 1.7.8, 8.0+ ou 9.0+, PHP 7.4 ou plus récent.
2. Installez l’archive depuis le gestionnaire de modules. Les sept formulaires natifs sont créés pour chaque boutique et la liste de domaines jetables est ajoutée.
3. Ouvrez Configurer 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.
4. 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, les bannissements expirés et les autres données arrivées à échéance.
5. Ouvrez Formulaires et cliquez Tout observer. Tous les contrôles s’exécutent, rien n’est refusé et le journal enregistre ce qui aurait été bloqué.
6. Laissez tourner quelques jours, puis ouvrez le Journal des tentatives bloquées et le Tableau de bord : les motifs montrent si le blocage viserait des robots ou des clients derrière une adresse partagée.
7. Lancez Tester ma protection. L’outil lit la page du formulaire comme un visiteur, vérifie la présence des champs, du jeton et du script, teste un envoi direct sans champs pour vérifier qu’il serait refusé, et contrôle les clés du fournisseur choisi.
8. Passez en protection avec Tout protéger, ou formulaire par formulaire en commençant par le contact et la newsletter, puis l’inscription, la connexion et les avis. Laissez le formulaire client de la commande à ses seuils larges et sans durée minimale.
9. Ajoutez un CAPTCHA seulement si un formulaire reste visé, après avoir saisi vos clés et vérifié le bouton Test. Placez les adresses de vos partenaires dans la liste d’autorisation avant de resserrer les limites.

Le module ne modifie aucun fichier de thème : Classic et Hummingbird fonctionnent tels quels. Les droits des employés se répartissent entre consultation, gestion et données. La documentation détaille chaque réglage.

Comment lire le journal et agir sur un refus ?

Le journal donne pour chaque tentative le formulaire, le résultat, le motif, la date, l’adresse masquée et le domaine e-mail, avec des actions immédiates sur la ligne.

Les motifs sont explicites. Vous y lisez Champ piège rempli, Envoyé trop vite, Champs de protection absents et Trop d’envois depuis cette adresse. D’autres lignes portent CAPTCHA échoué, Adresse sur la liste de blocage, E-mail sur la liste de blocage ou Le domaine de l’adresse ne peut pas recevoir d’e-mails. Chaque ligne propose de bloquer l’adresse ou sa plage, d’autoriser l’adresse, de bloquer le domaine e-mail ou de lever un bannissement. Vous pouvez exporter le journal filtré en CSV et le vider.

Le Tableau de bord donne la vue d’ensemble : Accepté, Bloqué, Taux de blocage, Aurait été bloqué, Accepté sans contrôle et Exempté, avec un graphique sur 30 jours et le détail par formulaire et par motif.

La conservation est de 30 jours par défaut, réglable dans Journal et confidentialité. L’adresse est masquée et une empreinte hachée sert aux listes et aux limites ; seul le domaine e-mail est gardé.

Un cas concret : un formulaire de contact saturé la nuit

Le formulaire de contact reçoit chaque nuit une dizaine de messages identiques. Le journal montre le motif Champ piège rempli sur la même plage d’adresses. Vous bloquez la plage en un clic depuis la ligne, puis vous vérifiez le lendemain que les envois de vos clients passent toujours. Si un message légitime tombe, la liste d’autorisation le rétablit sans désactiver la protection.

Faut-il ajouter un CAPTCHA externe, et lequel choisir ?

Pas par défaut : les contrôles côté serveur fonctionnent sans clé ni compte tiers, et un CAPTCHA externe s’ajoute seulement sur un formulaire qui reste visé.

Quand vous en voulez un, le choix se fait formulaire par formulaire : reCAPTCHA v2 (case à cocher ou invisible) ou v3 avec seuil de score, Cloudflare Turnstile, hCaptcha (normal, compact ou invisible) ou Friendly Captcha. Vous saisissez vos clés dans Configurer ; le module ne les affiche jamais et le bouton Test vérifie qu’elles sont acceptées.

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. Si le fournisseur est injoignable, vous choisissez de laisser passer l’envoi, journalisé comme non contrôlé, ou de le refuser.

Le consentement se règle aussi : le script peut attendre l’accord du visiteur, avec le module Cookies RGPD ou un autre outil 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.

Un CAPTCHA externe a ses propres conditions et sa propre politique de confidentialité. À vous de le mentionner dans votre politique et de choisir le consentement adapté ; le module ne certifie pas votre conformité au RGPD.

Que fait le module, et quelles sont ses limites ?

Le module réduit les envois automatisés et documente chaque refus, mais il ne promet pas zéro spam et ne remplace ni un pare-feu ni un conseil juridique.

• Aucune promesse de résultat. Un spammeur humain peut remplir un formulaire correctement. Le module rend les envois automatisés coûteux et visibles, sans les supprimer tous.
• La commande reste hors du filtre. Ni le panier, ni le paiement, ni la confirmation, ni les adresses ne sont contrôlés. Le formulaire client de la commande garde des seuils larges.
• Les visiteurs partagent des adresses. Une limite trop stricte peut gêner une entreprise ou un opérateur mobile. Le mode observation et la liste d’autorisation servent à vérifier avant de resserrer.
• Pas de certification RGPD. Le module aide à limiter les données collectées et fournit des hooks d’export et d’effacement, mais il ne remplace pas votre politique de confidentialité ni un conseil juridique.
• Une licence valide. Sans licence valide, le module se désactive : les formulaires ne sont plus contrôlés, aucun CAPTCHA n’est affiché et rien n’est journalisé. Les réglages, listes et journal sont conservés.
• Des appels réseau. La vérification d’un CAPTCHA, le contrôle MX et la vérification des robots de moteurs de recherche utilisent des appels sortants ; si le fournisseur d’un CAPTCHA est injoignable, le comportement choisi s’applique, et une recherche DNS qui échoue ne refuse jamais l’envoi.

Sur une boutique multiboutique, réglages, formulaires, journal et statistiques restent propres à chaque boutique. Si votre formulaire de contact vient d’un autre module, la fiche du formulaire de contact dynamique montre un cas courant ; pour la sécurité générale de la boutique, un audit de sécurité complète la protection des formulaires.