Nouveaux CAPTCHA Google
adieu feux rouges, bonjour QR code et smartphone obligatoire.

Depuis avril 2026, Google déploie progressivement Cloud Fraud Defense, une nouvelle génération de contrôle anti-bot qui change la manière dont un internaute peut être invité à prouver qu’il est humain. Dans les situations considérées comme à risque, le test visuel classique peut être remplacé par un QR code affiché sur l’ordinateur et à scanner avec un smartphone.

Le mécanisme repose sur davantage de signaux que les anciens CAPTCHA. Avant même que le QR code apparaisse, l’algorithme analyse des éléments comportementaux, techniques et contextuels. Le fichier cite notamment l’adresse IP, l’empreinte du navigateur et l’historique de navigation comme exemples de signaux utilisés pour évaluer le niveau de risque.

Le QR code n’est donc pas présenté à tous les visiteurs. Il intervient lorsqu’une session est jugée suspecte, par exemple dans des contextes de création de compte, de paiement ou de trafic inhabituel. L’utilisateur doit alors scanner le code avec son téléphone et laisser le mobile communiquer avec les serveurs Google ou Apple afin d’attester que l’appareil est considéré comme fiable.

Cette vérification impose des prérequis précis. Le fichier mentionne Android avec Google Play Services en version 25.41.30 ou supérieure, ou une version récente d’iOS ou d’iPadOS. Un appareil trop ancien ou un téléphone Android dégooglé sans Play Services peut donc échouer avant même que la personne ait la possibilité de prouver qu’elle est humaine.

Le changement est important parce que le CAPTCHA ne vérifie plus seulement une interaction ponctuelle. Il lie désormais une session web ouverte sur un ordinateur à un second appareil personnel. La logique consiste à utiliser l’intégrité et la réputation de ce second appareil comme élément de confiance supplémentaire.

La raison officielle du changement tient à l’efficacité croissante des modèles d’intelligence artificielle face aux anciens CAPTCHA. Les tests visuels demandaient d’identifier des objets dans une image à une époque où cette tâche était difficile pour un programme automatique. Ce n’est plus le cas en 2026.

Le fichier cite les modèles de type GPT-4o, Claude ou Grok comme exemples de systèmes capables de résoudre désormais ces tests avec une précision proche de celle d’un humain et à très faible coût. Augmenter la difficulté des images pénalise alors surtout les utilisateurs réels sans rendre la fraude suffisamment coûteuse.

Cloud Fraud Defense s’inscrit donc dans une stratégie plus large. Le document mentionne la création automatisée de faux comptes, le scraping massif, le credential stuffing, les attaques aidées par l’IA générative et la fraude aux paiements. Le QR code n’est que la partie visible d’un système qui cherche surtout à évaluer la fiabilité globale d’une session.

Cette logique n’est pas nouvelle chez Google. Le fichier rappelle le projet Web Environment Integrity de 2023, qui visait déjà à attester l’intégrité de l’environnement navigateur. Le projet avait provoqué une forte opposition et Google avait reculé. Avec Cloud Fraud Defense, une logique comparable revient sous la forme d’un produit cloud activé site par site.

Le changement pose donc une question de proportion. La menace est réelle : les bots sont plus performants, plus rapides et moins chers. Mais la réponse ne consiste plus seulement à distinguer un humain d’un robot ; elle consiste aussi à décider quel environnement matériel et logiciel est suffisamment fiable pour poursuivre la navigation.

Le premier risque concerne l’exclusion. Une personne sans smartphone, avec un appareil ancien ou avec un système non compatible peut se retrouver bloquée alors qu’elle est parfaitement humaine. Le problème est particulièrement visible pour les personnes âgées, précaires ou peu à l’aise avec la technologie.

Les utilisateurs de ROM dégooglées constituent un autre cas directement visé par le fichier. GrapheneOS, CalyxOS et /e/OS sont utilisés par des personnes qui cherchent à réduire leur dépendance aux services Google. Or le nouveau mécanisme repose précisément sur Google Play Services côté Android. Une démarche de protection de la vie privée peut donc devenir un motif indirect de blocage.

Le deuxième risque concerne la vie privée. Pour valider une session ouverte sur un ordinateur, le système demande de faire intervenir un téléphone personnel. Cette opération crée un lien explicite entre les deux appareils et renforce la possibilité d’un profilage croisé.

