Les plateformes de données internes comme des produits

En 2019, l'équipe data platform d'Airbnb a fait un constat inconfortable : elle avait construit une infrastructure de données élégante sur le plan technique, et magnifique, à laquelle presque personne ne faisait confiance. Les analystes maintenaient discrètement des pipelines fantômes. Les équipes produit tiraient leurs métriques de trois sources différentes et obtenaient trois réponses différentes. L'équipe plateforme mesurait son succès en tables ingérées et en requêtes servies, mais les personnes qui comptaient, les consommateurs internes, la contournaient. La réponse d'Airbnb a été de traiter la plateforme non pas comme de la plomberie, mais comme un produit avec des utilisateurs, une proposition de valeur et un problème de churn. Ce recadrage, formalisé plus tard dans leurs travaux « Data QualityData QualityLe degré d'aptitude des données à l'usage prévu : exactes, complètes, cohérentes, à jour, valides et uniques. Une data quality faible fragilise l'analytics, le reporting et l'IA.Voir la définition complète → at Airbnb » et sur la couche de métriques Minerva, est la discipline dont parle cette leçon.

Le piège est séduisant parce qu'il donne l'impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète → d'avancer. Vous livrez un nouveau lakehouselakehouseUne architecture hybride qui combine la flexibilité d'un data lake et les capacités analytiques d'un data warehouse, sur une seule couche de stockage.Voir la définition complète →, un 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 →, une couche 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 → en self-serve. L'infrastructure est bien réelle. Mais livrer de l'infrastructure n'est pas la même chose que créer de la valeur, et un CDO qui confond les deux financera une plateforme qui sera construite, admirée en revue d'architecture, et abandonnée par les analystes et les product managers qu'elle devait servir.

De propriétaire d'infrastructure à propriétaire de produit

Le basculement essentiel porte sur qui définit le « terminé ». Quand vous détenez une infrastructure, terminé signifie que le système est debout, que le 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 → est respecté, que 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 → a tourné. Quand vous détenez un produit, terminé signifie qu'un client interne a accompli une tâche plus vite ou mieux qu'avant, et qu'il serait contrarié si vous lui retiriez l'outil.

Ce n'est pas un habillage sémantique du même métier. Cela change quatre choses concrètes dans la manière de piloter l'équipe plateforme.

Cela change ce que vous financez. Les roadmaps d'infrastructure sont organisées par composant : « migrer l'entrepôt », « mettre à niveau l'orchestration », « ajouter du streaming ». Les roadmaps produit sont organisées par tâche utilisateur : « permettre à un analyste marketing de construire un modèle d'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 → sans ouvrir de ticket », « permettre à un data scientist de passer une feature en production en une journée, pas en un sprint ». Chaque initiative technique doit se rattacher à une tâche nommée pour un segment d'utilisateurs nommé. Sinon, c'est un coût, pas un investissement.

Cela change qui vous recrutez. Les plateformes pilotées comme des produits ont des product managers, dont le travail est de parler aux utilisateurs internes, de prioriser sans complaisance et de dire non. L'absence d'un PM data platform est le prédicteur le plus fiable qu'une plateforme est pilotée comme une infrastructure. Les ingénieurs optimisent pour le cas général élégant ; les PM optimisent pour la tâche précise qui débloque les utilisateurs les plus précieux.

Cela change votre relation avec les consommateurs. Les propriétaires d'infrastructure traitent des tickets. Les propriétaires de produit font de la discovery. La différence se lit dans une question : quand une équipe demande un nouveau jeu de données, exécutez-vous la demande, ou demandez-vous quelle décision elle cherche à prendre ? La seconde question révèle régulièrement que le jeu de données demandé n'est pas la bonne solution, et qu'une métrique curatée ou un template self-serve servirait dix équipes au lieu d'une.

Cela change la façon dont vous vous mesurez, ce qui est le cœur de cette leçon.

Segmentez vos clients internes

Vous ne construiriez jamais un produit externe pour « tout le monde ». Ne construisez pas votre plateforme interne pour « le business ». Vos utilisateurs se regroupent en segments identifiables aux besoins très différents :

• Les data engineers et les builders proches de la plateforme, qui ont besoin de primitives, d'API et de contrôle.
• Les analystes et analytics engineers, qui ont besoin de tables curatées et fiables et d'une couche sémantique, pas de logs bruts.
• Les data scientists, qui ont besoin d'environnements reproductibles, d'accès aux features et d'un chemin rapide vers la production.
• Les power users métier (responsables ops, marketeurs, finance), qui ont besoin d'un self-serve gouverné, de dashboards et de métriques qu'ils peuvent découper sans SQL.
• Les dirigeants, qui consomment, et qui ont surtout besoin d'un chiffre auquel ils font confiance.

Chaque segment a sa propre définition d'une bonne journée. Servir les builders de la plateforme avec toujours plus de primitives tout en privant les power users métier d'un self-serve gouverné est une mauvaise allocation fréquente et coûteuse : cela ressemble à du travail technique de fond pendant que la plus large population d'utilisateurs churne vers les tableurs.

