L'état d'esprit data-as-a-product

En 2016, Airbnb avait un problème de dashboards qu'aucun dashboard ne pouvait résoudre. Les analystes de l'entreprise produisaient des chiffres contradictoires pour une même métrique : « bookings » signifiait une chose pour l'équipe growth, une autre pour la finance, une troisième pour l'équipe host-supply. Chaque réunion s'ouvrait sur quinze minutes de débat pour savoir qui avait le bon chiffre. La solution n'a pas été un nouvel outil de BIBITechnologies et processus qui transforment des données brutes en insights actionnables via du reporting, des dashboards et de l'analyse, pour que les équipes décident sur des faits plutôt qu'à l'intuition.Voir la définition complète →. Ce fut la décision de traiter leurs jeux de données curés comme des produits : nommés, avec un owner, versionnés, certifiés, et une équipe responsable. Ils ont appelé le système Minerva, et le basculement a été philosophique avant d'être technique : quelqu'un était désormais owner de « bookings » comme un PM est owner d'un tunnel de checkout.

Toute la leçon tient dans cette histoire. L'outillage vient après. Ce qui change tout, c'est de décider qu'un jeu de données n'est pas un résidu d'un système, c'est un produit avec un utilisateur, une promesse, et une personne dont le nom est dessus.

Ce que le mot « produit » vous impose réellement

Vous connaissez déjà le vocabulaire. Le piège consiste à traiter « data productdata productUn actif de données géré comme un produit : un owner, des utilisateurs identifiés, une qualité garantie et une valeur business mesurable.Voir la définition complète → » comme un rebranding de « le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → qui alimente le dashboard ». Un simple changement de nom ne vous apporte rien. **L'état d'esprit ne paie que lorsque vous acceptez les quatre obligations que le mot *produit* traîne derrière lui.**

Un owner responsable des résultats, pas de l'uptime. Un owner de pipeline est jugé sur le fait que le job a tourné. Un owner de data product est jugé sur le fait que le produit a été utilisé et qu'on lui fait confiance. C'est un autre métier. L'owner fait de la discovery : qui sont mes consommateurs, quelle décision cette donnée alimente-t-elle, qu'est-ce qui les pousserait à construire leur propre copie ? Quand une équipe marketing forke discrètement votre table clients et maintient sa propre version, c'est un client churné, et votre produit vient d'échouer même si tous les jobs étaient au vert.

Des utilisateurs que vous pouvez nommer, pas « le business ». Si vous ne pouvez pas lister vos cinq principaux consommateurs et les décisions précises que votre produit alimente, vous n'avez pas un produit, vous avez une table avec du trafic. Une vraie ownership produit signifie que vous savez que le produit revenue_daily sert le board deck du CFO (tolérance à la latence : quelques heures ; tolérance à l'erreur : quasi nulle) et les expérimentations de l'équipe pricing (tolérance à la latence : quelques minutes ; tolérance à l'erreur : modérée). Ce sont des besoins différents sur un même asset, et les nommer oblige à prioriser.

Un SLA qui est un contrat, pas une intention. C'est là que la plupart des organisations révèlent qu'elles n'ont pas fait le basculement. Un vrai SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète → data spécifie la fraîcheur, la complétude, la stabilité du schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →, et ce qui se passe en cas de violation, y compris qui est appelé et à quoi le consommateur a droit. Le SLA est une *promesse faite à un consommateur précis*, ce qui lui donne du mordant : le violer a des conséquences pour le producteur.

Une roadmap, ce qui implique que vous direz non. Une roadmap produit est une déclaration sur ce que vous *ne ferez pas* ce trimestre. Une donnée sous-produit n'a pas de roadmap parce que personne ne choisit : chaque demande reçoit un « on l'ajoute au backlog ». Un owner de data product trie : ce nouveau champ sert trois consommateurs et débloque une décision de revenu, donc il part en prod ; celui-là sert une curiosité ad-hoc isolée, donc il attend.

Voici le cadrage tranchant à emporter pour lundi : la donnée sous-produit optimise le confort du producteur ; la donnée produit optimise le résultat du consommateur. Chaque décision d'architecture, de staffing et de priorisation découle de celui des deux que vous avez réellement choisi, quoi qu'en dise votre organigramme.

Le contrat de data product : rendre le SLA réel

L'état d'esprit devient opérationnel dès l'instant où la fraîcheur et la qualité cessent d'être du savoir tribal pour devenir un contrat lisible par une machine. C'est l'artefact le plus à effet de levier de toute la discipline, parce qu'il fixe simultanément les attentes du consommateur, définit l'obligation du producteur, et devient ce que votre monitoring fait respecter.

