Métadonnées actives et data catalog

La question à 60 millions de dollars à laquelle personne ne pouvait répondre

En 2019, un réassureur mondial a découvert qu'il existait 14 définitions différentes de « prime nette émise » réparties entre ses entrepôts de données, ses tableurs et ses outils de BI. Le chiffre qui atterrissait dans le board deck dépendait de l'analyste qui l'avait extrait, et de celle des 14 définitions à laquelle il faisait confiance cette semaine-là. L'entreprise avait dépensé un montant à neuf chiffres en infrastructure data. Elle avait un comité de gouvernance, un dictionnaire de données et une équipe BIBITechnologies et processus qui transforment des données brutes en insights actionnables via du reporting, des dashboards et de l'analyse, pour que les équipes décident sur des faits plutôt qu'à l'intuition.Voir la définition complète → bien dotée. Ce qu'elle n'avait pas, c'était un moyen de répondre à une question faussement simple : *d'où vient ce chiffre, et puis-je lui faire confiance ?*

Cet écart, entre posséder des données et être capable de les trouver, les comprendre et leur faire confiance, c'est la différence entre un data asset et un data swamp. Et c'est précisément l'écart qu'un data catalogdata catalogUn inventaire centralisé des actifs de données d'une organisation, enrichi de métadonnées, qui aide chacun à trouver, comprendre et faire confiance aux données dont il a besoin.Voir la définition complète → moderne, alimenté par des métadonnées actives, est conçu pour combler. Pas grâce à un dictionnaire de données plus joli. Grâce à un modèle opérationnel fondamentalement différent pour les métadonnées.

De l'inventaire passif aux métadonnées actives

Vous connaissez déjà les métadonnées comme « les données sur les données ». La distinction qui compte à votre niveau est celle entre métadonnées passives et actives, et c'est le cadrage le plus important à retenir de cette leçon.

Les métadonnées passives sont un inventaire. C'est le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →, les noms de colonnes, le champ propriétaire que quelqu'un a rempli lors d'une migration il y a deux ans. Elles dorment dans un référentiel. Elles deviennent obsolètes à l'instant où elles sont écrites. Le dictionnaire de données de l'ancien monde et la première génération de catalogs étaient passifs : des humains documentaient, des humains cherchaient, et l'ensemble se dégradait à la vitesse de la négligence organisationnelle.

Les métadonnées actives sont des métadonnées en mouvement. Elles sont collectées en continu depuis les systèmes qui font réellement tourner votre patrimoine data, logs de requêtes, outils d'orchestration, plateformes de BI, frameworks de transformation, APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → cloud, puis *renvoyées* vers les endroits où les gens travaillent. Le catalog cesse d'être une bibliothèque qu'on visite pour devenir une couche d'intelligence qui agit sur ce qu'elle sait.

Gartner a formalisé ce basculement en retirant son Magic Quadrant « MetadataMetadataDonnées sur les données, informations décrivant le contexte, la structure, la provenance et les caractéristiques d'un asset de données (auteur, date, format, source, définition). Management Solutions » en 2021 pour le remplacer par le concept d'active metadata management. Le sujet n'était pas un changement de nom. C'était la reconnaissance du fait que **la valeur des métadonnées est proportionnelle à leur *fraîcheur* et à leur *mise en action***.

Voici le test pratique à appliquer lundi matin. Pour toute métadonnée détenue par votre catalog, demandez :

• Est-elle observée ou déclarée ? Une métadonnée observée provient de l'observation du système en fonctionnement (cette table a été requêtée 4 000 fois la semaine dernière, toujours jointe à celle-là). Une métadonnée déclarée est ce qu'un humain a affirmé (ce dataset est « gold »). L'observé bat le déclaré à chaque fois, parce qu'il ne peut pas mentir et ne peut pas se périmer.
• Revient-elle en flux ? Si vos scores de popularité, vos flags de qualité et vos tags PII ne vivent qu'à l'intérieur de l'interface du catalog, vous avez un système passif portant une étiquette active. Les métadonnées actives apparaissent dans l'éditeur de requêtes, dans le sélecteur de champs de l'outil de BI, dans le canal Slack où quelqu'un demande « quelle table de revenu ? »

