Data Clean Room et Conformité RGPD : Comment Partager les Données Clients sans Risque Légal

Une Data Clean Room (DCR) est un environnement technologique sécurisé où deux ou plusieurs organisations peuvent partager et analyser des données clients sans exposer les données brutes—mais ce partage doit respecter le RGPD, notamment via une base légale explicite, la documentation du traitement conjoint, et l'information préalable des personnes concernées. La conformité n'est pas automatique : c'est l'organisation du partage, les contrats en place et la traçabilité des opérations qui transforment une DCR en outil compliant ou en risque légal.

Comprendre le cadre légal spécifique au partage de données en Data Clean Room

Le partage de données clients en Data Clean Room implique plusieurs acteurs avec des rôles distincts aux yeux du RGPD. Contrairement à une simple prestation technique (où un sous-traitant agit sous le contrôle d'un contrôleur unique), une DCR crée généralement une situation de contrôle conjoint ou partagé. Cela signifie que deux ou plusieurs organisations sont ensemble responsables des traitements réalisés dans l'environnement de la DCR.

Cette responsabilité conjointe est définie à l'article 26 du RGPD et implique des obligations spécifiques : les contrôleurs doivent déterminer clairement, dans un accord écrit, qui fait quoi, qui a quelle responsabilité, et comment les droits des personnes concernées seront respectés. Le simple fait de brancher deux systèmes sans cadre contractuel explicite expose les organisations à des risques majeurs lors d'un audit CNIL ou d'une plainte de données.

La première étape est donc d'identifier qui contrôle vraiment les données. Si votre organisation partage une liste de clients avec une agence média pour faire du matching publicitaire, vous restez contrôleur des données de vos clients. L'agence média, même si elle a accès à la DCR, peut être co-contrôleur ou sous-traitant, selon comment le traitement est structuré. Cette distinction détermine l'ensemble des obligations légales.

Quelle est la base légale valide pour partager des données clients en DCR ?

Partager les données de clients existants en Data Clean Room nécessite une base légale. Le consentement est une possibilité, mais c'est rarement la solution la plus pratique à grande échelle, car il faut connaître le consentement spécifique de chaque personne concernée pour chaque utilisation. Plus couramment, les organisations s'appuient sur l'intérêt légitime (article 6.1.f du RGPD).

Pour invoquer l'intérêt légitime, l'organisation doit démontrer : (1) qu'elle poursuit un objectif légitime (par exemple, améliorer le ciblage publicitaire, optimiser les ventes croisées), (2) que le traitement est nécessaire à cet objectif, et (3) que cet intérêt prévaut sur les droits et libertés des personnes. Cette démonstration doit être documentée, notamment via un test de proportionnalité écrit.

Un cas pratique : une banque qui partage des données de clients dans une DCR avec un partenaire d'assurance pour proposer des produits d'assurance adaptés peut invoquer l'intérêt légitime si elle peut justifier que (a) l'enrichissement croisé des offres sert ses clients, (b) les données partagées sont minimales (pas de données sensibles inutiles), et (c) les clients ont eu une information claire sur ce partage lors du consentement initial ou dans la politique de confidentialité mise à jour.

Alternativement, si les données ont été collectées initialement avec un consentement qui mentionne explicitement le partage avec des partenaires ou l'usage via une DCR, ce consentement peut servir de base légale—mais le libellé du consentement initial est alors crucial. Une base légale vague ("nous pouvons partager vos données pour améliorer nos services") peut être jugée insuffisante si elle ne détaille pas assez les cas d'usage spécifiques.

Le contrat entre les contrôleurs conjoints doit expliciter la base légale choisie et justifier son applicabilité aux données en question.

Comment documenter correctement la responsabilité conjointe ?

L'accord de contrôle conjoint (ou "joint controller agreement") est le document fondateur. Il doit couvrir plusieurs éléments obligatoires selon le RGPD :

Identification précise des rôles : Qui est responsable de quoi ? Par exemple, l'organisation A est responsable de la collecte et de l'information aux personnes ; l'organisation B est responsable de la sécurité technique de la DCR ; les deux sont conjointement responsables de la durée de conservation. Cette clarté est essentielle pour les droits des personnes : si un client demande l'accès à ses données ou la suppression, il doit savoir qui contacter et comment la demande sera traitée.

Finalités du traitement : Lister précisément ce qui sera fait des données dans la DCR. Par exemple, "matching entre les bases de clients pour identifier les clients communs", "analyse des habitudes de consommation combinées", etc. Plus les finalités sont vagues, plus le risque légal augmente.

Catégories de données : Spécifier quelles données exactement seront partagées. Si la base comprend des noms, adresses, emails, historiques d'achat, le contrat doit les énumérer. L'accord doit aussi interdire l'ajout ultérieur de nouvelles catégories sans accord écrit supplémentaire.

Durée de conservation : Les données doivent être supprimées au-delà d'une durée justifiée. Une DCR ne peut pas fonctionner comme archivage permanent. Si le matching est annuel, définir clairement que les données hors du périmètre de l'année en cours seront supprimées renforce la conformité.

Mécanismes de droit des personnes : Comment sera traitée une demande d'accès, de rectification ou de suppression ? Qui la reçoit, comment elle est documentée, quel délai de réponse ? La DCR doit inclure un processus tracé pour ces demandes.

Obligations de sécurité et de confidentialité : Qui est responsable du chiffrement, de l'audit, du contrôle d'accès au sein de la DCR ? Ces obligations techniques doivent être liées à des responsabilités contractuelles claires.

Ce contrat doit être signé avant tout partage de données. Un audit CNIL remarquera rapidement l'absence d'accord écrit, ce qui constitue une violation de l'article 26.

Comment assurer la traçabilité des opérations en DCR ?

La traçabilité est un pilier souvent négligé. Le RGPD n'impose pas explicitement un "registre des accès" au sein d'une DCR, mais l'article 5 impose la traçabilité ("accountability") et la démonstration de conformité. En pratique, lors d'un audit, la CNIL demandera : "Qui a accédé à quelles données, quand, et pourquoi ?"

Une DCR compliant doit donc loguer :

• Accès aux données : Quels utilisateurs, de quelles organisations, ont consulté ou extrait des données, à quelle date et heure. Ces logs doivent être conservés pendant une durée raisonnable (généralement au minimum pendant la durée du contrat plus quelques mois).

• Opérations d'analyse : Si la DCR permet des analyses (jointures, segmentations, statistiques), chaque opération doit être enregistrée avec son objet. Cela permet, en cas d'audit, de prouver que les données n'ont été utilisées que pour les finalités convenues.

• Exports ou résultats : Si la DCR génère des résultats (liste de clients à cibler, scores, insights), il doit y avoir une trace de ce qui a été exporté, par qui, et quand. Cela empêche les abus : par exemple, l'absence de logs ne permet pas de vérifier si quelqu'un a exfiltré un fichier complet de clients au-delà de ce qui était autorisé.

• Incidents : Accès non autorisé, tentatives d'extraction non réussies, anomalies. Ces incidents doivent être documentés et évalués pour déterminer si une notification de violation est requise (article 33 du RGPD).

Un exemple concret d'erreur courante : deux organisations mettent en place une DCR, puis découvrent que la base de données sous-jacente ne loggue aucun accès. Quand la CNIL audite quelques mois plus tard et demande qui a consulté les données de clients sensibles, les organisations ne peuvent pas répondre. Cela crée une présomption de violation et une charge de preuve difficile à gérer.

Le contrat de contrôle conjoint doit donc spécifier qui a la responsabilité de maintenir ces logs, comment ils sont conservés, qui y a accès, et comment ils sont protégés (les logs eux-mêmes sont une donnée sensible car ils révèlent les patterns d'utilisation).

Informer les personnes concernées sur le partage de données

Une obligation souvent minimisée : les personnes dont les données sont partagées en DCR doivent être informées. Cette obligation découle du RGPD (articles 13-14) et du respect de la transparence.

Si les données sont collectées directement auprès des personnes (par exemple, à l'inscription sur un site), l'information peut être donnée au moment de la collecte, dans la politique de confidentialité ou la notice d'information. Si les données sont collectées sans contact direct, l'information doit être donnée dans un délai raisonnable (généralement avant la première utilisation des données, au maximum sous un mois).

Cette information doit préciser :

• Qui partage les données : Les noms exacts des organisations contrôleurs.
• Avec qui : L'identité ou au minimum la catégorie des destinataires (par exemple, "avec nos partenaires en assurance et services financiers").
• Pour quoi faire : Les finalités précises ("pour vous proposer des offres personnalisées", "pour analyser les comportements d'achat").
• Combien de temps : La durée de conservation des données dans la DCR.
• Droits : Comment exercer le droit d'accès, de rectification, de suppression, d'opposition.

Une erreur courante : mettre dans la politique de confidentialité une phrase générique comme "nous pouvons partager vos données avec des partenaires" sans préciser qu'un partage en DCR aura lieu. Lors d'une plainte, la CNIL considère que l'information était insuffisante si elle n'était pas spécifique au mode de partage et aux destinataires réels.

Si les personnes n'ont pas eu d'information préalable, la conformité est compromise. Certaines organisations lancent une DCR, découvrent trop tard qu'elles n'ont pas informé les clients, et doivent alors lancer une campagne de communication pour régulariser la situation—ce qui est coûteux et peut nuire à la confiance client.

Quels sont les risques spécifiques lors d'un audit CNIL ?

Un audit CNIL sur une DCR porte généralement sur plusieurs axes. Connaître ces axes permet de préparer proactivement une DCR conforme.

Absence ou faiblesse de la base légale : La CNIL demandera comment la base légale a été évaluée, et si un test de proportionnalité a été documenté (notamment si l'intérêt légitime a été invoqué). L'absence de documentation écrite est une non-conformité majeure.

Manque de contrat de contrôle conjoint : Si deux organisations partagent des données dans une DCR sans accord écrit détaillant les responsabilités, c'est une violation flagrante de l'article 26. La CNIL peut demander la suspension du partage jusqu'à la signature d'un accord conforme.

Données excessives : La DCR contient-elle des données inutiles pour les finalités déclarées ? Par exemple, partager le numéro de sécurité sociale de clients pour faire un matching publicitaire est une violation du principe de minimisation des données.

Conservation excessive : Les données restent-elles dans la DCR plus longtemps que justifié ? Une DCR pour une campagne annuelle ne doit pas archiver les données indéfiniment.

Absence de traçabilité : Aucun log des accès ou des opérations. Cela rend impossible de vérifier que les données ont été utilisées conformément à la finalité. C'est considéré comme une violation grave de l'accountability.

Non-respect des droits des personnes : Pas de processus pour traiter les demandes d'accès ou de suppression. Si une personne demande la suppression de ses données et que la DCR n'a pas de mécanisme pour le faire, c'est une violation directe.

Information insuffisante : Les personnes concernées n'ont pas été informées de l'existence de la DCR ou du partage avec tel partenaire. La documentation fournie lors de la plainte montre que la politique de confidentialité ne mentionnait pas ce type de partage.

Transferts hors UE non sécurisés : Si la DCR est hébergée en dehors de l'UE (par exemple, sur un serveur aux États-Unis), il faut des garanties légales (adéquation de la Commission, clauses contractuelles types, ou mécanismes supplémentaires selon les décisions récentes de la CJUE). Une DCR sans garanties de transfert pose un problème majeur.

Dans la pratique, un audit aboutissant à la détection de violations importantes peut mener à des injonctions de cesser l'activité, des amendes (jusqu'à 4% du chiffre d'affaires global), et des dommages civils si des personnes poursuivent.

Checklist d'audit interne : évaluer votre DCR

Avant un audit CNIL ou pour vérifier la conformité proactive, parcourez cette checklist :

Documentation et contrats

• Un accord de contrôle conjoint signé avec chaque partenaire est en place
• Cet accord détaille les rôles, les finalités, les catégories de données, et la durée de conservation
• Une analyse d'impact relative à la protection des données (DPIA) a été réalisée et documentée, surtout si la DCR implique un partage massif ou des données sensibles
• Un registre des traitements (article 30) mentionne les traitements en DCR

Base légale et proportionnalité

• La base légale pour le partage (consentement, intérêt légitime, autre) est identifiée et justifiée par écrit
• Si c'est l'intérêt légitime, un test de proportionnalité a été documenté (objectif poursuivi, nécessité du traitement, balance avec les droits des personnes)
• La base légale est applicable à toutes les données partagées (pas de mélange de données justifiées par des bases différentes sans traçabilité)

Données et minimisation

• Les données partagées en DCR sont limitées au strict nécessaire pour la finalité (noms, emails suffisent-ils, ou faut-il aussi l'historique d'achat complet ?)
• Les données sensibles (données de santé, données biométriques, etc.) ont été évaluées et justifiées comme nécessaires
• Un processus existe pour retirer des données de la DCR dès qu'elles ne sont plus utiles

Information des personnes

• La politique de confidentialité ou les notices d'information mentionnent le partage en DCR
• L'information est suffisamment spécifique (noms des partenaires ou au moins leur catégorie, finalités précises, durée)
• Les personnes ont eu l'information avant ou juste après le partage (pas d'oubli dans la régularisation)

Accès et traçabilité

• Un système de logging des accès est en place et actif
• Les logs enregistrent qui a accédé, quand, et à quelles données
• Les logs sont conservés pendant une durée définie (exemple : 3 ans après la fin du contrat)
• Les logs eux-mêmes sont sécurisés et seuls les rôles autorisés y accèdent
• Une procédure existe pour auditer les logs régulièrement (par exemple, trimestriellement) et signaler les anomalies

Sécurité et contrôle d'accès

• La DCR est techniquement sécurisée (chiffrement en transit et au repos, authentification multifacteur, etc.)
• Seules les personnes autorisées ont accès, avec des rôles granulaires (par exemple, une personne ne peut pas exfiltrer des données brutes, uniquement des résultats agrégés)
• Un incident response plan existe au cas où une violation serait détectée

Droits des personnes

• Un processus est en place pour traiter les demandes d'accès (article 15) : comment la demande est reçue, qui la traite, quel délai ?
• Un processus existe pour les demandes de suppression (article 17) : comment la donnée est localisée dans la DCR et supprimée ?
• Un processus couvre les demandes d'opposition (article 21)
• Un responsable des données ou un point de contact est clairement désigné pour répondre aux demandes

Conformité de transfert (si applicable)

• Si la DCR est hébergée hors UE, les transferts sont sécurisés par des clauses contractuelles types, une adéquation, ou un autre mécanisme reconnu
• Les partenaires dans d'autres pays (par exemple, une filiale américaine) ont des obligations de protection équivalentes au RGPD

Incidents et notification

• Un processus existe pour détecter et signaler les violations (article 33)
• L'équipe sait qui notifier en cas d'incident (responsable de la protection des données, direction, CNIL si nécessaire)
• Une liste des incidents détectés et des actions correctrices a été constituée

Un score de 100% à cette checklist indique une DCR solide. Chaque case non cochée est un point d'amélioration et un risque potentiel.

Erreurs courantes observées en pratique et comment les éviter

Les auditeurs de conformité et les praticiens du RGPD identifient régulièrement les mêmes erreurs dans les DCR :

Erreur 1 : Confondre DCR et simple intégration technique Une organisation met en place une connection entre deux bases de données et considère que c'est une DCR conforme parce qu'aucune donnée brute ne transite. Or, sans accord contractuel explicite, sans traçabilité des accès, et sans information aux personnes, c'est un partage de données non documenté. La conformité ne vient pas de la technologie, mais de l'organisation du partage.

Erreur 2 : Invoquer l'intérêt légitime sans test écrit Une organisation dit "on se fie à l'intérêt légitime pour partager les emails clients avec un partenaire publicitaire", mais aucun document ne prouve que ce test a été réalisé. En audit, l'absence de documentation signifie que la base légale ne peut pas être démontrée.

Erreur 3 : Partager plus de données que nécessaire Une DCR pour faire du matching publicitaire n'a besoin que du nom et de l'email. Partager aussi l'historique d'achat complet, les adresses de facturation, et les données de navigation est une violation du principe de minimisation. Cela augmente aussi le risque si la DCR est compromise.

Erreur 4 : Oublier d'informer les clients Une organisation lance une DCR avec un partenaire sans mettre à jour la politique de confidentialité. Quelques mois plus tard, un client demande access subject access request, découvre le partage, et fait une plainte. La défense "nous pensions que c'était implicite" ne convainc pas la CNIL.

Erreur 5 : Pas de processus pour les demandes d'accès La DCR logge les accès, mais quand un client demande l'accès à ses données, personne ne sait comment traiter la demande. Elle reste bloquée plusieurs mois. C'est une violation du droit d'accès.

Erreur 6 : Conserver les données indéfiniment Une DCR lancée pour une campagne marketing d'un an devient un archivage permanent parce que "on ne sait pas si c'est encore utile". La donnée doit être supprimée dès que sa finalité est atteinte. Un audit révèlera une conservation injustifiée.

Erreur 7 : Ne pas documenter la base légale L'équipe technique sait qu'une DCR existe et pourquoi, mais il n'existe pas de document écrit justifiant la légalité du partage. Lors d'un audit, cette absence est catastrophique.

Erreur 8 : Logs insuffisants ou non conservés Un partenaire dit "on a un système de logging" mais les logs sont supprimés après deux semaines, et aucun extraction annuelle n'existe. Après un incident, il est impossible de vérifier ce qui s'est passé.

Pour éviter ces erreurs, dédier une personne (ou une équipe, selon la taille) à la conformité de la DCR, en phase de lancement et en continu. Les erreurs coûtent bien moins chères à prévenir qu'à corriger après un audit ou une plainte.

Structurer une DCR conforme dès la conception

La meilleure approche est de construire la conformité dès le départ, pas après. Cela implique plusieurs étapes :

Étape 1 : Évaluation préalable (DPIA) Avant de lancer la DCR, réaliser une analyse d'impact relative à la protection des données. Cela implique d'identifier : quels types de données, quels risques (vol, accès non autorisé, révélation d'information personnelle), quelles mesures (chiffrement, logging, minimisation). Cette DPIA doit être documentée et conservée.

Étape 2 : Négociation du contrat de contrôle conjoint Travaille avec ton partenaire et éventuellement ton conseil juridique pour définir un accord qui couvre les 8 éléments mentionnés précédemment (rôles, finalités, données, durée, droits des personnes, sécurité, etc.). Ne pas signer un contrat vague.

Étape 3 : Configuration technique sécurisée Mettre en place : authentification (accès contrôlé par rôles), chiffrement (données en transit et au repos), logging détaillé (qui accède, quand, à quoi), et une politique d'accès minimale (un utilisateur n'a accès que aux données dont il a besoin pour son rôle).

Étape 4 : Information des personnes Mettre à jour la politique de confidentialité et/ou envoyer une notification pour informer les clients du partage. Ne pas attendre un audit pour le faire.

Étape 5 : Définir les processus RH Former l'équipe sur le traitement des demandes d'accès, les incidents, et les responsabilités. Désigner un responsable des données qui pilote ces processus.

Étape 6 : Audit interne régulier Chaque trimestre ou semestriellement, passer en revue la checklist ci-dessus. Documenter les résultats et les actions correctrices. Cela démontre, en audit, que l'organisation a un programme de conformité actif.

Conclusion : la DCR comme atout de compliance, pas obstacle

Une Data Clean Room n'est pas intrinsèquement incompatible avec le RGPD. Au contraire, si elle est bien structurée, elle peut être un atout de conformité : en centralisant le partage de données dans un environnement sécurisé avec traçabilité, elle renforce la transparence et la maîtrise des données.

La clé est de ne pas considérer la DCR comme un problème technique à résoudre seul. C'est un dispositif de gouvernance des données qui implique le droit, la technique, et l'organisation. Chaque rôle doit comprendre sa responsabilité : le responsable de la protection des données évalue la légalité, les équipes techniques sécurisent l'accès et logent les opérations, le responsable des données traite les demandes des personnes, et la direction s'engage contractuellement.

Une DCR lancée avec cette approche globale sera non seulement conforme, mais aussi plus robuste en cas de contentieux ou d'audit. Et paradoxalement, cette conformité accrue permet d'utiliser la DCR plus largement et avec plus de confiance : partenaires, clients, et régulateurs verront une organisation qui maîtrise ses données.