Réponse concise : vous. Depuis le 2 avril 2026, Google se déclare sous-traitant pour reCAPTCHA et désigne l'exploitant du site comme seul responsable du traitement des données client. Aucune migration, aucune action, aucun changement de tarif n'étaient requis, ce qui explique que le changement soit passé inaperçu. Le cookie du dispositif, lui, reste en place, donc la question du consentement préalable se pose dans les mêmes termes qu'avant.
Sources : documentation reCAPTCHA de Google Cloud, annonce sur la communauté sécurité de Google Cloud, blog Google Cloud du 22 avril 2026, article 82 de la loi informatique et libertés et délibération CNIL 2020-091. Page mise à jour en août 2026.
Dans cet article
Un petit widget carré, en bas à droite du formulaire de contact, avec la mention « protégé par reCAPTCHA » et deux liens vers les documents de Google. Des millions de sites l'affichent, et à peu près personne ne l'a regardé depuis le jour de son installation.
Il vaut la peine de le regarder maintenant. Le 2 avril 2026, Google a modifié la répartition juridique des responsabilités autour de ce service, et l'exploitant du site s'est retrouvé seul responsable du traitement des données de ses visiteurs. Rien à installer, rien à valider, rien à payer de plus. C'est exactement pourquoi le changement est passé sous les radars.
Ce qui a changé le 2 avril 2026
Google a annoncé la chose en janvier 2026, sur la communauté sécurité de Google Cloud : reCAPTCHA cessait d'être une offre de responsable de traitement pour devenir une offre de sous-traitance, alignée sur le reste des services Google Cloud. La documentation du produit le formule sans détour. Depuis le 2 avril 2026, les clients sont seuls responsables du traitement des données client, et Google ne traite ces données que selon les conditions de service Google Cloud et l'avenant de traitement des données.
Le même document en tire la conséquence visible. Les références à la politique de confidentialité et aux conditions d'utilisation de Google disparaissent du badge, parce qu'elles ne décrivent plus la répartition des rôles. Google recommande aux exploitants de retirer ces mêmes références de leurs propres pages, par souci d'exactitude. Autrement dit, les liens que des milliers de sites affichent encore sous leur formulaire ne décrivent plus rien.
Côté technique, rien n'a bougé. Les clés de site restent valides, l'intégration reste identique, aucune migration n'était demandée, le tarif ne change pas. Un changement qui ne réclame rien à personne ne se remarque pas, et celui-ci a traversé le printemps sans faire de bruit chez les PME françaises.
Ce que « seul responsable de traitement » veut dire pour vous
Traduit en clair, le responsable du traitement est celui qui doit pouvoir expliquer ce que le dispositif collecte, à quoi cela sert, et qui répond quand un visiteur ou un contrôleur pose la question. C'est aussi lui qui doit gérer ce qui est déposé sur le terminal du visiteur, et justifier qu'il avait le droit de le faire. Tant que Google se présentait comme responsable indépendant pour la fourniture du service, un exploitant pouvait s'appuyer sur ce statut et sur les liens du badge. Ces liens ont disparu et Google indique lui-même qu'ils étaient devenus inexacts.
Google encourage d'ailleurs ses clients à relire les informations qu'ils donnent à leurs visiteurs, pour vérifier qu'elles disent bien à quoi sert reCAPTCHA, ce qu'il décrit comme la sécurité et la prévention de la fraude et des abus. La demande est raisonnable. Elle suppose seulement que quelqu'un, chez l'exploitant, ait lu l'annonce et ouvert la politique de confidentialité.
Nous ne sommes pas juristes et nous ne dirons pas ce que votre situation exige. Un délégué à la protection des données ou un avocat le fera mieux que nous, et sur ce terrain nous nous en tenons à ce qui est écrit et daté. La partie qui nous concerne vient maintenant.
Le périmètre a grandi, lui aussi
Le 22 avril 2026, à Cloud Next, Google a présenté Google Cloud Fraud Defense comme l'évolution suivante de reCAPTCHA : une plateforme de confiance destinée au web dit agentique, chargée de vérifier la légitimité des humains, des robots et des agents autonomes. reCAPTCHA n'est pas abandonné, il devient le pilier anti-robots de cet ensemble plus large. Le blog Google Cloud précise que les clients reCAPTCHA existants sont automatiquement clients de Fraud Defense, sans migration, sans action de leur part, sans changement de tarif, leurs clés et leurs intégrations restant en place.
Regardez le trajet. Une PME a posé un petit widget pour empêcher les robots de remplir son formulaire de contact. Ce widget est aujourd'hui un composant d'une plateforme dont le champ couvre l'usurpation de compte, la défense des transactions et le trafic d'agents autonomes. Elle n'a pas choisi cet élargissement, elle n'avait rien à accepter, et elle sera tout aussi étrangère au suivant.
C'est la définition d'une dépendance tierce, et c'est le seul endroit de cet article où nous parlons en connaissance directe. Sur les sites que nous construisons, le filtrage anti-robots d'un formulaire de contact tient en quelques dizaines de lignes dont le périmètre n'a pas varié depuis leur écriture. Ce n'est pas plus intelligent que reCAPTCHA, qui fait un travail que nous ne prétendons pas égaler sur les attaques massives. C'est simplement à nous, donc prévisible, et son poids au chargement se mesure comme le reste des bibliothèques d'une page. Nous avons tenu le même raisonnement en retirant les cartes Google des sites que nous livrons, pour des motifs différents mais avec la même conclusion sur la prévisibilité d'une brique tierce.
Ce que le changement ne règle pas
La documentation Google est explicite sur un point : le cookie reCAPTCHA reste en place et n'est pas affecté par le changement de rôle. La question qui existait avant existe donc encore.
En France, la lecture et l'écriture d'informations sur le terminal d'un visiteur relèvent de l'article 82 de la loi informatique et libertés. Les exemptions de consentement y sont étroites. Le traceur doit avoir pour finalité exclusive de permettre ou faciliter la communication par voie électronique, ou être strictement nécessaire à la fourniture d'un service de communication en ligne à la demande expresse de l'utilisateur. Les lignes directrices de la CNIL du 17 septembre 2020, délibération 2020-091, précisent ce cadre et posent la règle qui décide de tout ici : un traceur exempté ne le reste que s'il sert uniquement à ce que les exceptions couvrent. Dès qu'il sert aussi à autre chose, ne serait-ce qu'un usage supplémentaire, le consentement redevient obligatoire.
Appliqué aux captchas, cela donne une doctrine que la CNIL publie dans sa foire aux questions sur les cookies, et qui mérite d'être lue en entier avant de conclure quoi que ce soit. Un dispositif qui ne fait que sécuriser le site, ou protéger une page de connexion, n'a pas besoin de consentement. Il en a besoin dès que ce qu'il écrit sur le terminal sert aussi à autre chose que cette sécurité. La CNIL admet d'ailleurs explicitement les traceurs qui sécurisent une authentification, y compris en limitant les tentatives d'accès robotisées. Le problème n'est donc pas d'être un captcha, c'est ce que le fournisseur fait des données en plus.
Ce cadre, nous le connaissons par l'autre bout. La même délibération 2020-091 est celle sous laquelle notre Matomo auto-hébergé fonctionne sans bandeau, parce que sa configuration reste dans la finalité exemptée. Un texte, deux résultats opposés, et ce qui les sépare est ce que l'outil fait réellement des données.
Il faut reconnaître la difficulté que cela crée. Soumettre un dispositif de sécurité au consentement le rend contournable par un refus, ce qui affaiblit la protection qu'il apportait. La tension est réelle et nous n'avons pas de solution élégante à proposer, sinon de choisir un mécanisme qui n'a pas besoin d'écrire quoi que ce soit sur le terminal du visiteur.
Un mot, enfin, sur le statut que Google s'attribue. Se déclarer sous-traitant ne suffit pas à l'être : la CNIL écrit que la qualification dépend des faits, de qui décide quoi, et non d'un choix contractuel. Nous ne savons pas ce que Google fait de ces données et nous n'affirmerons rien là-dessus, mais la question reste ouverte, et elle se pose à un délégué à la protection des données plutôt qu'à nous.
Quand un captcha reste défendable
Il y a des situations où un captcha est la réponse proportionnée. Une page de connexion attaquée par bourrage d'identifiants, un tunnel de paiement, une création de compte ouverte à grande échelle, un formulaire public qui reçoit des milliers de soumissions par jour : le rapport entre la gêne imposée aux visiteurs et le risque écarté penche clairement d'un côté. Sur la protection d'une page de connexion, la doctrine de la CNIL est même explicitement favorable : elle exempte de consentement les traceurs qui sécurisent une authentification, notamment en limitant les tentatives robotisées. Un captcha qui s'arrête là entre dans cette catégorie.
Ce que nous mettons en doute est le réflexe qui consiste à en poser un sur un formulaire de contact recevant quelques messages par semaine. Le coût y est supporté par les visiteurs légitimes, dont une part abandonne devant l'épreuve, et la charge de conformité par le propriétaire du site. Un captcha est aussi un obstacle d'accessibilité documenté, indépendamment de tout débat réglementaire. Des solutions hébergées en Europe et sans cookie existent, et elles répondent à une partie du problème.
Ce que vous pouvez faire vérifier cette semaine
Les deux premiers points se règlent en quelques minutes par la personne qui gère votre site. Le troisième demande un œil technique, et nous le disons plutôt que de prétendre le contraire. Le plus simple est de transmettre cette liste telle quelle.
-
Retirer les renvois vers les documents de Google autour du formulaire. Toute mention qui pointe vers la politique de confidentialité ou les conditions d'utilisation de Google au titre du captcha ne décrit plus la répartition des rôles depuis le 2 avril, et Google recommande lui-même de la supprimer. Résultat attendu : plus aucun renvoi vers ces deux documents à côté de votre formulaire.
-
Ajouter dans la politique de confidentialité une phrase sur le captcha. Elle doit le nommer, dire à quoi il sert, à savoir la sécurité et la prévention de la fraude et des abus, et indiquer que des données techniques sont transmises au fournisseur. Résultat attendu : un visiteur qui se demande ce que fait ce widget trouve la réponse sans quitter votre site.
-
Faire dire si un cookie est déposé avant tout consentement. Il faut ouvrir l'onglet réseau du navigateur sur la page de contact, sans rien toucher, et regarder ce qui part vers un domaine tiers et à quel moment. Résultat attendu : une réponse par oui ou par non. Si c'est oui, la question du consentement préalable se pose, et c'est le moment d'en parler à un délégué à la protection des données ou de changer de dispositif.
Si l'une des trois réponses reste floue après avoir posé la question, c'est en soi un renseignement : personne ne sait aujourd'hui ce que votre formulaire de contact envoie, ni à qui.
Ce que nous en retenons
Le changement d'avril n'est pas un scandale, et Google a fait ce qui est attendu d'un fournisseur : il a publié, daté, et indiqué quoi corriger. Le problème est ailleurs. Une PME a hérité d'obligations nouvelles et d'un périmètre de service élargi sans avoir rien décidé, ni rien signé, ni même reçu un signal qu'elle pouvait comprendre. C'est le mode de fonctionnement normal d'une dépendance tierce, et la seule variable sur laquelle vous gardez la main est le nombre de ces dépendances que vous acceptez de porter. La même logique s'applique aux outils qui traitent les conversations de vos prospects.
Nous ne posons pas de captcha tiers sur les sites que nous livrons, et ce n'est pas une posture : notre politique de sécurité du contenu n'autorise aucun domaine Google en source de script, ce qui rend son chargement impossible. L'en-tête est lisible dans le même onglet réseau que celui du troisième point. Notre formulaire filtre les robots sans appeler de service tiers ni déposer de cookie, et nous détaillons cette approche dans un prochain article. Le calcul vaut d'ailleurs au-delà du seul captcha.
Un formulaire de contact est l'un des rares endroits d'un site où cette arithmétique se règle simplement, parce que le besoin réel y est modeste et qu'il se couvre sans appeler personne à l'extérieur.
Questions fréquentes
Faut-il retirer le captcha de son formulaire de contact ?
Pas nécessairement. La réponse dépend du volume d'attaques réel et de ce que le captcha vous apporte. Sur un formulaire de contact qui reçoit quelques messages par semaine, la friction imposée aux visiteurs légitimes et la charge de conformité dépassent souvent le bénéfice, et d'autres méthodes filtrent les robots sans rien demander au visiteur.
Le changement du 2 avril 2026 règle-t-il la question du consentement ?
Non. La documentation de Google indique que le cookie reCAPTCHA reste en place et n'est pas affecté. La question du consentement préalable au dépôt de traceurs, régie en France par l'article 82 de la loi informatique et libertés, se pose dans les mêmes termes qu'avant. Le critère retenu par la CNIL est la finalité : un dispositif dont la seule finalité est la sécurisation du site ou d'une authentification est exempté, un dispositif dont les opérations servent aussi d'autres finalités ne l'est pas.
Qui répond en cas de contrôle ?
Depuis le 2 avril 2026, Google désigne l'exploitant du site comme seul responsable du traitement des données client. Les obligations d'information, de base légale et de gestion des traceurs reposent donc sur lui. Un délégué à la protection des données ou un avocat confirmera ce que votre situation précise implique.
Dites-nous votre adresse, nous regardons ensemble ce qui part vers des tiers au chargement de votre page de contact et ce que votre politique de confidentialité doit désormais dire.
En parler avec nousRéponse par une personne, pas par un formulaire automatique.