Mesurer l'adoption et la satisfaction, pas la production

Voici le recadrage rendu opérationnel. Arrêtez de rapporter des métriques de production d'infrastructure à vos pairs du comité de direction : tables ingérées, uptime, pétaoctets stockés. Ce sont des métriques de santé pour vos ingénieurs, pas des métriques de valeur pour le business. Rapportez un scorecard produit.

Les quatre familles de métriques

1. L'adoption. Qui utilise réellement la plateforme, et ces gens reviennent-ils ? Empruntez au SaaS la distinction entre utilisateurs enregistrés et utilisateurs actifs. Une équipe à qui l'on a ouvert les accès il y a six mois et qui n'a lancé aucune requête n'est pas un utilisateur. Suivez :

• Les utilisateurs actifs hebdomadaires et mensuels par segment.
• La largeur : pourcentage d'équipes éligibles qui ont été onboardées.
• La profondeur : utilisent-elles les capacités centrales ou un seul dashboard ?

2. La rétention et la stickiness. La métrique de plateforme la plus honnête est de savoir si les gens reviennent volontairement. Les courbes de rétention par cohorte, les analystes onboardés au T1 sont-ils encore actifs au T3 ?, révèlent si vous avez construit quelque chose de précieux ou simplement imposé un outil. Une plateforme qui ne survit que parce que son usage est obligatoire cache un problème de satisfaction.

3. Le time-to-value. Combien de temps s'écoule entre « une équipe veut répondre à une question » et « elle a une réponse fiable » ? C'est la métrique de débit centrale de votre plateforme. Deux sous-mesures comptent énormément :

