Comment un graphe global révèle les appels cachés

Un graphe de dépendances n'est honnête que si sa frontière d'analyse l'est aussi. L'analyse dépôt par dépôt peut sembler précise et complète tout en restant presque inutile : les appels qui déterminent si une réécriture conserve le comportement passent souvent par un ordonnanceur, une base de données, un fichier généré, un copybook partagé ou un protocole qui n'appartient à aucun dépôt.

Lire tout l'arbre ensemble change l'unité d'analyse. Un programme COBOL et son JCL ne sont plus des ressources séparées. Un job RPG, un wrapper CL et une table alimentée par un import nocturne forment un même chemin d'exécution. Le graphe relie des preuves issues de plusieurs langages et indique aussi où elles s'arrêtent. Ce point compte : un graphe crédible distingue une arête prouvée d'une arête plausible au lieu de transformer chaque nom ressemblant en certitude.

J'ai vu des analyses par dépôt produire des schémas rassurants alors que le chemin de production passait par du code absent du dessin. L'analyseur fonctionnait. La question posée était trop étroite.

Les frontières des dépôts sont administratives

Un graphe limité à un dépôt décrit les références entre fichiers source dans un conteneur choisi. Un graphe du système décrit le déplacement du comportement parmi tous les éléments capables d'influencer une exécution. Ce ne sont pas les mêmes résultats, et les confondre conduit directement à un périmètre de migration incomplet.

Les dépôts reflètent généralement la responsabilité des équipes, les droits d'accès, les livraisons d'un fournisseur ou une ancienne migration. Le comportement à l'exécution ignore ces choix. Une requête Web peut commencer dans Classic ASP, appeler un composant COM écrit en VB6, exécuter une procédure stockée conservée dans le dépôt de la base et laisser du travail à un programme COBOL planifié. Chaque dépôt peut être bien compris sans que la transaction métier complète soit visible.

Le mot dépendance exige aussi de la rigueur. Une référence textuelle prouve qu'un artefact en nomme un autre. Une dépendance appelable signifie que la cible peut réellement recevoir le contrôle sous certaines conditions. Une dépendance comportementale signifie qu'une modification de la cible peut changer un résultat observé par un utilisateur ou un système aval. Les outils par dépôt réduisent souvent ces trois relations à la même ligne. Lors d'une réécriture, ce raccourci crée une confiance injustifiée et du travail inutile.

Le graphe utile doit donc contenir davantage que des fichiers et des fonctions. Il lui faut des jobs, objets de base, destinations de messages, artefacts générés, programmes externes, schémas, écrans, rapports et entrées de configuration lorsqu'ils participent au comportement. Chaque arête doit expliquer sa présence : appel direct, sélection dynamique, flux de données, planification, génération ou nom non résolu. Avec cette preuve, un ingénieur peut contester le graphe au lieu de l'admirer.

Ce modèle plus large n'impose pas de réunir tous les fichiers dans un dépôt. Gardez les dépôts et changez la frontière de l'analyse. La bonne frontière réunit les artefacts capables d'influencer le comportement réécrit, même si la propriété et le déploiement les séparent.

Les arêtes multilangages utilisent des mécanismes ordinaires

Les appels décisifs se présentent rarement comme une architecture multilangage. Ils prennent la forme de mécanismes ordinaires : chaîne de commande, nom de procédure stockée, étape de job, symbole exporté, destination de file ou nom du fichier destiné au processus suivant. Un parseur de langage voit la syntaxe. Un graphe système doit comprendre ce qu'elle provoque ailleurs.

Prenons une étape JCL contenant PGM=BILLRUN. L'arête ne s'arrête pas au jeton BILLRUN. L'analyse doit résoudre le programme dans les bibliothèques de chargement concernées, le relier à l'inventaire des sources ou binaires, et conserver l'incertitude lorsque plusieurs candidats existent. Dans le programme, un CALL WS-PROGRAM COBOL n'est pas un appel statique normal puisque la cible vient des données. Sa valeur peut provenir d'un copybook, d'un fichier de paramètres ou d'une lecture antérieure en base.

