Data sharing, marketplaces et écosystèmes

En 2021, un assureur européen de taille moyenne a découvert que son actif le plus précieux n'était pas ses modèles actuariels, mais quinze ans de données granulaires de sinistres sur les dégâts des eaux en résidentiel. Un cabinet d'analytics en réassurance a proposé sept chiffres pour y accéder. Le CDO a dit oui au revenu, puis a passé dix-huit mois à en démêler les conséquences : un concurrent a reconstitué la logique de souscription de l'assureur à partir de patterns agrégés, et un régulateur a posé des questions précises sur le périmètre du consentement. Le deal n'était pas une erreur. **C'est l'*architecture de décision* derrière lui qui manquait**.

C'est ce manque que cette leçon comble. Vous comprenez déjà la monétisation comme concept. Ce qu'il vous faut maintenant, c'est le jugement opérationnel pour décider où vous vous situez dans un écosystème de données, acheteur, vendeur ou opérateur, et comment construire la machinerie qui rend chaque rôle sûr et rentable.

Les trois postures et pourquoi vous devez choisir délibérément

Toute transaction dans un écosystème de données vous place dans l'une des trois postures, et la plupart des CDO y arrivent par accident plutôt que par choix stratégique.

En tant qu'acheteur, vous acquérez des données externes pour enrichir vos décisions internes : overlays démographiques, flux météo, panels de transactions, firmographics. Le piège ici n'est pas le coût ; c'est la *dépendance et l'attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète →*. Quand un signal acheté devient porteur dans un modèle en production, vous avez 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 →éé un fournisseur qui fixe désormais son prix en fonction de votre coût de sortie. Le Data Marketplace de Snowflake et AWS Data Exchange ont rendu l'acquisition sans friction, et c'est précisément le danger : un achat sans friction produit une prolifération sans gouvernance. Un distributeur avec qui j'ai travaillé avait 34 abonnements à des données externes répartis sur cinq équipes, dont trois faisaient doublon et un était juridiquement indéfendable.

En tant que vendeur, vous packagez et licenciez vos propres données. L'assureur ci-dessus était vendeur. La discipline centrale consiste à comprendre ce que vous vendez réellement : des enregistrements bruts, des features dérivées ou des *insights*. Ce sont trois métiers différents avec trois profils de risque différents. Vendre des enregistrements bruts maximise la flexibilité de l'acheteur et votre exposition. Vendre des insights (par exemple des « scores de propension » plutôt que le comportement sous-jacent) protège votre moatmoatUn avantage durable sur les concurrents : une ressource, une capacité ou une position qu'ils ne peuvent pas répliquer facilement, et qui permet à une entreprise de dégager des rendements supérieurs à la moyenne dans la durée.Voir la définition complète → concurrentiel mais exige de construire et maintenir un produit.

En tant qu'opérateur, vous construisez la marketplace ou la clean room où les autres transigent, la posture qu'a prise Bloomberg il y a des décennies et qu'occupent aujourd'hui des acteurs comme Snowflake, Databricks ou des spécialistes comme Habu/LiveRamp. C'est un business de plateforme avec une économie de plateforme : potentiel énorme, dynamique de cold start brutale, et une charge de gouvernance qui écrase les deux autres rôles.

Le test de décision n'est pas « quelle posture est la plus rentable » mais quelle posture correspond à la position structurelle de vos données :

• Si vos données sont *proches d'une commodité* (vous les avez, d'autres aussi), vous êtes acheteur de données différenciées et, au mieux, vendeur à faible marge.
• Si vos données sont *uniques et difficiles à répliquer* (réseaux de capteurs propriétaires, flux de transactions exclusifs), vous disposez d'une optionalité vendeur et peut-être opérateur.
• Si vous vous situez à un *point d'agrégation naturel* où de nombreuses parties ont besoin de combiner des données qu'elles ne se partageront pas directement, vous avez un potentiel d'opérateur, et seulement dans ce cas.

La plupart des CDO sont des acheteurs qui vendent occasionnellement. Très peu devraient être opérateurs, et ceux qui s'y essaient sans l'avantage du point d'agrégation brûlent du capital de façon spectaculaire.

Comment la machinerie fonctionne réellement : clean rooms et contrats

Le basculement technique déterminant des cinq dernières années, c'est que vous n'avez plus besoin de déplacer les données pour les combiner. Cela change tout pour les postures vendeur et opérateur.

L'ancien modèle était « on envoie un fichier et on croise les doigts ». Le modèle actuel est la data clean room : un environnement gouverné où deux parties ou plus peuvent exécuter des calculs approuvés sur leurs données combinées sans qu'aucune ne voie les enregistrements bruts de l'autre. C'est ainsi que les annonceurs matchent leurs audiences avec les éditeurs dans l'ère post-cookie, et c'est ainsi que l'assureur *aurait dû* structurer son deal de réassurance.

