Au cours de la dernière décennie, les catalogues de données ont émergé en tant que piliers dans l’écosystème data. Cependant, de nombreux fournisseurs ne répondent pas aux attentes – avec en cause des délais prolongés, des projets complexes et coûteux, des modèles bureaucratiques de gouvernance des données, des taux d’adoption faibles et une création de valeur limitée. Cette problématique va au-delà des projets de gestion des métadonnées, reflétant un échec plus général au niveau de la gestion des données.
Face à ces lacunes, un nouveau concept a le vent en poupe, celui de place de
marché interne à l’organisation, que nous appelons Enterprise Data Marketplace (EDM) chez Zeenea.
Dans cette série d’articles, vous trouverez des extraits de notre Guide Pratique du Data Mesh dans lequel nous expliquons l’intérêt des data marketplaces internes pour la production et la consommation de data products, comment une EDM prend en charge l’exploitation du data mesh à l’échelle, et comment elles vont de pair avec une solution de catalogue de données :
- Faciliter la consommation des data products avec les métadonnées
- Déployer une marketplace à l’échelle de l’entreprise
- Alimenter la marketplace via des data catalogs par domaine
—
Avant d’aborder le concept de data marketplace interne, revenons un instant sur la notion de data product, qui selon nous constitue la pierre angulaire du data mesh, et la première étape de la transformation du data management.
Partage et exploitation des data products grâce aux métadonnées
Comme mentionné dans notre précédente série d’articles sur le data mesh, un data product est un jeu de données gouverné, réutilisable, évolutif, et offrant des garanties en matière de qualité de données et de conformité aux différentes réglementations et règles internes. Notons que cette définition est assez restrictive – elle exclut d’autres types de produits tels que les algorithmes ou modèles de machine learning (ML), ou encore les tableaux de bord.
Il est bien sûr souhaitable que ces artefacts soient également gérés comme des produits, mais ce ne sont pas des data products. Ce sont d’autres types de produits, que l’on pourrait qualifier de façon très générale d’Analytics Products, et dont les data products sont l’une des sous-catégories.
En pratique, un data product opérationnel est constitué de deux choses :
-
1. Les données - matérialisées sur une plateforme data centralisée ou non, et garantissant l’adressage, l’interopérabilité et la sécurisation de l’accès aux données. -
2. Les métadonnées - qui fournissent l’ensemble des informations nécessaires pour partager et exploiter les données.
Les métadonnées permettent d’assurer que les consommateurs disposent de toutes les informations nécessaires pour utiliser le produit.
Elle couvrent typiquement les aspects suivants :
Le schéma – qui fournit la structure technique du data product, la classification des données, des échantillons, ainsi que leur origine (lignage).
La gouvernance – qui identifie le ou les responsables du produit, ses versions successives, son éventuelle dépréciation, etc.
La sémantique – qui fournit une définition claire des informations exposées, idéalement rattachée au glossaire métier de l’organisation, et une documentation exhaustive du data product.
Le contrat – qui définit les garanties en matière de qualité, les modalités de consommation (protocoles et sécurité), les éventuelles restrictions d’usage, les règles de redistribution, etc.
Dans la logique du data mesh, ces métadonnées sont gérées par l’équipe produit, et déployées selon le même cycle de vie que les données et les pipelines. Reste une question fondamentale : où déployer les métadonnées ?
Utilisation d’une data marketplace pour déployer les métadonnées
La plupart des organisations disposent déjà d’un système de gestion des métadonnées, généralement sous la forme d’un Data Catalog.
Mais les Data Catalogs, sous leur forme actuelle, présentent des inconvénients majeurs :
Ils ne supportent pas toujours la notion de data product – elle doit être plus ou moins émulée avec d’autres notions.
Ils sont complexes à utiliser – ils ont été conçus pour cataloguer un grand nombre d’assets avec une granularité parfois très fine, et souffrent très souvent d’un déficit d’adoption au-delà des équipes de data management centralisées.
Ils imposent le plus souvent une organisation rigide et unique des données, décidée et conçue en central – cela peine à refléter la variété des différents domaines ou les évolutions de l’organisation à mesure que le data mesh s’étend.
Leurs capacités de recherche sont souvent limitées, particulièrement pour les aspects exploratoires – il est souvent nécessaire de savoir ce que l’on cherche pour pouvoir le trouver.
L’expérience qu’ils proposent manque parfois de la simplicité à laquelle les utilisateurs aspirent – je recherche avec quelques mots-clés, j’identifie le data product adéquat, puis je déclenche le processus opérationnel de demande d’accès ou de livraison des données.
Dans notre prochain article, découvrez les différentes façons de mettre en place une data marketplace interne, et pourquoi elles sont essentielles pour l’exploitation du data mesh.
Le Guide Pratique du Data Mesh: Mettre en place et superviser un data mesh à l’échelle de l’entreprise
Rédigé par Guillaume Bodet, co-fondateur et CPTO chez Zeenea, ce guide vous apportera une approche pratique pour mettre en œuvre un data mesh dans votre organisation, en vous aidant à :
✅ Entamer votre démarche data mesh avec un projet pilote focalisé
✅ Découvrir des méthodes efficaces pour mettre votre mesh à l’échelle,
✅ Comprendre le rôle essentiel joué par une data marketplace interne pour faciliter la consommation des data products
✅ Découvrir pourquoi Zeenea est un système de supervision robuste du data mesh à l’échelle de l’entreprise