Le même schéma existe ailleurs. CL peut soumettre un programme RPG à une file batch. VB6 peut créer une classe COM à partir d'une chaîne du registre ou d'un fichier de configuration. ColdFusion peut appeler une procédure dont l'implémentation PL/SQL vit avec la base. Un monolithe PHP peut écrire un fichier de contrôle interprété comme instruction par un démon Perl. Aucune réflexion exotique n'est nécessaire. Ces arêtes disparaissent simplement parce que chaque parseur s'arrête à la limite de son langage ou dépôt.

Un artefact intermédiaire utile rend la jointure visible et vérifiable. Un fichier d'arêtes séparé par des tabulations peut porter la preuve minimale à inspecter :

source	target	mechanism	evidence
JCL:AR_CLOSE:STEP20	COBOL:BILLRUN	program-load	PGM=BILLRUN
COBOL:BILLRUN:PARA140	DB2:SP_POST_LEDGER	dynamic-sql	value-set:POST_LEDGER
DB2:SP_POST_LEDGER	TABLE:GL_ENTRY	write	INSERT INTO GL_ENTRY
CL:ENDDAY:CMD7	RPG:RECONCILE	submit-job	CALL PGM(RECONCILE)

Ce fichier n'est pas le graphe final. C'est un contrat entre l'extraction et la revue. Chaque ligne donne la source, la cible, le mécanisme et la preuve. Si l'outil ne peut pas remplir la dernière colonne, il ne doit pas tracer silencieusement une arête certaine.

Les noms se résolvent quand les preuves sont réunies

Les appels dynamiques ne sont pas forcément inconnaissables. Beaucoup deviennent résolubles quand l'analyse rassemble les affectations, la configuration, les métadonnées de build et les observations d'exécution de tout l'arbre. L'erreur consiste à traiter un site d'appel non littéral comme une impasse avant de chercher les valeurs qui peuvent l'atteindre.

Imaginons qu'un paragraphe COBOL appelle WS-NEXT-PGM. Un dépôt contient l'appel mais pas l'affectation. Du JCL dans un autre dépôt transmet un paramètre symbolique. Un copybook partagé définit la largeur du champ. Un export de table de contrôle contient les valeurs déployées. Séparément, l'appel reste non résolu. Ensemble, ces éléments permettent de dériver des candidats, d'exclure les valeurs trop longues et de relier les autres à l'inventaire des programmes.

La résolution doit rester fondée sur les preuves. J'utilise quatre états lors des revues : confirmé par la syntaxe, dérivé de valeurs bornées, observé dans le trafic enregistré et non résolu. Les noms importent moins que leur séparation. Un candidat dérivé aide à cadrer le périmètre, mais ne prouve pas que la production emprunte ce chemin. Un appel observé prouve sa présence dans l'échantillon, pas l'absence de toute autre cible.

C'est aussi le point faible de la simple correspondance de noms. POST, UPDATE ou CLOSE peuvent exister dans des dizaines d'espaces. Une correspondance devient crédible après application des règles de résolution de la plateforme, des contraintes du champ, de la convention d'appel, du contexte de déploiement et des affectations accessibles. L'analyse globale apporte plus de preuves, mais doit aussi mieux les distinguer. Davantage d'entrées sans règles produit seulement un graphe faux plus dense.

Le code généré exige le même traitement. Le générateur, ses modèles, ses entrées et l'artefact produit forment une chaîne. Analyser seulement la sortie fait prendre une conséquence pour l'autorité. Analyser seulement les modèles fait perdre les noms concrets du déploiement. Conservez les deux et marquez l'arête de génération afin de remonter d'un changement jusqu'à ce qui recréera le fichier.

Le déplacement des données est souvent l'appel manquant

Un graphe d'appels ne suffit pas à expliquer de nombreux systèmes anciens, car les données assurent le transfert. Un processus écrit une ligne, un fichier ou une entrée de spool, puis un autre l'interprète plus tard. Aucune fonction n'appelle directement la suivante, mais le premier programme commande le comportement du second. Pour la parité, c'est une dépendance.

