Catalogue de données : définition, fonctionnement, mise en place et choix d’un outil

Un catalogue de données est un inventaire organisé et documenté des actifs de données d’une organisation. Il s’appuie sur les métadonnées, c’est-à-dire les données qui décrivent les données, pour rendre chaque table, chaque champ et chaque rapport trouvable, compréhensible et fiable. Concrètement, il se connecte aux systèmes existants de l’entreprise, en aspire automatiquement les métadonnées techniques, puis laisse les équipes data et métier les enrichir de contexte. Le résultat : un point d’entrée unique vers les données de l’entreprise, pour savoir quelles données existent, ce qu’elles signifient, d’où elles viennent, qui en répond et si l’on peut s’en servir.

• Ce que c’est : un inventaire des actifs de données de l’entreprise, structuré par les métadonnées, et non un entrepôt supplémentaire. La donnée reste dans ses systèmes d’origine.
• Comment ça marche : collecte automatique par connecteurs, enrichissement humain du sens métier, traçabilité des transformations, recherche et certification.
• À quoi ça sert : moins de temps perdu à chercher, des indicateurs fiabilisés, une conformité documentée, des projets data et IA accélérés.
• Ce que ce n’est pas : ni un dictionnaire de données seul, ni un glossaire métier seul, ni un MDM (master data management, gestion des données de référence).
• Comment le réussir : un cas d’usage précis, un pilote restreint, des rôles nommés, une mesure d’adoption, puis une extension par vagues.

Qu’est-ce qu’un catalogue de données ?

Une définition normalisée

Le catalogue de données, ou data catalog, répond à quatre questions que se pose tout utilisateur : quelles données existent, que veulent-elles dire, d’où viennent-elles, peut-on leur faire confiance. Le data catalog y répond en centralisant, dans un référentiel unique et interrogeable, les métadonnées de tous les systèmes qui produisent ou consomment de la donnée.

L’objet est normalisé. Le W3C publie le vocabulaire DCAT (Data Catalog Vocabulary), dont la version 3 est une recommandation officielle depuis août 2024, et qui définit un catalogue comme une collection curée de métadonnées sur des ressources. Le mot « curée » porte tout le sens : un catalogue n’est pas un déversoir automatique, c’est un inventaire entretenu. La série ISO/IEC 11179 sur les registres de métadonnées va dans la même direction.

Retenez surtout sa double finalité, sur laquelle les éditeurs convergent : la découverte et la gouvernance. Un catalogue de données qui ne sert qu’à chercher devient un annuaire mort. Un catalogue qui ne sert qu’à contrôler n’est jamais utilisé. C’est en tenant les deux qu’il devient le socle opérationnel de la gouvernance des données (data governance).

Les métadonnées, matière première du catalogue

Les métadonnées d’un catalogue de données se répartissent en quatre familles, qui n’ont ni la même origine ni le même coût d’obtention. La distinction est opérationnelle : les techniques et les opérationnelles s’obtiennent de manière presque automatique, les métadonnées métier et de gouvernance se construisent.

Les métadonnées opérationnelles sont les grandes oubliées des projets data, et pourtant les plus rentables. Savoir qu’une table n’a été consultée par personne depuis six mois vaut souvent mieux qu’une définition parfaite : cela permet de trancher entre ce qu’on documente et ce qu’on décommissionne.

Comment fonctionne un data catalog ?

C’est la question la plus mal traitée du sujet, alors qu’elle décide de tout. Le fonctionnement se décompose en cinq mécaniques enchaînées.

1. La collecte automatique des métadonnées

Le catalogue de données se branche aux systèmes de l’entreprise grâce à des connecteurs : entrepôts, lakehouses (plateformes combinant lac et entrepôt), bases de données relationnelles, plateformes big data (données massives), outils de BI (business intelligence, décisionnel) comme Power BI ou Tableau, orchestrateurs de pipelines, API applicatives. Le scan lit les schémas, les logs de requêtes et la description des rapports.

