Périmètre sûr : ce guide porte sur vos propres applications — développement, préproduction, production — ou sur des systèmes pour lesquels vous détenez une autorisation écrite. Il ne couvre pas l'automatisation de sites tiers.
Un client vous écrit : « votre formulaire refuse ma commande et je ne vois aucun défi CAPTCHA ». Côté serveur, la vérification renvoie pourtant un token valide, un score de 0,2, et votre backend rejette sans un mot parce que le seuil est fixé à 0,5. Quand des visiteurs légitimes tombent sous le seuil de façon répétée, la cause tient presque toujours à votre intégration ou au seuil choisi. Voici les points à tester, dans l'ordre.
Ce que mesure vraiment le score reCAPTCHA v3
reCAPTCHA v3 ne bloque rien par lui-même : il renvoie une valeur entre 0,0 et 1,0, et c'est votre code serveur qui décide de la suite. Google ne fixe aucun seuil à votre place — la valeur 0,5 souvent citée est un point de départ documenté, pas une règle.
| Ce qu'observe reCAPTCHA v3 | Ce que vous contrôlez |
|---|---|
| Cohérence de l'action | La chaîne passée à grecaptcha.execute() |
| Fraîcheur du token | Le moment de la demande |
| Fréquence des exécutions | Les appels par page et par session |
| Réputation réseau | Rien — mais vous pouvez adapter le seuil |
Pourquoi le score chute chez des utilisateurs légitimes
1. Une action absente ou incohérente
Chaque appel à grecaptcha.execute() embarque une chaîne d'action. Si le front envoie submit alors que le backend attend login, la vérification renvoie un score dégradé. Correctif : alignez la constante des deux côtés, sans la coder en dur dans un template.
2. Un token demandé trop tôt
Un token reCAPTCHA v3 reste valide deux minutes. Généré au chargement d'un formulaire long, il arrive périmé. Correctif : demandez le token juste avant l'envoi, jamais dans le DOMContentLoaded.
3. Une exécution déclenchée sans interaction
Un appel lancé dans la première seconde d'affichage, sans aucune interaction, produit un contexte pauvre. Correctif : rattachez l'exécution à l'événement de soumission réel, pas à un minuteur.
4. Des exécutions répétées dans la même session
Un composant monté deux fois ou un formulaire à étapes multiplient les appels sur la même page, et les scores baissent. Correctif : mémorisez le token de l'étape en cours et dédupliquez les appels.
5. Une confusion de sitekey entre v2 et v3
Une clé reCAPTCHA v2 déclarée dans un widget v3 produit des vérifications incohérentes. Correctif : vérifiez que la clé du site est de type v3 et que le domaine de préproduction y est enregistré.
6. Un seuil recopié sans mesure
Beaucoup d'équipes reprennent 0,5 d'un exemple, puis passent à 0,7 « pour être tranquilles », sans jamais mesurer. Correctif : mesurez d'abord, décidez ensuite.
Diagnostiquer un score faible avant de corriger
Journalisez le score, l'action et l'environnement à chaque vérification, puis comparez les distributions sur sept jours glissants. Une bascule visible partout signale une régression front ; un écart limité à la production oriente vers le réseau ou la configuration des domaines.
Exemple Python de vérification serveur :
import requests
def verify_token_with_backend(token: str, your_backend_url: str) -> bool:
"""Vérifier le token CAPTCHA avec votre propre backend."""
response = requests.post(
your_backend_url + '/api/captcha/verify',
json={'token': token},
timeout=15,
)
response.raise_for_status()
return response.json().get('valid', False)
Trois indicateurs suffisent : le score médian par action, la part de vérifications sous le seuil, et le délai entre génération et vérification du token. Si ce délai dépasse régulièrement 120 s, vous tenez la cause. Un identifiant de corrélation (OpenTelemetry, par exemple) permet ensuite de rejouer un parcours depuis un ticket support.
Cas concret : un SaaS B2B hébergé en région parisienne
Un éditeur SaaS héberge son application chez OVHcloud, avec une réplique sur la région AWS eu-west-3 (Paris). Après la refonte du tunnel d'inscription, le support reçoit une dizaine de tickets « inscription impossible » par jour. La journalisation isole deux populations : les visiteurs en 4G, dont l'adresse IP publique est partagée derrière le CGNAT de leur opérateur, et les salariés d'un grand compte belge qui sortent par un unique proxy d'entreprise. Score médian de 0,3 pour ces deux groupes, contre 0,7 pour le reste du trafic.
Aucun réglage front n'y changera quoi que ce soit : des centaines de personnes partagent la même adresse IP. La réponse utile consiste à abaisser le blocage dur et à ajouter une vérification dans la zone grise. Côté conformité, le score et l'adresse IP sont des données de connexion : conservation courte et mention au registre RGPD.
Ajuster le seuil sans bloquer vos clients
Un seuil unique produit toujours des faux positifs. Une réponse graduée coûte peu :
- Au-dessus de 0,7 : laissez passer sans friction.
- Entre 0,3 et 0,7 : ajoutez une étape visible — défi CAPTCHA classique, confirmation par e-mail ou limitation de débit.
- Sous 0,3 : refusez, mais avec un message explicite et un canal de contact. Un rejet muet coûte un client.
Réservez les seuils élevés aux actions critiques (paiement, changement de mot de passe) et restez bas sur l'inscription, où un blocage abusif coûte le plus cher.
Liste de contrôle avant mise en production
- L'action envoyée par le front correspond à celle attendue par le backend.
- Le token est demandé à la soumission et vérifié en moins de deux minutes.
- La clé du site est bien une clé v3, domaine de préproduction déclaré.
- Le score, l'action et l'environnement sont journalisés à chaque vérification.
- La clé API vit dans un secret de CI ou un coffre, jamais en clair.
FAQ
Que signifie concrètement un score de 0,1 ou de 0,3 ?
Rien d'absolu. Ces valeurs traduisent un contexte de navigation jugé peu caractéristique, pas une preuve d'automatisation : un navigateur durci, une session neuve ou une adresse IP partagée suffisent. Comparez-les à la distribution mesurée sur votre propre trafic.
Pourquoi mes utilisateurs mobiles ont-ils des scores plus faibles ?
Parce qu'ils partagent leur adresse IP publique avec des milliers d'abonnés, via le CGNAT des opérateurs mobiles. Le motif est banal en France comme au Maghreb : segmentez vos mesures par type de réseau avant de conclure à un défaut d'intégration.
Faut-il bloquer dès qu'un score passe sous le seuil ?
Non. Le blocage dur convient aux actions critiques ; ailleurs, une réponse graduée protège votre chiffre d'affaires.
Combien de temps un token reCAPTCHA v3 reste-t-il valide ?
Deux minutes. Au-delà, la vérification serveur échoue quel que soit le score initial : c'est la cause la plus rapide à confirmer.
Comment reproduire un score faible dans mes tests automatisés ?
Rejouez le parcours en préproduction sur un environnement que vous contrôlez et résolvez le défi via l'API CaptchaAI, qui prend en charge reCAPTCHA v2 et v3, Cloudflare Turnstile et GeeTest v3. Le plan BASIC ($15/mois, 5 threads) suffit à une suite de tests nocturne.
Guides connexes
- Démarrage rapide de l'API CaptchaAI
- QA CAPTCHA en environnement autorisé
- Tester vos formulaires via l'endpoint API
- Résolution CAPTCHA dans votre CI
- Résoudre reCAPTCHA v2 via l'API
- Résoudre Cloudflare Turnstile via l'API
Passez du diagnostic ponctuel à la mesure continue. – Obtenez votre clé API CaptchaAI.