reCAPTCHA pour PrestaShop : protéger votre boutique du spam et des bots

Une boutique PrestaShop sans CAPTCHA n'est pas exposée à un risque théorique : c'est une cible que le trafic automatisé trouve tout seul. Les bots parcourent le web à la recherche des points d'entrée standard des formulaires PrestaShop et, dès qu'ils trouvent les vôtres, ils commencent à les marteler : fausses inscriptions sur AuthController, messages indésirables via le formulaire de contact, tentatives de combinaisons de mots de passe sur la connexion, rafales d'e-mails de réinitialisation. Rien de tout cela n'exige que quelqu'un connaisse l'existence de votre boutique. Les formulaires sont fournis avec PrestaShop, les bots les connaissent, et une installation PrestaShop standard n'offre aucune protection anti-bot sur aucun d'eux.

Ce guide explique comment combler cette faille : ce que les bots font réellement à une boutique PrestaShop, quels formulaires précis ils attaquent et comment CAPTCHA bloque chaque scénario. Si votre préoccupation est l'autre versant du sujet, ajouter une protection sans faire fuir les vrais clients avec des défis agaçants, c'est une question de conversion que nous traitons séparément dans reCAPTCHA sans agacer les vrais clients. Ici, nous nous concentrons sur la menace et la défense.

Ce que font réellement les bots à une boutique PrestaShop

"Spam et bots" reste vague tant qu'on ne le voit pas frapper son propre back-office. Voici comment cela se manifeste dans une installation PrestaShop réelle, avec la partie de la boutique touchée et les dégâts associés.

Le fil conducteur de tout cela : les dégâts ressemblent rarement à une faille spectaculaire. C'est une dégradation lente : une base clients dans laquelle vous ne pouvez plus avoir confiance, une boîte de support que vous redoutez d'ouvrir, une réputation e-mail qui s'enfonce silencieusement. Installer CAPTCHA sur les bons formulaires coupe l'essentiel du problème à l'entrée. (Pour l'extrémité plus grave du spectre, credential stuffing, abus de commandes/cartes bancaires et skimmers, CAPTCHA n'est qu'une couche parmi d'autres ; consultez la checklist complète de durcissement de la sécurité et l'anatomie d'une attaque de type Magecart.)

Quels formulaires PrestaShop protéger, et lesquels laisser tranquilles

Le réflexe consistant à "mettre CAPTCHA partout" est le mauvais. Les bots se concentrent sur une poignée de points d'entrée, et chaque formulaire protégé ajoute un peu de friction. Protégez en fonction des endroits où les attaques arrivent, pas au feeling.

À protéger en priorité : là où les bots se trouvent

• Formulaire d'inscription. La cible numéro un des bots sur n'importe quelle boutique PrestaShop. Sans protection, c'est ainsi que la pile de faux comptes grossit. Non négociable.
• Formulaire de contact. Le deuxième plus visé. C'est ce qui vous sépare d'une boîte Service client pleine de bruit.
• Formulaire de connexion. Empêche les tentatives par force brute de devenir à la fois un problème de charge serveur et un problème de comptes compromis.

À protéger ensuite

