Data clean room marketing : vérifier les garanties

Une data clean room permet d’encadrer des calculs entre partenaires sans leur remettre directement toutes les données respectives. Elle ne rend pas automatiquement ces données anonymes ni leur utilisation licite. Pour l’acheter ou l’autoriser, examinez trois niveaux : les entrées personnelles, les opérations permises et ce que les résultats révèlent ensemble.

La bonne question n’est donc pas seulement « peut-on télécharger la base ? ». Un utilisateur peut apprendre une information individuelle sans recevoir une seule ligne nominative. Inversement, une sortie réellement anonyme ne dispense pas de justifier les traitements personnels qui ont permis de la produire.

Définir la collaboration avant l’outil

Une marque souhaite connaître le recouvrement entre son audience et celle d’un distributeur. Elle peut demander un nombre, une mesure de campagne ou une liste d’acheteurs à recontacter. Ces livrables ne répondent pas à la même finalité et ne nécessitent pas les mêmes accès.

Pour le premier besoin, le produit attendu peut être un effectif global et une méthode documentée. Pour le troisième, des identifiants exploitables doivent sortir ou être activés ailleurs : le projet ne se limite plus à un résultat statistique. La possibilité technique d’une fonction d’activation ne l’autorise pas juridiquement.

Le guide du retail media distingue notamment attribution et effet causal. Une clean room ne transforme pas un rapprochement exposition-achat en preuve de ventes supplémentaires. Elle encadre le traitement ; elle ne corrige pas une question métier mal posée.

Avant consultation des fournisseurs, écrivez une phrase qui puisse être acceptée ou refusée : « Produire, pour la campagne C12, le nombre de clients admissibles communs aux deux ensembles, sans livrer leurs identifiants ni créer d’audience de ciblage. » Cette formulation pédagogique définit un périmètre. Elle ne suppose pas que les conditions de licéité soient déjà réunies.

Les entrées restent soumises au RGPD

Les Art. 5(1)(b), 5(1)(c) et 6(1) imposent de définir la finalité, limiter les données et établir le fondement. Une adresse recueillie pour envoyer une facture ne devient pas disponible pour tout rapprochement commercial parce qu’elle reste dans un environnement contrôlé.

Chaque contributeur doit établir ce qu’il peut apporter : personnes concernées, catégories, période, information et choix applicables. Lorsque la finalité change, l’analyse de l’Art. 6(4) doit être menée dans son champ. Si un consentement est nécessaire, les usages envisagés doivent être couverts ; un document vague ne peut pas être élargi rétroactivement.

L’absence de nom dans la table ne suffit pas. Une clé hachée qui permet de retrouver les mêmes personnes dans les deux fichiers conserve une fonction de rapprochement. Les Art. 4(1) et (5) et le guide pseudonymisation et anonymisation permettent de qualifier cette étape sans la confondre avec le résultat final.

Pour C12, les coordonnées de livraison, commentaires clients et lignes de panier hors périmètre sont inutiles au simple effectif commun. La vue d’entrée doit donc être limitée avant l’accès à l’outil. Charger toute la base puis masquer quelques colonnes dans un écran laisse subsister d’autres copies et possibilités d’accès.

Ce que les contrôles techniques doivent réellement couvrir

Le contrôle d’une clean room doit distinguer les colonnes de rapprochement, les calculs autorisés, les filtres et les sorties. Un utilisateur qui ne peut pas sélectionner directement l’identifiant peut néanmoins influencer le groupe étudié par une autre colonne.

À titre d’illustration documentaire, AWS Clean Rooms décrit des règles d’agrégation comportant des contrôles sur les colonnes et les résultats. La documentation prévoit notamment des contraintes de nombre minimal de valeurs distinctes pour restituer une ligne agrégée. Ce sont des paramètres de configuration, pas un seuil légal d’anonymat ni la preuve qu’un projet particulier est correctement réglé.

Le choix d’un minimum exige d’identifier ce qui est compté. Cent transactions ne signifient pas cent personnes. Cent valeurs de clés ne garantissent pas cent individus distincts si les clés changent ou si plusieurs enregistrements correspondent au même titulaire. Le modèle de données fait partie du contrôle.

La CNIL invite à examiner individualisation, corrélation et inférence. L’analyse doit prendre en compte les autres informations raisonnablement disponibles, pas uniquement le tableau isolé. Aucun nombre universel ne remplace cette appréciation.

Deux réponses agrégées peuvent révéler un achat

Considérons un exemple entièrement fictif, indépendant des produits cités. Une équipe connaît les 80 personnes de son groupe G. Elle peut soumettre deux requêtes exactes à une collaboration : la première porte sur G, la seconde sur les mêmes personnes sauf Lina.

La différence 23 − 22 = 1 révèle que Lina appartient au groupe des acheteurs, si les données, la période et les autres paramètres sont identiques. Le partenaire n’a pourtant reçu ni son ticket ni une ligne portant son nom.

Un contrôle se limitant à exiger au moins 50 personnes dans le groupe examiné laisserait passer les deux requêtes de cet exemple : 80 et 79 dépassent ce minimum. Ce nombre est choisi pour la démonstration, pas recommandé pour une configuration. Le problème vient de la combinaison autorisée, pas seulement de la taille de chaque résultat.

