reCAPTCHA devient Google Cloud Fraud Defense : ce qui change vraiment

Il y a vingt ans, reCAPTCHA nous demandait de déchiffrer des numéros de maison flous pour prouver qu’on n’était pas un robot. Puis les cochettes « Je ne suis pas un robot » ont pris le relais. Puis le scoring silencieux de reCAPTCHA v3. Et maintenant, Google tire un trait sur le nom même de reCAPTCHA — du moins dans sa déclinaison entreprise — pour lancer Google Cloud Fraud Defense. Ce n’est pas un simple lifting de marque.

Là où reCAPTCHA avait pour mission de distinguer humains et bots, Google Cloud Fraud Defense ambitionne de couvrir l’intégralité du spectre de la fraude en ligne : credential stuffing, account takeover, fraude au paiement, abus de promotions. Google veut devenir la couche de sécurité comportementale universelle du web. C’est une ambition différente — et une proposition à décortiquer sérieusement.

C’est impressionnant sur le papier. Sur le fond, il y a des choses intéressantes à creuser — techniques comme éthiques.

De reCAPTCHA à Fraud Defense : une évolution qui avait de la logique

reCAPTCHA v3, sorti en 2018, avait déjà posé les bases de ce changement de paradigme. Fini les challenges visuels : l’API retournait un score de 0.0 à 1.0 basé sur l’analyse comportementale passive. Le développeur récupérait ce score et décidait quoi faire. C’était élégant, mais ça n’allait pas assez loin.

Le problème de reCAPTCHA v3, c’est qu’il se concentrait sur la distinction bot/humain. Or la fraude moderne vient souvent d’humains — ou de bots suffisamment sophistiqués pour imiter parfaitement des sessions légitimes. Le credential stuffing, par exemple, peut tout à fait ressembler à une connexion normale si les attaquants font leur travail proprement. Un score « humain » de 0.9 ne signifie pas « utilisateur de bonne foi ».

Google Cloud Fraud Defense élargit donc le scope à des vecteurs que reCAPTCHA ne couvrait pas vraiment : protection de compte, fraude au paiement, et ce qu’ils appellent le « multi-merchant fraud » — la capacité à corréler des comportements frauduleux entre plusieurs sites utilisant la même plateforme. C’est sur ce dernier point que Google a un avantage structurel difficilement contestable : leur réseau couvre une part colossale du web mondial. Un pattern détecté sur un site peut alimenter le modèle qui protège un autre site quelques heures plus tard.

Ce que cache vraiment le « fraud score »

La mécanique centrale reste la même : ton backend appelle l’API avec un token généré côté client, et tu reçois un score. Mais le score de Fraud Defense est plus granulaire que celui de reCAPTCHA v3. Il intègre des « fraud signals » catégorisés — signaux de bot, signaux de compte, signaux de paiement — que tu peux interroger séparément selon le contexte de l’action déclenchée.

Concrètement, l’API peut te retourner un score global de risque, une probabilité que l’email soit lié à un compte récemment compromis, des signaux comportementaux sur la session courante, et des données de réputation du device. Pour un développeur qui gère une plateforme SaaS ou un site e-commerce, c’est une richesse d’informations qui permet des logiques métier différenciées : forcer un 2FA si le score dépasse un seuil, bloquer silencieusement une tentative de paiement, déclencher une vérification manuelle.

L’intégration technique : ce qui change, ce qui reste

Bonne nouvelle pour ceux qui utilisaient déjà reCAPTCHA Enterprise : Google assure une compatibilité ascendante. Les clés existantes fonctionnent, les endpoints /v1/projects/.../assessments restent en place. La migration se fait progressivement, en activant les nouvelles fonctionnalités à la carte sans tout casser.

Le SDK JavaScript côté client change peu. On charge toujours grecaptcha.enterprise.execute(), on récupère un token, on l’envoie à son backend, qui fait une requête REST à l’API Google. La nouveauté principale, ce sont les paramètres supplémentaires qu’on peut désormais passer — notamment des userInfo (email hashé, identifiant utilisateur) que Google utilise pour enrichir son modèle avec des données de réputation cross-merchant.

