Catalogue de données — Data Catalog

Définition complète

Un catalogue de données (data catalog) est un système centralisé qui inventorie, documente et rend découvrables l'ensemble des actifs de données d'une organisation. Il ne stocke pas les données elles-mêmes — cela reste le rôle de l'entrepôt de données, du data lake ou des bases opérationnelles — mais il en indexe les métadonnées et le contexte. Pour chaque dataset, table ou rapport, le catalogue documente son schéma (colonnes, types, contraintes), son ownership (qui en est responsable), sa classification de sensibilité (données publiques, internes, confidentielles, PII), sa fraîcheur (quand a-t-elle été mise à jour pour la dernière fois), sa traçabilité (d'où viennent les données et quels modèles en dépendent) et la qualité observée (taux de valeurs nulles, anomalies détectées).

La valeur d'un catalogue de données n'est pas uniquement technique. Pour les équipes analytiques, il réduit le temps de découverte : au lieu de passer deux heures à interroger cinq personnes pour trouver la bonne table et comprendre sa structure, un analyste trouve l'information en quelques minutes via la recherche du catalogue. Pour les équipes opérationnelles, il garantit que tout le monde parle des mêmes données avec les mêmes définitions. Pour les équipes conformité, il fournit l'inventaire des traitements requis par le RGPD et la cartographie des données à caractère personnel.

Le catalogue de données est l'un des deux piliers — avec la traçabilité des données — sur lesquels repose une gouvernance des données efficace. Un programme de gouvernance sans catalogue est difficile à opérationnaliser : on ne peut pas gouverner ce qu'on n'a pas inventorié. À l'inverse, un catalogue sans politique de gouvernance est un répertoire de plus — utile, mais sans cadre de responsabilité.

Les catalogues de données modernes diffèrent radicalement de leurs prédécesseurs des années 2000 et 2010. La première génération de catalogues (IBM InfoSphere, Informatica Enterprise Data Catalog) était principalement manuelle : les équipes data saisissaient les métadonnées dans un formulaire. La maintenance était un fardeau permanent et la dégradation du contenu commençait dès la première semaine suivant le déploiement. La deuxième génération — Atlan, Castor, OpenMetadata, DataHub, Alation, Collibra — connecte directement les systèmes sources (Snowflake, BigQuery, dbt, Looker, Tableau) et extrait automatiquement les métadonnées techniques, réduisant l'effort humain à la documentation du contexte métier que les outils ne peuvent pas inférer.

Composantes et fonctionnement d'un catalogue de données

Un catalogue de données mature comprend six composantes distinctes, chacune répondant à un besoin spécifique des utilisateurs et des équipes de gouvernance.

1. 1

   Collecte automatique de métadonnées

   Le catalogue se connecte aux systèmes sources via des connecteurs natifs (Snowflake, BigQuery, Redshift, dbt, Looker, Tableau, Fivetran) et extrait automatiquement les schémas, les statistiques d'usage, les fréquences de mise à jour et les relations entre tables. Cette collecte est planifiée (toutes les heures ou tous les jours selon les cas) pour maintenir les métadonnées à jour sans intervention manuelle.

2. 2

   Classification et tagging automatiques

   Les catalogues modernes appliquent des règles de classification automatique basées sur les noms de colonnes et les patterns de données : une colonne nommée "email" ou "phone_number" est automatiquement taguée comme donnée à caractère personnel. Des règles personnalisées peuvent être configurées pour refléter la taxonomie de données propre à l'organisation — par exemple, tagger automatiquement toutes les tables préfixées "raw_" comme données brutes non validées.

3. 3

   Graphe de traçabilité (data lineage)

   Le catalogue reconstruit le graphe de dépendance entre les datasets : quelle table source produit quel modèle dbt, qui produit quel dashboard Looker, qui alimente quel rapport Tableau. Cette vue de traçabilité permet l'analyse d'impact ("si je modifie cette table, quels rapports sont affectés ?"), le débogage ("d'où vient ce chiffre ?") et la documentation de la généalogie analytique pour les auditeurs.

4. 4

   Documentation du contexte métier

   C'est la composante à valeur ajoutée humaine : les data owners et data stewards ajoutent des descriptions en langage naturel pour chaque dataset ("cette table contient les commandes validées après déduction des retours — ne pas confondre avec orders_raw qui inclut les commandes annulées"), documentent les conventions de nommage, les cas d'usage typiques et les pièges d'interprétation fréquents. Les outils modernes intègrent des suggestions IA pour accélérer cette documentation.

