Data product

Résumé

Un data product (produit de données) est un jeu de données publié pour des consommateurs comme on publie un service : il a un propriétaire nommé, une interface stable, des engagements mesurables et un cycle de vie. Un jeu de données avec un propriétaire n’est pas encore un produit. Le data mesh est l’approche d’ensemble (organisation, plateforme, gouvernance) dans laquelle le produit de données est l’unité de base. Les deux ne sont pas synonymes : le mesh sans produits réels est un ensemble de silos décentralisés ; des produits peuvent exister sans mesh.

Prérequis

Data mesh pour le contexte.

Définition

Dehghani fait du produit de données le quantum architectural du mesh, c’est-à-dire la plus petite unité qu’on peut déployer seule tout en restant cohérente. Cette unité regroupe trois éléments :¹

• le code : pipelines, interfaces d’accès, et application des règles de sécurité et de conformité ;
• les données et leurs métadonnées, servies sous la forme qui convient aux consommateurs (événements, fichiers, tables) ;
• l’infrastructure qui les fait tourner.

Les qualités attendues

L’article de 2019 résume ce qui distingue un produit d’un simple jeu de données en six qualités :²

Qualité	En pratique
Découvrable	On le trouve sans demander à quelqu’un
Adressable	Il a un emplacement stable et unique
Fiable	Le propriétaire s’engage sur sa véracité (SLO), teste à la source et documente provenance et lineage
Auto-descriptif	Sa sémantique et sa syntaxe sont documentées
Interopérable	Il respecte des standards communs pour se combiner avec d’autres produits
Sécurisé	L’accès est contrôlé selon une politique globale

Un même domaine peut publier plusieurs produits de niveaux de service différents : l’article cite des événements de lecture proposés en version quasi temps réel, moins exacte, et en version plus tardive et plus exacte, avec des SLO propres à chacune.²

Le rôle de propriétaire de produit

Le data product owner porte la vision et la feuille de route du produit, répond de la satisfaction des consommateurs et de la qualité, et décide quand modifier ou retirer des données et des schémas. Ses indicateurs sont alignés sur le métier : le délai pour qu’un consommateur découvre et utilise le produit en est un. Il travaille avec des data engineers au sein de l’équipe du domaine.²

Un service, pas un jeu de tables

Le modèle de Dehghani attend d’un produit de données ce qu’on attend d’un service : un propriétaire qui décide de son évolution et de son retrait, des objectifs de niveau de service (SLO) sur la véracité, une documentation qui évite d’accompagner chaque consommateur, et un accès contrôlé.² Concrètement, cela se traduit par :

• un propriétaire nommé ;
• un contrat : Data contract et ODCS ;
• des SLO mesurés (fraîcheur, qualité) ;
• un cycle de vie : accueil des consommateurs, versionnement, gestion des incidents, dépréciation.

Le contrat, partie du produit

Un contrat de données écrit ce que le producteur promet : schéma, responsable, niveaux de service. Il joue pour les données le rôle d’une API pour un logiciel.³ Deux conséquences pratiques pour un produit :

• le propriétaire est attaché au contrat (donc au produit), pas seulement à une équipe, de façon que la responsabilité survive aux réorganisations ;
• le contrat est versionné avec le code du produit et vérifié à chaque changement, sinon il dérive.

Détail et exemple dans Data contract et ODCS.

Data mesh ou data product ?

	Data mesh	Data product
Nature	Modèle d’organisation et d’architecture	Unité livrable
Échelle	Toute l’organisation : plusieurs domaines, une plateforme, une gouvernance	Un jeu de données et son interface
Répond à	« Comment répartir la responsabilité de la donnée ? »	« Qu’est-ce qu’un consommateur peut attendre de ce jeu de données ? »
Principes	Quatre : domaines, produit, plateforme, gouvernance	Qualités : découvrable, adressable, fiable, auto-descriptif, interopérable, sécurisé
Porté par	Direction, plateforme, instance de gouvernance	Un propriétaire de produit et son équipe
Réussite mesurée	Interopérabilité et valeur pour les consommateurs	Usage, respect des SLO, incidents côté consommateurs
Standard de description	Aucun unique	ODPS, voir Data product, définitions et points de vue

flowchart TB
    M["Data mesh<br/>modèle d'ensemble"] --> P1["Principe : propriété par domaine"]
    M --> P2["Principe : la donnée comme produit"]
    M --> P3["Principe : plateforme en libre-service"]
    M --> P4["Principe : gouvernance fédérée"]
    P2 --> DP["Data product<br/>code + données + métadonnées + infrastructure"]
    DP --> C["Contrat<br/>ODCS"]

Mesh et produits : quatre combinaisons

	Avec de vrais produits	Sans vrais produits
Avec mesh	Le modèle visé	Propriété de façade : des tables par domaine, sans engagement. La décentralisation produit alors des silos incohérents
Sans mesh	Une équipe centrale peut publier des produits avec propriétaire, contrat et SLO. C’est de la discipline produit, sans la décentralisation	Un lac ou un entrepôt classique

La case « sans mesh, avec produits » est une lecture qui n’apparaît pas telle quelle dans les sources : elles présentent le produit comme l’un des principes du mesh, sans le traiter isolément.

Définitions, points de vue et standard

La notion a plusieurs définitions, des jalons de 2012 à 2025 et des positions de praticiens différentes. Elles sont réunies, avec la description du standard ODPS, dans Data product, définitions et points de vue.

Mesurer la valeur

Compter les produits créés mesure l’activité, pas la valeur. On regarde qui consomme réellement le produit et quels produits ne sont plus utilisés.

Est-ce un produit ?

Liste de contrôle

• Un nom de propriétaire est écrit à un endroit que les consommateurs peuvent trouver.
• Il existe un contrat écrit : schéma, qualité, SLA.
• Les SLO sont mesurés et leur respect est visible.
• Les consommateurs savent où demander de l’aide, et quand un changement va les casser.
• On sait qui l’utilise, et on peut le retirer proprement.

Si l’une de ces cases manque, c’est un jeu de données, pas encore un produit.

Notes liées

• Data mesh : le modèle d’ensemble.
• Data contract et ODCS : l’engagement écrit.
• Choisir entre lake, lakehouse et warehouse : la couche technique sous-jacente.
• Glossaire data engineering : data product, SLO, domaine.
• MOC Data Engineering : carte du vault.

Notes de bas de page

1. Zhamak Dehghani, Data Mesh Principles and Logical Architecture, 2020, consulté le 24 octobre 2026. ↩

2. Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh, 2019, consulté le 24 octobre 2026. ↩ ↩² ↩³ ↩⁴

3. Foundational, Data Contracts: Implementation and Best Practices Guide, billet d’éditeur non daté, consulté le 24 octobre 2026, source secondaire à visée commerciale. ↩