Un bon contrat de donnéescontrat de donnéesAccord formel entre l'équipe qui produit les données et celles qui les consomment, fixant structure, sens, qualité et responsabilité en cas de rupture.Voir la définition complète → répond explicitement à quatre questions : *Qu'est-ce qui est garanti ? Pour qui ? Qu'est-ce qui casse la garantie ? Que se passe-t-il quand elle casse ?*

product: customer_360
owner: data-platform-crm@company.com
consumers:
  - team: pricing
    decision: dynamic-discount-eligibility
    criticality: tier-1
  - team: marketing
    decision: campaign-segmentation
    criticality: tier-2
sla:
  freshness: "< 3h from source event"
  completeness: ">= 99.5% of active accounts"
  schema: "additive-only; breaking changes require 2-sprint notice"
on_breach:
  tier-1: page on-call; notify consumers within 15m
  quality_gate: block publish; serve last-known-good

Deux choix de conception dans cet extrait comptent plus que la syntaxe. D'abord, `schema: additive-only` avec un délai de préavis. La première façon dont les data products trahissent leurs utilisateurs est un breaking change silencieux : une colonne renommée, un type modifié, une redéfinition sémantique. Traiter le schéma comme une interface versionnée, comme une équipe 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 → traite un endpoint public, fait la différence entre un produit et un passif. Ensuite, `serve last-known-good` en cas d'échec d'un quality gate. Un pipeline sous-produit publie ce qu'il a calculé, quoi qu'il arrive. Un produit refuse de livrer des données qui échouent à ses propres contrôles de qualité et sert à la place la dernière version de confiance, parce qu'un consommateur qui prend une décision de pricing est mieux servi par une donnée vieille de trois heures que par une donnée silencieusement fausse.

Le travail du CDO n'est pas d'écrire ces fichiers YAML. C'est d'exiger que tout asset promu au statut de « produit » en ait un, et que les conséquences en cas de violation soient réelles. Si violer un SLA tier-1 n'appelle personne, vous n'avez pas un contrat, vous avez de la documentation.

Le piège des niveaux de certification

Un échec courant consiste à tout certifier. Quand chaque jeu de données obtient un badge gold, le badge ne vaut rien. Tenez une structure de niveaux délibérément réduite : une poignée de produits certifiés, une large couche d'assets « connus, utilisés, mais non certifiés », et tout le reste marqué explicitement comme brut. C'est la rareté du niveau supérieur qui lui donne du sens. Minerva d'Airbnb a en partie réussi parce que devenir une métrique Minerva était *difficile* : cela imposait une revue de définition. La rareté a 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 →éé la confiance.

Pourquoi cet état d'esprit débloque la valeur

Maintenant l'argument stratégique, parce qu'il vous faudra défendre l'investissement. Pourquoi traiter la donnée comme un produit, plutôt que livrer des jeux de données plus vite, débloque-t-il une valeur disproportionnée ?

Cela fait s'effondrer la taxe sur la confiance. Dans la plupart des entreprises, le plus gros coût caché de l'analytics n'est ni le compute ni les effectifs, c'est l'effort humain récurrent de *vérifier si un chiffre est fiable* avant d'agir dessus. Chaque analyste qui reconstruit une métrique depuis les tables brutes parce qu'il ne fait pas confiance à la version partagée paie la taxe sur la confiance. Un produit certifié avec un contrat visible élimine cette boucle de vérification. C'est le mécanisme derrière les gains de productivité : pas des requêtes plus rapides, mais *du re-work supprimé*.

Cela rend la valeur attribuable. Quand la donnée est un sous-produit, son ROI est une bouillie : vous ne pouvez pas séparer la valeur de la donnée de celle du système qui l'a générée. Quand c'est un produit avec des consommateurs nommés et des décisions nommées, vous pouvez tracer une ligne de customer_360 aux décisions de pricing qu'il permet, puis à la marge que ces décisions ont déplacée. Cette traçabilité est ce qui vous permet de défendre le budget de la plateforme data en période de récession, et c'est ce qui transforme vos produits internes en candidats à une monétisation externe. Vous ne pouvez pas monétiser un asset dont vous n'êtes pas capable d'articuler la valeur auprès de vos propres collègues.

Cela change qui fait le travail. Le basculement structurel le plus profond, et cela rejoint les modèles d'ownership par domaine que vous croiserez dans la pensée data mesh moderne, c'est que la responsabilité produit pousse l'ownership vers les gens qui comprennent le sens de la donnée. Les équipes data centrales ne peuvent pas être owners de la *sémantique* de chaque domaine ; l'équipe supply-chain sait ce qu'est un enregistrement d'expédition valide, l'équipe centrale non. L'état d'esprit produit permet de décentraliser l'ownership sans décentraliser le chaos, parce que le contrat est le mécanisme de coordination. La fédération ne fonctionne que si chaque unité fédérée livre un vrai produit avec un vrai SLA.

