Data products : définition, design et gestion du cycle de vie
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 → n'est pas un dashboard. Ce n'est pas un rapport. Ce n'est pas un dataset brut.
Un data product est un dataset curaté, managé et gouverné, traité avec la même rigueur qu'un produit logiciel : il a un propriétaire, un SLA, de la documentation, du versioning et des garanties de qualité.
Cette distinction compte parce qu'elle change fondamentalement l'économie de la donnée. Les datasets bruts sont des actifs internes qui disparaissent quand l'ingénieur qui les a construits s'en va. Les data products sont des actifs organisationnels qui persistent, passent à l'échelle et accumulent de la valeur.
Ce qui fait un data product
Un data product a cinq caractéristiques déterminantes :
1. Une ownership claire, une personne ou une équipe nommée est responsable de la qualité, de la disponibilité et de l'évolution de ce data product. Pas « la data team » en général.
2. Des consommateurs définis, le data product sait qui l'utilise et pourquoi. Ce sont les besoins des consommateurs qui pilotent la roadmap produit, pas la commodité interne.
3. Un SLA de qualité, une fraîcheur engagée (données mises à jour en moins de X minutes), une complétude (Y % de valeurs non nulles sur les champs critiques) et une validité (Z % des enregistrements passent les règles métier).
4. Documentation et discoverability, les consommateurs peuvent trouver le produit, comprendre son 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 faire confiance à ses définitions sans avoir à solliciter le propriétaire.
5. Versioning et garanties de stabilité, les breaking changes suivent un processus de dépréciation. Les consommateurs ne découvrent pas les changements de schéma par surprise.
Data Products: From Theory to Practice
Vérification des acquis
1. D'après la leçon, qu'est-ce qui distingue fondamentalement un data product d'un dataset brut ?
2. Pourquoi traiter la donnée comme un produit plutôt que comme un dataset brut compte-t-il sur le plan économique ?
3. En quoi le rôle de Data Product Manager (DPM) diffère-t-il de celui d'un analyste BI et d'un data engineer ?
4. Sélectionnez TOUTES les caractéristiques qui définissent un data product selon la leçon.
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les affirmations qui reflètent correctement le principe des « consommateurs définis » et les bonnes pratiques des data products.
Sélectionnez toutes les réponses correctes.
Le rôle de data product manager
Construire des data products à l'échelle demande un nouveau rôle : le Data Product Manager (DPM). Ce rôle se situe à l'intersection de l'expertise métier, de la compréhension technique et de la discipline du product management.
Un DPM sur le domaine client serait propriétaire de : le data product customer 360, le feature store de prédiction de churn et le stream d'événements clients. Il travaille avec les data engineers pour construire et maintenir ces produits, avec les parties prenantes métier pour comprendre les besoins, et avec les équipes de gouvernance pour assurer la conformité.
C'est distinct d'un analyste 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 → traditionnel (qui consomme les data products) et d'un data engineer (qui construit l'infrastructure). Le DPM est propriétaire du cycle de vie du produit.
Airbnb a été pionnier de ce modèle. Leurs « data product managers » sont propriétaires de domaines de données spécifiques et responsables de la qualité des data products produits par ces domaines. Résultat : une responsabilité plus claire, une livraison plus rapide et une meilleure qualité.
Patterns de design des data products
Le Domain Event Stream, un flux temps réel de tout ce qui se passe dans un domaine. Exemple : tous les événements de checkout avec un schéma standard. Les consommateurs construisent leurs vues spécifiques à partir de ce stream.
L'Aggregate Entity, une vue curatée d'une entité métier centrale. Exemple : le « customer 360 » qui agrège les données comportementales, transactionnelles et démographiques de chaque client. Forte valeur, forte maintenance.
Le Feature Dataset, des features ML précalculées et servies aux modèles en temps réel ou en batch. Exemple : les « features de probabilité d'achat client » calculées quotidiennement et servies au modèle de recommandation. Géré par l'équipe ML platform.
Le Metric Dataset, des métriques métier standardisées et validées. Revenue, DAU, taux de conversiontaux de conversionLe 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 → : définis une fois, calculés de manière cohérente, utilisés partout. Cela élimine le problème du « pourquoi les dashboards finance et marketing affichent-ils des chiffres de revenue différents ? ».
Mesurer la qualité d'un data product
La qualité d'un data product n'est pas subjective. Définissez-la avec des 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 → mesurables :
- Freshness : les données sont mises à jour dans les X minutes/heures suivant l'événement source
- Completeness : < Y % de valeurs nulles sur les champs obligatoires
- Accuracy : règles métier validées par des tests automatisés
- Uptime : produit disponible Z % du temps
- Stabilité du schéma : aucun breaking change sans préavis de 14 jours
Publiez ces SLA. Suivez-les. Alertez en cas de violation. Communiquez-les aux consommateurs de données. C'est du product management appliqué à la donnée.
Quiz Questions
- Quelle est la principale différence entre un data product et un dataset brut ?
A) Le data product est stocké dans un système différent
B) Le data product a un propriétaire, un SLA de qualité, de la documentation et un versioning, traité comme un produit logiciel
C) Le data product est uniquement pour les données en temps réel
D) Le data product est plus facile à maintenir
Réponse: B
- Quel est le rôle du Data Product Manager (DPM) ?
A) Il remplace le data engineer
B) Il consomme les data products pour cré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 → des dashboards
C) Il possède le cycle de vie du data product, entre expertise domaine, technique et management produit
D) Il gère la sécurité des données
Réponse: C
- Quelle métrique de qualité mesure si les données sont mises à jour suffisamment rapidement ?
A) Completeness
B) Accuracy
C) Freshness
D) Uptime
Réponse: C
À faire, tiré de cette leçon
Ces actions sont compilées dans le plan d'action du rôle.
- Gérer les datasets critiques comme des data products, avec owners, SLA et versioning
Articles liés
Les articles récents du blog qui s'appuient sur cette leçon.
- DataFivetran et dbt Labs ont redessiné l'infrastructure data pour les agents : est-ce que votre pile est prête ?Au dbt Summit 2026, Fivetran et dbt Labs ont annoncé un ensemble de capacités dont l'objectif déclaré est de rendre les données d'entreprise consommables par des agents IA, et non plus seulement par des humains. Ce débrief examine ce qui a réellement été annoncé, ce que cela implique pour un CDO, et le signal que la plupart des équipes sont en train de rater.
- DataComment JPMorgan Chase a structuré ses contrats de données pour gouverner 50 domaines métiersJPMorgan Chase a déployé un cadre de contrats de données inter-domaines pour résoudre des conflits de propriété qui paralysaient ses équipes analytiques. Ce que la banque a construit, ce que ça a produit, et ce qu'un CDO peut en tirer concrètement.
- DataFeature stores et chaîne d'approvisionnement ML : le playbook du CDOSans architecture de feature store, chaque équipe ML réinvente ses propres pipelines de données, accumule de la dette technique et déploie des modèles qui dérivent en silence. Ce playbook détaille les étapes concrètes pour structurer une chaîne d'approvisionnement ML fiable, du catalogue de features jusqu'à la gouvernance en production.