Mécanisme anti-robots qui évalue discrètement, en arrière-plan, la probabilité qu’un utilisateur soit humain à l’aide d’un score de risque, sans imposer de défi perceptif (visuel, auditif) ni d’interaction explicite.
C’est une solution de protection contre les automates qui remplace les tests traditionnels (reconnaissance d’images, saisie de sons, puzzles) par une analyse passive et contextuelle du comportement de l’utilisateur.
Il fonctionne sans interruption visible de l’expérience, en attribuant un score de confiance à chaque session ou action, à partir de signaux techniques et comportementaux. Ce score détermine si l’action est acceptée, soumise à une vérification légère ou bloquée.
Principe de fonctionnement : le score de risque
Le système calcule dynamiquement un score de risque en croisant plusieurs indicateurs, tels que :
- Le temps de chargement et de remplissage du formulaire
- La cohérence des interactions (mouvements de souris, séquence de clics, navigation au clavier, focus)
- Le contexte technique (réputation de l’IP, navigateur, système d’exploitation, cohérence des en-têtes)
- La présence de comportements automatisés (soumissions instantanées, scripts détectés)
- Les signaux JavaScript et métadonnées réseau (user-agent, cookies, TLS fingerprint, etc.)
Selon la valeur du score (souvent normalisé entre 0 = bot certain et 1 = humain certain) :
- Score faible → utilisateur traité comme un bot (refus ou blocage)
- Score intermédiaire → déclenchement d’une vérification alternative (ex. question logique simple, envoi différé)
- Score élevé → validation silencieuse, sans friction
Caractéristiques clés
- Invisibilité : aucune interaction requise dans la majorité des cas
- Accessibilité par conception : ne sollicite ni la vision, ni l’ouïe, ni la motricité fine
- Compatibilité totale avec les technologies d’assistance (lecteurs d’écran, navigation clavier)
- Approche adaptative : la vérification est proportionnelle au risque perçu
- Friction minimale : améliore l’expérience utilisateur tout en renforçant la sécurité
Enjeux d’accessibilité
Les CAPTCHA invisibles adaptatifs répondent aux principes fondamentaux des WCAG :
- Perceivable : aucune information cachée derrière un test sensoriel
- Operable : aucune action inhabituelle ou complexe requise
- Understandable : pas de défi ambigu ou culturellement biaisé
- Robust : compatible avec les agents utilisateurs, y compris les outils d’accessibilité
Ils sont donc préférables aux CAPTCHA traditionnels, souvent exclusifs pour les personnes aveugles, malvoyantes, dyslexiques, en situation de handicap moteur ou cognitif.
Important : même si le mécanisme est invisible, une alternative accessible (ex. contact humain, canal d’assistance) doit toujours être prévue en cas de blocage erroné — conformément au critère 11.10 du RGAA.
Exemples concrets
- Google reCAPTCHA v3
→ Score de 0 à 1 basé sur l’analyse comportementale continue
→ Aucune interface utilisateur visible
→ Décision prise côté serveur selon les seuils définis par le site - Cloudflare Turnstile (mode invisible)
→ Évaluation passive de l’interaction avec le formulaire
→ Protection sans défi, intégrée via un simple widget invisible
→ Conçu explicitement pour l’accessibilité et la performance
Limites et vigilances éthiques
- Opacité algorithmique : le calcul du score reste souvent une boîte noire, difficile à auditer ou à expliquer
- Biais techniques : les utilisateurs de VPN, de réseaux partagés (écoles, bibliothèques) ou de configurations atypiques (navigateurs alternatifs, bloqueurs de JS) peuvent être injustement marqués comme bots
- Dépendance au JavaScript : sans JS activé, ces protections échouent ou nécessitent un recours alternatif
- Absence de recours clair : certains systèmes ne permettent pas à l’utilisateur de contester un blocage
Recommandation : toujours coupler ces solutions avec des mécanismes de recours transparents et une stratégie de détection complémentaire (ex. honeypots, rate limiting) pour réduire les faux positifs et renforcer la résilience.