Un catalog qui ne fait qu'ingérer est un musée. **Un catalog qui ingère *et* active est une infrastructure**.

Les quatre signaux de métadonnées qui comptent le plus

Toutes les métadonnées n'ont pas la même valeur. Priorisez la collecte de quatre types de signaux, à peu près dans cet ordre :

1. Métadonnées techniques, schémas, types, partitions. Le minimum, scanné automatiquement.
2. Métadonnées opérationnelles, fraîcheur, volume, fréquence de requêtage, taux d'échec. C'est là que naissent les signaux de confiance.
3. Métadonnées de lineage, le graphe de dépendances (traité en profondeur dans la prochaine leçon, mais il vit dans le catalog).
4. Métadonnées métier, définitions, propriété, classification de sensibilité, statut de certification.

Le mode d'échec de la plupart des entreprises consiste à inverser cet ordre : investir des efforts dans un glossaire métier (point 4) en ignorant les signaux opérationnels (point 2). Vous finissez avec des tables magnifiquement documentées dont personne ne peut dire qu'elles sont cassées.

Ce qu'un catalog doit réellement produire

Les éditeurs vont vous vendre une matrice de fonctionnalités. Ignorez-la. **Jugez un catalog sur les *résultats* qu'il doit produire pour votre organisation**. Il y en a quatre, et vous devez tenir tout investissement, build ou buy, responsable des quatre.

1. Findability : réduire le time-to-data de plusieurs jours à quelques minutes

L'échec central que corrige un catalog, c'est la recherche. Quand un analyste ne trouve pas le bon dataset, l'une de ces trois mauvaises choses se produit : il utilise le mauvais, il reconstruit un dataset qui existe déjà (l'épidémie des copies fantômes), ou il ouvre un ticket et attend une semaine. Airbnb a construit son Dataportal interne précisément parce que les analystes passaient plus de temps à chasser les données qu'à les analyser, et que personne ne pouvait dire laquelle de plusieurs tables similaires faisait référence.

Une findability efficace n'est pas une recherche full-text sur les noms de tables. C'est une recherche classée et sensible au contexte : les assets les plus requêtés, les plus récemment mis à jour, les plus connectés remontent en premier, pondérés par l'équipe et le rôle de celui qui cherche. C'est là que les métadonnées actives justifient leur coût, la popularité et la fraîcheur sont des signaux observés, pas curés.

2. Compréhensibilité : le contexte voyage avec l'asset

Trouver une table nommée fct_revenue_daily ne vaut rien si vous ne savez pas ce que signifie un « jour » (date de réservation ? date de comptabilisation ? UTC ?). La compréhensibilité signifie que chaque asset porte sa définition, son propriétaire, son lineage, des valeurs d'exemple et les limites connues, et que ce contexte est à un clic de là où l'analyste travaille.

Le jugement à porter ici est celui de la profondeur de curation contre la couverture. Vous ne pouvez pas documenter à la main 200 000 tables. Alors vous les hiérarchisez. Certifiez à un niveau élevé les 3 à 5 % qui alimentent le reporting de direction et les produits destinés aux clients. Laissez la longue traîne être documentée automatiquement et annotée par la communauté. Un CDO qui exige une qualité de documentation uniforme sur l'ensemble du patrimoine garantit que le projet ne se terminera jamais.

3. Confiance : certification et signaux de qualité à découvert

C'est le problème du réassureur. La confiance s'obtient par deux mécanismes qui fonctionnent ensemble :