Les traitements nocturnes le montrent bien. Une transaction en ligne écrit un code d'état dans une table. À la clôture, un ordonnanceur démarre un job batch. Le job sélectionne les lignes ayant ce code, produit un fichier à largeur fixe, puis un autre programme importe le fichier dans le grand livre. Les graphes locaux montrent quatre îlots. Le graphe du système montre une transaction dont les arêtes incluent un prédicat, un calendrier, un format d'enregistrement et une règle de nommage.

Considérer toute table partagée comme une dépendance créerait trop de bruit. Le graphe doit tenir compte de l'opération et des champs. Un programme qui modifie customer.last_seen n'influence pas forcément celui qui filtre customer.credit_hold. Modifier le champ d'état utilisé par le filtre crée en revanche une dépendance. Deux programmes qui ouvrent le même fichier ne sont pas liés s'ils utilisent des types d'enregistrements distincts.

Une arête de données pratique enregistre au moins l'objet, l'opération, les champs ou le format concernés et le prédicat qui déclenche le lecteur. Pour les fichiers batch, ajoutez le producteur, le consommateur, la règle de nommage, l'encodage, le séparateur ou les positions, ainsi que les totaux de contrôle vérifiés. Pour une procédure stockée, distinguez son appel de la lecture des tables qu'elle modifie. Ces détails indiquent où introduire sans risque un nouveau schéma ou une interface de service.

Une question gênante demeure : le graphe devient-il trop vaste ? Oui, si chaque coïncidence de données devient une arête certaine. Non, s'il offre des vues filtrées par transfert de contrôle, influence des données, planification, génération et incertitude externe. Le modèle unifié doit conserver les types d'arêtes au lieu d'aplatir toutes les flèches.

Même un arbre complet a un extérieur

Lire chaque fichier de l'arbre fourni ne donne pas une connaissance complète du système en cours d'exécution. Cela donne une connaissance complète de cet ensemble de preuves. Des ordonnanceurs externes, triggers, commandes d'opérateur, entrées de registre, routages middleware, binaires tiers et configurations de production peuvent ajouter un comportement que l'analyse du code ne peut prouver.

Beaucoup de rapports de modernisation deviennent trompeurs sur cette distinction. Ils disent que le graphe est complet quand l'analyseur a simplement terminé. La fin du scan ne dit pas si les entrées couvraient l'environnement d'exécution. Un bon résultat comprend une frontière explicite : les nœuds et arêtes qui dépassent les preuves fournies, avec la raison de chaque question ouverte.

Cette frontière peut prendre une forme concrète. Exportez les noms de programmes non résolus, objets externes, destinations de files, chemins et clés de configuration dans une table de revue. Attribuez à chaque élément un responsable et un état : fourni plus tard, externe vérifié, retiré ou encore inconnu. Ne supprimez pas un nœud parce que personne ne le reconnaît. Les anciens systèmes contiennent du code dormant, mais la reconnaissance ne prouve pas l'accessibilité.

Les observations d'exécution aident si personne ne les dit exhaustives. Le trafic de production enregistré peut confirmer un chemin et donner les valeurs de cibles dynamiques. Il ne prouve pas qu'une branche annuelle rare, une procédure de reprise ou une commande réservée à l'opérateur ne s'exécute jamais. Les preuves statiques donnent la structure possible, les preuves d'exécution le comportement observé. Leur recoupement est fort, leur désaccord doit être étudié.

Le graphe doit donc répondre séparément à deux questions : que peuvent provoquer les artefacts fournis, et qu'a réellement provoqué la charge enregistrée ? Un périmètre fondé sur la première vue peut conserver éternellement des chemins morts. Fondé sur la seconde, il peut supprimer une exception valide. Gardez les deux vues et rendez la décision explicite.

Une arête oubliée peut invalider une bonne réécriture

Une dépendance oubliée échoue généralement loin du code omis. Ce délai explique pourquoi les équipes sous-estiment les frontières des dépôts, puis accusent les tests quand la bascule révèle le véritable système.