Il faut donc examiner les changements de groupes, les filtres, les versions de fichiers et les résultats déjà livrés. Si le partenaire peut reconstruire ces deux populations par une autre voie, interdire seulement le filtre « sauf Lina » ne règle pas le risque.

Pour C12, la décision de conception est de limiter l’analyse à des groupes et modèles de requête approuvés, puis d’examiner les possibilités de combinaison avant ouverture. Cette restriction doit être effective dans l’outil et dans les exports. Si le scénario de différence reste possible dans le périmètre promis comme anonyme, la réception demeure réservée.

Comparer les garanties sans confondre les générations de produit

Une autre famille de contrôles consiste à ajouter un bruit calculé aux résultats et à limiter les informations révélées par les requêtes successives. Le « budget de confidentialité » est alors un paramètre de protection ; ce n’est pas le budget financier de la campagne.

La documentation Snowflake sur la confidentialité différentielle dans ses clean rooms historiques décrit notamment le bruit et le suivi d’un budget. Elle porte un avis de fin de vie pour les architectures Provider/Consumer concernées et précise que les outils doivent être configurés. Ne transposez donc pas ses réglages à une autre génération ou offre sans documentation correspondante.

Ces exemples montrent deux questions d’achat différentes : quelle règle est disponible, et quelle règle est effectivement appliquée dans notre configuration ? Une démonstration commerciale ne répond pas à la seconde si elle utilise un environnement ou un modèle différent du contrat proposé.

Demandez aussi ce qui arrive lorsque la protection bloque une requête. Le responsable métier doit accepter une réponse indisponible ou moins précise. Contourner la restriction en dupliquant un compte ou en demandant un export manuel détruirait la garantie recherchée.

Une fiche de réception utilisable

Voici les exigences proposées pour C12. Il s’agit d’un dossier à adapter et à vérifier, pas d’un résultat de test déjà obtenu.

Un résultat inconnu doit rester indiqué comme inconnu. Si le fournisseur n’explique pas l’accès du support, la fiche ne peut pas indiquer « aucun accès humain ». Si aucun export n’a été examiné, elle ne peut pas conclure « sortie anonyme » sur la seule présentation d’un écran.

La carte des accès d’agence aide à intégrer les intermédiaires. Examinez également les pays de traitement et d’accès ; les Art. 44–46 restent pertinents lorsque la chaîne comporte des transferts soumis au chapitre V.

Attribuer les responsabilités et prévoir les droits

Les rôles suivent les décisions réelles. Lorsque deux acteurs déterminent ensemble les finalités et moyens, l’Art. 26(1) doit être examiné. Un opérateur agissant pour leur compte relève, pour ces opérations, du cadre de l’Art. 28. Les accords RGPD doivent couvrir instructions, sécurité, assistance, autres intervenants et sortie selon le régime applicable.

Le contrat commercial doit aussi interdire les réutilisations exclues de C12, notamment la création d’une audience à partir d’un résultat prévu pour la mesure. Il doit préciser qui peut autoriser une nouvelle requête et comment une modification du modèle ou des données entraîne une nouvelle revue.

Les notices et la procédure de droits doivent refléter les traitements personnels réellement effectués, selon les Art. 12–21. Un retrait, une opposition ou une rectification peut concerner les entrées et les traitements suivants. Il faut distinguer ces données des résultats dont l’anonymat est effectivement établi, sans garder une table de correspondance inutile « au cas où ».

Définissez enfin les durées des données de travail, journaux et résultats. La fin du contrat ne prouve pas leur effacement ; la fermeture d’un accès ne supprime pas un fichier déjà exporté. La réception et la sortie doivent donc traiter les copies connues et leurs destinataires.

Ce qu’il faut retenir

Une clean room est un dispositif à examiner, pas un label de conformité. Limitez et justifiez les entrées, contrôlez les requêtes combinées et qualifiez les sorties. Achetez une configuration démontrable, avec des responsabilités et des règles de sortie précises. Une protection qui bloque un calcul ne doit pas être contournée pour satisfaire le tableau de bord.

FAQ

Faut-il toujours choisir une confidentialité différentielle ?

Ce n’est pas une obligation générale attachée au nom « clean room ». Le choix dépend des données, requêtes, destinataires et risques. Il faut démontrer l’efficacité des mesures retenues, sans présenter un seuil d’agrégation isolé comme une garantie universelle.

Une liste de clés peut-elle être considérée comme une simple statistique ?

Pas lorsque ces clés permettent d’activer ou de retrouver les personnes. Examinez la sortie et ses usages possibles. Un fichier sans nom peut rester personnel et exiger une analyse distincte de la mesure agrégée.

Peut-on commencer avec les données réelles pour évaluer l’outil ?

Un pilote demeure un traitement à justifier. Commencez les vérifications de schéma et de permissions avec des données fictives, puis n’introduisez des données personnelles que dans un périmètre autorisé. La mention « essai gratuit » ne dispense d’aucune condition juridique.

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.