OpenMetadata, DataHub, DataGalaxy : choisir un data catalog sans surdimensionner le projet

Cet article aide a clarifier un sujet de decision, de modernisation, de gouvernance ou d'exploitation avant de bouger l'existant.

• Enjeux metier reels
• Risques et dependances
• Arbitrages utiles
• Trajectoire recommandee

Le vrai risque : lancer un data catalog trop ambitieux pour vos usages réels

Dans beaucoup d’entreprises, le data catalog est lancé avec une promesse large : mieux documenter la donnée, clarifier les définitions, fiabiliser les usages BI, rendre les flux lisibles et préparer la gouvernance. Sur le papier, OpenMetadata, DataHub et DataGalaxy peuvent tous entrer dans cette trajectoire. En pratique, les écarts apparaissent vite dès qu’il faut arbitrer entre profondeur technique, confort d’usage métier et charge d’exploitation.

Le point de départ n’est donc pas un comparatif de fonctionnalités. Il faut d’abord poser une question plus simple : quel problème opérationnel cherchez-vous à traiter dans les 6 à 12 prochains mois ? Si votre enjeu principal est un glossaire métier partagé entre domaines, la logique de choix ne sera pas la même que pour un contexte où l’IT veut prioritairement documenter les pipelines, les tables, les dashboards et les dépendances entre systèmes. C’est ce cadrage initial qui évite les projets surdimensionnés, les intégrations trop lourdes et les catalogues remplis mais peu utilisés.

Dans une intervention directe de freelance senior, ce travail de cadrage consiste souvent à réduire le périmètre plutôt qu’à l’élargir : quels objets documenter en premier, quels rôles activer réellement, quels usages produire une valeur visible, et quelles dépendances techniques ou organisationnelles risquent de bloquer l’adoption.

OpenMetadata, DataHub, DataGalaxy : trois logiques de produit différentes

OpenMetadata convient souvent aux environnements qui cherchent un outil gouvernance data avec une base technique sérieuse, une logique open source et un bon compromis entre catalogage, lineage, profiling, qualité et documentation. Il parle bien aux équipes data qui veulent garder la main sur l’intégration et éviter une dépendance forte à un éditeur, tout en disposant d’une interface exploitable par des profils non purement techniques. En revanche, il demande un minimum de capacité d’exploitation, de paramétrage et de pilotage de la trajectoire.

DataHub est généralement pertinent quand la priorité est très orientée métadonnées techniques, architecture data, lineage, actifs analytiques et intégration avec un écosystème data déjà structuré. Il est souvent regardé dans des contextes où l’on veut un référentiel riche, extensible et proche des réalités d’une plateforme data moderne. Son intérêt est clair pour des équipes data engineering ou gouvernance déjà matures. Son point d’attention porte plus souvent sur la courbe de mise en route, la profondeur de paramétrage et la nécessité d’un sponsoring fort pour dépasser un usage réservé aux équipes techniques.

DataGalaxy est souvent évalué lorsque l’objectif prioritaire est l’appropriation métier : glossaire, définitions, objets de référence, cartographie compréhensible, collaboration entre métiers et IT. Son positionnement parle bien aux organisations qui veulent structurer une gouvernance lisible sans démarrer par un chantier trop technique. En contrepartie, le bon usage dépend fortement de la qualité du cadre de gouvernance : propriétaires, règles de contribution, processus de validation, articulation avec l’architecture et les outils existants.

Autrement dit, le sujet n’est pas de dire qu’un outil est meilleur qu’un autre. Le sujet est de savoir si vous pilotez d’abord un problème de compréhension métier, un problème de traçabilité technique ou un problème de coordination entre les deux.

Comparer par usage réel : glossaire métier, lineage, ownership, intégration

Pour un glossaire métier, la question clé n’est pas seulement la présence d’un module de glossaire. Il faut regarder la facilité à faire contribuer les métiers, à rattacher une définition à des objets concrets, à gérer des validations simples et à maintenir des responsabilités visibles. Si votre organisation a déjà du mal à stabiliser des définitions comme “client actif”, “contrat éligible” ou “incident résolu”, la capacité d’animation et de contribution comptera plus que la richesse technique native.

Pour le lineage, il faut distinguer le discours produit de la réalité d’intégration. Certains contextes ont des pipelines outillés, des transformations visibles et des connecteurs standard ; d’autres ont un patrimoine mêlant SQL artisanal, flux historiques, traitements intermédiaires et BI hétérogène. Dans ce cas, aucun outil ne recréera magiquement une traçabilité complète. Il faut évaluer ce qui sera réellement automatisé, ce qui devra être documenté manuellement et le niveau de confiance acceptable pour l’exploitation.

Sur l’ownership, beaucoup de projets échouent parce qu’ils confondent propriétaire théorique et responsable opérationnel. L’outil doit permettre d’assigner des rôles compréhensibles, mais surtout le modèle de responsabilité doit être tenable : qui répond sur la définition, qui répond sur la qualité, qui répond sur l’exposition dans la BI, qui arbitre en cas de conflit ? Sans cela, même un bon data catalog entreprise reste une vitrine sans gouvernance active.

