Product management appliqué à la data

En 2016, Airbnb comptait environ 100 analystes qui construisaient la même métrique de « santé de marché » de quinze façons légèrement différentes. Chaque revue de direction s'ouvrait sur une dispute pour savoir quel chiffre était le bon. Le correctif n'a pas été un nouveau dashboard ni une note de gouvernance, mais **le fait de traiter la couche de métriques comme un *produit*, avec un owner, une roadmap, du versioning et un contrat avec ses consommateurs**. Ce recadrage a donné naissance à la plateforme de métriques Minerva. La leçon pour vous ne porte pas sur l'outillage. Elle est qu'Airbnb a cessé de livrer des *artefacts* data pour livrer des *data products*, et que la différence tenait presque entièrement à la discipline : qui détient la chose et comment les décisions la concernant sont prises.

Vous savez déjà ce qu'est un 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 → sur le plan conceptuel. Ce que la plupart des CDO ratent, c'est de croire qu'un dataset orienté domaine assorti d'un 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 → constitue un produit. Non. Un produit se définit par **une *relation gérée avec un consommateur dans la durée*, la découverte d'un besoin réel, une priorisation impitoyable et un cycle de vie qui inclut le travail ingrat de la dépréciation**. Cette leçon traite de l'installation de cette discipline et du rôle qui la porte : le data product manager (DPM).

Pourquoi la discipline produit casse quand on la copie du logiciel

Le réflexe est de reprendre tel quel le Software Product Management. Il échoue de trois façons précises, et comprendre ces modes de défaillance vous dit quoi construire à la place.

D'abord, vos « utilisateurs » sont souvent des machines et des pipelines, pas des humains qui cliquent dans une UI. Une table de feature storefeature storeRéférentiel centralisé qui gère les features de ML et garantit la cohérence entre les environnements d'entraînement et de production.Voir la définition complète → alimentant un modèle de fraude n'a pas de session utilisateur, pas de funnelfunnelLe parcours client de la découverte à l'achat, généralement Awareness, Interest, Consideration, Decision, Action, avec des prospects de moins en moins nombreux à chaque étape.Voir la définition complète →, pas d'enquête NPSNPSLe Net Promoter Score (NPS) mesure la loyauté client en demandant aux clients quelle est la probabilité qu'ils recommandent une marque, puis en soustrayant les détracteurs des promoteurs.Voir la définition complète →. La discovery ne peut pas reposer sur l'observation des usages. Vous devez instrumenter la *consommation* : quels jobs downstream lisent quelles colonnes, comment la fraîcheur affecte la performance du modèle, quels champs sont interrogés et lesquels sont du poids mort. Le signal produit est dans les query logs et le graphe de lineage, pas uniquement dans les entretiens utilisateurs.

Ensuite, le coût d'un breaking change est asymétrique et souvent invisible pour vous. Dans le logiciel, si vous cassez une 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 →, l'application cliente plante et quelqu'un ouvre un ticket. Dans la data, si vous changez silencieusement la sémantique d'une colonne, disons revenue qui passe du brut au net, rien ne plante. Les modèles dérivent, les dashboards mentent discrètement, et un VPVPFormulation claire des bénéfices apportés par votre produit, des problèmes qu'il résout et des raisons pour lesquelles les clients doivent vous choisir plutôt qu'une alternative.Voir la définition complète → prend une mauvaise décision trois semaines plus tard. Le rayon d'impact d'un data product est plus large et plus silencieux que celui d'une fonctionnalité logicielle, ce qui veut dire que le *contrat* doit faire plus de travail.

Enfin, la valeur est fréquemment indirecte. Une fonctionnalité logicielle peut souvent être rattachée à un chiffre de conversion ou de rétention. Une entité client canonique peut 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 →éer de la valeur en rendant possibles neuf produits downstream, dont aucun ne le lui crédite. Cela ruine une priorisation naïve fondée sur le ROI et oblige les DPM à raisonner en *valeur d'option* et en *levier de dépendance*, pas seulement en usage direct.