Un point est souvent mal compris : le data catalog n’aspire pas les données elles-mêmes, il ne copie que leur description. Les valeurs restent dans leur système d’origine, ce qui limite la surface de risque en matière de sécurité et de confidentialité, et évite un nouveau silo. Remontent seuls l’arborescence des tables, le typage des colonnes, les volumétries, les dépendances, les requêtes fréquentes. Ne remonte jamais seul : le sens. Une colonne nommée flg_ct_v2 le restera tant qu’un humain n’aura pas écrit ce qu’elle signifie. La profondeur de cette collecte varie fortement selon la plateforme, ce qui se vérifie très concrètement quand il s’agit de cataloguer Snowflake et Databricks.

2. L’enrichissement humain, la partie qui fait la valeur

Un data catalog purement automatique produit un annuaire technique illisible pour un métier. L’enrichissement ajoute ce que la machine ne peut pas déduire : la définition métier, le propriétaire, la criticité et les règles d’usage.

Il se pilote comme une campagne, pas comme un vœu pieux : un lot d’actifs, des contributeurs identifiés, une échéance, un taux de complétion mesuré. Les catalogues récents proposent un premier jet de définition à partir du nom, des valeurs d’exemple et des utilisations observées, que le référent métier valide ou corrige. Le gain porte sur le volume traité grâce à l’automatisation, mais la validation humaine reste obligatoire : une définition fausse et certifiée fait plus de dégâts qu’une case vide.

3. Le data lineage et l’analyse d’impact

Le data lineage (lignage des données) retrace le parcours d’une donnée, de sa source à son usage final, en passant par chaque transformation. Il sert deux finalités symétriques. En amont, il répond à « d’où sort ce chiffre », question posée dès qu’un indicateur surprend. En aval, il répond à « qu’est-ce que je casse si je modifie ce champ ». Prenez la refonte d’un champ de statut dans le CRM : sans data lineage, l’équipe data découvre les dégâts quand des tableaux de bord affichent zéro ; grâce à un lignage de bout en bout, la liste des objets impactés et de leurs propriétaires est disponible avant la modification.

4. La recherche et la certification

Du point de vue de l’utilisateur métier, le catalogue de données se résume à une barre de recherche et à une fiche. Le moteur de recherche mêle mots-clés, synonymes du glossaire, filtres à facettes et formulation en langage naturel. La fiche regroupe la définition, le propriétaire, le data lineage, les indicateurs de qualité et les usages connus.

Le signal qui change tout, c’est la certification. Marquer explicitement les jeux de données validés distingue la table de référence des dizaines de copies de travail qui traînent dans les schémas personnels. C’est ce qui rend possible le self-service analytics (analyse en autonomie) sans multiplier les erreurs, et fait de la découverte des données un réflexe plutôt qu’une enquête.

5. Le cycle de vie des entrées

Un data catalog vieillit : les définitions se périment, les propriétaires changent de poste, les tables disparaissent. Le catalogue de données doit donc tenir à jour ses propres entrées, avec une date de dernière revue, des alertes sur les fiches obsolètes et la réaffectation quand un propriétaire quitte l’entreprise. Une revue trimestrielle par domaine suffit à éviter la dérive. Sans cet entretien, la confiance dans le catalogue s’érode et les utilisateurs retournent poser leurs questions sur la messagerie interne.

Les fonctionnalités d’un data catalog

Ces fonctionnalités se retrouvent dans presque tous les outils de catalogage. La différence se joue sur quatre terrains : la collaboration (commentaires, propositions de correction, workflows de validation), axe qu’approfondissent les 7 fonctionnalités d’un Data Knowledge Catalog ; les métadonnées actives, qui font basculer de la documentation à la gouvernance opérationnelle, puisque le catalogue propage alors un tag de sensibilité vers l’entrepôt ou alerte un propriétaire quand un contrôle échoue ; l’ouverture (API complète, gestion as-code, export standard) ; et l’assistance IA, qui abaisse le coût d’entretien sans remplacer le socle.

