Les responsables conjoints du RGPD ne peuvent pas externaliser le consentement

Un consentement non recueilli reste une responsabilité que vous assumez. C’est la leçon concrète de l’amende de 8,6 millions d’euros que l’autorité norvégienne de protection des données vient d’infliger à Xandr, société de technologie publicitaire désormais rattachée à Microsoft. Ce cas devrait changer la façon dont chaque responsable de la protection des données interprète l’expression « notre partenaire gère le consentement ».

Les faits sont précis. La Datatilsynet norvégienne a signé sa décision finale le 2 octobre 2026, annoncé l’amende en Norvège le 12 octobre, et le Comité européen de la protection des données a relayé la décision sur sa page d’actualités le 16 octobre. L’affaire a débuté par une plainte déposée en 2020 par le Conseil norvégien des consommateurs concernant les enchères en temps réel impliquant des utilisateurs de Grindr, une application de rencontres pour personnes gays, bi, trans et queer. Xandr n’a jamais demandé le consentement de ces utilisateurs. Elle s’est appuyée sur le consentement que Grindr affirmait avoir recueilli, mais l’autorité a jugé ce consentement invalide.

Le contexte est celui de la publicité en ligne, mais le principe s’applique partout. Toute organisation qui reçoit des données personnelles d’un partenaire, les transmet à un partenaire ou les partage par e-mail, partage sécurisé de fichiers, API ou agents IA se retrouve dans la même situation que Xandr dès qu’un régulateur demande qui a vérifié quoi. Cet article détaille la décision de l’autorité, explique pourquoi son raisonnement importe pour un RSSI ou un responsable conformité, et montre comment un échange gouverné tel que l’échange de données sécurisé Kiteworks peut vous aider à appliquer et démontrer vos propres décisions — et là où il ne le peut pas.

Résumé de la décision

1. Le consentement en amont ne suffit pas.

L’autorité a estimé que chaque responsable conjoint doit vérifier la validité du consentement et s’assurer qu’il couvre ses propres traitements. L’assurance d’un partenaire ne transfère pas la responsabilité.

2. Une clause contractuelle ne supprime pas la responsabilité conjointe.

Xandr interdisait à ses partenaires de partager des données sensibles, mais l’autorité a tout de même considéré qu’elle déterminait conjointement les catégories de données partagées.

3. Utiliser une application peut révéler des données sensibles.

L’autorité a considéré que le simple fait d’utiliser Grindr, associé à un identifiant publicitaire et une adresse IP, constitue une donnée relative à l’orientation sexuelle au sens de l’article 9(1).

4. La négligence ne suppose pas d’intention malveillante.

L’autorité a jugé les infractions au moins négligentes et très graves, car elles concernaient des dispositions centrales du RGPD et des données sensibles.

5. L’élément clé : la preuve.

Les responsables conformité capables de prouver quelles données sont sorties, à qui, selon quelle règle et avec quelle approbation, sont bien mieux armés que ceux qui s’appuient uniquement sur des assurances contractuelles.

Ce qu’a décidé l’autorité norvégienne

L’autorité a infligé à Xandr Inc. une amende de 92 000 000 NOK, soit 8 600 000 euros selon l’EDPB, pour avoir traité les données des utilisateurs de Grindr sans base légale au titre de l’article 6(1) du RGPD et en violation de l’article 9(1), aucune exemption valable ne s’appliquant. Les données concernées étaient le fait d’utiliser Grindr, l’identifiant publicitaire et l’adresse IP de l’utilisateur. Selon la version publique expurgée de la décision publiée par le Conseil norvégien des consommateurs, l’autorité a également considéré les identifiants d’application comme faisant partie de ce jeu de données.

Deux points du raisonnement méritent une attention particulière. D’abord, l’autorité a considéré que le simple fait d’utiliser Grindr révélait l’orientation sexuelle. Il n’était pas nécessaire de déclarer son orientation dans un formulaire : l’inférence contextuelle suffisait pour faire entrer la donnée dans la catégorie spéciale. Ensuite, l’autorité a conclu que l’exemption pertinente était le consentement explicite, et qu’aucun consentement explicite valable n’existait pour le traitement par Xandr.