• Réinitialisation du mot de passe. Ferme le vecteur d'inondation d'e-mails de réinitialisation qui dégrade votre réputation d'expéditeur.
• Inscription à la newsletter. Empêche les fausses inscriptions d'entrer dans votre liste.
• Avis produits (si vous utilisez un module d'avis). Les bots publient de faux avis pour manipuler les notes.

À laisser de côté sauf problème avéré

• Commande. Ajouter un CAPTCHA visible au tunnel de commande revient à se tirer une balle dans le pied : cela augmente l'abandon sur la page la plus précieuse de la boutique. N'y touchez que si vous observez une vraie fraude au paiement ou à la commande, et uniquement avec une évaluation invisible (jamais une case à cocher). Ces arbitrages sont exactement le problème "ne pas agacer les vrais clients" traité dans le guide complémentaire.
• Champ de recherche et ajout au panier. Rarement de vraies cibles ; la friction n'en vaut pas la peine.

reCAPTCHA v2, v3 ou hCaptcha : quelle protection déployer

La version choisie change à la fois la difficulté pour un bot de passer et la visibilité du contrôle pour un vrai client. Trois choix réalistes pour une boutique PrestaShop :

Pour la plupart des boutiques PrestaShop, le choix se fait entre v3 pour une évaluation invisible et v2 ou hCaptcha pour un défi explicite. Le module mprrecaptcha actuel vous permet de choisir reCAPTCHA v2, reCAPTCHA v3 ou hCaptcha et de définir le seuil de score v3 ; il ne bascule pas automatiquement de v3 vers v2 sur les scores limites. Le traitement des scores faibles relève donc du réglage et du rejet, pas d'un second défi. Le seuil exact à définir, et la façon d'éviter de bloquer de vraies personnes, relèvent du travail d'ajustement ; c'est traité dans le guide complémentaire.

Ajouter CAPTCHA aux formulaires PrestaShop : la mécanique

PrestaShop n'intègre aucun CAPTCHA, la protection passe donc par un module. Ce qui compte, c'est la manière dont il se greffe aux formulaires, car c'est cela qui détermine s'il bloque vraiment une soumission ou s'il se contente de décorer le formulaire.

Étape 1 : générer vos clés

Pour reCAPTCHA, enregistrez le site sur www.google.com/recaptcha/admin ; pour hCaptcha, dans le tableau de bord hCaptcha. Dans les deux cas, vous obtenez une Site Key publique (rendue dans la page) et une Secret Key privée (utilisée côté serveur pour la vérification). Ajoutez vos domaines avec www et sans www. Les clés sont liées au domaine : un domaine qui ne correspond pas peut casser la validation CAPTCHA ou bloquer des soumissions légitimes. Enregistrez donc une paire distincte par environnement et vérifiez que le formulaire échoue de manière fermée (il rejette au lieu de laisser passer silencieusement les soumissions) lorsque le jeton ne se vérifie pas.

Étape 2 : comment un bon module s'accroche

Les réglages importants sont le fournisseur, les clés, les formulaires protégés et le seuil v3.

Dans un vrai module, les hooks d'affichage rendent le widget et les hooks d'action rejettent la soumission avant que PrestaShop ne crée le compte, le message ou l'inscription. Voici les hooks pertinents issus du code source de mprrecaptcha.

public function getHooks()
{
    return [
        'displayHeader',
        'displayFooter',
        'displayCustomerLoginFormAfter',
        'displayCustomerAccountForm',
        'displayNewsletterRegistration',
        'displayGDPRConsent',
        'actionContactFormSubmitBefore',
        'actionSubmitAccountBefore',
        'actionCustomerLoginBefore',
        'actionNewsletterRegistrationBefore',
    ];
}

C'est là que la vraie protection se distingue du théâtre. Un bot ne remplit pas votre formulaire à la main ; il envoie un POST directement au contrôleur. La vérification doit donc avoir lieu côté serveur, avant que PrestaShop ne traite la soumission, et pas seulement sous la forme d'un widget dessiné sur la page. L'exigence clé est la même sur toutes les versions : le jeton est validé côté serveur avant que le compte, le message de contact, la connexion ou l'inscription à la newsletter ne soit traité. Les noms exacts des hooks diffèrent selon les branches : les anciennes versions 1.6/1.7 utilisent des flux de front-controller et de formulaires différents de ceux des versions 8/9. Un module bien construit se branche donc sur les hooks Before validés disponibles pour votre version cible (par exemple les hooks d'inscription, de formulaire de contact, de connexion et de soumission newsletter). Quel que soit le hook utilisé, il valide le jeton auprès du point de terminaison siteverify de Google ou de hCaptcha et rejette la requête avant qu'un compte ou un message ne soit créé. Côté affichage, il s'appuie sur displayCustomerAccountForm, displayCustomerLoginFormAfter et displayHeader/displayFooter pour injecter le widget et charger le script. Si un module se contente d'afficher le badge sans verrouiller les hooks Before, un bot qui envoie un POST direct passe tout droit.

Étape 3 : vérifier qu'il bloque vraiment

Ne supposez rien : testez. Soumettez chaque formulaire protégé comme un client normal pour confirmer que l'utilisation légitime fonctionne toujours, puis consultez le tableau de bord du fournisseur pour vérifier que les validations sont bien enregistrées. L'erreur de configuration la plus courante est un formulaire qui semble protégé mais dont le hook Before n'est pas raccordé : les bots passent alors sans obstacle pendant que vous pensez être couvert.

Le choix du module propre à PrestaShop

Comme la protection tient ou tombe sur ces hooks côté serveur, le module choisi compte plus que la marque du CAPTCHA. Notre module mprrecaptcha (PrestaShop 1.6 à 9) a été conçu précisément pour cela : il prend en charge reCAPTCHA v2, v3 et hCaptcha et, sur chaque branche compatible, il se branche sur les vrais hooks de soumission côté serveur de cette version pour l'inscription, le contact, la connexion et la newsletter. Ainsi, un POST direct de bot est validé puis rejeté au niveau du contrôleur, au lieu d'être simplement masqué sur la page. Concrètement, qu'est-ce que cela change pour vous ? Vous choisissez depuis le back-office les formulaires à protéger, vous laissez la commande sans friction et vous pouvez réduire les fausses inscriptions comme le spam de contact, sans modifier un fichier de thème ni toucher au core, donc sans casser aux mises à jour. Il expose aussi un hook displayGDPRConsent afin que le script CAPTCHA puisse être lié à votre flux de consentement, ce qui compte dans l'UE (voir ci-dessous).

Le piège RGPD à ne pas ignorer

Le reCAPTCHA de Google charge du JavaScript Google et envoie l'adresse IP ainsi que les données de comportement du visiteur aux serveurs de Google. Au regard du RGPD, il s'agit d'un traitement qui nécessite une base légale, et plusieurs autorités européennes de protection des données (dont la CNIL en France) l'ont signalé. Cela crée une vraie tension pour une boutique de l'UE : bloquez reCAPTCHA jusqu'au consentement aux cookies et vos formulaires restent sans protection pour les visiteurs qui ne consentent pas ; chargez-le malgré tout et vous vous exposez sur le plan de la conformité. Il n'existe pas de réponse universellement "correcte" : c'est un arbitrage de risque. Deux voies pratiques : intégrer CAPTCHA à votre mécanisme de consentement (le hook displayGDPRConsent ci-dessus existe pour cela) ou éviter entièrement le transfert de données vers Google en utilisant hCaptcha, qui ne partage pas les données avec Google. Ce n'est qu'un volet d'un sujet de conformité plus large ; la vue d'ensemble pour les propriétaires de boutique se trouve dans le guide de sécurité en langage clair.

CAPTCHA est une couche, pas tout le mur

CAPTCHA bloque les abus automatisés de formulaires : faux comptes, spam de contact, inondations de réinitialisation, bruit de force brute. Il ne bloque pas tout, et le traiter comme toute votre défense serait une erreur. Les bots distribués qui alternent les IP, les inondations de trafic et les acteurs malveillants déjà passés au-delà du formulaire nécessitent tous d'autres couches :

• Blocage des mauvais bots et des IP pour le trafic qui ne devrait même pas atteindre vos formulaires : voir bloquer les mauvais bots et le trafic indésirable et les bannissements d'IP pour les visiteurs problématiques.
• Protection côté administration : CAPTCHA aide pour la connexion front-office, mais le back-office a besoin d'une authentification à deux facteurs et d'une politique de mots de passe : 2FA et sécurité d'administration.
• Charge provoquée par les robots d'indexation qu'aucun CAPTCHA ne traite, comme l'inondation de requêtes de recherche à facettes : survivre à l'inondation ?q=.
• Si quelque chose passe malgré tout : le plan d'intervention en cas d'incident dans la réponse à une violation de données.

La conclusion honnête : installez CAPTCHA sur vos formulaires d'inscription, de contact et de connexion avec un module qui verrouille les hooks Before côté serveur, laissez la commande tranquille, traitez la question RGPD délibérément et considérez le résultat comme une couche solide d'une boutique durcie, pas comme la ligne d'arrivée. Avec cette approche, les faux comptes et le spam de contact peuvent diminuer, ce qui facilite la gestion de vos données clients et de votre boîte de réception.

Questions fréquentes

Sur quels formulaires faut-il vraiment mettre CAPTCHA ?

Protégez là où les bots sont présents, pas partout. Les trois premiers à traiter sont le formulaire d'inscription (la cible numéro un : c'est comme cela que la pile de faux comptes grossit), le formulaire de contact (pour garder votre boîte Service client exploitable) et le formulaire de connexion (pour stopper le bruit des tentatives par force brute). Niveau suivant : réinitialisation du mot de passe, inscription à la newsletter et avis produits si vous utilisez un module d'avis. Laissez la commande tranquille sauf fraude prouvée : un CAPTCHA visible à cet endroit augmente l'abandon sur votre page la plus précieuse, et si vous devez vraiment intervenir, utilisez uniquement une évaluation invisible, jamais une case à cocher.

reCAPTCHA v2, v3 ou hCaptcha : lequel choisir ?

v3 est invisible et attribue au comportement un score de 0.0 à 1.0 avec un seuil que vous définissez. Il convient aux formulaires à fort trafic ou sensibles à la conversion, mais exige un réglage prudent pour ne pas rejeter de vraies personnes sur des scores faibles. v2 et hCaptcha affichent un défi explicite, ce qui convient aux formulaires de contact et d'inscription où un petit clic reste acceptable. Le point distinctif de hCaptcha pour les boutiques de l'UE est qu'il n'envoie pas de données à Google. Le module mprrecaptcha prend en charge les trois et vous permet de définir le seuil de score v3 ; il ne bascule pas automatiquement de v3 vers v2 sur les scores limites, donc le traitement des scores faibles relève d'une décision de réglage et de rejet.

Mon formulaire semble protégé, mais le spam passe encore : qu'est-ce qui ne va pas ?

Presque toujours, la vérification est décorative au lieu d'être imposée. Un bot ne remplit pas votre formulaire à la main : il envoie un POST directement au contrôleur. Donc, si le module se contente de rendre le widget sur la page sans verrouiller les hooks Before côté serveur (les hooks d'inscription, de contact, de connexion et de soumission newsletter), un POST direct passe juste à côté. Une vraie protection valide le jeton auprès du point de terminaison siteverify du fournisseur avant la création du compte, du message ou de l'inscription. Testez-la : soumettez chaque formulaire comme un client normal pour confirmer qu'il fonctionne toujours, puis vérifiez dans le tableau de bord du fournisseur que les validations sont enregistrées.

