Spam dans les formulaires PrestaShop malgré le CAPTCHA : que vérifier avant de changer de module ?

Si le spam passe malgré le CAPTCHA, vérifiez d’abord si le serveur valide la soumission de ce formulaire précis. Une case à cocher visible, un badge reCAPTCHA ou un module actif ne suffisent pas. La protection doit couvrir à la fois la génération du jeton dans le navigateur et la décision du serveur avant la création du compte, l’enregistrement de l’abonnement ou l’envoi du message.

Ce guide s’adresse aux propriétaires de boutiques PrestaShop et aux personnes responsables de leur maintenance technique. Il aide à identifier la source du problème et à préparer un test vérifiable. Il ne part pas du principe que chaque cas nécessite le remplacement du module.

1. Déterminez par où le spam arrive réellement

Commencez par un seul exemple : l’heure du signalement, le type d’événement et le formulaire auquel vous l’associez. Ne publiez pas l’adresse du client, le contenu d’une correspondance privée ni la requête complète contenant des jetons. Pour un signalement au développeur, des données anonymisées et des instructions de reproduction du problème suffisent.

Le message reçu dans la boîte de la boutique peut provenir du contact standard, d’un formulaire sur la fiche produit, d’un module d’avis ou directement de la messagerie. La protection du formulaire de contact ne filtre pas automatiquement les messages envoyés à une adresse e-mail publique. De même, un CAPTCHA lors de la création de compte ne sécurise pas par défaut l’inscription à la newsletter.

• Notez l’URL exacte et le nom du module qui gère le formulaire.
• Déterminez si le problème concerne un visiteur, un client connecté ou les deux groupes.
• Reproduisez le signalement sur ordinateur et sur téléphone si les formulaires diffèrent dans leur mise en page.
• Vérifiez si le formulaire est envoyé de manière classique, via AJAX ou via un checkout externe.

Ce n’est qu’avec une telle description que vous pourrez comparer le périmètre de reCAPTCHA Pro pour PrestaShop avec l’emplacement réel du problème. L’affirmation générale « le CAPTCHA est activé sur le site » ne permet pas d’évaluer l’efficacité d’un parcours précis.

2. Vérifiez le type de clé, le domaine et la configuration complète

La clé v2, la v3 et la configuration Enterprise relèvent de modes différents. Le type de vérification défini dans le module doit correspondre à la configuration du service. Vérifiez aussi le domaine utilisé par le client : une copie de test, le domaine de production et un hôte supplémentaire n’ont pas forcément les mêmes autorisations.

Dans la version examinée de reCAPTCHA Pro 1.4.9, une clé publique vide entraîne l’omission de la validation centrale. Un module installé et un interrupteur activé ne constituent donc pas une preuve d’activation complète de la protection. Vérifiez que les champs requis du mode choisi sont bien renseignés ; ne placez pas la clé privée dans des captures d’écran ni dans le code de la page.

Configurez les restrictions de domaine côté Google. Le code du module examiné n’effectue pas de comparaison supplémentaire du champ hostname dans la réponse. La documentation Google sur les domaines explique que la désactivation de leur vérification exige un contrôle autonome de l’hôte dans le backend. Ne désactivez pas cette restriction comme tentative hasardeuse de corriger le formulaire.

3. Distinguez le fonctionnement du navigateur de la décision du serveur

Dans les outils de développement, vérifiez si le script CAPTCHA a bien été chargé, s’il n’y a pas d’erreur JavaScript et si un jeton apparaît lors de l’envoi du formulaire. Si le problème ne survient qu’après une décision précise dans le panneau des cookies, analysez l’ordre de chargement des scripts et l’intégration des consentements. Ne modifiez pas à l’aveugle la classification des cookies uniquement pour faire disparaître le message d’erreur.

Vérifiez ensuite la requête envoyée à la boutique. Le jeton doit parvenir au chemin qui exécute l’action protégée. Masquer le bouton ou vérifier un champ uniquement en JavaScript ne remplace pas un contrôle côté serveur.

Google décrit le jeton de réponse comme étant à usage unique et valable pendant deux minutes. Un formulaire laissé ouvert trop longtemps, un nouvel envoi de la même requête ou deux validations indépendantes d’un même jeton peuvent donc se solder par un refus. Après une erreur, une nouvelle tentative correcte avec un nouveau jeton est nécessaire. Les détails et les codes d’erreur figurent dans la documentation de vérification de la réponse reCAPTCHA.

En v3, l’absence de case à cocher est normale. C’est le score et le contexte de l’action qui sont évalués. Le seuil doit résulter de l’observation du trafic réel ; le résultat d’une copie de test ne reflète pas forcément le comportement en production. Google décrit séparément le score et le nom de l’action. Lors du diagnostic, consignez la raison du refus au lieu d’abaisser automatiquement le seuil à chaque erreur.

4. Vérifiez le périmètre réel des formulaires

Le tableau ci-dessous décrit les parcours trouvés dans le code de reCAPTCHA Pro 1.4.9. Il s’agit d’une information sur l’intégration, et non d’une déclaration de bon fonctionnement pour chaque thème et chaque version d’autres modules.

5. Test propre : réponse acceptée et refusée

Nous avons effectué un test contrôlé du code non modifié de reCAPTCHA Pro 1.4.9 et de l’override de contact déployé. Nous avons remplacé la réponse du service par des données préparées et la fonction d’envoi par un compteur d’appels. Nous avons vérifié la décision du programme ; nous n’avons pas envoyé de messages, nous n’avons pas utilisé de jetons de clients et nous n’avons pas mesuré l’efficacité antispam de Google.

Un tel test permet de vérifier la barrière dans le code. La validation complète du déploiement exige encore un passage par le formulaire réel sur une copie de la boutique : avec son thème, sa version de PrestaShop, son module de formulaire et ses paramètres. Pour un checkout externe, confirmez en particulier qu’un refus du backend bloque bien l’action finale.

6. Pensez aussi à l’utilisateur normal

Après un refus, le formulaire doit expliquer le problème et permettre une nouvelle tentative. Vérifiez le comportement après une pause prolongée, une perte de réseau et une erreur du service. Évaluez si l’utilisateur peut conserver le contenu saisi et si le bouton ne reste pas bloqué de façon permanente. Ce sont des critères de validation d’un déploiement précis, et non une caractéristique automatique de chaque ensemble de modules.

Si le parcours protégé fonctionne correctement, mais que le problème concerne une charge massive du serveur ou la messagerie directe, adaptez la protection à cette couche. Les limites de requêtes, le WAF et le filtrage de la boîte nécessitent des réglages distincts. Le CAPTCHA ne garantit pas l’élimination de tous les bots.

Étape suivante : vérifiez le périmètre de reCAPTCHA Pro pour votre formulaire. Si vous ne parvenez pas à identifier l’endroit où le contrôle est interrompu, utilisez l’assistance technique PrestaShop en indiquant l’URL, les versions et le déroulement anonymisé du test.

Vérifié le 13.09.2026. Périmètre : sources du module 1.4.9, réponses contrôlées du validateur et documentation Google. L’illustration est un contenu éditorial, et non une capture de l’interface testée.