L’autorité a qualifié les infractions d’au moins négligentes et très graves. Ces qualificatifs ne nécessitent pas de prouver une volonté de violer la loi. Ici, la négligence signifie qu’une organisation n’a pas pris les précautions qu’un responsable de traitement aurait dû prendre dans sa situation. Ce critère est bien plus facile à établir pour un régulateur que l’intention, et c’est celui qui s’appliquera à votre propre dossier.

Un point sur les dates évitera toute confusion lors de discussions internes. La décision est datée du 2 octobre 2026. Les médias norvégiens et européens l’ont relayée à partir du 12 octobre. La page EDPB, que beaucoup consulteront en premier, affiche une publication au 16 octobre. Ces trois dates concernent la même décision.

Pourquoi la confiance dans le consentement de Grindr a échoué

Xandr n’a pas recueilli elle-même le consentement des utilisateurs. Elle s’est appuyée sur le consentement collecté par Grindr via sa précédente plateforme de gestion du consentement, selon la décision. L’autorité a estimé que ces consentements ne respectaient pas les exigences du RGPD, qui selon les articles 4(11) et 7 doivent être libres, spécifiques, informés, non ambigus, et aussi faciles à retirer qu’à donner. Si le consentement en amont ne répond pas à ces critères, tout ce qui en découle tombe avec lui.

La leçon structurelle va au-delà de la mécanique du consentement. Xandr avançait un argument commercial crédible : Grindr gérait la relation avec l’utilisateur, le parcours de consentement, et Xandr recevait un signal attestant de l’existence du consentement. L’autorité a rejeté cet argument, dans une phrase que toute équipe conformité devrait afficher : la responsabilité ne se délègue pas.

Le texte de l’article 7 explique pourquoi. Il fait peser la charge de la preuve sur le responsable de traitement, qui doit pouvoir démontrer que la personne concernée a consenti. Un signal d’un partenaire n’est pas une preuve. Une preuve, c’est un enregistrement consultable, indiquant à quoi la personne a consenti, quand, pour quels usages, et que l’accord couvre votre propre traitement.

Pour un RSSI, il s’agit davantage d’un problème de traçabilité des données que d’un problème juridique. La question est de savoir si vous pouvez tracer un enregistrement depuis son entrée dans votre environnement jusqu’au destinataire actuel, et rattacher à chaque étape la base légale invoquée. Peu d’organisations savent répondre rapidement à cette question. Encore moins pour des données qui circulent par e-mail et partage sécurisé de fichiers, hors de toute application unique.

Pourquoi une clause contractuelle n’a pas limité la responsabilité conjointe

L’autorité a considéré que Xandr était responsable conjointement avec Grindr, agissant à la fois comme plateforme côté offre et côté demande lors des enchères. Le raisonnement s’appuie sur la convergence des décisions concernant les finalités et les moyens du traitement. Le cadre contractuel et la plateforme de Xandr déterminaient quelles données et quels destinataires étaient impliqués.

Les contrats de Xandr interdisaient à ses partenaires de partager des données sensibles. Cette clause n’a rien changé. L’autorité l’a jugée insuffisante et a conclu à la responsabilité conjointe de Xandr avec Grindr. Une interdiction sur le papier ne sert à rien si le système que vous avez conçu transmet malgré tout les données.

Le texte de l’article 26 va dans le même sens. Les responsables conjoints doivent répartir de façon transparente leurs responsabilités respectives, et la personne concernée peut exercer ses droits auprès de chacun d’eux. La décision cite l’article 26(1) et précise qu’un accord entre responsables conjoints ne retire aucune obligation à l’une ou l’autre des parties.

Pour un responsable conformité, c’est la partie de la décision qui doit inciter à dresser un inventaire. Tout accord de partage de données impliquant une plateforme, une interface administrateur, des standards ou pipelines partagés comporte un risque de responsabilité conjointe, quelle que soit la documentation contractuelle. Un accord de responsabilité conjointe décrit une réalité, il ne la crée pas.

Au-delà de la publicité : un schéma généralisé

Il serait tentant de classer cette décision dans la publicité et de passer à autre chose. Les chiffres de l’application du RGPD prouvent le contraire. Le rapport DLA Piper sur les amendes et violations RGPD indique que le total des amendes infligées depuis l’entrée en vigueur du règlement le 25 mai 2018 jusqu’au 10 janvier 2026 atteint 7,1 milliards d’euros, dont 1,2 milliard d’euros pour la seule année 2025.

