Comment CodeGraph fonctionne
Parser le patrimoine en un graphe typé, puis exécuter des analyses déterministes. Aucun LLM ne se trouve sur le chemin critique.
Le pipeline exécute le patrimoine fixture, puis le parse (COBOL, copybooks, JCL, DB2 DDL), puis construit un graphe de connaissances typé, puis l'impact par fermeture transitive plus la provenance, puis les analyses déterministes, puis un audit et l'export de preuves, puis le tableau de bord interactif. Au chargement, l'application exécute cela en direct via Server-Sent Events, de sorte que chaque étape raconte sa latence réellement mesurée dans une console, les panneaux se remplissent progressivement, et un rail d'étapes persistant permet d'ouvrir la trace Input, Processing et Output de n'importe quelle étape. Un seul contrôle rejoue toute l'exécution.
Le graphe de connaissances typé
Construit avec networkx et conservé en mémoire plus SQLite, le graphe a sept types de nœuds (program, copybook, variable, table, jcl, dataset, et un placeholder non résolu) et des arêtes typées telles que DEFINES, IMPORTS, REDEFINES, CONTROLS_TYPE_OF, WRITES_VAR, REFERENCES, CALLS, READS et WRITES, EXECUTES, USES_DATASET et PRECEDES. Sur la fixture livrée, le graphe a 47 nœuds et 70 arêtes : 14 programs, 5 copybooks, 17 variables, 3 tables DB2, 3 jobs JCL, 4 datasets, et 1 nœud non résolu.
Quatre analyses déterministes
Ce sont de simples algorithmes de graphe, pas des appels de modèle, donc la même fixture produit le même résultat à chaque exécution.
1. Fermeture d'impact avec provenance
La tranche de dépendances transitives d'un changement, chaque arête portant sa source file:line, pour voir non seulement ce qui est affecté mais où vit la preuve.
2. Rappel naïf versus graphe
La fermeture du graphe scorée par rapport au jeu de dépendances de vérité terrain connu de la fixture, versus une fenêtre simulée d'un seul fichier, ce qu'un outil textuel nourrit réellement à un modèle.
3. Séquençage d'extraction
Un score de couplage et de rayon d'impact par programme (couplage pondéré trois, pièges COMP-3 pondérés deux, criticité JCL pondérée deux, appels non résolus pondérés cinq) qui classe un ordre de migration strangler-fig sûr.
4. Accessibilité du code mort et porte de complétude
Chaque PERFORM, CALL, COPY et référence DB2 doit se résoudre ou être signalé comme needs review, jamais écarté silencieusement. Les paragraphes inatteignables sont rapportés à titre d'illustration, pas scorés comme métrique phare.
Un seul interrupteur rend la différence tangible. Cochez la vue de contexte IA naïve et le graphe s'estompe jusqu'au seul fichier source avec quelques lignes de contexte. Six des neuf faits du virement disparaissent, une bannière rouge énonce la conséquence, et le retour restaure 9/9 avec les justificatifs. Cet interrupteur illustre le contexte que la couche de récupération doit fournir, ce n'est pas la source de valeur.
Lorsque vous avez terminé, Export JSON écrit un fichier migration-evidence.json, et Evidence report rend un Rapport de topologie et de complétude du code imprimable : le résumé des nœuds et arêtes, les fermetures par module avec provenance file:line, le résultat de rappel et la méthode, la séquence d'extraction classée, la liste du code mort, et un horodatage. Nous le positionnons comme un inventaire d'actifs TIC DORA et un reçu de contrôle des changements SOC-2. Une couche Pydantic-AI optionnelle peut répondre à des questions sur la fermeture, mais elle est désactivée par défaut et protégée par clé, et la démonstration déterministe enregistre le résultat sans aucune clé.
