reCAPTCHA v3 ne montre aucun défi visible : il attribue silencieusement un score compris entre 0,0 (robot probable) et 1,0 (humain probable). Le point décisif, quand vous comparez plusieurs solveurs, n'est donc pas le score moyen affiché, mais la proportion de tokens qui franchissent réellement le seuil configuré côté serveur. Deux services peuvent annoncer une moyenne proche et pourtant produire des taux d'acceptation très différents une fois vos règles appliquées.
Cet article propose un cadre de comparaison reproductible, centré sur le taux d'acceptation par seuil plutôt que sur une moyenne isolée.
Comment lire un score reCAPTCHA v3
Le score reflète la confiance de Google dans le caractère humain de la session. Le site cible fixe un seuil et rejette les requêtes en dessous. Les valeurs courantes selon le type de page :
- Page de connexion : 0,5
- Inscription : 0,5 à 0,7
- Parcours de paiement : 0,3 à 0,5
- Envoi de formulaire : 0,5
- Accès API : 0,7
Un solveur qui renvoie un token à 0,4 est inutile sur une page dont le seuil est fixé à 0,5 : le token est techniquement valide, mais votre backend le refuse. C'est cette réalité — et non la moyenne annoncée — qui doit guider votre choix.
Ce qu'il faut réellement comparer
Un comparatif pertinent mesure plusieurs dimensions, pas une seule :
- La distribution des scores obtenus (0,1–0,3, 0,3–0,5, 0,5–0,7, 0,7 et plus), pas seulement la moyenne.
- Le taux d'acceptation des tokens à chacun de vos seuils serveur (0,3, 0,5, 0,7).
- L'effet des signaux attachés à la requête :
action,cookies,userAgent,proxy. - La stabilité des résultats selon la région et la plage horaire.
- Le coût par token accepté, et non le coût unitaire affiché.
C'est la combinaison de ces mesures qui distingue un service exploitable en production d'un service qui paraît économique sur le papier.
Protocole de test reproductible
Les chiffres ci-dessous reposent sur des mesures observées et des retours d'utilisateurs. Les résultats varient selon l'environnement, le volume et le moment de la journée. Renseignez ce tableau avec vos propres relevés plutôt que de vous fier à des moyennes publiées hors contexte :
| Mesure | CaptchaAI | Fournisseur B | Fournisseur C |
|---|---|---|---|
| Score moyen | à mesurer | à mesurer | à mesurer |
| Tokens ≥ 0,5 | à mesurer | à mesurer | à mesurer |
| Tokens ≥ 0,7 | à mesurer | à mesurer | à mesurer |
| Rejet côté serveur | à mesurer | à mesurer | à mesurer |
| Coût par token accepté | à mesurer | à mesurer | à mesurer |
Pour un relevé exploitable :
- Sélectionnez une liste de pages représentatives (connexion, inscription, formulaire, paiement interne).
- Définissez vos seuils serveur cibles (0,3, 0,5, 0,7) selon vos politiques.
- Mesurez sur plusieurs jours avec le même protocole de polling.
- Journalisez le score renvoyé, l'
action, le succès et le motif de rejet. - Comparez le coût par token accepté, pas seulement le prix unitaire.
Un relevé étalé sur plusieurs jours évite les conclusions tirées d'un unique lot de tests, souvent trompeuses. Si vous mesurez depuis une infrastructure européenne — par exemple une instance en région eu-west-3 (Paris) chez votre hébergeur — comparez avec et sans proxy résidentiel : l'IP d'un datacenter pèse sur le score. Côté conformité, limitez la journalisation aux données strictement nécessaires au diagnostic, conformément à vos obligations RGPD.
Exemple d'appel reCAPTCHA v3 avec signaux
L'appel ci-dessous soumet une tâche v3 avec l'action attendue par la page, puis interroge le résultat jusqu'à obtention du token :
import requests
import time
API_KEY = "YOUR_API_KEY"
submit = requests.post(
"https://ocr.captchaai.com/in.php",
data={
"key": API_KEY,
"method": "userrecaptcha",
"version": "v3",
"googlekey": "SITE_KEY",
"pageurl": "https://example.com/login",
"action": "login",
"json": 1,
},
timeout=30,
)
submit.raise_for_status()
task_id = submit.json()["request"]
for _ in range(40):
time.sleep(5)
poll = requests.get(
"https://ocr.captchaai.com/res.php",
params={"key": API_KEY, "action": "get", "id": task_id, "json": 1},
timeout=30,
)
payload = poll.json()
if payload["request"] != "CAPCHA_NOT_READY":
token = payload["request"]
break
L'action transmise doit correspondre à celle que la page déclare (login, register, checkout…). Une action incohérente fait baisser le score ou provoque le rejet du token, même quand la valeur numérique paraît correcte.
Validation côté serveur indispensable
Un token renvoyé n'est pas un token accepté. Contrôlez systématiquement trois champs de la réponse siteverify, côté serveur :
success: la vérification a abouti.score: la valeur réelle attribuée par Google.action: elle doit correspondre à l'action attendue.
Sans cette validation, vous payez pour des tokens que votre propre logique applicative rejette ensuite. C'est précisément la mesure qui révèle l'écart entre deux services au score moyen équivalent : celui dont les tokens franchissent votre seuil, et celui dont ils s'en approchent sans jamais le dépasser.
Pourquoi les solveurs par opérateurs humains échouent sur v3
reCAPTCHA v3 est invisible : il n'y a aucun puzzle à résoudre. Le score dépend de l'empreinte du navigateur, des schémas de comportement (souris, clavier), de l'historique de navigation, de l'état des cookies et de la réputation de l'IP. Des opérateurs humains qui cliquent dans une file de CAPTCHA ne génèrent pas ces signaux : ni l'historique, ni l'environnement navigateur d'un utilisateur réel. Ils obtiennent donc des scores bas sur v3, quel que soit leur taux de réussite sur les CAPTCHA visibles. Un service qui simule un environnement navigateur complet, comme CaptchaAI, est mieux armé pour produire des scores exploitables.
Le vrai coût des scores faibles
Un service peut paraître bon marché au token et coûter plus cher au final. Si une part importante des tokens tombe sous votre seuil, vous multipliez les appels pour un même volume de pages validées, et le prix unitaire perd tout son sens. Le bon indicateur reste le coût par token accepté.
CaptchaAI facture au thread (BASIC à $15/mois, 5 threads) plutôt qu'à la résolution : un thread libéré enchaîne immédiatement la tâche suivante, sans surcoût par CAPTCHA. Le coût devient prévisible dès lors que les scores restent au-dessus de votre seuil, puisque vous ne payez pas de nouvelles tentatives à l'unité. Intégrez ce paramètre à votre comparatif avant de trancher sur le seul prix affiché.
FAQ
Faut-il comparer les solveurs sur le score moyen ou sur le taux d'acceptation ?
Sur le taux d'acceptation à votre seuil. La moyenne masque la distribution : un service peut afficher une valeur correcte tout en produisant beaucoup de tokens juste sous votre seuil, donc rejetés côté serveur.
Comment mesurer le score réel d'un token ?
Côté serveur, via l'endpoint siteverify de Google avec votre clé secrète. Lisez score, action et success. Réservez cette vérification aux sites que vous exploitez ou à vos environnements de développement.
Le score varie-t-il selon la région ou l'heure ?
Oui. La réputation de l'IP, la charge et le contexte de session influent sur le score. Mesurez sur plusieurs jours et depuis l'infrastructure qui servira en production, pas sur un unique relevé ponctuel.
Peut-on relever le score sans paramètre dédié ?
Il n'existe pas de paramètre score-target sur l'API v3 ou v3 Enterprise de CaptchaAI. Pour peser sur le score renvoyé, attachez des signaux plus pertinents via cookies (session déjà active), userAgent (cohérent avec le trafic de la page) et proxy (IP résidentielle).
Une comparaison reCAPTCHA v3 solide repose sur des taux d'acceptation réels par seuil, mesurés dans votre propre contexte — pas sur des scores moyens hors sol.
