Data Product ou simple dataset : la différence qui change tout
Un dataset est un fichier que quelqu'un produit. Un data product est un service que quelqu'un possède, avec un contrat, une qualité mesurée et des consommateurs identifiés. La nuance paraît sémantique. Elle détermine si vos données survivent au départ de leur producteur.
Dans la plupart des organisations, la donnée circule sous forme de fichiers, d'extractions et de tables partagées. Cela fonctionne — jusqu'au jour où la personne qui produisait l'extraction change de poste. Le flux s'arrête, personne ne sait comment le relancer, et l'équipe qui consommait la donnée découvre qu'elle n'a jamais eu de garantie.
Le concept de data product répond à ce problème précis. Pas en ajoutant un outil, mais en changeant la nature de ce qui est livré : non plus un fichier, mais un service avec un propriétaire, un contrat et une qualité mesurable.
Les quatre différences concrètes
1. Un propriétaire nommé
Un dataset a un producteur. Un data product a un propriétaire, avec un rôle identifié et une responsabilité dans la durée. La différence se voit le jour où quelque chose casse : dans le premier cas, on cherche ; dans le second, on sait qui appeler.
2. Un contrat explicite
Le contrat décrit le schéma, la sémantique, la fraîcheur, les règles de qualité et les conditions d'usage. Il n'est pas un document de plus : c'est ce qui permet à un consommateur de savoir, sans demander, ce qu'il peut attendre.
3. Une qualité mesurée
Un data product publie ses indicateurs : complétude, fraîcheur, cohérence, taux d'erreur. Ces indicateurs sont visibles par les consommateurs. C'est ce qui distingue une promesse d'une preuve.
4. Des consommateurs identifiés
Un produit sans consommateur n'est pas un produit. Connaître les usages permet de prioriser, de dimensionner et de décider ce qui doit être maintenu.
« Si la personne qui produit cette donnée part demain, que se passe-t-il ? » Si la réponse est « on ne sait pas », ce n'est pas un data product. C'est une dépendance personnelle déguisée en flux de données.
Pourquoi les organisations échouent souvent
Le passage au data product échoue rarement pour des raisons techniques. Il échoue parce qu'il exige un changement de responsabilité : quelqu'un doit être propriétaire d'un produit qui n'est pas son cœur de métier, avec des engagements de qualité qu'il ne contrôle pas entièrement.
Sans mandat clair, le propriétaire désigné reste un propriétaire de façade. Le contrat existe, mais personne ne le fait vivre. Les indicateurs sont publiés, mais personne ne les regarde.
Trois conditions de réussite
- Un périmètre restreint au départ : commencer par les données qui ont un consommateur identifié et un usage critique.
- Un contrat minimal mais réel : schéma, fraîcheur, propriétaire, contact. Pas besoin de tout décrire pour commencer.
- Une revue périodique : les contrats se revoient, les consommateurs changent, les produits évoluent ou disparaissent.
« Une donnée sans propriétaire n'est pas un actif. C'est un espoir. »
Ce qu'il faut retenir
Le data product n'est pas un niveau de maturité technique. C'est un engagement organisationnel : quelqu'un répond de quelque chose, devant quelqu'un, avec des critères mesurables. Les entreprises qui l'ont compris obtiennent des résultats durables ; les autres ajoutent un catalogue à leur existant sans changer la nature de ce qu'elles livrent.
Retour aux articles