Pourquoi CAPTCHA "cesse-t-il de fonctionner" après un changement de domaine ou l'ajout de www ?

Les clés reCAPTCHA et hCaptcha sont liées au domaine. Si votre Site Key et votre Secret Key ont été enregistrées pour un hôte, elles ne seront pas validées sur un autre : une entrée www / sans www incorrecte ou manquante peut donc casser la validation ou bloquer des soumissions légitimes. Ajoutez vos domaines avec www et sans www à la clé, et enregistrez une paire de clés distincte par environnement (préproduction et production). Vérifiez aussi que le formulaire échoue en mode fermé : il doit rejeter les soumissions lorsque le jeton ne se vérifie pas, plutôt que les laisser passer silencieusement.

L'utilisation de Google reCAPTCHA pose-t-elle un problème RGPD pour une boutique de l'UE ?

C'est un vrai arbitrage de risque, pas un oui/non définitivement tranché. reCAPTCHA charge du JavaScript Google et envoie l'adresse IP ainsi que le comportement du visiteur à Google, ce qui constitue un traitement nécessitant une base légale au titre du RGPD, et plusieurs autorités européennes (dont la CNIL en France) l'ont signalé. Deux voies pratiques : intégrer CAPTCHA à votre mécanisme de consentement (le hook displayGDPRConsent existe pour cela) ou éviter entièrement le transfert de données vers Google en utilisant hCaptcha. Quel que soit votre choix, ne déclenchez jamais le script CAPTCHA avant le consentement si vous le traitez comme non essentiel.

CAPTCHA remplace-t-il les autres mesures de sécurité ?

Non : ce n'est qu'une couche. CAPTCHA bloque les abus automatisés de formulaires : faux comptes, spam de contact, inondations d'e-mails de réinitialisation, bruit de force brute. Il ne bloque pas les bots distribués qui alternent les IP, les inondations de trafic ni les personnes déjà passées au-delà du formulaire. Associez-le au blocage des mauvais bots et des IP pour le trafic qui ne devrait même pas atteindre vos formulaires, à l'authentification à deux facteurs et à une politique de mots de passe sur le back-office, ainsi qu'à un plan d'intervention si quelque chose passe malgré tout. CAPTCHA sur l'inscription, le contact et la connexion est une couche solide d'une boutique durcie, pas la ligne d'arrivée.