// Côté client — quasi identique à reCAPTCHA Enterprise
const token = await grecaptcha.enterprise.execute('VOTRE_CLE_SITE', {
  action: 'checkout',
  userInfo: {
    accountId: hashSHA256(userId), // identifiant hashé côté client
  }
});

C’est ce bloc userInfo qui est nouveau, et qui mérite d’être examiné attentivement — pour des raisons techniques autant que pour des raisons de vie privée. On y revient juste après.

La vie privée : l’éléphant dans la pièce

Utiliser Google Cloud Fraud Defense, c’est confier à Google un flux quasi-exhaustif des sessions sensibles de tes utilisateurs. Chaque tentative de connexion, chaque checkout, chaque action à risque génère une empreinte traitée dans l’infrastructure de Google.

La frontière entre « outil de sécurité » et « collecte de données comportementales à grande échelle » devient structurellement floue — et ce n’est pas une question de mauvaise intention, c’est une question de design.

Dans un contexte RGPD, ça se discute. La documentation Google indique que les données sont traitées selon les termes du Data Processing Amendment (DPA) de Google Cloud, et que les tokens ne persistent pas bruts. Mais « ne persistent pas » ne signifie pas que les signaux agrégés ne nourrissent pas les modèles — c’est précisément la proposition de valeur du produit. Ce n’est pas un problème nouveau avec reCAPTCHA, mais l’extension du scope l’amplifie notablement.

Avant, on transmettait des signaux comportementaux génériques. Maintenant, on peut transmettre des identifiants de compte (hashés, certes) et des métadonnées de transaction. Ce n’est pas forcément un problème — mais c’est une décision consciente à prendre, pas un détail de configuration à ignorer dans la doc.

Les alternatives : sérieuses, mais avec leurs propres compromis

Si la dépendance à Google te pose un problème de fond, l’écosystème propose des options sérieuses. hCaptcha est la plus connue, avec un modèle économique différent — ils rémunèrent les sites pour le travail de labellisation. Bonne séparation avec Google, mais couverture réseau et précision du scoring moins impressionnantes.

Cloudflare Turnstile est devenu une option crédible depuis son lancement. Gratuit, sans challenge visuel, et avec un engagement explicite sur la non-utilisation des données à des fins publicitaires. Pour des projets qui passent déjà par Cloudflare pour l’hébergement et la sécurité, l’intégration est particulièrement naturelle et cohérente avec l’infrastructure existante.

Arkose Labs, HUMAN (ex-White Ops) ou Sift visent le marché enterprise avec des promesses similaires à Google Cloud Fraud Defense — mais à des tarifs qui sortent rapidement les PME du tableau. Pour une boutique en ligne de taille moyenne, le compromis Fraud Defense reste souvent le plus rationnel : produit solide, bien documenté, gratuit jusqu’à un volume significatif, et équipe dev qui n’a pas à maintenir une infrastructure de scoring maison.

Ce que ça implique concrètement pour toi

Google Cloud Fraud Defense est un bon produit — techniquement, c’est difficile à contester. L’extension du scoring au-delà de la détection de bots répond à un vrai besoin, et la migration depuis reCAPTCHA Enterprise est suffisamment douce pour ne pas être une corvée. Si tu gères une application sur mesure avec un espace membre ou un tunnel de paiement, les nouveaux signaux offrent une vraie valeur ajoutée pour implémenter des politiques de risque plus fines.

Mais cette annonce illustre aussi un pattern qu’on doit nommer clairement : Google étend progressivement sa surface d’observation du web, en emballant ça dans des produits de sécurité légitimes et utiles. C’est rationnel de leur part, et pas nécessairement malveillant. Mais ça mérite une décision explicite de ta part — pas un copier-coller de snippet par défaut.

Mon pari : d’ici deux ans, la majorité des frameworks et CMS populaires auront une intégration officielle Google Cloud Fraud Defense dans leurs modules de sécurité. Ce sera pratique, rapide à déployer, et la question de la dépendance sera encore moins posée qu’aujourd’hui. Ce serait dommage. Les alternatives existent, elles fonctionnent, et prendre le temps de choisir consciemment sa couche de sécurité fait partie du métier.