Le DPM n'est donc pas un PM logiciel qui a changé de domaine. Le rôle est hybride : assez d'aisance en data engineering pour lire un graphe de lineage et interroger un schéma, assez d'économie du domaine pour savoir quelles décisions un dataset éclaire réellement, et assez de capital politique pour dire non à un VP insistant. Quand vous recrutez ou promouvez sur ce rôle, **pondérez davantage le *jugement sur le besoin du consommateur en situation d'ambiguïté* que l'expertise outillage**. Les outils changent ; le jugement se capitalise.

Ce que le DPM détient réellement

Tracez la ligne clairement, sinon vous obtiendrez un coordinateur qui organise des réunions. Un vrai DPM détient quatre choses :

• La définition du problème : quelle décision ou quel workflow ce produit améliore, énoncé dans le langage du consommateur.
• La roadmap priorisée : ce qui est construit, ce qui est refusé, dans quel ordre.
• Le contrat d'interface : schéma, sémantique, SLA et politique de changement.
• Le cycle de vie : du lancement à l'itération jusqu'à la dépréciation.

Il ne détient *pas* l'implémentation du pipeline (c'est le data engineering) ni l'architecture de stockage (couverte dans vos fondamentaux). **Le DPM détient l'*extérieur* du produit, la promesse, tandis que l'engineering détient l'*intérieur***.

Discovery : trouver le produit à l'intérieur de la demande

Tout CDO reçoit un flux de demandes qui ressemblent à des produits : « Il nous faut un dataset de churn. » « Le marketing veut une vue client unifiée. » Traiter ces demandes comme des specs, c'est ainsi qu'on se retrouve avec le problème des 15 versions de la santé de marché. La discovery est la discipline consistant à traduire une demande en problème validé avant d'engager de la capacité d'engineering.

Les meilleurs DPM appliquent une version compressée de la logique « Jobs to Be Done » adaptée à la data. La question n'est pas « quelles données voulez-vous ? ». C'est « quelle décision prenez-vous, à quelle fréquence, et que coûte le fait de vous tromper ? ». Ce recadrage fait trois choses : il révèle si la demande est un vrai besoin récurrent ou une analyse ponctuelle (qui ne devrait pas être un produit du tout), il déduit la fraîcheur et la précision requises de l'économie de la *décision* plutôt que de la liste de souhaits du demandeur, et il fait apparaître les vrais consommateurs.

Prenez une demande de « données d'inventaire en temps réel ». La discovery révèle que la décision réelle est une commande de réapprovisionnement nocturne passée à 2 h du matin. Le temps réel est coûteux et sans objet ; une photo batch fiable à 23 h constitue le produit. Vous venez d'économiser un trimestre d'infrastructure de streaming en posant la question de la décision plutôt que celle des données.

Un artefact de discovery concret sur lequel j'insiste est un data product brief d'une page que le DPM rédige *avant* toute construction :

product: customer_churn_signals
consumer_decision: "Retention team decides weekly which accounts get intervention"
decision_cadence: weekly
cost_of_error:
  false_positive: "$40 wasted outreach per account"
  false_negative: "avg $2,400 lost LTV per churned account"
required_freshness: "daily, by 6am"
required_accuracy: "recall prioritized over precision"
consumers: [retention_ops, cs_leadership_dashboard, expansion_model_v3]
NOT_in_scope: ["real-time scoring", "prospect data"]

Remarquez l'asymétrie de cost_of_error : les faux négatifs coûtent 60 fois plus cher que les faux positifs. Cette seule ligne dicte la cible d'optimisation du modèle et le SLA. Remarquez NOT_in_scope. La moitié de la discovery consiste à décider ce que le produit *refuse* d'être. Minerva chez Airbnb a réussi en partie parce qu'il a déclaré qu'il ne servirait que des métriques *certifiées*, pas tous les calculs ad hoc.

Priorisation : le problème de portefeuille pour lequel personne ne vous a formé