Le fichier rappelle que la vérification dépend soit de l’écosystème Google, soit de celui d’Apple. Cette dépendance technique pose la question d’un web à deux vitesses : d’un côté les appareils certifiés et reconnus par les grandes plateformes, de l’autre les environnements alternatifs ou anciens qui pourraient rencontrer davantage de blocages.

Des forums comme Hacker News ou Privacy Guides rapportent déjà des cas d’utilisateurs bloqués sur des sites e-commerce, des forums ou des services bancaires. Le document établit un parallèle avec les critiques formulées par GrapheneOS et avec les alertes plus larges concernant la surveillance invisible.

Le troisième risque est celui de la fermeture progressive du web. Si prouver son humanité revient de plus en plus à prouver qu’on utilise un appareil approuvé par Google ou Apple, l’accès à certains services peut devenir dépendant d’acteurs privés qui contrôlent les mécanismes d’attestation.

Pour l’utilisateur, le fichier propose d’abord des solutions pragmatiques. Utiliser un navigateur et un appareil compatibles réduit le risque de blocage. Il suggère aussi l’usage d’outils anti-tracking comme uBlock Origin, même si ces outils ne garantissent pas qu’un QR code ne sera jamais déclenché.

Tester plusieurs navigateurs peut également modifier le résultat. Firefox, Brave ou LibreWolf sont cités comme exemples. Le document précise toutefois qu’un VPN, un proxy ou certains navigateurs orientés privacy peuvent parfois augmenter le score de risque au lieu de le réduire. Il ne s’agit donc pas d’une méthode de contournement fiable.

Les utilisateurs bloqués peuvent enfin signaler les sites qui rendent ce mécanisme obligatoire aux associations de défense de la vie privée. Cette démarche ne résout pas immédiatement l’accès, mais elle permet de documenter les cas dans lesquels un contrôle anti-bot crée une discrimination technique disproportionnée.

Pour les webmasters, Cloud Fraud Defense reste optionnel. Le fichier rappelle qu’un site peut conserver d’anciennes versions de reCAPTCHA ou choisir d’autres solutions. L’enjeu est d’évaluer le risque réel avant d’imposer une vérification qui peut dégrader l’expérience utilisateur.

Un site soumis à une forte fraude sur les paiements ou à des vagues de création automatisée de comptes peut avoir davantage de raisons d’utiliser une solution renforcée. À l’inverse, un site peu exposé peut créer plus de problèmes qu’il n’en résout en imposant un contrôle basé sur smartphone.

Le document cite trois alternatives : hCaptcha, Cloudflare Turnstile et Friendly Captcha. Elles ne sont pas présentées comme parfaites, mais comme des options à examiner lorsqu’un webmaster cherche à réduire sa dépendance à l’écosystème Google.

Les nouveaux CAPTCHA QR code répondent à une évolution réelle : les barrières visuelles historiques ne suffisent plus face aux bots capables d’utiliser des modèles d’intelligence artificielle. Continuer à multiplier les images difficiles aurait surtout pour effet de rendre la navigation pénible pour les humains.

Google change donc de niveau de vérification. Au lieu de tester uniquement la capacité d’un utilisateur à reconnaître un objet, Cloud Fraud Defense cherche à évaluer la fiabilité de l’environnement, puis à utiliser le smartphone comme preuve supplémentaire lorsque le risque est jugé élevé.

Cette approche peut améliorer la lutte contre la fraude automatisée, mais elle déplace le coût vers l’utilisateur. Pour accéder à un service sur ordinateur, il peut devenir nécessaire de posséder un téléphone compatible, d’accepter une communication avec Google ou Apple et de relier temporairement les deux appareils.

Le dossier pose ainsi une question de fond : un web plus sûr doit-il nécessairement être un web plus fermé ? La réponse dépendra de la manière dont les sites utilisent ce nouvel outil. S’il reste réservé aux situations réellement sensibles, son impact peut être limité. S’il devient un réflexe généralisé, les problèmes d’exclusion et de dépendance aux plateformes prendront davantage d’importance.

Pour l’instant, Cloud Fraud Defense est une offre cloud que les webmasters peuvent choisir ou non. Rien n’oblige l’ensemble du web à adopter cette méthode. Mais le fichier rappelle qu’une généralisation progressive reste possible si l’efficacité est jugée suffisante.