Prenons une clôture mensuelle répartie dans quatre dépôts. Un programme RPG marque les comptes admissibles et appelle un wrapper CL. Le wrapper soumet un job dont le nom vient d'une zone de données. Du JCL sur un hôte relié lance le programme COBOL choisi. Celui-ci écrit un fichier d'exceptions à largeur fixe, puis un outil VB6 permet à un opérateur d'approuver les lignes avant leur comptabilisation par PL/SQL. Chaque dépôt a ses tests et chaque équipe connaît sa partie.

L'analyse locale trouve l'appel RPG vers CL et les écritures PL/SQL. Elle manque le programme soumis car son nom est une donnée, le JCL car il se trouve ailleurs et l'approbation graphique car le fichier sert d'interface. La réécriture remplace le premier segment par un service et reproduit ses mises à jour. Les tests automatiques réussissent sur des comptes normaux.

À la clôture, les exceptions restent non comptabilisées. Le nouveau service n'émet pas le fichier puisque personne n'a inclus cette sortie dans son contrat. L'outil de bureau n'affiche rien, l'opérateur ne peut rien approuver et aucune exception n'atteint la procédure. Le défaut ressemble à un problème d'interface ou de base, mais l'omission date du choix d'une frontière de service autour d'un seul dépôt.

Un graphe global aurait relié le chemin avec plusieurs types d'arêtes : appel, job soumis, programme planifié, production du fichier, action humaine et appel de procédure. Il aurait aussi identifié la zone de données et la règle de nommage comme entrées de contrôle. Les tests auraient pu enregistrer du trafic représentatif sur les chemins normal et exceptionnel, puis comparer les sorties à chaque frontière.

Il ne faut pas conserver chaque ancien artefact. Il faut comprendre avant de supprimer. Une fois le chemin visible, l'équipe peut remplacer le fichier et l'approbation VB6 par un client TypeScript et une API. C'est une modification d'architecture avec une obligation connue, pas une disparition accidentelle.

Transcrire le graphe conserve les mauvaises frontières

Créer un module moderne pour chaque ancien programme paraît prudent, car la correspondance est facile à auditer. C'est aussi le moyen de conserver des décennies d'accidents de déploiement. Le graphe doit préserver les obligations et révéler de meilleures frontières, pas dicter une traduction fichier par fichier.

Les anciennes frontières viennent souvent de limites de mémoire, fenêtres batch, contraintes de langage ou histoires d'équipes. Une étape JCL peut uniquement convertir deux formats parce qu'aucun programme voisin ne pouvait gérer les deux. Une procédure stockée peut porter des règles métier parce que le client d'origine était difficile à déployer. Un copybook peut lier des programmes indépendants parce qu'il était le seul mode de distribution pratique. Reproduire chaque artefact dans un nouveau langage conserve les contraintes sans leur raison.

Cherchez plutôt les comportements cohérents dans le graphe. Les nœuds qui changent ensemble, partagent des règles transactionnelles et produisent le même résultat observable peuvent former un composant moderne. Les arêtes traversant des zones de confiance, des cycles de livraison indépendants ou des charges réellement différentes peuvent devenir des interfaces explicites. Les arêtes de données montrent où Postgres doit protéger des invariants. Un noyau numérique exigeant peut justifier Rust, l'orchestration rester en Go et l'interface opérateur passer en TypeScript. La cible suit le comportement et les contraintes, pas les extensions.

Je déconseille de commencer par une conversion dépôt par dépôt, même si les achats et l'affectation des équipes la rendent séduisante. Elle produit vite un progrès facile à compter, mais repousse le comportement transversal à l'intégration, quand modifier les frontières coûte davantage. Construisez d'abord le graphe système, choisissez les nouvelles frontières, puis distribuez les lots.

La traçabilité reste nécessaire. Chaque nouveau composant doit renvoyer aux comportements source et aux arêtes qu'il remplace. Cette carte permet de demander si une ancienne relation a été conservée, redessinée volontairement ou retirée avec preuve. Sans elle, la modernisation se réduit à comparer la ressemblance du code, ce qui mesure la mauvaise chose.

Les tests de parité doivent suivre les chemins