• Le time-to-first-insight pour un nouvel utilisateur (friction d'onboarding).
• Le time-to-production pour un nouveau data product ou modèle (friction de livraison).

Si l'onboarding d'un nouvel analyste demande trois semaines de demandes d'accès et de configuration d'environnement, votre plafond d'adoption est fixé par cette friction, pas par vos capacités.

4. La satisfaction et la confiance. Mettez en place un NPS ou un CSAT interne sur la plateforme, segmenté par type d'utilisateur. Mais la métrique la plus révélatrice est la confiance : quand un chiffre apparaît sur votre plateforme, les consommateurs agissent-ils dessus, ou vont-ils le revérifier ailleurs ? La présence de pipelines fantômes et de tableurs de réconciliation est un signal de confiance direct et mesurable. Comptez-les.

Une synthèse utile est un unique Platform Product Scorecard trimestriel que vous présentez à côté du dashboard de santé de l'infrastructure :

Le recul de la rétention chez les data scientists dans cet exemple est le type de signal qu'un dashboard limité à la production ne ferait jamais remonter, et c'est exactement là qu'un CDO devrait orienter l'investissement du trimestre suivant.

Instrumentez la plateforme pour produire ces métriques

Vous ne pouvez pas rendre compte d'une adoption que vous ne mesurez pas. Traitez la télémétrie de la plateforme elle-même comme une exigence produit de premier rang, pas comme un après-coup. Loguez les événements d'usage comme une entreprise SaaS instrumente son application : chaque requête, chargement de dashboard, déploiement de modèle et accès à un jeu de données, rattaché à un utilisateur et à une équipe.

# Platform usage event schema — emitted on every meaningful interaction
event:
  user_id: analyst_4471
  team: growth-marketing
  segment: business_power_user
  action: dashboard_view      # query_run | model_deploy | dataset_access
  asset_id: attribution_v3
  latency_ms: 820
  success: true
  timestamp: 2024-11-04T14:22:00Z

Ce flux d'événements alimente votre rétention par cohorte, votre mesure du time-to-value et votre capacité à repérer un segment qui churne en silence. Il vous permet aussi de trouver vos power users et vos assets abandonnés, les jeux de données que personne n'a touchés depuis quatre-vingt-dix jours et que vous continuez de payer pour maintenir.

Piloter la plateforme comme une équipe produit

Des métriques sans rythme opérationnel ne sont que des dashboards. Le recadrage produit doit changer la façon dont l'équipe travaille concrètement, semaine après semaine.

Traitez les équipes internes comme des clients que vous pouvez perdre

La discipline la plus puissante est l'optionalité. Quand les équipes internes *peuvent* construire leur propre pipeline ou acheter une solution ponctuelle, votre plateforme doit mériter son usage. Certains CDO y résistent : ils rendent la plateforme obligatoire pour garantir l'adoption. Mais l'adoption imposée masque précisément le signal dont vous avez besoin. La posture la plus saine est celle-ci : la plateforme doit être si clairement meilleure que les équipes la choisissent. Là où vous imposez (généralement pour des raisons de gouvernance ou de conformité), reconnaissez que vous avez étouffé le signal de satisfaction et compensez en le mesurant directement par des entretiens et des métriques de confiance.

Priorisez avec une grille valeur / reach

Vous aurez toujours plus de demandes que de capacité. Priorisez en posant deux questions à chaque investissement candidat : combien d'utilisateurs, dans un segment à quelle valeur, cela débloque-t-il (reach), et quelle friction cela supprime-t-il (valeur) ? Une couche sémantique self-serve qui débloque 200 utilisateurs métier bat généralement un pipeline de streaming sur mesure pour une seule équipe à fort statut, même si le projet de streaming est techniquement plus intéressant. Le travail du PM est de protéger cette discipline contre l'attraction gravitationnelle du stakeholder interne le plus bruyant.

Publiez des SLA et un contrat, puis honorez-les

Les produits externes font des promesses. Le vôtre aussi devrait. Publiez des SLA de données (fraîcheur, disponibilité, seuils de qualité) par jeu de données critique, et traitez un manquement comme un incident avec un postmortem. C'est ce qui transforme la confiance d'un espoir en une évidence. Une équipe finance qui sait que la table de revenus est garantie fraîche à 6 h du matin avec un historique de fiabilité de 99,5 % arrêtera de construire son tableur de réconciliation. Ce tableur abandonné, c'est votre ROI.

Faites du dogfooding et de la discovery

Installez vos PM plateforme aux côtés des analystes une journée par mois. Regardez un nouvel arrivant s'onboarder et chronométrez-le. Les équipes qui font tourner d'excellentes plateformes internes connaissent les workflows de leurs utilisateurs dans leurs moindres détails : elles ont vécu l'attente de vingt minutes pour une requête et la confusion de trois métriques contradictoires. La discovery n'est pas un questionnaire ; c'est regarder du vrai travail se faire et trouver la friction.

Gouverner la plateforme sans tuer l'adoption

Le mode d'échec subtil pour un CDO à l'esprit produit est l'inverse du piège de l'infrastructure : suroptimiser pour l'adoption et la satisfaction en érodant la gouvernance. Une plateforme que tout le monde adore parce qu'elle laisse tout faire est un incident de conformité en attente.

La solution est de faire du chemin gouverné le chemin facile. La gouvernance doit être intégrée à l'expérience produit, pas rajoutée comme une barrière. Concrètement :

• Faites de l'option conforme l'option par défaut. Si le moyen le plus rapide d'obtenir une métrique certifiée passe par la couche sémantique, les gens utilisent la couche sémantique, et héritent automatiquement de son lineage et de ses contrôles d'accès. La friction dirige les comportements plus sûrement que la politique.
• Certifiez les assets de façon visible. Un badge « gold-certified » sur un jeu de données, avec un propriétaire nommé et un SLA publié, fait plus pour la confiance et l'adoption gouvernée qu'une note de gouvernance. Cela vous permet aussi de distinguer, dans votre télémétrie d'usage, les assets sanctionnés de la prolifération expérimentale.
• Utilisez la même télémétrie pour la gouvernance et le produit. Le flux d'événements qui vous montre l'adoption vous montre aussi les schémas d'accès, qui touche aux données sensibles, quels assets non certifiés gagnent une traction non autorisée. L'observabilité produit et l'observabilité de gouvernance sont le même instrument.

L'arbitrage qui revient au CDO est de calibrer le compromis par segment. Les data scientists ont besoin d'un sandbox permissif ; les power users métier ont besoin de garde-fous si serrés qu'ils ne peuvent pas publier par accident un chiffre erroné au CEO. Une gouvernance unique étrangle les builders ou met en danger les consommateurs. Segmentez votre gouvernance comme vous segmentez votre produit.

À retenir

1. Réorganisez la roadmap par tâche utilisateur, pas par composant. Chaque initiative technique doit se rattacher à une tâche nommée pour un segment interne nommé ; sinon, c'est un coût, pas un investissement. Recrutez un PM plateforme : son absence est le signe le plus sûr que vous pilotez une infrastructure, pas un produit.

1. Remplacez les métriques de production par un scorecard produit. Rapportez l'adoption, la rétention, le time-to-value et la confiance, segmentés par type d'utilisateur, à vos pairs du comité de direction. Gardez l'uptime et le débit comme métriques internes de santé technique, pas comme métriques de valeur.

1. Instrumentez l'usage de la plateforme comme une exigence de premier rang. Vous ne pouvez pas piloter une adoption que vous ne mesurez pas ; un flux de télémétrie par événement alimente la rétention par cohorte, le time-to-value et la détection précoce du churn, et sert en même temps d'observabilité de gouvernance.

1. Comptez les pipelines fantômes et les tableurs de réconciliation. Ils sont la mesure la plus honnête de la confiance dans la plateforme. Les éliminer, en publiant et en honorant des SLA par jeu de données, constitue un récit de ROI concret et défendable.

1. Faites du chemin gouverné le chemin facile, et segmentez la gouvernance par utilisateur. Intégrez la conformité dans l'expérience produit par défaut, donnez aux builders un sandbox permissif et aux consommateurs des garde-fous serrés, et utilisez un seul flux de télémétrie pour les décisions produit comme de gouvernance.