Une telle ampleur ne vient pas d’un seul secteur. Elle résulte d’autorités qui posent les mêmes questions à chaque responsable de traitement, et la décision Xandr illustre ce que donne l’une de ces questions appliquée à une supply chain de données : qui vous a transmis ces données, sur quelle base, et comment le savez-vous ?

Le nombre d’incidents à l’origine de ces contrôles augmente aussi. L’analyse DLA Piper de février 2026 révèle que les autorités européennes ont reçu en moyenne 443 notifications de violation de données par jour, soit une hausse annuelle de 22 %. Chaque notification est une occasion pour un régulateur d’exiger d’un responsable de traitement qu’il explique où sont passées ses données et qui y a eu accès.

Rien de tout cela n’est réservé aux entreprises qui commercialisent des données personnelles. Un hôpital qui partage des dossiers de patients avec une clinique partenaire, une banque qui envoie des fichiers clients à un prestataire, un industriel qui transmet des données d’employés à un gestionnaire de paie : tous transfèrent des données personnelles à un tiers. Ils diffèrent de Xandr par l’échelle et l’intention, mais partagent la même exposition à un régulateur qui s’interroge sur la base légale du destinataire. Le canal ne change rien à la question. E-mail, partage sécurisé de fichiers, API et agents IA font tous circuler des données personnelles entre personnes, machines et systèmes, et chaque transfert est un point où la responsabilité s’exerce — ou pas.

Ce que les régulateurs attendent désormais de vous

L’exposition n’est pas négligeable. L’article 83(5) du RGPD place les violations des articles 5, 6, 7 et 9 dans la catégorie d’amende la plus élevée, soit jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires mondial annuel, selon le montant le plus élevé. Ce sont précisément les articles au cœur de la décision Xandr.

Les plafonds d’amende attirent l’attention, mais pour un responsable conformité, le signal le plus utile est ce que l’autorité attendait du responsable de traitement : vérifier le consentement pour son propre traitement, confirmer que le consentement couvrait l’usage spécifique, conserver la preuve. Trois actions, aucune n’étant un achat technologique. Ce sont des pratiques de preuve.

Le manque de preuves ressort dans les enquêtes. Dans le rapport annuel Kiteworks Data Security and Compliance Risk 2026, 63 % des 459 professionnels interrogés (sécurité, conformité, IT) ont signalé une conséquence liée à la conformité dans les 12 derniers mois : audit, plan de remédiation, remontée au conseil, pénalité contractuelle ou enquête réglementaire. Les chiffres sont déclaratifs, la moitié de l’échantillon étant basée dans l’UE et au Royaume-Uni, donc à lire comme une tendance, non un recensement.

La pression sur la souveraineté des données augmente aussi. Une enquête BARC sur la souveraineté des données 2026 menée auprès de 320 entreprises en février-mars 2026 montre que 51 % jugent la souveraineté des données très importante (contre 42 % en 2025), mais seulement 10 % disposent d’un budget dédié. Ce décalage entre l’importance d’un contrôle et son financement est précisément là où une action de régulation trouve ses faits.

En résumé, le problème du responsable conformité se précise : le régulateur ne vous demandera pas si vous avez une politique, mais la preuve que cette politique a bien été appliquée à un transfert précis, à une date précise, pour un destinataire précis.

La place de l’échange de données gouverné

Commençons par ce qu’un échange gouverné ne fait pas : il ne décide pas de la validité d’un consentement et ne remplace pas l’avis juridique de votre DPO ou de votre conseil. Une plateforme de gestion du consentement gère la collecte. Une équipe juridique statue sur la base légale. Entre les deux et le destinataire, il y a l’échange lui-même : le moment où la donnée quitte votre contrôle par e-mail, partage sécurisé de fichiers, API ou agent IA. C’est là que l’échange de données sécurisé Kiteworks intervient.

À ce stade, la plateforme vous permet de transformer vos décisions en règles appliquées. Les règles de données, que Kiteworks met en œuvre sous forme de contrôles d’accès basés sur les attributs, évaluent ensemble trois éléments : les attributs de la donnée (chemin du dossier, tag), ceux de l’expéditeur et du destinataire (domaine, profil) et l’action tentée. Le moteur de règles peut alors autoriser, bloquer ou soumettre l’action à approbation avant l’envoi ou le partage.