• La certification, un tampon explicite et engageant indiquant qu'un data owner nommé se porte garant de cet asset pour un usage défini. Pas une case à cocher. Une signature avec une personne derrière.
• Les signaux automatisés de qualité et de fraîcheur, les métadonnées opérationnelles observées, affichées en ligne. « Dernière mise à jour il y a 3 heures. 6 contrôles de qualité sur 6 passés. Certifié Gold par l'équipe Finance Data. »

La magie vient de leur combinaison. Une certification sans signaux en direct est une promesse périmée. Des signaux sans certification sont un bruit dont personne ne sait quoi faire. Ensemble, ils permettent à un analyste de répondre à *« puis-je faire confiance à ce chiffre ? »* en quelques secondes, et vous permettent de tuer à la racine le problème des 14 définitions, parce que l'asset certifié surclasse visiblement les copies fantômes.

4. Activation de la gouvernance : une politique appliquée, pas seulement documentée

Votre module de gouvernance vous a enseigné le cadre de politique. Le catalog est l'endroit où la politique cesse d'être un PDF pour devenir une réalité appliquée. Les métadonnées actives rendent la classification *exécutable* : lorsque le catalog tague une colonne comme PII via un scan automatisé, ce tag peut se propager en aval à travers le lineage et déclencher automatiquement du masking, des restrictions d'accès ou des règles de rétention.

C'est le tissu conjonctif entre le catalog et vos investissements existants en gouvernance et conformité. Un tag qui se contente d'informer est passif. **Un tag qui *agit*, qui révoque un accès ou masque un champ, c'est le retour sur investissementretour sur investissementReturn on Investment : le rapport entre le profit net et le coût d'un investissement. Un ROI de 300 % signifie que chaque dollar investi en rapporte 3.Voir la définition complète →**.

Les décisions de build-vs-buy et de déploiement

Build, buy ou open-source

Les géants de la tech ont construit le leur, Dataportal chez Airbnb, DataHub chez LinkedIn, Amundsen chez Lyft, Databook chez Uber, parce que leur échelle et leur profondeur d'ingénierie le justifiaient, et plusieurs ont ouvert le résultat en open-source. Pour presque toutes les autres entreprises, construire est une erreur stratégique. Vous passerez deux ans à réinventer des connecteurs au lieu de piloter l'adoption.

La vraie décision se joue entre les plateformes commerciales (Alation, Collibra, Atlan, Informatica) et l'open-source mature (DataHub, OpenMetadata). Tranchez sur trois axes :

• La couverture des connecteurs pour *votre* stack réelle. La première source d'échec d'un catalog est un outil incapable de collecter automatiquement depuis vos systèmes clés, ce qui impose une saisie manuelle que personne ne tient dans le temps.
• La surface d'activation, l'outil renvoie-t-il les métadonnées dans vos outils de BI et vos éditeurs de requêtes, ou se contente-t-il de les afficher dans sa propre interface ?
• Le coût total de possession, où l'open-source échange les frais de licence contre les effectifs d'ingénierie nécessaires pour l'exploiter.

La séquence de déploiement qui fonctionne réellement

Ne tentez pas un catalog big-bang sur l'ensemble du patrimoine. C'est ainsi que ces programmes meurent. Séquencez :

1. Commencez par un domaine à forte douleur et forte visibilité. Le reporting financier ou l'analytics client, un endroit où la douleur du « quel chiffre croire » est aiguë et où une victoire est visible par la direction.
2. Collectez d'abord automatiquement tout le technique et l'opérationnel. Faites circuler les signaux générés par la machine avant de demander à un seul humain de documenter quoi que ce soit. Cela prouve la valeur sans aucune charge manuelle.
3. Certifiez les quelques éléments critiques. Mettez le nom des propriétaires sur les assets qui comptent le plus dans votre domaine de tête de pont.
4. Instrumentez l'adoption dès le premier jour. Suivez les sessions de recherche dans le catalog, les clics vers les assets et, surtout, la réduction des tickets « où sont les données ? » et de la crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éation de datasets dupliqués.
5. Étendez domaine par domaine, en utilisant chaque succès pour financer le suivant.