5. 5

   Recherche et découverte

   L'interface de recherche est ce que les utilisateurs finaux voient. Elle doit permettre de trouver des datasets par nom, par description, par tag de classification, par ownership, par usage récent et par popularité. Les meilleures implémentations intègrent une recherche sémantique (pas uniquement syntaxique) qui retourne des résultats pertinents même quand l'utilisateur ne connaît pas le nom exact de la table. Google-like experience dans l'infrastructure analytique.

6. 6

   Intégration avec le contrôle d'accès

   Les catalogues avancés s'intègrent avec les systèmes de contrôle d'accès de l'entrepôt de données pour afficher uniquement les datasets auxquels l'utilisateur a accès et pour déclencher des demandes d'accès directement depuis l'interface de découverte. Cette intégration ferme la boucle entre la découverte ("je trouve ce dont j'ai besoin") et l'autorisation ("j'obtiens l'accès de façon contrôlée").

Exemple concret : déploiement d'un catalogue chez une marketplace B2B française

Prenons le cas de Bordeaux Procurement, une marketplace B2B basée à Bordeaux spécialisée dans l'approvisionnement industriel. L'entreprise génère 8,5 M€ de GMV mensuel, emploie 120 collaborateurs dont 8 dans l'équipe data, et opère un entrepôt BigQuery contenant 2 400 tables réparties en trois domaines : transactions (commandes, paiements, retours), fournisseurs (catalogue produits, stocks, délais) et clients (profils, historique d'achat, segments). Problème central : chaque analyste consacre en moyenne 40 % de son temps à chercher les bons datasets et à vérifier leur fiabilité avant d'analyser quoi que ce soit.

L'équipe déploie Castor en deux semaines. Castor se connecte à BigQuery et à dbt et catalogue automatiquement les 2 400 tables avec leurs schémas, leurs statistiques d'usage (quelles tables sont requêtées combien de fois par semaine), leurs fréquences de mise à jour et les dépendances dbt. La classification automatique identifie 312 tables contenant des données acheteurs potentiellement soumises au RGPD. Les data stewards passent trois semaines à documenter les 80 tables les plus utilisées avec leur contexte métier — pour les 2 320 autres, les métadonnées techniques automatiques suffisent pour orienter les utilisateurs.

Trois mois après le déploiement, le temps de découverte des datasets chute de 40 % à 12 % du temps des analystes. L'équipe finance arrête de recréer sa propre table de réconciliation des commandes — elle trouve la table officielle dans le catalogue et comprend pourquoi elle diffère de sa version historique (périmètre des retours traité différemment). L'auditeur RGPD annuel demande la cartographie des traitements de données personnelles : le catalogue exporte la liste des 312 tables classifiées en moins d'une heure, un exercice qui aurait auparavant nécessité plusieurs semaines d'investigation manuelle.

Analyse approfondie

Le problème que résout le catalogue de données est fondamentalement un problème de dette cognitive organisationnelle. Dans toute organisation qui accumule des données depuis plusieurs années, la connaissance de ce qui existe et comment l'utiliser est distribuée dans les têtes de quelques individus clés. Quand ces personnes partent — ou quand l'organisation grandit au-delà de ce que la connaissance tribale peut couvrir — cette connaissance disparaît ou devient inaccessible. Le catalogue externalise et structure cette connaissance dans un système accessible à tous. Il transforme une ressource implicite en ressource explicite.

La question du modèle d'auto-alimentation est critique pour la viabilité à long terme d'un catalogue. Les organisations qui déploient un catalogue mais dépendent d'un effort humain pour maintenir les métadonnées à jour découvrent invariablement le même pattern : la qualité du catalogue est excellente les deux premiers mois, puis se dégrade progressivement à mesure que les équipes maintiennent les vraies priorités. Six mois plus tard, un analyste qui cherche une table trouve une description datée de l'architecture précédente. Un catalogue dégradé est pire qu'aucun catalogue : il crée une fausse confiance. La règle d'or est de n'exiger un effort humain que pour les métadonnées que les outils ne peuvent pas extraire automatiquement — essentiellement le contexte métier et les décisions d'interprétation.

Le catalogue de données joue un rôle croissant dans l'adoption de l'IA générative en entreprise. Les assistants IA qui génèrent du SQL à partir de langage naturel (text-to-SQL) ont besoin de comprendre le schéma et le sens métier des tables pour produire des requêtes correctes. Sans catalogue, ces assistants travaillent à l'aveugle sur des noms de colonnes cryptiques et génèrent des résultats incorrects. Avec un catalogue bien documenté, l'assistant IA dispose du contexte nécessaire pour interpréter la demande "montre-moi les commandes du mois dernier" et sélectionner la bonne table avec le bon filtre de date, en excluant automatiquement les commandes annulées. La qualité du catalogue détermine directement la qualité des assistants IA analytiques.