La classification renforce ce contrôle. Les règles peuvent appliquer un tag lors de l’import ou de la pièce jointe (par exemple, un tag « données de santé » ou autre catégorie spéciale), et d’autres règles s’appuieront ensuite sur ce tag. La classification des données dès l’entrée permet de trancher une fois pour toutes sur l’article 9, puis d’appliquer la décision à chaque mouvement de la donnée.

La plateforme permet aussi de consigner le raisonnement. Une règle peut exiger un formulaire à l’import ou à l’export, pour que la personne indique une classification ou une justification, laquelle sera conservée dans le journal d’audit avec l’événement. Pour une équipe qui doit justifier un transfert, une justification enregistrée vaut mieux qu’un souvenir reconstitué des mois plus tard. Les formulaires Web RGPD appliquent la même logique aux données collectées directement auprès des personnes concernées.

La preuve constitue l’autre moitié. Kiteworks trace l’activité des utilisateurs, des données et du système dans une traçabilité unique, sans la fragmenter entre sous-systèmes, et sans limiter le volume de logs lors des pics de trafic. Les entrées alimentent les outils SIEM externes en temps réel via syslog ou Splunk Universal Forwarder. Un responsable conformité qui doit prouver qui a envoyé quoi, à qui, quand et où, peut tout retrouver dans un seul enregistrement.

Pour les organisations devant conserver les données dans une juridiction, les contrôles de conformité souveraineté des données permettent à un administrateur d’assigner des utilisateurs à un pays dans un déploiement distribué, pour que leurs données ne soient stockées et routées que par ce lieu, et le reporting intégré montre aux auditeurs où elles se trouvent. Si l’organisation dispose de Kiteworks Advanced Governance, le rapport de conformité RGPD ajoute un résumé des règles, de la configuration et des opérations surveillées. Aucun de ces outils ne prouve la conformité. Ils vous donnent de la matière pour la démontrer.

Checklist de révision pour DPO et RSSI

La décision invite à une revue pratique, qui ne nécessite pas d’outil nouveau pour démarrer, mais un créneau dans l’agenda et des réponses honnêtes.

1. Recensez tous les flux sortants de données personnelles. Incluez e-mail, partage sécurisé de fichiers, connexions API et tout agent IA pouvant envoyer ou recevoir des données. Nommez le destinataire et la base légale invoquée pour chaque flux, car un flux sans destinataire nommé n’a pas de base défendable.
2. Comparez le consentement en amont à votre usage réel. Pour chaque cas où un partenaire a recueilli le consentement pour vous, notez ce qui a été dit à la personne, ce à quoi elle a consenti, et si votre traitement s’inscrit dans ce cadre. Si vous ne pouvez pas l’écrire, vous avez identifié une faille.
3. Classez les données sensibles dès l’entrée. Santé, orientation sexuelle et autres données relevant de l’article 9 doivent être étiquetées dès leur arrivée, pour que la règle s’applique sans intervention humaine.
4. Filtrez les transferts selon le destinataire et le type de données. Rédigez des règles qui autorisent, bloquent ou soumettent à approbation, et testez-les sur les cas limites : destinataire avec une adresse e-mail gratuite, ou dans un pays où vous n’opérez pas.
5. Consignez la justification au moment du transfert. Un court formulaire rempli lors du mouvement de la donnée est plus facile à défendre qu’une reconstitution après un courrier du régulateur.
6. Entraînez-vous à répondre à une demande de preuve. Choisissez un transfert réel et demandez à votre équipe d’en produire l’historique complet sous deux jours ouvrés. Le délai obtenu mesure votre préparation réelle.

Cet article est une information générale, non un avis juridique. Pour toute application contraignante de la décision à vos traitements, consultez votre équipe juridique ou votre DPO.

Pour en savoir plus sur l’application et la preuve de vos propres décisions de consentement et de partage de données par e-mail, partage sécurisé de fichiers, API et agents IA, réservez une démo personnalisée dès maintenant.

Ressources complémentaires

• Article de blog La bataille autour de vos données : comment les lois CLOUD et SHIELD opposent sécurité et vie privée
• Article de blog Sécuriser les données sensibles en alignant le DSPM sur vos objectifs de conformité
• Brief Top 3 des violations FERPA et comment les éviter
• Article de blog Executive Order 14117 : protéger les données personnelles sensibles des Américains
• Article de blog Besoin de conformité NIS2 ? Commencez par l’ISO 27001