reCAPTCHA et RGPD : choisir une protection adaptée
reCAPTCHA, consentement et alternatives : décidez avec les règles actuelles, un dossier de formulaire rempli et des contrôles de réception.
reCAPTCHA n’est ni interdit par principe, ni dispensé de toute analyse parce qu’il protège un formulaire. Il faut distinguer la nécessité de la protection, les opérations sur le terminal et le traitement des données personnelles. Une protection strictement nécessaire peut relever de l’exemption de consentement aux traceurs ; une finalité supplémentaire ne bénéficie pas automatiquement de cette exemption.
Le dossier doit aussi être daté. Depuis le 2 avril 2026, Google annonce un changement de rôle concernant les données client de reCAPTCHA. Reprendre sans examen un avis fondé sur ses anciennes conditions peut donc conduire à une mauvaise décision. Voici comment choisir une protection et conserver un formulaire utilisable.
Séparer les trois décisions juridiques
La première concerne l’accès au terminal : dépôt de cookie, lecture d’informations ou autre opération entrant dans l’Art. 82 de la loi Informatique et Libertés. Le consentement préalable est le principe, avec notamment une exception pour les opérations strictement nécessaires à un service expressément demandé par l’utilisateur. Le nom commercial du dispositif ne tranche pas cette question. Art. 82.
La CNIL admet l’exemption pour certains CAPTCHA limités à la sécurité du site ou du mécanisme d’authentification au bénéfice des utilisateurs. Elle distingue les finalités supplémentaires non nécessaires et recommande des protections alternatives ou complémentaires lorsque la sécurité dépendrait du consentement. Cette appréciation exige de connaître les usages effectifs, pas seulement la catégorie « nécessaire » inscrite dans un bandeau. FAQ CNIL, questions 16 à 18.
La deuxième décision porte sur la base légale du traitement personnel. L’intérêt légitime de sécuriser un formulaire peut être retenu après analyse de sa nécessité et des conséquences pour les personnes. Il ne dispense pas du consentement aux traceurs lorsqu’il est requis. Inversement, un traceur exempté ne rend pas licite une collecte disproportionnée. L’Art. 6(1)(f) impose une mise en balance, et l’Art. 5(1)(c) une limitation des données. RGPD, chapitre II.
La troisième décision concerne les garanties : prestataires, accès, conservation et transferts éventuels. Elle reste nécessaire même si les deux premières décisions sont favorables. Le dossier de conformité des cookies peut accueillir l’analyse du terminal ; le registre décrit aussi le traitement de sécurité et son responsable.
Intégrer le changement contractuel de 2026
La FAQ Google Cloud consultée en septembre 2026 indique que, depuis le 2 avril, le client est seul responsable du traitement des « Customer Data » et Google sous-traitant dans ce périmètre. Elle précise que le cookie demeure et invite les clients à adapter leur information. Cette évolution ne signifie donc pas disparition des opérations sur le terminal. FAQ Google Cloud, traitement des données.
Les conditions spécifiques actuelles limitent l’utilisation des informations à la fourniture, au maintien et à l’efficacité de la protection ; elles excluent notamment leur emploi par Google pour la publicité personnalisée. Leur section concerne désormais Google Cloud Fraud Defense, anciennement reCAPTCHA Enterprise. Il faut rattacher le service réellement intégré au contrat pertinent. Conditions spécifiques, section 45.
La FAQ CNIL conserve un exemple relatif à des usages propres de Google. Il faut donc confronter cet exemple au contrat et aux flux actuels, sans transformer la nouvelle documentation de Google en décision d’exemption délivrée par la CNIL.
Demandez à l’intégrateur la version installée, le projet associé, les conditions applicables et les traitements ajoutés par son extension. Une capture du badge ne suffit pas. Le contrat de sous-traitance doit couvrir les opérations effectivement réalisées ; l’Art. 28(3) précise les engagements attendus. RGPD, chapitre IV.
Comparer des protections pour un besoin précis
Une PME qui reçoit des messages indésirables n’a pas nécessairement le même besoin qu’un service exposé à des tentatives massives de connexion. Écrivez d’abord ce que vous cherchez à empêcher : répétitions rapides, liens malveillants, usurpation ou création automatisée de comptes. Compter tous les messages sans qualifier l’abus peut conduire à bloquer des demandes légitimes.
Le tableau suivant est une grille de conception proposée, pas un classement de produits ni un résultat d’essai.
| Option | Réponse apportée | Limite à traiter |
|---|---|---|
| Limitation de fréquence côté serveur | Contenir les envois répétés vers une même fonction | Un réseau partagé ne doit pas entraîner une exclusion durable de tous ses utilisateurs |
| Champ piège conçu pour les robots | Repérer certains remplissages automatisés simples | Prévoir les lecteurs d’écran et le remplissage automatique ; ne pas rejeter sur ce seul signal non évalué |
| Validation du format et de la taille | Refuser les charges manifestement incompatibles avec le formulaire | Un message correctement formé peut rester abusif |
| Confirmation de l’adresse email | Vérifier que la personne contrôle la boîte indiquée | Ne prouve pas l’absence de robot ; ajoute un message et ne convient pas à toutes les demandes urgentes |
| Analyse de risque par un prestataire | Apporter des signaux complémentaires | Examiner données, erreurs de classement, contrat et opérations sur le terminal |
Ces mesures peuvent se combiner. Une protection interne traite elle aussi potentiellement des données personnelles, par exemple une adresse IP : elle n’est pas « hors RGPD ». L’Art. 32(1) demande une sécurité adaptée au risque ; il n’impose pas la présence d’une marque particulière.
Dossier rempli : le formulaire de l’atelier Orme
Prenons un exemple fictif. L’atelier Orme propose un formulaire de demande de réparation de mobilier. Il recueille une adresse email et une description courte. Les pièces jointes sont demandées ensuite si elles sont utiles. L’équipe veut empêcher les envois automatisés sans transformer une prise de contact en contrôle d’identité.
Sa décision de conception est la suivante : validation et limitation de fréquence au serveur, file de traitement pour les messages suspects, puis évaluation d’un dispositif tiers uniquement si le besoin résiduel le justifie. Ce choix illustre un raisonnement ; aucune protection n’a été effectivement installée ou testée pour cet article.
| Élément du dossier O-19 | Décision retenue dans l’exemple |
|---|---|
| Finalité | Maintenir la réception de demandes utilisables, sans classement commercial des visiteurs |
| Données métier | Email et description nécessaires à la réponse ; aucune copie d’identité demandée |
| Signal de sécurité | État de validation et motif technique limité ; pas de copie systématique du texte dans le journal |
| Décision sur un message suspect | Mise en attente avec contrôle par une personne habilitée, sans accusation de fraude |
| Durée proposée | Journal technique conservé sept jours, puis suppression ; prolongation motivée séparément si incident |
| Responsables | Prestataire web pour les contrôles techniques, responsable de l’atelier pour le traitement des demandes |
| reCAPTCHA | Activation réservée tant que le dossier contractuel et les flux ne sont pas expliqués |
Les sept jours sont un choix illustratif à justifier, pas une durée légale des CAPTCHA. Le dossier sépare aussi le message client du journal : supprimer ce dernier ne doit pas effacer une demande encore en cours de réponse.
Si les mesures retenues laissent passer trop d’abus, l’atelier examine les incidents documentés : origine commune, fréquence, fonction visée et conséquences. Il peut renforcer le contrôle concerné. Il ne conclut pas automatiquement qu’un suivi de toutes les pages est nécessaire. Si, au contraire, les réclamations montrent des demandes légitimes bloquées, il adapte la règle et ouvre le canal de secours.
Réceptionner l’intégration avant son ouverture
Le développeur doit remettre une description du flux : ce que charge le navigateur, ce qu’il transmet, ce que reçoit le serveur, puis la décision appliquée au message. Le DPO ou le référent confronte cette description aux finalités et à la notice. Une liste de cookies isolée ne décrit pas les autres appels réseau.
Pour une intégration utilisant siteverify, Google demande une vérification du jeton depuis le serveur. Le jeton est à usage unique et valable deux minutes. La présence du widget ou d’un champ rempli ne suffit donc pas à établir que la validation a été correctement effectuée. Ces indications concernent cette interface précise. Documentation de validation Google.
La réception proposée doit couvrir quatre situations : demande ordinaire, répétition automatisée simulée, indisponibilité du service tiers et utilisateur incapable de terminer le contrôle. Pour chacune, consignez le résultat attendu, le résultat observé et la destination réelle du message. Une réponse affichée « envoyée » sans réception métier est une anomalie, pas un formulaire fonctionnel.
Si un accès au terminal soumis au consentement est retenu, ajoutez les parcours avant choix, après refus et après retrait. Si le composant s’exécute malgré ces états, suspendez l’intégration concernée et maintenez une voie protégée indépendante ; corrigez puis refaites les contrôles avant réactivation. Si l’exemption est retenue, conservez plutôt sa justification précise et la preuve que des finalités supplémentaires ne se sont pas ajoutées.
Limiter les données transmises et organiser le secours
Ne placez ni adresse email ni détail de la demande dans un nom d’action. Google interdit les actions propres à un utilisateur. Sa FAQ présente également recaptcha.net comme une alternative au domaine google.com, sans annoncer la disparition du cookie de sécurité. Ce remplacement ne démontre pas à lui seul une localisation européenne ou l’absence de transferts. FAQ développeurs.
Contrôlez aussi les paramètres UTM et autres données dans les URL. Un email placé dans un lien peut circuler dans plusieurs journaux indépendamment du formulaire. Pour un formulaire HubSpot intégré, décrivez séparément le formulaire, sa protection et les fonctions de suivi associées.
Le canal de secours doit être exploitable : adresse surveillée, demande limitée aux informations nécessaires et consigne de ne pas transmettre de document sensible à ce stade. Son responsable doit pouvoir retrouver une demande interrompue sans demander une pièce d’identité par défaut. Évitez une boucle dans laquelle le formulaire d’assistance impose le même contrôle inaccessible.
L’information reste due pour les données personnelles, y compris si le traceur est exempté. Une première couche adaptable serait : « Nous utilisons les données de ce formulaire pour répondre à votre demande et sécuriser sa réception. Certaines demandes peuvent être examinées avant transmission à notre équipe. Consultez notre information détaillée pour connaître les destinataires, durées et modalités d’exercice de vos droits. » Cet extrait est incomplet : l’information détaillée doit notamment identifier le responsable, préciser les bases retenues et couvrir les éléments applicables de l’Art. 13. RGPD, chapitre III.
Ce qu’il faut retenir
La bonne décision repose sur le besoin de protection et les flux réels. Le changement contractuel de 2026 mérite une révision du dossier reCAPTCHA, sans assimilation automatique à une exemption. La réception doit démontrer à la fois la protection recherchée et la possibilité de transmettre une demande légitime.
FAQ
Faut-il obliger l’utilisateur à accepter tous les cookies ?
Non. Un besoin de sécuriser le formulaire ne justifie pas de conditionner son utilisation à des traceurs publicitaires indépendants. Séparez les fonctions et prévoyez une solution adaptée si le composant choisi nécessite un consentement refusé.
Peut-on déduire qu’un score faible désigne un fraudeur ?
Non. Traitez-le comme un signal à apprécier dans son contexte. La conservation d’une accusation nominative et son utilisation commerciale constituent des décisions supplémentaires, qui ne découlent pas de la protection du formulaire.
Le fournisseur peut-il remplacer notre analyse ?
Sa documentation apporte des éléments techniques et contractuels. L’entreprise doit encore les confronter à son intégration, aux données réellement envoyées et aux droits des utilisateurs. Une fonctionnalité documentée n’est pas la preuve qu’elle est correctement configurée chez vous.
Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.
Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.