Data product
Aussi : Data product, Data-as-a-product, DaaP, Produit de donnees, Produit data
Un actif de données géré comme un produit : un owner, des utilisateurs identifiés, une qualité garantie et une valeur business mesurable.
De quoi il s'agit
Un data product est un actif de données réutilisable, conçu, livré et maintenu comme un véritable produit, et non comme un rapport ponctuel ou un extract ad hoc. Il a un owner responsable, un ensemble connu de consommateurs, un contrat de qualité explicite et un lien clair avec la valeur business.
Contrairement à une table brute posée dans un warehouse, un data product est packagé pour être consommé. Il regroupe en général :
- Les données elles-mêmes (un dataset curé, une métrique, un ensemble de features ou une API).
- Les métadonnées et la documentation (schéma, définitions, lineage, ownership).
- Des garanties de service (fraîcheur, complétude, exactitude, disponibilité).
- Les accès et interfaces (table SQL, endpoint d'API, dashboard ou flux).
Pourquoi c'est important
La plupart des organisations croulent sous des datasets que personne ne trouve ni ne juge fiables. Traiter la donnée comme un produit remet les incitations à l'endroit :
- Responsabilité : quelqu'un répond de la justesse et de l'utilité de la donnée.
- Confiance : les consommateurs disposent d'une qualité documentée et garantie au lieu de deviner.
- Réutilisation : un produit bien construit sert plusieurs équipes et réduit les pipelines dupliqués.
- Suivi de la valeur : l'usage et les résultats sont mesurés, ce qui permet de retirer les produits à faible valeur.
Cette logique est au fondement d'approches modernes comme le data mesh, où les équipes domaine possèdent et publient leurs propres data products.
Comment on l'utilise en pratique
Construire et exploiter un data product suppose en général :
1. Définir le consommateur et le cas d'usage. Qui en a besoin, et pour décider quoi ?
2. Désigner un owner. Un product owner (souvent dans un domaine métier) en est responsable.
3. Fixer un data contract. Se mettre d'accord sur le schéma, la fraîcheur et les seuils de qualité (un service level agreement, ou SLA).
4. Construire et publier. L'exposer via une interface stable, documentée dans un catalogue.
5. Suivre et itérer. Mesurer l'usage, la qualité et la valeur ; versionner les changements avec soin.
Un exemple concret
Un distributeur crée un data product « Customer 360 ».
- Owner : le responsable du domaine Customer Analytics.
- Consommateurs : le marketing (segmentation), la finance (lifetime value) et une équipe IA (features du modèle de churn).
- Contrat : rafraîchi chaque jour avant 6 h, taux de rapprochement d'identité de 99 %, champs conformes au RGPD uniquement.
- Interface : une table gouvernée plus une API documentée.
- Valeur : mesurée par le lift des campagnes, la précision des modèles et les heures économisées par rapport à la reconstruction des jointures à chaque fois.
Parce que c'est un produit, l'équipe marketing n'assemble plus des tableurs, l'équipe IA obtient des features stables et la finance utilise les mêmes définitions client que tout le monde. Quand le schéma doit évoluer, l'owner le versionne et prévient les consommateurs au lieu de casser silencieusement les traitements en aval.
Questions fréquentes
Qu'est-ce qu'un data product ?
Un data product est un actif de données réutilisable géré comme un vrai produit, et non comme un rapport ponctuel : il a un owner responsable, des consommateurs identifiés, un contrat de qualité explicite et un lien mesurable avec la valeur métier. Concrètement, il réunit la donnée elle-même (dataset, métrique, feature set ou API), ses métadonnées et sa documentation, des garanties de fraîcheur et d'exactitude, et une interface d'accès stable.
Quelle différence entre un data product et une table dans le warehouse ?
Une table brute est stockée ; un data product est packagé pour être consommé. La table existe sans owner désigné, sans engagement de qualité ni consommateurs connus, donc personne ne sait s'il faut lui faire confiance. Le data product ajoute un propriétaire, un schéma documenté avec sa lineage, un SLA sur la fraîcheur et la complétude, et une interface stable : c'est ce qui le rend réutilisable par plusieurs équipes.
Pourquoi un CMO ou un CFO devrait s'intéresser aux data products, et pas seulement l'équipe data ?
Parce que l'owner d'un data product siège généralement dans un domaine métier, pas à la DSI, et que les consommateurs sont le marketing, la finance et les équipes IA. Un produit « Customer 360 » partagé fait que la segmentation marketing, le calcul de lifetime value en finance et le modèle de churn s'appuient sur les mêmes définitions client, au lieu de trois fichiers divergents. La valeur se mesure d'ailleurs en termes métier : lift des campagnes, précision des modèles, heures économisées.
Que contient un data contract ?
Un data contract fixe ce sur quoi les consommateurs peuvent compter : le schéma, la fréquence de rafraîchissement et des seuils de qualité formulés en SLA. Pour un produit « Customer 360 », cela peut être un rafraîchissement quotidien avant 6 h, un taux d'appariement d'identité de 99 % et uniquement des champs conformes au RGPD. L'intérêt : toute évolution de ces termes est versionnée et annoncée aux consommateurs, plutôt que de casser silencieusement les usages en aval.
Par quoi commencer pour créer un premier data product ?
Commencez par le consommateur et la décision, pas par le pipeline : qui a besoin de cette donnée, et pour décider quoi ? Désignez ensuite un owner responsable, formalisez le data contract sur le schéma, la fraîcheur et la qualité, publiez via une interface stable documentée dans un catalogue, puis suivez usage, qualité et valeur pour pouvoir retirer les produits qui n'en créent pas. Sauter la première étape, c'est produire des jeux de données que personne n'utilise.