L'indicateur qui prédit le succès n'est pas le nombre de tables cataloguées. C'est le nombre d'utilisateurs actifs hebdomadaires parmi les analystes. Un catalog que personne n'ouvre est un actif immobilisé, quelle que soit son exhaustivité.

Le piège organisationnel : le catalog est un produit, pas un projet

La façon la plus courante dont un investissement dans un catalog échoue est de le traiter comme une implémentation ponctuelle. Vous achetez l'outil, vous lancez le scan, vous déclarez victoire, et dix-huit mois plus tard les métadonnées se sont dégradées et l'adoption s'est effondrée.

Un catalog est un produit vivant avec un propriétaire permanent, une roadmap et une boucle de feedback. Quelqu'un, généralement un responsable gouvernance ou plateforme data qui vous est rattaché, porte l'adoption du catalog comme un KPIKPIKey Performance Indicator : une valeur mesurable qui montre l'efficacité avec laquelle vous atteignez un objectif précis, suivie dans le temps par rapport à une cible.Voir la définition complète → continu. Cette personne observe ce que les gens cherchent sans trouver, et comble ces manques. Elle impose qu'aucun nouveau data product n'atteigne la production sans enregistrement dans le catalog et propriétaire assigné (câblez cela dans votre pipeline de déploiement comme un gate, pour que ce soit automatique et non velléitaire).

Le modèle de stewardship compte autant que l'outil. La propriété fédérée, où les équipes de domaine certifient leurs propres assets selon des standards centraux, passe à l'échelle ; la propriété centralisée non. C'est l'expression opérationnelle de la logique data-as-a-product que vous approfondirez ailleurs dans ce parcours : chaque dataset a un propriétaire responsable de sa présence dans le catalog, exactement comme un product manager possède un produit.

Les organisations qui gagnent traitent les indicateurs de qualité du catalog, pourcentage d'assets critiques certifiés, pourcentage avec propriétaire assigné, fraîcheur de la documentation, comme des KPI de gouvernance de premier rang, présentés aux côtés de la conformité et de la qualité. Celles qui perdent traitent le catalog comme de la plomberie IT et se demandent pourquoi les 14 définitions sont revenues.

Points clés

• Exigez des métadonnées actives, pas passives. Avant d'approuver tout investissement dans un catalog, appliquez le test en deux volets : la métadonnée est-elle *observée* (collectée depuis les systèmes en fonctionnement) plutôt que simplement déclarée, et *revient-elle en flux* dans les outils où les gens travaillent réellement ? Un catalog qui ne fait qu'ingérer est un musée ; celui qui ingère et active est une infrastructure.

• Priorisez les signaux opérationnels sur le glossaire métier. La fraîcheur, la fréquence de requêtage et les taux d'échec créent la confiance automatiquement. Documenter des définitions en ignorant si une table est cassée inverse l'ordre de valeur et produit des datasets magnifiquement décrits sur lesquels personne ne peut compter.

• Combinez certification et signaux de qualité en direct pour tuer le problème du « quel chiffre croire ». La signature d'un propriétaire nommé plus des contrôles automatisés de fraîcheur et de qualité affichés en ligne permettent à un analyste de décider en quelques secondes, et font que l'asset certifié surclasse visiblement les copies fantômes.

• Séquencez le déploiement : domaine à forte douleur d'abord, collecte automatique avant documentation manuelle, certification des quelques éléments critiques, puis extension. Ne tentez jamais un catalog big-bang. Mesurez le succès par le nombre d'analystes actifs hebdomadaires et la réduction des datasets dupliqués, pas par le nombre de tables cataloguées.

• Pilotez le catalog comme un produit, avec un propriétaire permanent et un gate dans le pipeline. Une certification fédérée, portée par les domaines selon des standards centraux, passe à l'échelle ; une implémentation ponctuelle se dégrade. Câblez l'enregistrement dans le catalog dans votre processus de déploiement pour qu'il soit imposé et non espéré.