Catalogue de données, dictionnaire, glossaire, MDM : ne pas confondre

La confusion entre ces objets est la première cause de cahiers des charges mal calibrés. Chacun répond à une question différente.

La ligne de partage la plus utile tient en une phrase : le MDM gère des valeurs, le catalogue gère des descriptions. Le MDM tranche que « Dupont SA » et « DUPONT S.A. » sont la même entité et produit l’enregistrement de référence ; le catalogue de données documente que la table qui héberge ce référentiel existe, qui en répond et quels rapports en dépendent.

Même logique entre dictionnaire et glossaire métier (business glossary), dont les différences méritent d’être posées précisément : le premier décrit une colonne, le second définit une notion. Ne faire que le premier produit de la documentation technique que les métiers ne lisent pas ; ne faire que le second produit un lexique déconnecté du réel. Le lien entre les deux est ce qui rend le dictionnaire de données utile au-delà de l’IT. Le cadre de référence DAMA-DMBOK traite également gouvernance, métadonnées, qualité et master data management comme des disciplines distinctes mais reliées : cataloguer ne dispense d’aucune des autres.

Pourquoi utiliser un catalogue de données : les avantages

Le temps de recherche est le gain le plus tangible, et la mesure la plus directe de l’efficacité opérationnelle. Un InfoBrief IDC commandité par Alteryx, publié en janvier 2018 auprès de plus de 400 professionnels de la data en Amérique du Nord et en Europe, mesurait que ces derniers consacraient 60 % de leur temps à produire un résultat exploitable, dont 37 % à chercher les données, 36 % à les préparer et 27 % seulement à les analyser. L’étude est ancienne et sponsorisée par un éditeur, mais la ligne la plus intéressante reste d’actualité : 20 % du temps, soit environ dix heures par semaine, partait à recréer des actifs existants. Un actif refabriqué faute d’avoir été trouvé coûte deux fois, en temps de production et en divergence future.

La confiance suit. Deux directions au sein d’une même entreprise qui présentent deux chiffres de marge différents ne débattent plus de la stratégie, elles débattent du calcul. Le catalogue de données transforme cet arbitrage récurrent en prise de décision documentée une fois, accessible à tous. Il n’héberge pas une démarche de data quality, dont les principes de qualité des données donnent le cadre, mais il en affiche les résultats à l’endroit où ils sont vus.

La conformité ensuite. L’article 30 du RGPD impose un registre des activités de traitement, obligation qui vise en pratique toute entreprise ou organisme traitant des données personnelles. Ce registre et l’inventaire des actifs se nourrissent des mêmes informations : finalités, catégories de données, destinataires, durées de conservation. Documenter deux fois les mêmes informations est une perte pure.

L’architecture décentralisée enfin. Dès qu’une entreprise confie ses données aux domaines métier, elle a besoin d’un point de rencontre commun : c’est la fonction du catalogue de données dans une architecture de maillage de données, décrite dans data mesh et data catalog, comme dans les modèles de data fabric ou les pratiques DataOps. Sans catalogue de données partagé, la décentralisation reproduit les silos qu’elle prétendait supprimer.

Les cas d’usage les plus fréquents

Un projet de catalogue de données se cadre sur des usages, pas sur un périmètre théorique. Les deux premiers sont les points d’entrée les plus sûrs pour un pilote.

Comment mettre en place un catalogue de données

La mise en œuvre tient en sept étapes, dans cet ordre.