Enfin, l’intégration technique doit être jugée avec lucidité. Listez vos sources prioritaires : entrepôt de données, outils BI, orchestration, transformation, référentiels, documentation existante. Puis regardez l’effort réel de connexion, de synchronisation et de maintenance. Le bon arbitrage n’est pas l’outil qui promet de tout couvrir, mais celui qui couvre bien le périmètre utile sans ouvrir un chantier d’exploitation disproportionné.

Le coût de mise en route ne se limite ni à la licence ni à l’open source

Comparer OpenMetadata, DataHub et DataGalaxy uniquement sous l’angle budgétaire conduit souvent à de mauvais choix. Un outil open source peut sembler économiquement évident, puis mobiliser fortement les équipes sur l’hébergement, les mises à jour, les connecteurs, la sécurité, le support et l’administration. À l’inverse, un outil éditeur peut réduire certains efforts de run, mais déplacer la complexité vers le cadrage, la conduite du changement et les règles de gouvernance.

Le coût réel se situe dans quatre blocs. D’abord, le cadrage : quels objets, quels domaines, quelles responsabilités, quel dictionnaire minimum. Ensuite, l’intégration : connecter les bonnes sources sans multiplier les flux secondaires. Puis l’adoption : former, animer, faire contribuer, arbitrer les zones grises. Enfin, l’exploitation : maintenir les connecteurs, surveiller la fraîcheur des métadonnées, traiter les écarts entre la théorie du catalogage et la réalité des usages.

Dans un contexte d’entreprise, le meilleur choix est souvent celui qui permet une première marche crédible : un périmètre limité, utile, démontrable, avec une gouvernance sobre. C’est particulièrement vrai quand la direction attend des résultats visibles sans vouloir créer une usine à gaz de gouvernance data. Une intervention directe, sans couche agence, permet justement de tenir cette ligne : audit rapide de l’existant, arbitrage des usages prioritaires, sélection de l’outil et séquencement de mise en œuvre au bon niveau de séniorité.

Une méthode de choix fiable : partir des décisions à prendre, pas du catalogue des fonctionnalités

Une méthode simple consiste à structurer l’évaluation autour de scénarios concrets. Par exemple : un responsable métier veut comprendre la définition d’un indicateur contesté ; un data analyst cherche la bonne table source ; un data owner doit savoir sur quel périmètre il est responsable ; une équipe projet veut mesurer l’impact d’un changement dans un flux ; une équipe qualité veut rattacher une règle à des objets critiques. Si l’outil est convaincant sur ces cas, il a plus de chances d’être adopté qu’avec une grille abstraite de cent critères.

Ensuite, il faut tester trois dimensions. La lisibilité pour les métiers : comprend-on rapidement ce que contient le catalogue et à quoi il sert ? La robustesse technique : les intégrations tiennent-elles la route sur votre patrimoine réel ? Et la tenue dans le temps : qui va maintenir, arbitrer et faire vivre l’outil après le lancement ?

Dans la pratique, un cadrage sérieux aboutit rarement à une réponse universelle. Une entreprise très orientée plateforme data pourra préférer une logique plus technique et extensible. Une organisation en phase de structuration de son glossaire métier et de sa gouvernance choisira plus volontiers un outil plus accessible aux métiers. Entre les deux, il existe aussi des trajectoires mixtes, à condition de ne pas promettre dès le départ un coverage complet de tous les usages.

Le rôle d’un accompagnement senior n’est pas de pousser un produit. Il est d’éviter une décision de court terme qui crée de la dette de gouvernance, de documenter les dépendances, d’objectiver les compromis et de construire une trajectoire réaliste entre ambition, capacités internes et usages prioritaires.

FAQ

Quel outil choisir si l'objectif principal est de construire un glossaire métier partagé ?

Si votre priorité est l’alignement métier sur les définitions, les responsabilités et les objets clés, il faut privilégier l’outil le plus lisible et le plus simple à faire contribuer par des profils non techniques. Le bon choix dépend moins du volume de fonctionnalités que de la capacité à installer des règles de contribution, de validation et de maintenance dans la durée.

OpenMetadata ou DataHub sont-ils réservés aux organisations très matures techniquement ?

Pas nécessairement, mais ils demandent un minimum de capacité de cadrage et d’exploitation. Dans une entreprise où les équipes data sont déjà structurées, ils peuvent très bien convenir. En revanche, si la gouvernance est encore peu formalisée et que l’enjeu principal est l’adoption métier, il faut regarder avec attention l’effort d’appropriation, pas seulement la puissance technique.

Peut-on lancer un data catalog sans viser tout le patrimoine de données dès le départ ?

Oui, et c’est souvent la meilleure approche. Un périmètre initial limité à quelques domaines, objets critiques, indicateurs sensibles ou flux prioritaires permet de valider l’usage réel, de clarifier les rôles et d’éviter un chantier trop lourd. C’est généralement plus fiable qu’un déploiement large sans gouvernance opérationnelle suffisamment solide.