Data partnerships & clean rooms

Data partnerships et clean rooms

En 2021, le prompt App Tracking Transparency d'Apple a réussi ce qu'aucune réglementation sur la vie privée n'avait accompli : faire s'effondrer presque du jour au lendemain l'économie publicitaire fondée sur les identifiants. Meta à elle seule a enregistré un manque à gagner de 10 milliards de dollars en 2022. Mais l'histoire la plus intéressante, c'est ce que les survivants ont fait. Des distributeurs comme Walmart, Kroger et Albertsons ont découvert que les données d'achat first-party dormant dans leurs entrepôts étaient soudain la devise la plus précieuse de la publicité, non parce qu'ils les vendaient, mais parce qu'ils avaient trouvé le moyen de laisser les marques les *utiliser* sans jamais les céder. Ce mécanisme, c'est la data clean room. Et il a fait de Walmart Connect une activité générant plus de 4 milliards de dollars de revenus publicitaires annuels.

Cette leçon traite de la mécanique derrière ce basculement : comment deux organisations combinent leurs données pour crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → une valeur qu'aucune ne pourrait débloquer seule, tout en prouvant aux régulateurs, aux conseils d'administration et l'une à l'autre qu'aucun enregistrement brut n'a changé de mains. En tant que CDO, on vous demandera de plus en plus de valider ces montages. Se tromper sur la gouvernance vous expose à une responsabilité réglementaire ; se tromper sur l'architecture détruit l'économie du dispositif. Les deux échecs atterrissent sur votre bureau.

La logique de valeur : pourquoi combiner des données ?

Commencez par la question stratégique, car la technologie en découle. Un data partnership existe pour résoudre une asymétrie d'information entre deux parties qui détiennent chacune un fragment d'un tableau complet.

Prenez le cas canonique du retail media. Une marque de produits de grande consommation sait qui a vu ses publicités, mais pas qui a acheté le produit. Un distributeur sait qui a acheté le produit, mais pas quelle publicité a influencé cet achat. Aucun des deux ne peut mesurer l'efficacité publicitaire seul. En croisant leurs données sur une clé commune, un e-mail hashé, un identifiant de fidélité, les deux parties apprennent quelque chose qui vaut d'être payé : la marque obtient un vrai return-on-ad-spend, le distributeur obtient un produit de mesure monétisable. La valeur est créée *à l'intersection*, et elle est réellement mutuelle.

C'est le test à appliquer à toute proposition de partenariat qui passe sur votre bureau : existe-t-il un calcul qui vaille plus pour les deux parties que les données que chacune apporte ? Si une seule partie en profite, vous n'avez pas un partenariat, vous avez une vente de données déguisée en partenariat, et elle doit être gouvernée comme une vente.

Trois archétypes reviennent :

• Mesure et attribution, deux parties se joignent sur l'identité pour boucler la chaîne (publicités → résultats). La sortie est constituée de métriques agrégées.
• Enrichissement et activation d'audience, les attributs d'une partie améliorent le ciblage ou la modélisation de l'autre. La sortie est un segment ou un modèle de lift, pas des enregistrements individuels.
• Rapprochement supply-chain et opérationnel, les partenaires réconcilient des entités partagées (expéditions, patients, signaux de fraude) pour réduire un coût collectif.

Remarquez ce qu'ils ont en commun : la *sortie* est étroite et agrégée, tandis que l'*entrée* est sensible et brute. Toute la discipline des clean rooms consiste à élargir l'écart entre ces deux choses, maximiser la valeur de la sortie tout en minimisant l'exposition de l'entrée.

La clean room comme architecture de contraintes

Une data clean room se comprend mieux non comme un produit mais comme un ensemble de contraintes imposées à un calcul conjoint. Les fournisseurs, Snowflake, Google Ads Data Hub, AWS Clean Rooms, Habu, InfoSum, diffèrent par la topologie, mais tous implémentent les mêmes quatre contrôles. En tant que CDO, évaluez toute clean room à l'aune de ces contrôles, pas de listes de fonctionnalités.