C'est ici que les CDO perdent de la valeur. Parce que la valeur des data products est indirecte et en réseau, les frameworks de priorisation classiques (RICE, scoring pondéré) sous-pondèrent systématiquement les produits qui comptent le plus : les entités et métriques fondationnelles dont tout le reste dépend.

Utilisez une grille à deux axes que le DPM applique à chaque candidat : le levier décisionnel (combien de décisions à fort enjeu ce produit touche, pondérées par leur valeur) face au coût de service fiable (construction plus charge de maintenance continue, astreinte comprise). Le piège est que les produits fondationnels, une entité client ou produit canonique, obtiennent un score faible en levier *direct* parce qu'aucune décision unique ne leur « appartient », alors qu'ils débloquent des dizaines de produits downstream. Le DPM doit modéliser explicitement le levier de dépendance : le score d'un produit hérite d'une fraction de la valeur de tout ce qui est bâti dessus.

C'est pourquoi vous séparez le portefeuille en trois niveaux, financés différemment :

• Produits plateforme (entités canoniques, couche de métriques, feature tables centrales) : financés comme de l'infrastructure, évalués sur l'adoption et la réutilisation, pas sur le ROI direct. Ce sont vos actifs de classe Minerva.
• Produits de décision (un modèle de churn précis, un dataset d'élasticité-prix) : financés sur l'économie de la décision, évalués sur l'amélioration effective de la décision.
• Produits exploratoires (une nouvelle segmentation expérimentale) : financés comme des options, bornés dans le temps, tués vite s'ils ne se valident pas.

Le geste de priorisation le plus précieux d'un DPM est de refuser de construire. Chaque data product entraîne une taxe de maintenance permanente : dérive de schéma, changements upstream, astreinte, obsolescence de la documentation. Une règle que j'ai vue fonctionner : aucun nouveau produit ne sort tant que l'équipe n'a pas identifié quelle capacité il consommera *pour toujours*, pas seulement pour le construire. Si une équipe est saturée en maintenance, la réponse à une nouvelle demande est « non » ou « qu'est-ce qu'on déprécie d'abord ? », pas « oui, au prochain trimestre ».

Rendre la taxe de maintenance visible

Donnez à votre DPM un ratio simple à remonter : capacité de build vs capacité de run. Quand le run dépasse environ 60-70 % de la capacité totale de l'équipe, vous n'êtes plus une organisation produit, vous êtes une organisation de maintenance, et l'innovation s'est arrêtée. Ce ratio est votre signal d'alerte précoce indiquant que le portefeuille contient trop de produits et pas assez de dépréciation. C'est aussi le chiffre que vous apportez à votre CFO pour justifier soit des recrutements, soit un sprint de dépréciation. La plupart des CDO ne le mesurent jamais et s'étonnent ensuite que la vélocité s'effondre.

Cycle de vie : la discipline des contrats et des fins

Les équipes logicielles ont appris depuis des décennies que la vie d'un produit se joue surtout *après* le lancement. Les équipes data agissent régulièrement comme si le lancement était la ligne d'arrivée. La contribution la plus durable du DPM est de gérer le cycle de vie complet, en particulier les deux phases négligées : le contrat d'interface et la dépréciation.

Le contrat est la véritable interface du produit. Parce que les breaking changes sont silencieux et à fort rayon d'impact (rappelez-vous l'exemple du revenu brut vs net), le contrat doit être explicite et applicable par la machine. C'est là que la pratique moderne du « data contract » prend tout son sens. Le DPM détient la *sémantique et la politique de changement* du contrat ; l'engineering l'applique dans le pipeline. Un contrat minimal déclare le schéma, la signification sémantique de chaque champ, les SLA et, surtout, la politique de changement : ce qui constitue un breaking change, quel préavis les consommateurs obtiennent, et comment les versions coexistent.

La politique de changement est une décision *produit*, pas technique, car elle arbitre entre la stabilité du consommateur et votre vélocité. Un produit plateforme servant 40 consommateurs peut promettre 90 jours de préavis de dépréciation et des versions en double exécution. Un produit exploratoire peut ne rien promettre. Le DPM fixe cela délibérément par niveau.