Les mécanismes qu'un CDO doit comprendre tiennent en trois couches :

1. La couche privacy, les techniques qui rendent les outputs sûrs : seuils d'agrégation (aucun résultat publié pour moins de N individus), differential privacy (injection de bruit calibrée) et audit des requêtes. C'est ce qui empêche un acheteur de reconstituer des enregistrements individuels ou, comme dans notre cas d'ouverture, de faire du reverse engineering sur votre modèle.

1. La couche gouvernance, qui peut exécuter quelles requêtes sur quelles colonnes, avec quelle allowlist d'opérations. C'est là que la plupart des implémentations échouent, parce que les équipes la traitent après coup.

1. La couche commerciale, le metering, les entitlements et la facturation liée à la consommation.

Voici à quoi ressemble une politique de clean room qui sépare un deal défendable de l'erreur de l'assureur, en restreignant les opérations à des agrégats au-dessus d'un seuil plutôt qu'en exposant des lignes jointes :

clean_room_policy:
  dataset: residential_claims
  allowed_operations: [count, sum, avg, join_on_hashed_key]
  blocked_operations: [select_raw, export_rows]
  aggregation_threshold: 50   # supprime tout résultat couvrant <50 enregistrements
  join_keys:
    - property_id_hashed
  output_review: automated_plus_manual_sample
  differential_privacy:
    epsilon: 1.0

L'assureur a vendu des enregistrements bruts joignables. S'il avait vendu *uniquement des résultats de requêtes agrégés au-dessus d'un seuil de 50 avec la clé de jointure hachée*, le réassureur aurait obtenu un signal de risque légitime et aurait été incapable de reconstituer la logique de souscription propriétaire. Même revenu, risque radicalement différent. Les termes du contrat et les contrôles techniques doivent encoder la même intention : si votre accord juridique dit « agrégats uniquement » mais que votre plateforme autorise l'export de lignes, c'est la plateforme qui gagne.

Côté acheteur, la discipline symétrique est un gate d'acquisition de données : aucun dataset externe n'entre en production sans répondre à quatre questions. Quelle décision améliore-t-il, et de combien ? Quel est notre coût de sortie si le fournisseur change ses conditions ? La chaîne de provenance et de consentement est-elle garantie contractuellement ? Qu'advient-il de notre modèle si ce flux devient obsolète ou disparaît ? Les 34 abonnements du distributeur sont tombés à 11 dès que ces questions ont été appliquées.

L'économie : pricing, capture de valeur et le cold start de l'opérateur

La question qui bloque la plupart des initiatives de data sharing est le pricing, et la raison est que les CDO tarifent la donnée comme un produit alors qu'ils devraient la tarifer comme *un accès à une décision*.

Trois modèles de pricing dominent, et chacun signale une relation différente :

• L'abonnement (accès forfaitaire) récompense les gros utilisateurs et se budgète facilement, mais il découple votre revenu de la valeur pour l'acheteur, ce qui est dangereux quand vos données sont très différenciées.
• La consommation (par requête / par enregistrement) aligne le revenu sur l'usage et constitue désormais le standard des marketplaces, mais elle pénalise l'exploration et peut étouffer l'expérimentation qui révèle à l'acheteur la valeur de vos données.
• Le modèle à l'outcome lie le prix au lift réellement obtenu par l'acheteur. C'est le graal, et c'est presque impossible à instrumenter honnêtement, parce que l'attribution est contestée.

La réponse pratique pour un vendeur est généralement un hybride : un plancher d'abonnement pour l'accès plus de la consommation pour le volume, le plancher étant calibré pour couvrir votre coût de gouvernance et de support. Ne tarifez jamais en dessous de votre *coût pour servir en sécurité*, qui inclut le coût continu de la surveillance des usages abusifs, pas seulement l'infrastructure.

Sur la capture de valeur, le cadrage le plus tranchant pour un CDO est la question de la migration de valeur : quand vous vendez de la donnée, la valeur migre-t-elle *vers* le produit de votre acheteur d'une manière qui finira par vous concurrencer ? L'assureur a vendu à un réassureur : adjacent, pas directement concurrent. Vendre les mêmes données de sinistres à une startup insurtech aurait été nourrir un futur concurrent. La donnée est identique ; la conséquence stratégique est inverse. C'est un jugement qu'aucun modèle de contrat ne prend à votre place.