Les tests de dépôt sont des preuves utiles, mais établissent rarement la parité du système puisque leurs assertions s'arrêtent aux frontières locales. Un banc de parité doit rejouer des transactions complètes et comparer les effets observables le long du chemin exposé par le graphe.

Choisissez des chemins aux comportements distincts, pas seulement les points d'entrée fréquents. Incluez le traitement normal, une cible dynamique, un transfert batch, une exception approuvée par un opérateur et un échec ou une reprise si le système en possède. Enregistrez les entrées et sorties aux frontières stables : requêtes, modifications en base, enregistrements émis, états, rapports et erreurs visibles. Les appels internes peuvent changer avec l'architecture. Les obligations observables ne doivent pas changer par accident.

Un manifeste compact rend le périmètre de test vérifiable :

path: close-exception-approval
entry: account-status-change
observations:
  - eligible-account-row
  - exception-record
  - approval-state
  - ledger-entry
dynamic-targets:
  - reconciliation-program
external-frontier:
  - scheduler-calendar

Pour chaque cas de production enregistré, exécutez l'ancien et le nouveau système sur un état contrôlé, normalisez les valeurs autorisées à varier et comparez les observations. Un horodatage différent peut être acceptable, un enregistrement d'exception absent ne l'est pas. En cas d'écart, utilisez le chemin pour trouver la première frontière divergente au lieu de comparer des millions de lignes ou le seul état final.

Les échantillons de trafic demandent des ajouts ciblés. Les enregistrements reflètent la fenêtre de capture. Ajoutez donc des cas pour les bornes calendaires, permissions, reprises, valeurs rares et actions humaines trouvées par l'analyse statique. Si celle-ci trouve une branche apparemment accessible qu'aucun échantillon ne parcourt, ne l'éliminez pas en silence. Déterminez si elle est dormante, inaccessible ou simplement rare.

CodeHero lit toute la base de code dans ses différents langages et compare le système réécrit au trafic de production enregistré avec un banc de parité, le tout livré en moins de 30 jours. Quel que soit le moyen choisi, chaque frontière remplacée doit reposer sur une preuve du graphe et une preuve comportementale qui la traverse.

Le graphe est un artefact technique vérifiable

Un graphe global gagne la confiance quand les ingénieurs peuvent inspecter ses preuves, reproduire son extraction et consigner les décisions sur les arêtes incertaines. Un beau dessin sans provenance est une présentation, pas un artefact technique.

Conservez l'inventaire brut des arêtes sous gestion de versions, avec des identifiants stables pour les artefacts et leurs emplacements. Notez la version de l'extracteur et la révision des entrées. Pour une inférence, stockez les valeurs bornées et les règles utilisées. Quand le trafic confirme une arête, attachez un identifiant d'échantillon plutôt que des données sensibles. Les changements restent ainsi explicables quand le code et la conception évoluent.

La revue doit porter sur les frontières et les incertitudes. Demandez quels résultats visibles traversent les dépôts, quelles cibles dynamiques restent ouvertes, quelles arêtes de données commandent la suite et quels systèmes externes injectent du travail. Un schéma central gigantesque se prête mal à cet examen. Filtrez le même graphe pour une transaction, une frontière non résolue, une vue d'influence écriture-lecture ou la carte des futurs composants.

Après la découverte, attribuez les questions. Confiez les arêtes ouvertes aux personnes capables d'obtenir les exports de l'ordonnanceur, les définitions de base, la configuration ou les procédures opérateur. Consignez la réponse dans le graphe, pas dans un compte rendu. Si un artefact est déclaré mort, gardez les preuves, par exemple des valeurs inaccessibles et son absence d'un trafic suffisamment représentatif. Le silence ne prouve pas le retrait.

Le premier livrable utile n'est ni un nombre de fichiers ni un total impressionnant de nœuds. C'est un petit ensemble de chemins de bout en bout, avec une preuve pour chaque transition et chaque inconnue exposée. Les architectes peuvent alors dessiner les frontières, les testeurs choisir les cas et les opérateurs repérer les étapes manquantes. Étendez cet ensemble jusqu'à couvrir ainsi les comportements du périmètre.

