Le champ TRANS-AMT-CD Ce programme COBOL est en production depuis 1981. L'entrée FD le définit comme PIC S9(9)V99 COMP-3TRANS-AMT-CD est un champ numérique décimal signé compacté, à onze chiffres et deux décimales implicites. Ce sont les métadonnées techniques. Les métadonnées métier, à savoir la signification de TRANS-AMT-CD, la devise utilisée, l'unité de mesure des deux décimales implicites (cents ou points de base), la nature d'un crédit ou d'un débit pour une valeur négative, et l'interprétation d'une valeur nulle, sont absentes du code source. Elles figuraient dans un document de spécifications fonctionnelles imprimé en 1981, archivé dans une armoire et jamais revu depuis. Les deux développeurs qui connaissaient initialement la signification de TRANS-AMT-CD ont pris leur retraite en 2014.
C’est le problème des métadonnées auquel est confrontée toute organisation disposant de systèmes de données s’étendant sur plusieurs décennies, et c’est un problème que les cadres modernes de gouvernance des données n’ont pas été conçus pour résoudre. Collibra, Alation, Atlan et toutes les autres plateformes de catalogue de données d’entreprise excellent dans la gouvernance des métadonnées pour les données déjà décrites, les bases de données cloud avec des schémas documentés, les entrepôts de données avec une sémantique de colonnes définie et les points de terminaison d’API avec des spécifications OpenAPI. Elles ne sont pas conçues pour reconstruire des métadonnées qui n’ont jamais été formellement capturées, qui n’existent que dans le comportement de programmes écrits avant que la gestion des métadonnées ne devienne une discipline, et qui ont été modifiées par des dizaines de développeurs pendant quatre décennies sans que personne ne mette à jour un enregistrement central de la signification de chaque champ.
La gestion des métadonnées pour les systèmes de données pluridécennaux ne pose pas les mêmes problèmes que celle des systèmes modernes. Elle exige une approche fondamentalement différente, qui consiste à extraire les métadonnées des artefacts sources plutôt qu'à les ingérer à partir des systèmes connectés.
Trouver du sens avant qu'il ne prenne sa retraite
SMART TS XL extrait les métadonnées techniques au niveau du champ des entrées FD et des copybooks avant que les outils de catalogage puissent les gérer.
EN SAVOIR PLUS…Les trois couches de métadonnées héritées
Pour comprendre le problème des métadonnées dans les systèmes multi-décennaux, il faut reconnaître que les métadonnées dans ces environnements existent en trois couches distinctes, chacune ayant une extractibilité, une exhaustivité et des implications en matière de gouvernance différentes.
Les métadonnées techniques constituent la couche la plus facilement extractible. Elles décrivent la structure physique des données : noms des champs, types de données, longueurs, positions dans les enregistrements, spécifications de précision numérique et relations entre les champs au sein d'une structure d'enregistrement. Dans les environnements COBOL, les métadonnées techniques sont présentes dans les artefacts du code source : les entrées FD définissent les structures d'enregistrement, les membres COPY définissent les structures de données réutilisables, les clauses SELECT définissent l'organisation des fichiers et les méthodes d'accès, et les instructions DD du JCL définissent les jeux de données associés à chaque exécution de programme. Cette couche est en principe lisible par machine ; un analyseur syntaxique capable de comprendre la syntaxe COBOL peut l'extraire du code source. Cependant, elle est répartie dans des milliers de fichiers sources plutôt que centralisée dans un registre de schémas.
Les métadonnées opérationnelles décrivent la circulation des données au sein du système : quels programmes produisent quels jeux de données, quels programmes les utilisent, dans quel ordre et quelles transformations ils subissent. Dans les environnements mainframe, ces métadonnées sont réparties entre les flux de travaux JCL (qui définissent les séquences d’exécution et les associations de jeux de données), les graphes d’appels de programmes (qui définissent le flux de données entre les programmes) et la configuration du planificateur (qui définit la synchronisation et les dépendances). Cette couche est également extractible par machine à partir des artefacts sources, mais cette extraction nécessite de comprendre non seulement les programmes individuels, mais aussi les relations qui les unissent.
Métadonnées métier ou sémantiques est la couche la moins extractible et la plus précieuse. Elle répond aux questions que les métadonnées techniques ne peuvent pas répondre : que fait-elle ? TRANS-AMT-CD Que signifie concrètement en termes commerciaux ? Quelles sont les valeurs valides pour ACCT-TYPE-CD Que signifie chaque valeur ? Quelle règle métier détermine quand ? CUST-STATUS-FLG transitions de A à ICette couche existe, lorsqu'elle existe, dans les documents de spécification, dans la mémoire des développeurs, dans les connaissances institutionnelles détenues par des employés qui ont pu prendre leur retraite, et dans la logique procédurale des programmes qui appliquent les règles métier par le biais d'instructions IF et de blocs EVALUATE plutôt que par le biais de contraintes de base de données.
Le défi posé par les métadonnées pour les systèmes s'étendant sur plusieurs décennies réside dans le fait que ces trois couches ont été gérées différemment, voire pas du tout, au fil des décennies d'évolution du système. Les métadonnées techniques étaient intégrées au code source, mais jamais formalisées dans un dictionnaire de données. Les métadonnées opérationnelles étaient implicites dans les flux de tâches JCL, mais jamais documentées dans un historique. Les métadonnées métier étaient documentées dans les spécifications lors du développement initial et n'ont jamais été mises à jour au fur et à mesure de l'évolution des systèmes.
Le problème de la dérive des métadonnées
Chaque année, lorsqu'un système fonctionnant depuis plusieurs décennies ne fait pas l'objet d'une gestion systématique des métadonnées, l'écart entre les métadonnées présentes dans la documentation officielle et celles reflétant le comportement actuel réel du système se creuse. Cette dérive s'explique par quatre mécanismes :
Domaine signifiant évolution. Un domaine défini avec une seule signification commerciale en 1978 peut avoir accumulé des significations supplémentaires au cours des décennies suivantes. ACCT-TYPE-CD Il est possible qu'à l'origine, ce champ permettait de distinguer les comptes courants des comptes d'épargne. Au cours des quarante dernières années, des codes supplémentaires ont pu être ajoutés pour représenter les comptes du marché monétaire, les certificats de dépôt, les comptes IRA et les comptes séquestres. Chaque ajout est documenté uniquement dans le code du programme qui gère la nouvelle valeur du code, et non dans une définition de champ centrale. Le nom et le type du champ sont restés inchangés ; sa signification, en revanche, s'est considérablement complexifiée.
Réutilisation silencieuse. Il arrive que des champs soient réutilisés sans être renommés. Un champ initialement conçu pour un usage précis devient difficile à étendre, et un développeur peut alors utiliser une valeur inutilisée d'un champ indicateur adjacent pour encoder une autre information. TRANS-FLAG-1 Ce champ peut désormais encoder trois concepts différents selon le contexte du programme, discernables uniquement en examinant quels programmes lisent ce champ et dans quelles conditions. Les métadonnées techniques (nom, type et longueur du champ) ne fournissent aucune indication de cette surcharge sémantique.
Accumulation REDEFINES. Comme expliqué dans le cadre de l'analyse VSAM, les clauses REDEFINES superposent différentes interprétations de champs à un même espace de stockage physique. Chaque variante REDEFINES peut avoir été ajoutée à un moment différent de l'historique du système, par différents développeurs, et pour des raisons métier distinctes. La signification sémantique complète d'une hiérarchie REDEFINES (quelle variante s'applique et quand, signification des champs de chaque variante) ne peut être reconstituée qu'en analysant tous les programmes qui accèdent à chaque variante et les conditions dans lesquelles ils le font.
Divergence des copybooks. Lorsqu'un copybook COBOL standard est modifié pour répondre à une nouvelle exigence, les programmes qui l'incluent et n'ont pas été mis à jour pour gérer le nouveau champ peuvent présenter un comportement incorrect, voire ignorer ce dernier. Au fil des décennies, plusieurs versions d'un même copybook peuvent coexister dans différentes bibliothèques, et différents programmes peuvent utiliser des versions différentes. Les métadonnées d'un champ défini dans le copybook peuvent donc varier d'un programme à l'autre selon la version du copybook utilisée par chaque programme.
Ce que les outils de métadonnées modernes ne peuvent pas faire pour les données héritées
Le marché des catalogues de données d'entreprise a considérablement mûri. Collibra, Alation, Atlan, Microsoft Purview et Informatica Axon sont des plateformes sophistiquées permettant de gérer les métadonnées dans les environnements de données modernes. Elles excellent notamment dans : la découverte automatique des schémas à partir des bases de données connectées, le suivi de la traçabilité des données au niveau des colonnes tout au long des pipelines ETL, la maintenance des glossaires métiers avec des définitions de termes validées et l'affichage des indicateurs de qualité des données en parallèle des enregistrements de métadonnées.
Ce que ces outils ne peuvent pas faire pour les systèmes COBOL et mainframe datant de plusieurs décennies :
Il est impossible de se connecter à ce qui est invisible. Les catalogues modernes découvrent les métadonnées via des connecteurs, des connexions JDBC aux bases de données, des intégrations API avec les services cloud et des intégrations de scanners avec les plateformes compatibles. Les fichiers VSAM, les programmes COBOL et les flux de travaux JCL ne disposent pas de connecteurs de catalogue standard. Le catalogue ne peut donc pas accéder à ce qui lui est inaccessible. Les données gérées par ces systèmes sont de fait invisibles pour le catalogue, ce qui signifie que les enregistrements de traçabilité nécessaires à l'analyse cloud en aval, dérivés de ces données, sont incomplets, voire absents.
Ils ne peuvent pas extraire les métadonnées qui existent uniquement dans le code. Un catalogue de données connecté à une base de données DB2 peut lire le schéma de la base, les définitions de tables, les noms de colonnes, les types de données et les index. En revanche, il ne peut pas lire le programme COBOL qui alimente la table DB2 pour comprendre les règles métier qui régissent cette alimentation, les variantes REDEFINES présentes dans l'enregistrement source, ni les noms de conditions de niveau 88 qui définissent la validité sémantique de chaque champ. Les métadonnées au niveau du code, c'est-à-dire la couche où réside la signification métier des données héritées, nécessitent une analyse du code, et non une analyse du catalogue.
Il est impossible de reconstituer un sens qui n'a jamais été saisi. Même avec une extraction parfaite des métadonnées techniques, la signification métier des champs non documentés formellement ne peut être reconstituée automatiquement. Cette étape requiert une combinaison d'analyse de code (pour identifier les règles métier appliquées aux données par les programmes, lesquelles constituent des indicateurs de leur signification métier) et de vérification humaine (pour valider la signification reconstituée au regard des connaissances institutionnelles, tant que celles-ci sont encore disponibles).
L'approche de reconstruction des métadonnées
Pour les systèmes s'étendant sur plusieurs décennies et dont les métadonnées formelles n'ont jamais été capturées ou ont considérablement dévié de la réalité actuelle, la gestion des métadonnées exige une phase de reconstruction avant toute phase de gouvernance. Cette approche de reconstruction consiste à extraire les couches récupérables et à identifier les lacunes nécessitant une expertise humaine.
Phase 1 : Extraction des métadonnées techniques à partir des artefacts sources.
Analyser chaque entrée COBOL FD, membre COPY, clause SELECT et instruction JCL DD pour produire un inventaire des métadonnées techniques au niveau des champs :
Cobol
* Source FD entry -- technical metadata extraction target
FD TRANSACTION-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 200 CHARACTERS.
01 TRANSACTION-RECORD.
05 TRANS-DATE PIC 9(8). *> YYYYMMDD format
05 TRANS-TYPE-CD PIC XX. *> See 88-level values
88 TRANS-PAYMENT VALUE 'PM'.
88 TRANS-REFUND VALUE 'RF'.
88 TRANS-ADJUSTMENT VALUE 'AJ'.
88 TRANS-REVERSAL VALUE 'RV'.
05 TRANS-AMT-CD PIC S9(9)V99 COMP-3.
05 TRANS-CURRENCY-CD PIC X(3). *> ISO 4217
05 TRANS-DETAIL REDEFINES TRANS-TYPE-CD.
10 TRANS-MERCH-ID PIC X(12).
10 TRANS-AUTH-CD PIC X(6).
10 FILLER PIC X(84).À partir de cette unique entrée FD, l'extraction des métadonnées techniques produit : les noms de champs, les types de données, les longueurs, les positions, la précision décimale compressée de TRANS-AMT-CD (9 chiffres, 2 décimales, signé), les quatre valeurs sémantiques de TRANS-TYPE-CD tel que défini par les noms de conditions de niveau 88 et la structure REDEFINES qui crée deux interprétations qui se chevauchent des octets 10 à 105 de l'enregistrement.
Les noms des conditions de niveau 88 sont particulièrement précieux en tant que métadonnées : TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL Il s'agit de quatre éléments de vocabulaire métier fournis par le code COBOL lui-même, plus significatifs que le vocabulaire sous-jacent. PM, RF, AJ, RV valeurs que verrait un catalogue de données analysant la base de données.
Phase 2 : Extraction des métadonnées opérationnelles à partir des dépendances du programme.
Construisez la carte de lignage opérationnel en traçant les flux de données à travers le graphe de dépendance du programme :
- Quels programmes écrivent dans
TRANSACTION-FILE(producteurs) - Quels programmes lisent à partir de
TRANSACTION-FILE(consommateurs) - Quelles étapes du JCL invoquent chaque producteur et consommateur, et dans quel ordre ?
- Quels ensembles de données et bases de données en aval reçoivent des données transformées à partir de
TRANSACTION-FILE
Cette carte de lignage représente les métadonnées opérationnelles dont les outils de catalogage de données ont besoin pour la visualisation du lignage, mais qu'ils ne peuvent pas construire sans accès au code source du programme et au JCL.
Phase 3 : Extraction des règles métier en tant que proxy de métadonnées sémantiques.
Les règles métier encodées dans la logique COBOL PROCEDURE DIVISION sont des représentations de la signification métier. Un programme qui valide TRANS-AMT-CD pour s'assurer qu'elle se situe dans certaines plages avant le traitement, il faut fournir des preuves concernant la plage de validité du champ. Un programme qui convertit TRANS-AMT-CD Le fait de passer à une unité différente avant d'écrire dans un système en aval révèle une convention décimale ou d'unité implicite.
L'extraction de ces règles métier par l'analyse du code produit un ensemble de métadonnées sémantiques inférées : les plages de validation appliquées à chaque champ, les transformations entre la source et la cible, et les conditions d'exécution des différents chemins d'exécution. Ces métadonnées sémantiques inférées sont imprécises ; elles indiquent comment les programmes traitent les données, et non nécessairement leur signification initiale. Cependant, elles sont récupérables à partir du code, contrairement au document de spécification original.
Phase 4 : Validation humaine et enrichissement sémantique.
Les métadonnées techniques et opérationnelles extraites, ainsi que les métadonnées sémantiques inférées, constituent la base de sessions de validation humaine avec des experts du domaine et des développeurs partant à la retraite. L'objectif est de convertir la sémantique inférée en sémantique confirmée, validant ainsi que TRANS-AMT-CD signifie ce que le code suggère, identifiant les cas où le comportement du code ne reflète plus la signification métier prévue et capturant les connaissances institutionnelles sur l'historique du domaine que l'analyse du code ne peut pas récupérer.
Cette phase est limitée dans le temps par la disponibilité de l'expertise du domaine : chaque année qui passe, une part croissante de ce savoir disparaît avec ceux qui le détenaient.
Le déficit de métadonnées héritées à la frontière des systèmes modernes
Le déficit de métadonnées engendré par les systèmes datant de plusieurs décennies ne se limite pas à l'environnement existant. Il se propage en aval : chaque système analytique, entrepôt de données et pipeline d'apprentissage automatique qui exploite des données issues de ces systèmes hérités subit ce manque de métadonnées.
Un entrepôt de données cloud qui reçoit chaque nuit un extrait de fichier plat issu d'un programme batch COBOL a, dans ses définitions de colonnes, les noms que l'équipe d'ingénierie des données a choisis pour les colonnes lors de la création du pipeline ETL. Si le champ d'origine était TRANS-AMT-CD et le développeur ETL a nommé la colonne cible transaction_amountL'entrepôt de données semble disposer de métadonnées complètes : nom de colonne, type de données et description métier ajoutés au catalogue. Ce que le catalogue n'enregistre pas, c'est que… transaction_amount originaire de TRANS-AMT-CD in TRANSACTION-FILE, qui est produit par un programme COBOL nommé TRNSRC01, qui s'exécute dans une tâche JCL TRANSDAY chaque nuit à 2 heures du matin, et qui applique une conversion de devises spécifique codée en dur en 1987 sur la base d'une convention de taux de change qui peut ou non être encore en vigueur.
L'enregistrement des métadonnées en aval semble complet. La traçabilité est interrompue au niveau de la limite héritée. Toute charge de travail analytique ou d'IA qui dépend de la compréhension de la provenance et de la signification de transaction_amount présente une lacune : l’histoire de l’origine réelle de cette valeur n’est pas documentée.
Le constat de Gartner selon lequel 60 % des projets d'IA non étayés par des données exploitables seront abandonnés d'ici 2026 repose en partie sur une question de métadonnées. Les modèles d'IA qui consomment transaction_amount Sans savoir que ces données proviennent d'un champ COBOL décimal compacté avec une virgule implicite, libellé dans une devise ayant pu être convertie selon la convention de change de 1987, le modèle est entraîné sur des données dont la provenance est opaque. Il ne peut ni se méfier de ce contexte ni s'y adapter, car les métadonnées permettant de le signaler sont absentes de tout catalogue accessible au modèle ou à son pipeline de données.
Élaboration d'un programme de gestion des métadonnées pour les systèmes existants
Un programme de gestion des métadonnées pour les systèmes de données pluridécennaux comporte quatre composantes qui diffèrent des implémentations standard de catalogues de données d'entreprise :
Composant 1 : Extraction des métadonnées du code source. Avant qu’un outil de catalogage puisse gérer les métadonnées existantes, celles-ci doivent être extraites des artefacts sources où elles résident. Cette extraction doit couvrir : les entrées FD et les copybooks (métadonnées techniques des structures de données), les clauses SELECT (organisation des fichiers et méthode d’accès), les instructions DD JCL (associations d’ensembles de données et caractéristiques des fichiers) et les noms de conditions de niveau 88 (vocabulaire de valeurs sémantiques intégré au code source). Le résultat est un inventaire des métadonnées au niveau des champs, qui peut être chargé dans un catalogue comme point de départ pour l’enrichissement des métadonnées métier.
Composante 2 : Reconstruction de la lignée. La lignée des données des systèmes existants doit être reconstruite à partir d’une analyse des dépendances des programmes, et non par le suivi de la lignée effectué par un outil ETL. La cartographie de la lignée retrace les données depuis leur programme COBOL d’origine, en passant par les programmes de transformation intermédiaires, jusqu’à leurs utilisateurs finaux, y compris les processus ETL qui les acheminent vers les systèmes analytiques modernes. Cette reconstruction comble le manque de lignée au niveau de la limite des systèmes existants, en reliant les métadonnées des colonnes de l’entrepôt de données cloud aux métadonnées des entrées COBOL FD grâce à une chaîne documentée de dépendances de programmes.
Composante 3 : Enrichissement sémantique grâce à l'expertise du domaine. Les métadonnées techniques extraites fournissent la structure ; la confirmation de leur signification métier requiert une expertise du domaine. Le processus d’enrichissement utilise les métadonnées techniques comme guide structuré pour les entretiens avec les experts : « Ce champ est défini comme PIC S9(9)V99 COMP-3Cette valeur est validée comme non négative dans 14 programmes, puis convertie à une autre échelle avant d'être écrite dans la base de données en aval. Pouvez-vous confirmer ce qu'elle représente et ce que signifie cette conversion ? Cette approche structurée utilise l'analyse de code pour maximiser la valeur informative de chaque interaction avec un expert, permettant un enrichissement plus rapide et plus complet que les revues de documentation non structurées.
Composant 4 : Intégration de la gouvernance aux plateformes de catalogue modernes. Une fois les métadonnées existantes extraites, reconstruites et enrichies, elles doivent être intégrées à l’infrastructure de gouvernance des métadonnées modernes. Cette intégration relie l’inventaire des métadonnées existantes au catalogue de données d’entreprise, fournissant : une traçabilité au niveau des colonnes, de la source COBOL à la cible cloud ; des termes du glossaire métier liés aux définitions de champs existantes ; et des métadonnées de qualité des données pour les jeux de données existants, alimentant le même cadre de gouvernance que les métadonnées des systèmes modernes.
Comment SMART TS XL Extrait les métadonnées héritées
SMART TS XL Il traite les deux premiers composants du programme de gestion des métadonnées héritées, l'extraction des métadonnées du code source et la reconstruction de la lignée, en appliquant une analyse statique à l'ensemble du portefeuille COBOL, JCL et copybook.
La fonctionnalité d'analyse statique du code analyse chaque entrée de descripteur de fichier (FD), membre COPY, clause SELECT et définition de niveau 88 de l'ensemble du portefeuille COBOL, générant ainsi l'inventaire des métadonnées techniques au niveau des champs : nom de champ, type de données, longueur, spécification COMP, appartenance à REDEFINES et nom de condition de niveau 88 pour chaque programme et copybook de l'environnement. Pour un portefeuille de milliers de programmes COBOL, cette extraction produit en quelques heures l'inventaire des métadonnées techniques dont la production par documentation manuelle prendrait des années, voire serait impossible.
La cartographie des dépendances applicatives établit la cartographie de la lignée opérationnelle : chaque relation entre un programme et un jeu de données (quels programmes produisent quels jeux de données et lesquels les utilisent), chaque dépendance entre programmes (quels programmes appellent quels autres programmes et quelles données circulent entre eux), et chaque relation entre un JCL et un programme (quelles étapes de tâche invoquent quels programmes et dans quel ordre). Cette cartographie de la lignée constitue la couche de métadonnées opérationnelles qui assure la liaison entre les systèmes sources existants et les enregistrements de lignée du catalogue de données moderne.
La capacité d'expansion JCL retrace la chaîne d'exécution complète de chaque tâche JCL : résolution des références PROC, expansion des paramètres symboliques et construction des métadonnées opérationnelles complètes pour la production et la consommation de chaque ensemble de données, le contexte de planification, les tâches dépendantes et la séquence d'exécution qui détermine les caractéristiques de ponctualité et de fraîcheur de chaque ensemble de données.
La fonction de recherche d'entreprise permet d'interroger l'inventaire des métadonnées extraites dans l'ensemble du système de gestion des métadonnées : elle permet de trouver chaque champ défini comme COMP-3 (champs sensibles à la précision nécessitant un mappage cible rigoureux), chaque programme qui lit un champ spécifique (identification de tous les utilisateurs d'une donnée spécifique pour l'enrichissement sémantique et la traçabilité), et chaque nom de condition de niveau 88 correspondant à un terme métier spécifique (mise en correspondance du vocabulaire métier avec les définitions techniques des champs). Cette fonction de recherche facilite l'enrichissement sémantique, permettant aux experts du domaine de trouver toutes les utilisations d'un champ ou d'une valeur spécifique avant d'en confirmer la signification métier.
Pour les organisations menant modernisation de l'héritage programmes, SMART TS XLL'extraction de métadonnées de fournit les bases de la pré-migration : les métadonnées techniques au niveau des champs dont les outils de migration ont besoin pour mapper les champs sources aux schémas cibles, la lignée opérationnelle dont les programmes de migration ont besoin pour séquencer correctement les migrations d'ensembles de données, et le vocabulaire sémantique de niveau 88 qui permet un mappage précis des valeurs de code COBOL aux définitions de contraintes relationnelles.
L'urgence de la récupération des métadonnées avant que le savoir ne disparaisse
Le problème de la reconstruction des métadonnées est soumis à une échéance naturelle qui ne s'applique pas à la plupart des enjeux de gouvernance des données : le départ à la retraite des développeurs qui détiennent le savoir institutionnel que l'analyse de code ne peut retrouver. Près d'un tiers des programmeurs COBOL prendront leur retraite d'ici 2030. L'âge moyen d'un ingénieur mainframe est de 58.7 ans. Chaque année qui passe sans extraction systématique des métadonnées ni enrichissement sémantique réduit la période pendant laquelle la validation humaine des métadonnées récupérées est possible.
Les métadonnées techniques (définitions de champs, spécifications de types, dépendances du programme, traçabilité des données) sont récupérables indéfiniment à partir du code source, tant que celui-ci existe. Les métadonnées sémantiques (signification métier de chaque champ, historique des choix de conception des champs, conventions implicites non documentées par les spécifications techniques) ne peuvent être récupérées qu'auprès des personnes qui les connaissent et uniquement tant qu'elles sont disponibles.
Un programme de gestion des métadonnées pour les systèmes s'étendant sur plusieurs décennies, qui débute par l'extraction technique et se poursuit par l'enrichissement sémantique tant que l'expertise du domaine est encore disponible, produit une base de métadonnées complète et récupérable. Le même programme, différé jusqu'à la disparition des connaissances, produit une base de métadonnées techniques exacte mais incomplète : correcte quant à la structure des données, mais muette sur leur signification.
Les métadonnées sont la carte. Des systèmes datant de plusieurs décennies l'ont enfouie.
La gouvernance des données pour les systèmes modernes repose sur des métadonnées à jour, accessibles et au moins partiellement documentées. Pour les systèmes s'étendant sur plusieurs décennies, elle repose sur des métadonnées dispersées dans des milliers de fichiers de code source, partiellement documentées dans des spécifications antérieures à Internet et partiellement conservées dans la mémoire de développeurs proches de la retraite.
Le processus, de l'enfouissement à la gouvernance, passe par l'extraction, la reconstruction et l'enrichissement, dans cet ordre. Les métadonnées techniques extraites du code source constituent l'inventaire initial. La lignée opérationnelle reconstituée à partir des dépendances du programme fournit la carte de provenance. L'enrichissement sémantique, validé par l'expertise du domaine, apporte le sens métier qui rend les métadonnées techniques exploitables pour l'analyse, l'IA et la gouvernance.
Les plateformes modernes de catalogue de données sont la destination de ces métadonnées, et non leur point de départ. Avant que Collibra puisse les gérer, qu'Alation puisse les cataloguer et que les data scientists puissent leur faire confiance, les métadonnées contenues dans les systèmes vieux de plusieurs décennies doivent d'abord être localisées : dans les entrées FD, dans les copybooks, dans les noms de conditions de niveau 88 et dans les règles métier encodées au cours de quarante années de logique PROCEDURE DIVISION.
La carte existe. Il suffit de la lire.