• 1. Cadrer un cas d’usage précis. Pas « améliorer la gouvernance », mais « fiabiliser les indicateurs du comité de direction ». Le cas d’usage détermine le périmètre.
• 2. Délimiter un pilote. Un domaine, quelques systèmes, un trimestre. L’objectif du POC (preuve de concept) est de produire une preuve d’usage réutilisable, pas de tout couvrir.
• 3. Connecter et scanner. Brancher les sources, vérifier la profondeur du data lineage obtenu, mesurer ce qui manquera.
• 4. Définir un modèle de documentation minimal. Cinq à sept attributs obligatoires, pas trente. Un modèle trop riche ne se remplit jamais.
• 5. Documenter avec les métiers. Ateliers courts, campagnes assignées, échéances. L’adoption se joue là, pas à la démonstration de l’outil.
• 6. Ouvrir et mesurer. Taux de couverture et de documentation, nombre de recherches, part des actifs certifiés, contributeurs actifs.
• 7. Industrialiser par vagues. Un domaine après l’autre, en réutilisant le modèle validé. Le time-to-value (délai avant premier bénéfice) se dégrade dès qu’on tente le déploiement global d’un coup.

Par quoi commencer, et avec qui

Le réflexe naturel consiste à cataloguer les systèmes les plus volumineux de l’entreprise. C’est l’erreur de cadrage la plus fréquente. Trois filtres donnent une priorisation défendable : les actifs qui alimentent les indicateurs stratégiques suivis par la direction, ceux qui portent des données sensibles, et les plus consultés sur la base des logs. L’intersection des trois constitue le noyau. Un petit nombre d’actifs bien documentés produit plus d’usage qu’un inventaire massif de fiches vides.

Côté organisation, quatre rôles sont à nommer avant de démarrer. Le data owner (propriétaire), responsable métier d’un domaine, arbitre les définitions et valide les politiques d’accès : un domaine sans propriétaire nommé ne se documente pas. Le data steward documente au quotidien, contrôle la complétude et anime les campagnes. Le référent métier apporte la définition d’usage et signale les pièges d’interprétation. L’administrateur gère connecteurs, modèle de métadonnées et droits.

Bonnes pratiques et erreurs fréquentes

• Partir de l’usage, jamais de l’exhaustivité. Une donnée entre au catalogue parce que quelqu’un s’en sert.
• Nommer le propriétaire avant d’écrire la définition. Une information sans responsabilité nommée n’est pas opposable et ne se maintient pas.
• Garder le même modèle de documentation dans tous les domaines. La cohérence au sein de l’organisation vaut mieux que la finesse locale.
• Certifier explicitement, et dater la certification. Un label sans date perd son sens.
• Mesurer l’utilisation, pas seulement la couverture. Recherches, consultations, contributeurs actifs : ces indicateurs prédisent la survie du projet.

L’adoption, elle, se gagne sur trois leviers : des ambassadeurs data au sein de chaque domaine, une formation courte et orientée tâche du type « trouver la bonne table en deux minutes », et une présence du catalogue là où les gens travaillent déjà (lien depuis les tableaux de bord BI, accès depuis l’environnement de requêtage). Un catalogue de données qu’il faut aller chercher dans un onglet séparé perd ses utilisateurs occasionnels.

Les échecs, eux, se ressemblent : vouloir tout cataloguer d’emblée, traiter le sujet comme un projet IT sans sponsor métier, documenter sans nommer de propriétaire, ne mesurer que la couverture technique, ou confondre l’achat de l’outil avec la mise en place de la gouvernance. Ces points de vigilance sont détaillés dans réussir son projet de data catalog.

Comment choisir un outil de catalogue de données

La question « quel est le meilleur outil de catalogue de données » n’a pas de réponse unique. Les logiciels de catalogue de données se répartissent en trois familles, dont les modèles économiques et les angles morts diffèrent.

Aucune famille d’outils n’est supérieure dans l’absolu, et la combinaison est fréquente : catalogue de données natif pour la gouvernance technique fine d’une plateforme cloud, solution indépendante pour la vue transverse et l’usage métier, les deux fédérés par API. Sur le versant open source, évaluez la vitalité du projet avant sa richesse fonctionnelle : fréquence des versions, activité du dépôt, taille de la communauté.

