Ressources
Du catalogue de données à la marketplace de données
Les catalogues de données traditionnels ont longtemps été la solution de référence pour gérer les actifs de données. Leur efficacité se heurte pourtant à deux limites : la surindexation, et l'absence de sémantique et de garanties de qualité. Les architectures de données modernes reposent sur des produits de données dotés d'une propriété claire, de Data Contracts bien définis et d'une réelle attention aux besoins des Data Consumers. Ces produits sont réunis dans une marketplace de données d'entreprise pour partager des données maîtrisées avec d'autres équipes ou organisations.
Les catalogues de données : indexer les actifs de données
Un catalogue de données vise à dresser l'inventaire complet des actifs de données d'une organisation, pour répondre à des questions comme :
- Quelles données sont disponibles ?
- Où sont-elles stockées ?
- Quel est leur schéma ?
- Quelles sont leurs caractéristiques statistiques ?
- Quel est leur data lineage ?
- Comment sont-elles utilisées ?
Historiquement, les méta-catalogues étaient indispensables dans les architectures orientées data lake : ils décrivaient la structure des données contenues dans les fichiers stockés pour les rendre désérialisables et interrogeables de façon structurée (Hive Metastore, Project Nessie, Unity Catalog, etc.).
Au fil du temps, ces solutions se sont enrichies de fonctions de découverte et de gouvernance pour devenir des catalogues de données. Aujourd'hui, toutes les grandes plateformes de données proposent le leur (AWS Glue Catalog, Google Dataplex Catalog, Microsoft Azure Purview, Databricks Unity Catalog), tout comme de nombreux éditeurs tiers (Alation, Atlan, Collibra, Informatica, etc.).
Pourquoi les catalogues de données peinent à créer de la valeur
Dans beaucoup d'organisations, le catalogue de données est sous-utilisé malgré les investissements considérables consacrés à sa mise en place et à sa maintenance. À première vue, l'idée d'un référentiel centralisé indexant tous les actifs de données semble incontournable dans un monde piloté par la donnée. Sur le terrain, nous constatons pourtant l'inverse. La raison principale tient à ce que nous appelons la surindexation des actifs, doublée d'un manque d'informations sémantiques et actionnables dans ces catalogues.
Surindexation : un déluge de données sans intérêt
Les catalogues de données disposent de connecteurs pour toutes les grandes sources : bases de données, data lakes, entrepôts de données, outils de BI et pipelines. Quand chaque source est indexée automatiquement et intégralement, le catalogue capte certes les données métier à forte valeur, mais aussi toutes les tables intermédiaires, les tables brutes et les jeux de données obsolètes, sans intérêt pour la plupart des Data Consumers. Les équipes se retrouvent à fouiller un océan de jeux de données souvent incomplets, périmés ou hors sujet pour leur besoin, d'autant plus quand la sémantique et le contexte métier restent flous. La quasi-totalité de ces actifs indexés automatiquement n'est pas documentée. Cette surindexation provoque une surcharge informationnelle : impossible de repérer les actifs réellement utiles et dignes de confiance.
Un catalogue de données atteint vite plusieurs millions de tables, vues, fichiers, topics, tableaux de bord, rapports et autres objets indexés.
L'effet spectateur
L'effet spectateur est un phénomène de psychologie sociale : en présence d'autres personnes, un individu est moins enclin à intervenir ou à porter secours. La présence des autres dilue le sentiment de responsabilité et chacun suppose que quelqu'un d'autre agira, ou que son action n'est pas nécessaire. Dans un catalogue de données comptant des millions d'actifs indexés mais non documentés, l'effet spectateur se traduit par une réticence générale à prendre en charge la documentation ou l'amélioration du catalogue. Face à des millions d'actifs, chacun se dit qu'une autre équipe, un autre service ou un collègue est mieux placé, ou plus légitime, pour documenter telle ou telle métadonnée. L'ampleur du problème donne le sentiment qu'une contribution individuelle passera inaperçue ou ne changera rien, ce qui réduit d'autant la motivation. Documenter les actifs apparaît alors comme une tâche ingrate ou secondaire.
Les catalogues permettent bien sûr d'ajouter documentation et tags pour enrichir les métadonnées, et les Data Stewards encouragent les équipes à le faire. Mais personne ne veut être le premier, et le seul, à faire le ménage. Passer du temps à documenter et à nettoyer les données est frustrant quand l'immense majorité des actifs reste non documentée et de faible qualité.
Trop de détails techniques, trop loin du métier
Autre problème de fond : la focalisation sur les métadonnées techniques. Les informations sur la structure des schémas, le type des champs ou le data lineage rendent service aux ingénieurs, mais elles ne répondent guère aux attentes des utilisateurs métier, qui ont besoin de clarté sémantique et de garanties de qualité.
La plupart des catalogues de données ne parviennent ni à capturer ni à transmettre ces aspects pourtant décisifs :
- La sémantique : les utilisateurs métier ont besoin de comprendre ce que représentent les données dans un domaine métier donné, et par quels processus métier elles ont été produites. Cela suppose des définitions claires, des relations et des exemples, pas seulement des schémas techniques.
- La qualité des données : les utilisateurs doivent savoir si les données sont complètes, cohérentes et adaptées à leur usage. Or la plupart des catalogues n'en donnent aucune évaluation explicite.
- Les engagements de service : fiabilité, disponibilité et fréquence de mise à jour déterminent si un jeu de données est exploitable dans des processus opérationnels et analytiques. Sans ces informations, faire confiance aux données relève du pari.
Ces aspects ne s'extraient pas automatiquement des sources : ils exigent une curation manuelle et une connaissance du domaine.
Vers un nouveau paradigme : la marketplace de données d'entreprise
Les produits de données transforment la façon dont les organisations aux équipes distribuées gèrent et partagent leurs données. Ils marquent le passage à une gestion des données centrée sur le consommateur.
Les produits de données : conçus pour les consommateurs, avec une propriété claire
Les produits de données sont des unités logiques construites autour d'un concept métier : ils combinent actifs, code et documentation pour offrir une solution de données cohérente aux consommateurs. Ils masquent les détails d'implémentation (tables brutes et intermédiaires, pipelines, données de test) pour n'exposer aux autres équipes que les jeux de données finaux, via des Output Ports définis. Un produit de données appartient en général à l'équipe qui maîtrise le domaine métier ; il résulte d'une décision délibérée de partager la donnée sous forme de produit.
La plupart des organisations ne comptent que quelques centaines à quelques milliers de produits de données : bien plus facile à gérer et à maintenir que les millions d'actifs indexés dans un catalogue de données traditionnel.
Les Data Contracts : expliquer et vérifier la syntaxe, la sémantique et la qualité
Fournir un produit de données suppose d'en décrire et d'en expliquer le contenu aux Data Consumers potentiels. C'est le rôle des Data Contracts. Un Data Contract définit la structure, le format, la sémantique, les métriques de qualité, les SLA et les conditions des échanges de données entre fournisseurs et consommateurs. Techniquement, c'est une spécification YAML standardisée, lisible à la fois par l'humain et par la machine (voir la Data Contract Specification et ODCS). Les Data Contracts sont rédigés manuellement par les Product Owners et les consommateurs, dans une démarche collaborative d'ingénierie des exigences. La plateforme de données teste, valide puis fait respecter la conformité des produits de données à ces contrats.
Les Data Contracts sont aux produits de données ce que les API ont été aux systèmes logiciels. Ils fournissent une spécification d'interface claire qui permet aux Data Consumers de bâtir sur un produit de données sans avoir à en comprendre l'implémentation.
Un workflow self-service de demande et d'approbation
En réunissant les produits de données et leurs Data Contracts dans une marketplace de données d'entreprise, on peut rendre la gestion des accès entièrement self-service.
Les Data Consumers demandent l'accès aux produits de données dans le respect des conditions du Data Contract. Les Data Product Owners approuvent ou refusent ces demandes selon leur expertise du domaine et les règles de gouvernance. La plateforme de données automatise la gestion des droits d'accès, pour un traitement efficace et sûr des actifs. Ce workflow self-service supprime les goulets d'étranglement liés aux délais d'une gouvernance centralisée. Une piste d'audit complète des demandes, des approbations et des consommateurs actifs garantit une transparence totale aux Data Producers et aux équipes de gouvernance.
Une Data Governance pilotée par les contrats
Dans une marketplace de données, une gouvernance efficace repose sur une propriété claire et des Data Contracts stables. Les règles globales posent le socle applicable à tous les produits de données et assurent la cohérence de la marketplace. Les Data Contracts s'appuient sur ces règles pour préciser ce qui relève du domaine : conditions d'utilisation, standards de qualité, exigences de conformité. C'est ce qui rend les échanges entre producteurs et consommateurs dignes de confiance.
Les Data Product Owners répondent de la conformité de leur offre aux standards convenus, aussi bien aux règles globales qu'aux garanties propres à chaque contrat. En entretenant leurs produits de données et en collaborant avec les consommateurs, ils font tourner la marketplace de façon efficace et fiable.
L'IA peut renforcer la gouvernance : surveillance des métadonnées, contrôle de conformité, détection des risques. Avec de bonnes métadonnées, les LLM produisent des recommandations et des alertes qui allègent le travail des Data Product Owners. La responsabilité finale leur revient néanmoins : leur expertise du domaine garantit des décisions de gouvernance à la fois praticables et alignées sur les objectifs métier.
En résumé
Les catalogues de données ont longtemps été la solution de référence pour gérer les actifs de données. Leur efficacité reste pourtant limitée par la surindexation et par l'absence de sémantique et de garanties de qualité. Des métadonnées de produit de données utiles sont pilotées par les Data Contracts, curées manuellement et rattachées à une propriété claire. Dans une marketplace de données, les organisations partagent leurs produits de données maîtrisés avec d'autres équipes ou avec des organisations externes, en self-service et avec des règles de gouvernance explicites.
Entropy Data comme marketplace de données
Découvrez comment Entropy Data vous aide à construire une marketplace de données d'entreprise.
Commencez gratuitement, explorez la démo interactive d'Entropy Data ou réservez une visite guidée avec les auteurs.