Les quatre contrôles

1. Isolation des entrées. Les données brutes de chaque partie restent sous son propre contrôle. Dans une clean room « distribuée » (le modèle d'InfoSum), les données ne bougent jamais physiquement, le calcul est fédéré et seuls des résultats intermédiaires chiffrés franchissent la frontière. Dans un modèle « centralisé » (le data sharing de Snowflake), les données résident dans un environnement gouverné mais aucune partie ne peut interroger directement les lignes de l'autre.

2. Restriction des opérations. La clean room n'autorise que des types de requêtes pré-approuvés. Vous ne pouvez pas exécuter SELECT *. Vous exécutez un join-and-aggregate approuvé. C'est le contrôle que la plupart des CDO sous-estiment, et c'est celui qui compte le plus.

3. Agrégation et filtrage des sorties. Les résultats sous un effectif minimum sont supprimés. Si une requête devait renvoyer une métrique pour un segment de 3 personnes, la clean room renvoie null. C'est ce qui empêche les differencing attacks, la technique consistant à exécuter deux requêtes presque identiques et à soustraire les résultats pour isoler un individu.

4. Journalisation et auditabilité mutuelle. Chaque requête, des deux parties, est journalisée et visible. Aucun des deux camps n'opère dans l'obscurité.

Voici l'idée déterminante pour un dirigeant technique : la garantie de confidentialité de la clean room vient presque entièrement du contrôle n°3, pas du chiffrement du contrôle n°1. Les dirigeants se focalisent sur « les données ne bougent jamais ». Mais une clean room mal configurée, avec un chiffrement solide et *aucun filtrage des sorties*, laisse fuir des individus sans difficulté. Le chiffrement protège les données au repos et en transit ; il ne fait rien contre une requête légitime conçue pour isoler une personne.

C'est pourquoi le seuil d'agrégation est votre paramètre de gouvernance le plus important. Une configuration concrète dans AWS Clean Rooms ressemble à ceci :

analysisRuleAggregation:
  aggregateColumns:
    - columnNames: [purchases]
      function: SUM
  joinColumns: [hashed_email]
  outputConstraints:
    - columnName: user_id
      minimum: 100          # supprimer toute ligne de sortie adossée à <100 utilisateurs
      type: COUNT
  dimensionColumns: [campaign_id, region]

Le minimum: 100 n'est pas un détail technique. C'est la différence entre un insight agrégé et un vecteur de ré-identification. Si votre partenaire pousse pour l'abaisser « pour des résultats plus granulaires », comprenez exactement ce que vous cédez.

Choisir la topologie

Le choix centralisé contre distribué est une véritable décision stratégique, pas une préférence de fournisseur :

• Centralisé (données mutualisées dans un environnement gouverné partagé) est plus rapide à construire, permet des analyses plus riches, et convient quand vous faites confiance à l'opérateur de l'environnement. La plupart des clean rooms de retail media sont ici.
• Distribué / fédéré (les données ne quittent jamais chaque partie) est indispensable quand les données sont régulées au point que le déplacement lui-même constitue le risque, dossiers de santé, données transfrontalières sous RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →, ou quand un partenaire est aussi un concurrent et que vous ne pouvez tolérer que ses équipes aient *une quelconque* proximité avec vos lignes.

L'erreur consiste à retenir par défaut ce que vend le fournisseur. Une banque qui s'associe à une fintech sur des signaux de fraude et un distributeur alimentaire qui s'associe à une marque de grande consommation sur la mesure publicitaire n'ont pas le même modèle de menace et ne devraient pas utiliser la même topologie.

La gouvernance qu'un CDO doit porter

Les fournisseurs de technologie vous vendront la plateforme. Ils ne vous vendront pas le jugement, et c'est le jugement qui vous évite de faire la une. Voici la pile de gouvernance dont vous êtes responsable.

Avant la jointure : l'accord de partenariat

L'accord juridique doit préciser des points que la plupart des modèles omettent. Exigez :

• Une limitation de finalité, imposée par le calcul. Le contrat doit nommer les analyses spécifiquement autorisées, et ces analyses doivent correspondre une à une à l'allowlist de requêtes configurée dans la clean room. Si le contrat dit « mesure » mais que la configuration permet une agrégation arbitraire, votre contrat est décoratif.
• Un engagement de non-ré-identification avec du mordant. Une interdiction explicite de tenter d'isoler des individus, associée à des droits d'audit et à des conséquences définies en cas de manquement. L'architecture sans déplacement d'InfoSum est en partie une stratégie *juridique*, elle rend l'engagement physiquement crédible.
• Propriété des sorties et usage en aval. Qui détient le modèle entraîné dans la clean room ? Un segment de lift peut-il être exporté et réutilisé sur une population différente le trimestre suivant ? C'est là que la valeur, et le risque, fuient discrètement. Un segment construit à partir de vos données, une fois exporté, échappe à votre contrôle.
• Minimisation des données en entrée. N'apportez que les colonnes exigées par le calcul approuvé. Si la mesure a besoin d'un identifiant hashé et d'un indicateur d'achat, ne chargez pas les données démographiques « au cas où elles serviraient plus tard ».

En exploitation : les contrôles que vous surveillez

Les clean rooms échouent par accumulation, pas par une seule brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →èche spectaculaire. Les risques identifiés :

Differencing attacks. Un partenaire exécute la requête A sur un segment, puis la requête A′ sur le même segment moins un attribut connu, et soustrait. Défenses : seuils d'agrégation minimum *plus* surveillance du chevauchement des requêtes *plus* plafond sur le nombre total de requêtes. Aucun contrôle isolé ne suffit, c'est de la défense en profondeur.

Averaging attacks. Des requêtes répétées, légèrement variées, avec du bruit ajouté, moyennées pour annuler le bruit. Si votre clean room utilise la differential privacy (comme le fait l'ADH de Google), vous devez gérer un privacy budget, un epsilon fini consommé par chaque requête. Quand le budget est épuisé, les requêtes s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtent. Traitez epsilon comme une ressource gouvernée avec un propriétaire, pas comme une valeur par défaut fixée une fois par quelqu'un.

Le problème de l'initié avec du contexte. Les sorties agrégées ne sont « anonymes » que relativement à ce que le destinataire sait déjà. Un partenaire qui détient déjà des données substantielles sur la même population peut combiner vos agrégats avec ses connaissances antérieures pour ré-identifier. Cela signifie que votre seuil d'agrégation doit être fixé en fonction des *connaissances auxiliaires probables du partenaire*, pas d'un standard abstrait. Un seuil de 50 peut être sûr face à un inconnu et imprudent face à une entreprise qui détient déjà des données d'identité chevauchantes.

Le framework de décision de gouvernance

Faites passer chaque partenariat proposé par quatre portes, dans l'ordre. Une porte échoue, vous vous arrêtez :

1. Base légale, disposons-nous d'une base licite pour cet usage précis de ces données précises sous chacun des régimes applicables ? (Le périmètre du consentement est là où les deals de retail media échouent le plus souvent.)
2. Symétrie de valeur, la sortie conjointe vaut-elle plus que ce que nous apportons, et cette valeur est-elle mutuelle ?
3. Confinement technique, les contrôles configurés (topologie, allowlist, seuils, budget) rendent-ils les promesses contractuelles physiquement vraies ?
4. Tolérance réputationnelle, si cela paraissait en première page, décrit fidèlement, pourrions-nous le défendre ? Légal et défendable ne sont pas le même standard.

La porte 4 est celle que les CDO sautent et regrettent. Cambridge Analytica était, au sens strict, sans doute autorisé par les conditions de la plateforme Facebook à l'époque. Ce n'était pas défendable.

Application : le playbook du lundi matin

Vous avez une proposition de partenariat sur votre bureau, un grand groupe média veut combiner ses audiences avec vos données first-party pour une démarche de co-selling. Voici comment avancer concrètement.

Semaine une : interrogez la logique de valeur avant de toucher à la technologie. Écrivez, en une phrase, le calcul conjoint et qui en bénéficie. Si vous n'y parvenez pas, il n'y a pas de deal. Identifiez ensuite le minimum de colonnes de données que chaque camp doit apporter pour que ce calcul fonctionne. Cette liste de colonnes devient la spécification d'entrée de tout ce qui suit.

Semaine deux : modélisez la menace propre à ce partenaire. Que sait déjà ce partenaire de la population chevauchante ? La réponse fixe votre seuil d'agrégation et détermine si vous avez besoin d'une topologie fédérée. Un partenaire disposant de graphes d'identité profonds présente un risque de ré-identification plus élevé qu'un autre, quelles que soient ses bonnes intentions.

Semaine trois : alignez contrat et configuration comme un seul artefact. Ne laissez pas le juridique rédiger l'accord pendant que l'ingénierie configure la plateforme de son côté. Chaque finalité autorisée dans le contrat doit correspondre à une requête en allowlist ; chaque usage interdit doit être bloqué dans la configuration, pas seulement proscrit en prose. Quand ces deux documents divergent, vous avez un manquement latent.

En continu : gouvernez les sorties, pas seulement les entrées. L'erreur séduisante avec les clean rooms consiste à croire que le travail s'arrête quand les données brutes sont protégées. La valeur, et le risque résiduel, résident dans ce qui sort de la pièce. Tenez un registre de chaque modèle et segment produit, de ses usages autorisés et de sa date d'expiration. Un segment de lift est un dérivé de données personnelles et doit se périmer, pas persister indéfiniment.

Une remarque organisationnelle : les clean rooms créent une nouvelle collision entre parties prenantes internes. Votre équipe commerciale veut plus de requêtes et des seuils plus bas ; votre équipe privacy en veut moins et plus haut. N'arbitrez pas cela au cas par cas. Mettez en place une revue permanente, la même instance de gouvernance que vous utilisez ailleurs, avec l'autorité de fixer les seuils et les privacy budgets comme une politique. Le paramètre qui détermine votre exposition réglementaire ne devrait pas être fixé par celui qui ouvre le ticket.

Points clés

1. La garantie de confidentialité réside dans le filtrage des sorties, pas dans le chiffrement. Fixez et défendez le seuil d'agrégation minimum comme votre paramètre le plus important, et calibrez-le sur ce que votre partenaire spécifique sait déjà, pas sur un standard générique.

1. Faites du contrat et de la configuration un seul artefact. Chaque finalité autorisée doit correspondre à une requête en allowlist ; chaque interdiction doit être appliquée dans la configuration. Une prose que la plateforme n'applique pas est décorative.

1. Gouvernez les sorties, pas seulement les entrées. Les modèles et segmentssegmentsDécouper un marché en groupes distincts de clients partageant des besoins, des caractéristiques ou des comportements similaires, afin de traiter chaque groupe avec une approche dédiée.Voir la définition complète → construits dans la clean room sont des dérivés de données personnelles. Tenez un registre avec les usages autorisés et les dates d'expiration, le risque résiduel sort de la pièce avec les résultats.

1. Faites passer chaque partenariat par les quatre portes, base légale, symétrie de valeur, confinement technique, tolérance réputationnelle, et traitez la quatrième comme non négociable. Légal et défendable sont des standards différents, et c'est dans l'écart entre les deux que des carrières s'achèvent.

1. Choisissez la topologie à partir du modèle de menace, pas du fournisseur. Fédérée quand un partenaire est un concurrent ou que le déplacement des données constitue lui-même le risque régulé ; centralisée quand vous faites confiance à l'environnement et avez besoin d'analyses plus riches.