La posture d'opérateur mérite un avertissement sévère sur l'économie. Les marketplaces sont des réseaux biface, et les réseaux biface ont un problème de cold start : les acheteurs ne viennent pas sans vendeurs, les vendeurs ne viennent pas sans acheteurs. Les opérateurs qui ont gagné, Bloomberg, Snowflake, ont soit amorcé un côté avec une audience captive existante, soit subventionné lourdement un côté pendant des années. Si vous envisagez d'opérer un écosystème, la question diagnostique est brutale : *possédez-vous déjà un côté du marché ?* Une entreprise de logistique qui connecte déjà 10 000 chargeurs et transporteurs peut opérer de façon crédible un échange de données entre eux. Une entreprise sans cette gravité existante propose de financer un flywheel d'effets de réseau à partir de zéro, et c'est un pari de venture, pas une stratégie data.

Prendre la décision lundi matin

Convertissons tout cela en une séquence que vous pouvez réellement exécuter.

Étape 1 : inventoriez la position structurelle de vos données, pas leur volume. Pour chaque dataset significatif, positionnez-le sur deux axes : la *réplicabilité* (avec quelle facilité d'autres peuvent-ils obtenir des données équivalentes ?) et la *valeur d'agrégation* (combien vaut-il de plus une fois combiné aux données d'autres acteurs ?). Les actifs à forte unicité et forte valeur de combinaison sont vos candidats vendeur et opérateur. Pour tout le reste, vous êtes acheteur ou vous n'y touchez pas.

Étape 2 : passez les filtres de migration de valeur et de dépendance. Pour chaque candidat vendeur, cartographiez qui sont les acheteurs et si l'un d'eux se situe dans votre futur concurrentiel. Pour chaque besoin d'achat, appliquez le gate d'acquisition. C'est là que vous dites non à un revenu qui vous coûte du terrain stratégique, et non à des abonnements qui créent des dépendances cachées dans vos modèles.

Étape 3 : choisissez la posture technique minimale viable. Vous n'avez pas besoin de construire une clean room pour commencer à vendre. L'échelle de maturité est : (a) livraison de fichiers gouvernée avec des contrats solides, (b) accès par APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → avec metering, (c) accès par requête dans une marketplace, (d) clean room multipartite complète. Commencez un cran au-dessus de ce que votre risque exige, pas au sommet. L'assureur avait besoin du cran (c) ; il opérait au cran (a).

Étape 4 : instrumentez la détection des usages abusifs avant la première transaction, pas après. L'échec le plus courant est de découvrir une violation par un article de presse ou une lettre d'un régulateur. Le logging des requêtes, la détection d'anomalies sur les patterns d'accès et les audits périodiques des outputs ne sont pas une charge optionnelle : c'est ce qui vous permet de vendre tout court. Budgétez le coût *continu* d'un service sûr dans votre pricing.

Étape 5 : ne décidez de la posture d'opérateur qu'après le test de gravité réseau. Si vous ne possédez pas un côté du marché, participez à l'écosystème de quelqu'un d'autre comme acheteur ou vendeur et reposez la question de l'opérateur dans dix-huit mois. Opérer est la posture au plafond le plus élevé et au taux d'échec le plus élevé, et c'est rarement le bon premier mouvement.

Un recadrage utile tout du long : vous ne décidez pas si vous partagez vos données ; vous décidez quelle part de l'optionalité de vos données vous convertissez en revenu, et à quel coût stratégique. L'assureur a converti trop d'optionalité (des enregistrements bruts) pour le revenu qu'il a capté. Un CDO discipliné convertit le *minimum* de données nécessaire pour capter la valeur : vendre des insights avant des features, des features avant des enregistrements, et des agrégats avant du brut.

Points clés à retenir

• Choisissez votre posture délibérément, à partir de la position structurelle et non du volume. Des données à forte unicité et forte valeur de combinaison vous donnent une optionalité vendeur/opérateur ; des données de commodité font de vous un acheteur. La plupart des CDO devraient être des acheteurs disciplinés qui vendent occasionnellement des insights, pas des opérateurs.

• Encodez la même intention dans le contrat et dans la plateforme. Si votre accord dit « agrégats uniquement » mais que vos contrôles techniques autorisent l'export de lignes, ce sont les contrôles qui gagnent et vous êtes exposé. Vendez le minimum de données nécessaire : des insights avant des features, des features avant des enregistrements, des agrégats avant du brut.

• Faites passer chaque achat par un gate d'acquisition et chaque vente par un filtre de migration de valeur. Éliminez les dépendances cachées de vos modèles à des flux externes, et refusez un revenu qui alimente un futur concurrent même quand la donnée est identique à celle d'un deal sans risque.

• Tarifez l'accès à une décision, pas un produit, et tarifez au-dessus de votre coût pour servir en sécurité. Ce coût inclut la surveillance continue des usages abusifs, que vous instrumentez *avant* la première transaction, jamais après.

• Ne tentez la posture d'opérateur que si vous possédez déjà un côté du marché. Sans gravité réseau existante, construire une marketplace est un pari de venture déguisé en stratégie data, et le problème de cold start consommera votre capital.