Le build et le déploiement choisissent la vraie arête

Les noms du source ne disent pas quelle implémentation s'exécute. Scripts de build, cartes d'édition de liens, ordres de recherche, manifestes, descripteurs de déploiement et surcharges propres à un environnement choisissent le destinataire du contrôle. Un graphe qui les ignore peut relier le bon nom au mauvais code.

Les doublons sont normaux dans un système ancien. Une version de test peut côtoyer la production. Deux bibliothèques peuvent contenir le même nom de membre. Un projet VB6 peut référencer une interface COM compatible tandis que le déploiement choisit une implémentation enregistrée. Des synonymes SQL peuvent orienter le même texte vers plusieurs schémas. Le graphe a besoin d'un contexte de déploiement, pas d'une réponse universelle qui active tous les candidats.

Modélisez la résolution comme une suite de preuves. Relevez le nom et la convention d'appel. Appliquez ensuite l'ordre de recherche du build ou de l'exécution dans l'environnement choisi. Vérifiez le point d'entrée et la forme attendue, puis attachez l'enregistrement de configuration qui a fait le choix. Si une entrée manque, conservez les candidats et exposez la décision absente plutôt que de choisir le premier fichier indexé.

Les sorties du compilateur et de l'éditeur de liens règlent souvent des questions impossibles au niveau source. Une carte montre le symbole lié au binaire. Les journaux montrent les versions de source généré et de copybook utilisées. Les inventaires de paquets relient un artefact au serveur où le trafic l'a atteint. Ce ne sont pas des documents secondaires, mais des preuves du système exécutable. Le graphe doit leur donner un nœud ou une pièce jointe stable.

Gardez visibles les différences entre environnements. Développement, test, reprise et production peuvent résoudre différemment le même nom logique. Les fusionner peut cacher une dépendance propre à la production ou laisser croire que les tests ont exécuté du code jamais chargé. Marquez les arêtes par contexte et comparez les contextes. Une différence peut être voulue, mais reste dans le périmètre si la réécriture doit prendre cet environnement en charge.

Ce travail repère aussi les déclarations périmées. Un fichier de build peut nommer une bibliothèque qui n'est plus livrée tandis que le binaire trouve ses symboles ailleurs. À l'inverse, un source peut sembler inutilisé alors qu'un opérateur le compile par une procédure distincte avant un traitement annuel. Ne tranchez pas au goût. Enregistrez les preuves contradictoires et obtenez la procédure manquante.

Le test d'une arête est simple : un autre ingénieur doit pouvoir suivre ses preuves et obtenir les mêmes candidats avec les mêmes hypothèses d'environnement. La reproductibilité vaut mieux qu'une réponse unique forcée. Deux cibles défendables et un fichier de configuration manquant sont plus utiles qu'une flèche nette fondée sur la proximité des répertoires.

L'identité de version compte aussi après la construction du premier graphe. Une dépendance attachée à un chemin peut dériver si une branche de livraison, une bibliothèque copiée ou un membre généré change sans modifier ce chemin. Stockez une empreinte de contenu ou un identifiant de build avec le nœud, puis reliez l'exécutable déployé à cette révision exacte. Sinon, une preuve valide peut conduire le réviseur à la mauvaise version et lui faire approuver le remplacement d'un comportement jamais exécuté. Le risque augmente avec des archives assemblées depuis plusieurs machines plutôt qu'un checkout propre. L'analyse doit signaler les chemins en double, horodatages incohérents et artefacts impossibles à relier au source. Ces alertes ne bloquent pas la découverte, mais empêchent une précision injustifiée. Un export ultérieur du binaire ou du journal manquant permet alors de corriger les arêtes grâce à l'identité stable.

L'analyse par dépôt aide toujours à comprendre le code local. Elle ne peut pas établir la frontière comportementale d'un système composé de langages, jobs, bases, artefacts générés et actions humaines. Si les appels importants franchissent les conteneurs de l'analyse, ces conteneurs ont déjà décidé ce que le graphe manquera.