Le versioning doit être réel, pas déclaratif. Quand la sémantique change, vous publiez v2 à côté de v1, vous migrez les consommateurs selon un calendrier, et seulement ensuite vous retirez v1. C'est coûteux opérationnellement, et c'est exactement pour cela que la priorisation et le refus comptent : chaque produit que vous livrez est une obligation de versioning que vous acceptez.

La dépréciation est la phase qui sépare une organisation produit d'une décharge. La plupart des patrimoines data sont constitués à 60 % de tables abandonnées que personne n'ose supprimer parce que personne ne sait qui les lit. Le DPM gère la dépréciation comme un processus piloté : instrumenter la consommation, identifier les produits sous un seuil d'usage, annoncer l'arrêt avec un chemin de migration, et supprimer. C'est ingrat, et c'est l'hygiène à plus fort levier de tout votre patrimoine, parce que chaque produit retiré rend de la capacité de run à la colonne build.

Une cadence opérationnelle concrète pour votre DPM : une revue trimestrielle de portefeuille qui répond à trois questions pour chaque produit : *Quelqu'un l'utilise-t-il encore ? Respecte-t-il son contrat ? Faut-il le promouvoir, y investir ou le tuer ?* Les produits qui échouent au test d'usage se voient attribuer une date d'arrêt sur-le-champ. Cette revue est le mécanisme qui maintient le ratio build/run en bonne santé. Animez-la vous-même les deux premiers trimestres pour que l'organisation voie que tuer des produits est célébré, pas puni. Le signal culturel, à savoir qu'un DPM qui déprécie dix produits morts vaut autant que celui qui en livre un nouveau, n'est envoyé que par vous, CDO.

Mesurer la santé d'un data product

L'usage direct est nécessaire mais insuffisant. Suivez quatre signaux par produit : l'adoption (consommateurs distincts et leur tendance), la fiabilité (respect du contrat, SLA de fraîcheur et de qualité tenus), l'impact décisionnel (la décision cible s'est-elle améliorée de façon mesurable, le plus difficile et le plus important) et le coût de service (compute plus maintenance humaine). Un produit fort en adoption et en fiabilité mais dont l'impact décisionnel est inconnu est candidat à une investigation approfondie, pas à une reconduction automatique : ce peut être un artefact magnifiquement entretenu qui ne change aucune décision.

Points clés à retenir

• Installez le rôle de DPM avec un mandat net : il détient la définition du problème, la roadmap, le contrat d'interface et le cycle de vie, l'*extérieur* du produit. L'engineering détient l'*intérieur*. Brouillez cette frontière et vous obtenez un coordinateur de réunions, pas un product owner.

• Ancrez la discovery dans la décision, pas dans la demande de données. Exigez que chaque product brief énonce la décision du consommateur, sa cadence et le coût asymétrique de l'erreur. Cette seule discipline calibre la fraîcheur, la précision et le périmètre, et tue les produits qui auraient dû rester des analyses ponctuelles.

• Priorisez sur trois niveaux en gardant le levier de dépendance en vue. Financez les produits plateforme comme de l'infrastructure sur la réutilisation, les produits de décision sur l'économie de la décision, et les produits exploratoires comme des options bornées dans le temps. Un scoring RICE standard affamera vos actifs les plus fondationnels.

• Surveillez le ratio de capacité build/run comme une ligne de P&L. Quand le run dépasse ~60-70 %, vous avez cessé d'innover. C'est votre déclencheur quantitatif pour des recrutements ou un sprint de dépréciation, et le chiffre que vous apportez au CFO.

• Traitez la dépréciation comme une activité de premier plan, à célébrer. Animez une revue trimestrielle de portefeuille qui pose une date d'arrêt sur les produits inutilisés. Chaque produit retiré rend de la capacité au build, et vous seul pouvez envoyer le signal culturel selon lequel tuer des produits morts vaut autant qu'en livrer de nouveaux.