But
Ce guide explique comment diagnostiquer et résoudre un blocage causé par un CAPTCHA (ex. Google reCAPTCHA v2/v3 ou équivalent) qui empêche :
- la connexion à l’administration ou au compte utilisateur ;
- la création de commande ou le paiement (checkout) ;
- l’inscription ou la récupération de mot de passe.
Il couvre la récupération sûre des clés, la vérification du domaine et du fournisseur, et les points de compatibilité pour WordPress/WooCommerce et PrestaShop (1.7 → 9).
Prérequis
- Accès administrateur au CMS (interface d’administration) ;
- Accès au fournisseur CAPTCHA (compte Google reCAPTCHA ou autre) ;
- Accès au panneau Securantis (SaaS) si vous utilisez la configuration centralisée ;
- Sauvegarde récente du site (fichiers + base de données) avant toute modification de sécurité affecting l’authentification.
Avant d’agir : précautions essentielles
- N’envoyez jamais de mots de passe par email ou chat. Toute demande d’accès doit passer par l’espace client sécurisé pour une intervention payante.
- Ne supprimez pas automatiquement les règles WAF ni n’exécutez de restauration sans validation : la quarantaine et la suppression de fichiers malveillants exigent une décision humaine.
- Si le CAPTCHA est appliqué côté serveur (SaaS/WAF), notez qu’un réglage « fail-open/close » peut exister ; modifiez-le avec prudence.
Étapes communes de diagnostic (appliquées à toutes les plateformes)
- Reproduire l’erreur en navigation privée et sans extensions pour exclure le cache et les extensions du navigateur.
- Identifier le moment exact où le CAPTCHA bloque : page de connexion, inscription, mot de passe perdu, étape du checkout (validation du panier, paiement, redirection bancaire).
- Vérifier les messages d’erreur visibles côté client (console JavaScript) : erreurs de clé, domaine non autorisé, version API manquante ou requête bloquée.
- Vérifier si le blocage est global (tous les utilisateurs) ou lié à certaines adresses IP/régions : demandez à un collègue ou utilisez un VPN.
- Consigner l’heure exacte et la page affectée — utile pour corrélation avec logs WAF/serveur.
Récupération sûre des clés et vérification du domaine
- Connectez‑vous au compte du fournisseur CAPTCHA (ex. Google reCAPTCHA Console).
- Vérifiez le type de clé (v2 « checkbox », v2 « invisible » ou v3) et récupérez la clé publique (site key) et la clé privée (secret key).
- Vérifiez la liste des domaines autorisés pour la clé :
- Pour les sites en HTTPS, assurez‑vous que le domaine exact (avec ou sans www selon votre site) est listé.
- Pour multi‑domaines ou environnement de staging, ajoutez explicitement chaque domaine ou utilisez un wildcard si le fournisseur le permet.
- Si les clés ont été régénérées récemment, mettez à jour la configuration dans Securantis et dans le module/plugin CMS. Une clé incorrecte provoque une erreur côté navigateur ou un échec côté serveur.
- Si vous suspectez un problème de fournisseur (panne de l’API CAPTCHA), consultez leur page de statut ou testez une clé de test publique si disponible.
Spécificités WordPress & WooCommerce
But : protéger les formulaires (connexion, inscription, mot de passe perdu) et le checkout WooCommerce sans bloquer la vitrine.
Étapes
- Accédez au panneau de configuration CAPTCHA dans l’interface Securantis ou dans le plugin WordPress dédié (si vous avez activé une intégration locale).
- Vérifiez la version supportée (v2 ou v3) et assurez‑vous que la clé correspond au type sélectionné.
- Dans WooCommerce, vérifiez les emplacements pris en charge : champs de checkout standards, création de compte, etc. Si vous utilisez un checkout personnalisé (page builder, plugin de paiement tiers), testez le checkout standard pour isoler le problème.
- Désactivez temporairement le CAPTCHA pour le checkout uniquement (si l’option existe) et testez si le paiement passe. Ne laissez pas le checkout sans protection plus longtemps que nécessaire.
Erreurs fréquentes et dépannage spécifique
- Erreur « domaine non autorisé » : ajoutez le domaine exact dans la console CAPTCHA (www/non‑www) et attendez quelques minutes pour la propagation.
- Erreur côté JavaScript (clé inexistante ou mauvais format) : confirmez que la clé publique est correctement insérée dans la configuration du plugin.
- Checkout personnalisé cassé : certains plugins de paiement effectuent des soumissions AJAX particulières — activez les logs de WooCommerce et comparez les requêtes network pour voir si le token CAPTCHA est envoyé.
- reCAPTCHA v3 score trop bas : v3 attribue un score ; si votre configuration exige un seuil élevé, cela peut rejeter les utilisateurs légitimes. Baissez le seuil prudemment ou expérimentez la v2 pour le checkout.
Spécificités PrestaShop (1.7 → 9)
But : assurer que le module CAPTCHA pour PrestaShop protège les formulaires front-office (connexion client, création de compte) et les étapes du checkout sans interrompre la finalisation.
Étapes
- Accédez au module CAPTCHA dans le backoffice PrestaShop et vérifiez la version de l’API (v2/v3) et les clés saisies.
- Si un module PrestaShop tiers intervient sur le checkout (one page checkout, modules paiement), désactivez temporairement le CAPTCHA sur le checkout pour vérifier si c’est lui qui bloque.
- Testez le flux avec l’option « mode test » si le module le propose.
Erreurs fréquentes et dépannage
- Module non compatible avec checkout tiers : certains modules CAPTCHA ne reconnaissent pas les soumissions AJAX ou les contrôles customisés des modules de paiement. Dans ce cas, contactez l’éditeur du module de checkout pour vérifier la compatibilité.
- Absence de token dans la requête serveur : activez les logs du module CAPTCHA (ou du serveur) pour vérifier si le token est transmis lors de la soumission.
Réglages prudents et recommandations
- Ne passez pas le CAPTCHA en « off » de façon prolongée pour le checkout : cela expose la boutique aux bots et fraudes.
- Si vous devez réduire des faux positifs, testez : baisser le seuil v3 graduellement, passer temporairement en v2 « invisible » ou restreindre le CAPTCHA à certains formulaires seulement.
- Documentez chaque changement (qui, quoi, pourquoi) et restaurez la configuration précédente si le changement aggrave la situation.
Dépannage avancé
- Vérifiez les logs WAF/Securantis pour corréler le blocage : il peut y avoir superposition entre règles WAF et vérification CAPTCHA.
- Inspectez les entêtes HTTP et les en-têtes CORS si le token est chargé depuis un domaine tiers.
- Pour issues AJAX, utilisez l’outil Réseau du navigateur pour confirmer la présence et le format du token dans la requête POST.
- Si le fournisseur CAPTCHA indique que la clé est valide mais que votre site reçoit un rejet, testez avec une clé de test ou créez une nouvelle paire de clés temporaire pour validation.
Quand contacter le support Securantis
Contactez le support si :
- vous avez vérifié clés et domaine et le CAPTCHA continue de bloquer malgré une configuration correcte ;
- le blocage semble provenir du WAF/Saas Securantis (corrélation dans les logs) ;
- vous voyez des entrées d’erreurs répétées dans les logs Securantis et vous souhaitez une assistance à l’analyse ;
- vous utilisez un module de checkout tiers et avez besoin d’aide à confirmer la compatibilité.
Informations à fournir au support (ne transmettez jamais de mots de passe)
- URL exacte de la page affectée et captures d’écran des erreurs visibles côté client ;
- Heure(s) et fuseau horaire des tentatives reproductibles ;
- Type de CAPTCHA (reCAPTCHA v2 checkbox / v2 invisible / v3 ou autre) et confirmation que les clés site/secret ont été vérifiées ;
- Indication si le checkout utilise un module tiers (nom et version) ;
- Export des logs pertinents (WAF/Securantis) et captures de la console réseau montrant la requête/response (jeton présent ou absent, code d’erreur API).
Ce que Securantis peut et ne peut pas faire
- Securantis peut aider à analyser les logs, vérifier la configuration côté SaaS et proposer des ajustements de règles WAF ou de configuration CAPTCHA.
- Securantis ne supprimera pas automatiquement un composant ni ne modifiera de façon irréfléchie vos clés ; toute action impactante (restauration, suppression de fichiers, modification d’accès) requiert votre accord explicite.
Résultat attendu après résolution
- Les utilisateurs et administrateurs peuvent se connecter et finaliser des commandes normalement ;
- Les requêtes CAPTCHA valides sont acceptées par votre backend et les tokens sont correctement transmis depuis le frontend ;
- Les faux positifs sont réduits sans exposer le checkout à des risques de bots.
Conclusion
Suivez d’abord les étapes de diagnostic et de vérification des clés/domaine, testez sur un checkout standard pour isoler les conflits avec modules tiers, et fournissez les logs et captures d’écran au support si le problème persiste. Agissez toujours avec prudence et conservez une sauvegarde avant toute modification majeure.