La notion de data mesh — architecture organisationnelle qui distribue la propriété des données par domaine métier plutôt que de la centraliser dans une équipe data centrale — rend le catalogue encore plus critique. Dans un data mesh, chaque équipe (ventes, finance, produit, supply chain) est responsable de ses propres produits de données. Sans catalogue fédéré qui indexe tous ces produits distribués, la découverte devient impossible et le mesh se transforme en fragmentation incontrôlée. Le catalogue est l'infrastructure qui fait tenir ensemble une architecture décentralisée.

Les métriques de maturité d'un catalogue de données permettent de mesurer objectivement la progression du programme. Le taux de couverture documentée (% des tables activement utilisées avec une description métier) indique l'effort de documentation accompli. La fraîcheur des métadonnées (délai moyen entre une modification du schéma source et sa mise à jour dans le catalogue) mesure l'efficacité de l'auto-alimentation. Le taux d'adoption des utilisateurs (% des analystes qui utilisent activement le catalogue chaque semaine) révèle si l'outil résout réellement les problèmes des équipes ou s'il est utilisé uniquement par l'équipe data centrale. Une adoption inférieure à 40 % des analystes après six mois signale généralement un problème d'interface, de formation ou de couverture des systèmes sources.

Erreurs fréquentes dans le déploiement d'un catalogue de données

• ✗

  Vouloir tout cataloguer avant d'ouvrir l'outil aux utilisateurs : le piège classique est de planifier une phase de documentation exhaustive avant le déploiement — cataloguer les 3 000 tables avant de rendre le catalogue disponible aux équipes. Cette approche prend des mois, épuise l'équipe data et produit un catalogue dont la moitié du contenu est déjà obsolète au moment de l'ouverture. La bonne approche est d'ouvrir le catalogue avec les métadonnées techniques automatiques dès la deuxième semaine, puis d'enrichir la documentation métier progressivement en commençant par les 20 à 30 tables les plus utilisées.

• ✗

  Confondre catalogue de données et dictionnaire de données : un dictionnaire de données est un document statique (souvent un tableur ou une page Confluence) qui liste les définitions des colonnes clés. Il est utile mais limité : pas de recherche avancée, pas de traçabilité, pas d'intégration avec les systèmes sources, dégradation rapide. Un catalogue de données est un système vivant connecté à l'infrastructure réelle. Les deux ne sont pas équivalents, et tenter d'utiliser un dictionnaire statique comme substitut au catalogue sous-estime durablement le problème de découverte de données à l'échelle.

• ✗

  Ne pas assigner d'ownership clair pour chaque domaine de données : un catalogue sans data owners est un répertoire sans responsable. Quand personne n'est formellement responsable d'un domaine de données, la documentation n'est jamais mise à jour, les questions des utilisateurs restent sans réponse et la qualité du catalogue se dégrade. Chaque domaine de données (commandes, clients, produits, finances) doit avoir un data owner nommé dont l'une des responsabilités explicites est de maintenir la documentation du catalogue à jour. Sans cette responsabilité formelle, le catalogue devient rapidement un outil que l'équipe data maintient seule pour les autres équipes, qui n'en adoptent pas les bonnes pratiques.

Comment Fairview aborde la découverte et la confiance dans les données

Fairview intègre nativement la transparence sur les données sous-jacentes aux métriques opérationnelles. Chaque métrique affichée dans Fairview — MRR, taux de churn, marge de contribution, pipeline — est accompagnée de sa définition précise, de ses sources de données et de la logique de calcul appliquée. Quand votre équipe finance questionne un chiffre ou veut comprendre pourquoi le MRR Fairview diffère légèrement du MRR Stripe, elle trouve la réponse directement dans la plateforme sans solliciter l'équipe data.

Fairview agit comme un catalogue opérationnel pour les métriques de revenus et de marge : chaque connecteur documente ce qu'il importe, avec quelle logique de nettoyage et de normalisation, et dans quel périmètre. Cette transparence permet aux équipes opérationnelles de faire confiance aux chiffres qu'elles utilisent pour prendre des décisions — ce qui est précisément l'objectif d'un bon catalogue de données appliqué au domaine des revenus et de l'intelligence opérationnelle.

Questions fréquentes