Six critères départagent réellement : la couverture des connecteurs sur vos sources réelles et la profondeur obtenue sur chacune, pas la longueur de la liste commerciale ; l’automatisation (ce qui se documente sans intervention, détection des changements de schéma) ; l’adoption métier, à tester en faisant chercher un utilisateur non technique, qui doit trouver en deux minutes ; les capacités de gouvernance (workflows de validation, campagnes, rôles fins) ; l’ouverture et la réversibilité, car vous devez pouvoir sortir vos métadonnées ; et le coût total, dont le poste le plus sous-estimé reste l’entretien du catalogue de données. Pour structurer l’évaluation, la checklist d’évaluation d’une solution aide à construire la grille et une comparaison des catalogues de données à situer les acteurs.

Data catalog et intelligence artificielle

Les projets d’IA échouent rarement sur le modèle, ils échouent sur les données. Gartner prévoit que 60 % des projets d’IA non soutenus par des données prêtes pour l’IA (AI-ready data) seront abandonnés jusqu’en 2026, et relève que 63 % des organisations n’ont pas, ou ignorent si elles ont, des pratiques de gestion des données adaptées à l’IA. Or une donnée prête pour l’IA est une donnée dont on connaît l’origine, le sens, la qualité et les droits d’usage : c’est la définition même de ce que produit un catalogue de données.

La contrainte devient réglementaire. L’article 10 du règlement européen sur l’IA impose, pour les systèmes à haut risque entraînés sur des données, que les jeux d’entraînement, de validation et de test fassent l’objet de pratiques de gouvernance documentées : origine des données, préparation, hypothèses, examen des biais, identification des lacunes. Assurer la traçabilité des données d’entraînement n’est plus une bonne pratique, c’est une obligation, et elle s’appuie sur les mêmes métadonnées que l’inventaire.

Troisième raison, plus récente : les agents. Un modèle de langage reste aveugle au système d’information de l’entreprise. Pour répondre correctement, un agent doit connaître la table qui fait autorité, ce que signifie un terme métier et qui a le droit d’y accéder. C’est ce que décrit la pile de contexte des agents IA, dont la couche sémantique constitue l’étage de traduction entre le modèle physique et le vocabulaire métier.

Le mouvement fonctionne dans les deux sens, car l’IA améliore également le catalogue de données : premiers jets de définition, identification de colonnes contenant des données personnelles là où une expression régulière passe à côté, recherche en langage naturel, repérage des définitions contradictoires entre domaines. Une réserve de méthode s’impose : ces suggestions restent des propositions. La publication de définitions générées sans validation fabrique de la fausse confiance, ce qui est pire qu’une fiche vide. Cette articulation entre automatisation et contrôle est développée dans quand l’IA augmente le catalogue.

Points clés à retenir

• Définition : un inventaire des actifs de données organisé et documenté, structuré par les métadonnées, normalisé notamment par le vocabulaire DCAT du W3C.
• Matière première : quatre familles de métadonnées. Les techniques et les opérationnelles se collectent, celles de métier et de gouvernance se construisent.
• Fonctionnement : collecte automatique, enrichissement humain du sens, data lineage et analyse d’impact, recherche et certification, entretien du cycle de vie.
• Distinctions : le dictionnaire décrit les objets techniques, le glossaire fixe le vocabulaire, le MDM gère les valeurs de référence, le catalogue relie l’ensemble.
• Mise en œuvre : un cas d’usage précis, un pilote délimité, des rôles nommés, un modèle minimal, une mesure d’usage, puis une extension par vagues.
• Choix d’outil : trois familles (natifs cloud, open source, plateformes indépendantes) et six critères, dont l’adoption métier et le coût total de possession.

DataGalaxy adresse ce périmètre avec un catalogue de données augmenté par l’IA, un glossaire métier relié au technique et un lignage de bout en bout, dans une logique où le catalogage n’est plus une fin mais le socle d’une approche intégrée pour gouverner données et IA. C’est la direction que prend le sujet : un référentiel unique où la donnée, son sens et les usages qui en découlent, humains comme algorithmiques, se gouvernent ensemble.

À propos de l'auteur: Max Faivre

Product Marketing Manager