Qu'est-ce que le Data as a Product ?

Le Data as a Product est un principe d'architecture et d'organisation qui applique les methodes du Product Management aux donnees d'entreprise. Plutot que de considerer les donnees comme un sous-produit des systemes operationnels, cette approche les traite comme des produits autonomes, concus pour repondre aux besoins de consommateurs identifies.

Origine et lien avec le Data Mesh

Le concept a ete formalise par Zhamak Dehghani en 2019 dans le cadre du Data Mesh, dont il constitue l'un des quatre piliers fondateurs (aux cotes du Data Ownership par domaine, de la Self-Serve Data Platform et de la Federated Computational Governance). Mais le principe depasse le Data Mesh : toute organisation peut adopter une approche "data as a product" sans implementer l'ensemble du paradigme.

Les proprietes d'un Data Product

Un Data Product de qualite respecte plusieurs proprietes, souvent resumees par l'acronyme DATSIS :

• Decouvrable : les consommateurs potentiels peuvent trouver le produit via un catalogue de donnees, avec une documentation claire sur son contenu, sa fraicheur et ses limites.
• Accessible : l'acces se fait via des interfaces standardisees (API, SQL, fichiers partages) sans necessiter l'intervention de l'equipe productrice.
• Fiable (Trustworthy) : des mecanismes de qualite garantissent l'exactitude, la completude et la coherence des donnees. Des SLA (Service Level Agreements) definissent les engagements de disponibilite et de fraicheur.
• Semantiquement claire : les donnees sont documentees avec des definitions metier non ambigues, des schemas versionnes et des exemples d'utilisation.
• Interoperable : le produit suit des conventions globales (nommage, formats, fuseaux horaires) qui permettent de le combiner avec d'autres Data Products sans friction.
• Securisee : les politiques d'acces et de confidentialite sont integrees au produit, conformement aux regles de Data Governance de l'organisation.

Le Data Quantum : l'unite architecturale

Chaque Data Product s'incarne dans une unite logique appelee Data Quantum, qui encapsule l'ensemble des composants necessaires a son fonctionnement autonome : les donnees elles-memes, les metadonnees, le code de transformation, les politiques d'acces et l'infrastructure sous-jacente. Cette encapsulation garantit que le produit peut etre deploye, mis a jour et opere independamment.

Comment ca fonctionne en pratique

Concretement, construire un Data Product implique de definir :

1. Un responsable produit : souvent un Data Product Manager ou un Data Steward du domaine metier, qui priorise les evolutions en fonction des besoins des consommateurs.

2. Un contrat de donnees : un Data Contract qui formalise le schema, les SLA de qualite et les regles d'acces. Ce contrat sert d'interface entre producteurs et consommateurs.

3. Une infrastructure en self-service : hebergee sur une Data Platform qui fournit les briques de stockage, de transformation et de distribution sans que chaque equipe doive reinventer la roue.

4. Des metriques d'usage : comme pour un produit logiciel, on mesure l'adoption (nombre de consommateurs), la satisfaction et la qualite percue.

Pourquoi c'est important

L'approche Data as a Product resout un probleme recurrent : les donnees existent mais personne ne les utilise parce qu'elles sont mal documentees, difficiles d'acces ou de qualite incertaine. En appliquant les reflexes du Product Management (comprendre les utilisateurs, iterer, mesurer), les equipes produisent des donnees reellement exploitees.

Les organisations qui adoptent cette approche constatent generalement une reduction du temps de decouverte et d'acces aux donnees, une meilleure confiance dans les analyses et une diminution des pipelines de donnees "shadow" construits en contournant les systemes officiels.

Cas d'usage concrets

• Equipe Finance qui publie un Data Product "Revenue par produit" avec un SLA de fraicheur J+1, consomme par les equipes Marketing, Direction et Data Analysts.
• Equipe RH qui expose un Data Product "Effectifs et competences" avec des regles d'acces differenciees selon le niveau hierarchique du consommateur.
• Equipe Produit qui maintient un Data Product "Evenements utilisateur" alimente en temps reel, consomme par les equipes Data Science pour la modelisation et par les Analytics Engineers pour le reporting.