Le jugement qui vous revient en tant que CDO porte sur *où commencer*. N'essayez pas de produitiser tout votre patrimoine, c'est une marche de la mort sur plusieurs années. Choisissez les deux ou trois assets qui sont (a) consommés par de nombreuses équipes et (b) actuellement la source du plus grand nombre de débats de confiance. Ce sont vos produits tête de pont. Produitiser un jeu de données sur lequel personne ne se dispute ne génère aucune valeur visible ; produitiser celui qui ouvre chaque réunion par une bagarre de chiffres crée une légende interne.

Mettre en place votre premier vrai data product

Voici la séquence pour lundi matin. Ce n'est pas un modèle de maturité à contempler, c'est un ordre d'opérations.

1. Nommez l'owner avant de construire quoi que ce soit. L'owner est une personne, pas un alias d'équipe, et idéalement quelqu'un proche du domaine consommateur. Son premier livrable n'est pas du code, c'est une définition produit d'une page : la définition sémantique des entités centrales, les consommateurs nommés, et les décisions servies. Si personne n'accepte d'être responsable d'un produit candidat, c'est le signal que l'asset n'est pas prêt pour le statut de produit, ou que l'organisation ne croit pas encore à cet état d'esprit. Remontez-le au comité exécutif ; ne le maquillez pas.

2. Écrivez le contrat avec les consommateurs dans la pièce. Les SLA inventés par le seul producteur sont toujours faux : soit dorés à l'excès (coûteux, inutile), soit trop lâches (sans intérêt). Faites dire à voix haute au responsable pricing et au responsable marketing quelle fraîcheur et quelle exactitude ils ont réellement besoin. Vous découvrirez généralement que leurs besoins réels sont plus lâches que ce que l'ingénierie supposait, ce qui économise de l'argent, ou que deux consommateurs ont des besoins véritablement incompatibles, ce qui vous dit qu'il s'agit de deux produits.

3. Instrumentez la consommation avant d'optimiser quoi que ce soit. Vous ne pouvez pas piloter un produit dont vous ne voyez pas l'usage. Loguez qui l'interroge, à quelle fréquence, et, quand c'est possible, quelles décisions ou quels produits en aval en dépendent. C'est votre équivalent du product analytics. Sans cela, votre roadmap est une devinette et vous ne pouvez pas détecter le churn silencieux d'une équipe qui forke vos données.

4. Établissez le rituel de dépréciation. Les produits se retirent. Un pipeline sous-produit tourne indéfiniment parce que personne ne regarde ; un vrai produit a un chemin défini pour sa fin de vie, avec préavis aux consommateurs. Publiez une politique de dépréciation dès le premier jour, même pour votre premier produit, parce que cela signale à toute l'organisation que ces assets sont gérés, et non accumulés par sédimentation.

5. Passez en revue le portefeuille comme un portefeuille produit. Chaque trimestre, regardez vos produits certifiés comme un head of product regarde sa gamme : lesquels gagnent en adoption, lesquels déclinent, lesquels sont chers à maintenir au regard de la valeur délivrée, lesquels ont besoin d'investissement. C'est l'artefact qui transforme l'état d'esprit d'un projet ponctuel en rythme opérationnel, et c'est la revue qu'un CDO devrait animer personnellement.

Le mode d'échec à surveiller : des équipes adoptent le *langage* des data products, elles renomment leurs pipelines, elles montent un catalogue, sans accepter une seule des quatre obligations. Personne n'est appelé en cas de violation, personne ne peut nommer les consommateurs, aucune roadmap ne dit non. C'est de la produitisation culte du cargo, et c'est pire que ne rien faire, parce que cela brûle la crédibilité du terme auprès de vos dirigeants avant même qu'il ait délivré de la valeur.

Points clés

• Le mot « produit » impose quatre obligations non négociables : un owner nommé et responsable des résultats, des consommateurs nommés, un SLA opposable, et une roadmap qui sait dire non. S'il en manque une seule, vous avez un pipeline renommé, pas un produit.
• Faites du SLA un contrat lisible par une machine et qui a du mordant. Versionnez les schémas comme des interfaces publiques (additive-only, avec préavis), et servez le last-known-good plutôt que de publier des données qui échouent à leur propre quality gate. Un contrat pour lequel personne n'est appelé n'est que de la documentation.
• Gardez le niveau certifié rare. Quand tout est gold, plus rien n'inspire confiance. La valeur d'un data product vient de la difficulté à obtenir le badge.
• Commencez par l'asset qui provoque le plus de débats de confiance, pas par le plus facile à construire. Le déblocage de valeur, c'est la taxe sur la confiance éliminée et le re-work qu'elle supprime : visez donc le jeu de données qui ouvre chaque réunion par une bagarre de chiffres.
• Animez vous-même une revue trimestrielle du portefeuille produit. Adoption, déclin, rapport coût/valeur, candidats à la dépréciation : c'est ce rythme opérationnel qui transforme l'état d'esprit d'un projet en discipline.