L'architecture de la compréhension : au-delà de la syntaxe dans la modernisation des systèmes hérités d'entreprise

Résumé exécutif

La modernisation des systèmes hérités d'entreprise — plus précisément la migration des mainframes architectures vers des environnements cloud-native — a atteint un point d'inflexion critique au milieu des années 2020. Pendant des décennies, les secteurs financier et public ont fonctionné sous un paradigme paradoxal : l'impératif de moderniser est existentiel, pourtant le taux d'échec de telles initiatives reste catastrophiquement élevé, oscillant entre 70 % et 80 %. ¹ L'avènement récent des grands modèles de langage (LLM) promettait une révolution, offrant la possibilité séduisante d'une traduction automatisée du code. Toutefois, les premiers cycles d'adoption ont révélé une carence critique et systémique des approches d'IA générative standard lorsqu'elles sont appliquées à des dépôts complexes et monolithiques.

Nous assistons actuellement à l'émergence d'une nouvelle catégorie d'échec d'ingénierie, typifiée par le scénario apocryphe mais hautement réaliste d'une grande banque tentant de réécrire trente années de COBOL en Java à l'aide d'un assistant de codage commercial. L'IA, fonctionnant comme un traducteur localisé sophistiqué, a converti la syntaxe à la perfection. Cependant, la application résultante a fait planter la base de données dès le déploiement. L'échec n'était pas un échec de syntaxe, mais de contexte. L'IA, contrainte par le syndrome « Lost in the Middle » et une compréhension textuelle du logiciel, a manqué une dépendance de variable critique définie des milliers de lignes avant le bloc d'exécution. ³

Ce livre blanc, présenté par Veriprajna, soutient que l'approche dominante du « wrapper LLM » — qui traite le code comme une séquence linéaire de jetons de texte — est fondamentalement inadaptée à la complexité non linéaire de la modernisation d'entreprise. Le logiciel n'est pas du texte ; c'est un graphe. C'est un système hautement structuré de dépendances logiques, de flux de données et de changements d'état qui existe dans un espace topologique multidimensionnel. ⁵

Nous avançons que la seule voie viable consiste à adopter les Repository-Aware Knowledge Graphs . En passant de la prédiction stochastique de texte au raisonnement déterministe fondé sur les graphes, nous pouvons cartographier les dépendances de variables sur des millions de lignes de code, en résolvant le phénomène « Lost in the Middle » et en transformant la modernisation d'un pari risqué en un processus d'ingénierie mathématiquement vérifiable. ⁷ Ce document décrit la transition technique de la traduction syntaxique de surface vers une transformation structurelle sémantique profonde.

Chapitre 1 : La crise silencieuse de l'infrastructure héritée

1.1 Le paradoxe de la modernisation

Dans l'économie numérique actuelle, l'infrastructure du commerce mondial repose précairement sur des technologies développées pendant la Guerre froide. C'est une réalité saisissante, souvent non reconnue, que, en 2025, une majorité significative des systèmes financiers, de santé et gouvernementaux du monde sont alimentés par des bases de code héritées — des applications monolithiques écrites dans des langages comme COBOL, PL/I et RPG, depuis longtemps sortis du programme universitaire grand public en informatique. Ces systèmes ne sont pas simplement « anciens » ; ils sont le socle fondateur de l'économie mondiale, et pourtant ils s'érodent à un rythme alarmant.

Les statistiques brossent un tableau sombre de cette dépendance. Environ 70 % des logiciels qui font tourner les entreprises du Fortune 500 ont été développés il y a plus de deux décennies. ⁹ Dans le secteur bancaire, la situation est encore plus aiguë : 43 % des systèmes bancaires sont bâtis sur COBOL, et ces systèmes traitent 95 % de toutes les transactions de DAB. ¹ Nous faisons effectivement tourner l'économie moderne des paiements instantanés sur une fondation numérique antérieure à Internet.

Le coût du maintien de ce statu quo s'envole. La dette technique a atteint un montant estimé à $1.52 trillion aux États-Unis seulement. ¹ Les organisations sont piégées dans un cycle de « maintien des lumières allumées », avec 80 % des budgets informatiques fédéraux consacrés à l'exploitation et à la maintenance, ne laissant qu'un maigre 20 % à l'innovation. ⁹ Cette ponction de ressources est aggravée par une pénurie sévère de compétences ; à mesure que la génération de développeurs qui a écrit ces systèmes part à la retraite, la connaissance institutionnelle requise pour les maintenir disparaît. ¹⁰

Tableau 1 : Le fardeau économique des systèmes hérités

Indicateur	Statistique	Source
Coût de la dette technique (États-Unis)	$1.52 Trillion	1
Maintenance informatique fédérale Budget	~80 % des dépenses totales	9
Dépendance bancaire	95 % des transactions DAB sur COBOL	1

Probabilité de violation de données	3x plus élevée pour les systèmes >10 ans	11
Attrition des développeurs	58 % envisagent de démissionner à cause des piles héritées	1

Ces données indiquent une vulnérabilité systémique. L'impératif de modernisation n'est pas seulement une question de réduction des coûts ; c'est une question de survie. Les systèmes de plus de dix ans sont statistiquement trois fois plus susceptibles de subir une faille de sécurité que les applications modernes. ¹¹ À mesure que les exigences réglementaires en matière de confidentialité des données et de reporting en temps réel se durcissent (p. ex. RGPD, DORA), l'incapacité des systèmes hérités à s'adapter devient un risque de conformité du plus haut degré.

1.2 L'anatomie de l'« échec bancaire »

Pour comprendre la nécessité d'une nouvelle approche, nous devons disséquer le scénario qui est devenu le « patient zéro » des échecs de modernisation par l'IA. Cette étude de cas, citée par la direction de Veriprajna, illustre le mécanisme précis par lequel l'IA standard échoue dans les environnements d'entreprise.

Une grande institution financière a lancé un projet pour migrer un système central de traitement des transactions d'un mainframe IBM (COBOL/DB2) vers une architecture de microservices Java cloud-native. La banque a utilisé un assistant de codage IA populaire — essentiellement un wrapper autour d'un modèle de fondation — pour traduire le code.

L'IA a ingéré un programme COBOL chargé de traiter des virements de haute valeur. Le programme contenait une instruction COMPUTE complexe impliquant une variable que nous appellerons TRN-LIMIT. L'IA a traduit la syntaxe à la perfection. Elle a converti l'instruction COMPUTE en une opération Java BigDecimal. Le code a compilé. Les tests unitaires — générés par la même IA à partir du bloc de code local — ont réussi.

Cependant, lors du déploiement dans l'environnement de recette utilisateur (UAT), la première transaction a fait échouer le contrôle de cohérence de la base de données.

L'autopsie : La variable TRN-LIMIT n'était pas définie dans le fichier source que l'IA a traduit. Elle était définie dans un COPYBOOK (un fichier d'en-tête partagé) inclus des milliers de lignes plus tôt dans la chaîne d'exécution. Plus important encore, ce COPYBOOK contenait une clause REDEFINES — une construction COBOL qui permet d'interpréter la même adresse mémoire comme deux types de données différents selon un indicateur défini dans un module complètement différent. L'IA, opérant sur un « chunk » de texte, a vu TRN-LIMIT comme un simple champ numérique. Elle n'a pas vu la clause REDEFINES parce qu'elle se trouvait dans un fichier différent qui n'était pas dans la fenêtre de contexte immédiate. Elle a « halluciné » une définition standard pour la variable. Dans l'environnement mainframe, l'adresse mémoire contenait un packed decimal ; dans l'environnement Java, l'IA l'a traitée comme un entier standard. Le décalage a conduit l'application Java à écrire des données binaires corrompues dans la colonne de la base de données, déclenchant une défaillance d'intégrité référentielle. ⁴

L'échec n'était pas un échec de syntaxe ; le code Java était syntaxiquement parfait. L'échec était un échec d'aveuglement contextuel . L'IA a manqué une dépendance qui existait hors de son « champ de vision », conduisant à une divergence sémantique catastrophique.

1.3 Le dilemme « Lift and Shift » vs. refactoring

Le bilan de l'industrie en matière de modernisation est abyssal, même avant l'introduction de l'IA générative. Les recherches indiquent qu'entre 70 % et 80 % des projets de transformation numérique et de modernisation des systèmes hérités n'atteignent pas leurs objectifs. ²

Traditionnellement, les organisations ont été confrontées à un choix binaire :

1.​ Réhébergement (Lift and Shift) : Déplacer l'application compilée vers un émulateur dans le cloud. Cela préserve le « spaghetti code » et la dette, changeant seulement la facture d'hébergement. Cela ne parvient pas à débloquer l'agilité du cloud. ¹⁴

2.​ Réécriture (Refactor) : Réécrire manuellement le code dans un langage moderne. C'est astronomiquement coûteux, lent et risqué en raison du manque de documentation et de l'architecture « Big Ball of Mud » où la logique métier est inextricablement enchevêtrée avec l'accès aux données. ¹⁰

L'IA générative devait offrir une « troisième voie » — le refactoring automatisé. Cependant, l' « échec bancaire » prouve que, sans une compréhension plus profonde de la topologie logicielle, l'IA ne fait que accélérer la création de code défectueux.

Chapitre 2 : L'échec de la traduction stochastique

2.1 L'économie du « wrapper » et ses limites

Dans cet environnement à enjeux élevés est entré le « wrapper LLM ». La réaction immédiate du marché du conseil en logiciel à la sortie de GPT-4 a été la prolifération d'outils qui agissent comme de minces couches logicielles entre un développeur et un modèle de fondation. ¹⁵ Ces outils promettent de « discuter avec votre code », permettant aux développeurs de coller un paragraphe COBOL et de recevoir une méthode Java en retour.

Si ces wrappers abaissent la barrière à l'entrée pour l'adoption de l'IA, ils sont fondamentalement défaillants lorsqu'ils sont appliqués à la réingénierie de systèmes à grande échelle. Les wrappers s'appuient typiquement sur le RAG naïf (Retrieval-Augmented Generation). Dans ce processus, le système prend une requête utilisateur, cherche dans une base de données vectorielle des extraits de code textuellement similaires à la requête, et fournit ces extraits au LLM comme contexte. ¹⁷

Les limitations de cette approche dans un contexte d'entreprise sont sévères :

1.​ Myopie contextuelle : Un wrapper voit le code comme des segments de texte. Il ne comprend pas qu' une variable ACCOUNT-BALANCE modifiée dans SECTION-A pilote une logique de décision dans SECTION-Z cinq mille lignes plus loin.

2.​ Succès syntaxique, échec sémantique : Comme indiqué, un LLM peut produire du code Java qui compile parfaitement mais échoue à reproduire le comportement d'exécution exact du COBOL d'origine parce qu'il a manqué un changement d'état global. ⁴

Veriprajna se distingue en rejetant la philosophie du « thin wrapper ». Nous affirmons que les solutions d'IA profonde doivent comprendre la structure du dépôt, et pas seulement le texte du fichier.

2.2 Le syndrome « Lost in the Middle »

Pour comprendre pourquoi l'IA standard échoue à la modernisation des systèmes hérités, nous devons comprendre l' architecture cognitive des grands modèles de langage. Ces modèles reposent sur l' architecture Transformer, qui utilise un « mécanisme d'attention » pour pondérer l'importance des différentes parties du texte d'entrée. ¹⁸

Si les LLM modernes se prévalent de fenêtres de contexte massives (jusqu'à 1 million de jetons), leur capacité à utiliser effectivement ce contexte n'est pas uniforme. La recherche empirique a démontré un phénomène connu sous le nom d'effet « Lost in the Middle » . Lorsqu'on leur présente une longue séquence d'informations, les LLM exhibent une courbe de performance en U :

●​ Biais de primauté : Ils sont très précis pour rappeler l'information au début du prompt.

●​ Biais de récence : Ils sont très précis pour rappeler l'information à la fin du prompt.

●​ Le creux : Les performances se dégradent significativement pour l'information située au milieu. ³

Dans un projet de modernisation, un seul programme COBOL peut faire des milliers de lignes, et il peut référencer des copybooks (dépendances) qui font eux-mêmes des milliers de lignes. Si la définition d'une variable critique — disons MAX-TRANSACTION-LIMIT — apparaît au milieu de ce contexte massif, l'IA est statistiquement susceptible de la négliger. ²¹

Lorsque l'IA néglige une définition de variable, elle ne s'arrête pas. Elle « hallucine ». Elle suppose un type ou une valeur par défaut pour la variable sur la base de la probabilité, non du fait. Dans un système bancaire, supposer qu'une variable est un Integer alors qu'il s'agit en réalité d'un Packed Decimal peut conduire à des erreurs d'arrondi qui corrompent les données financières. ²²

Tableau 2 : Les limitations cognitives des LLM standard

Phénomène	Description	Impact sur la modernisation
Lost in the Middle	Attention dégradée au centre des longs prompts.3	Définitions de variables manquées enterrées dans de gros fichiers.
Hallucination	Fabrication de faits plausibles mais incorrects.22	Invention de dépendances ou de logique pour combler les lacunes de contexte.
Biais de primauté/récence	Focalisation sur le début/la fin du texte.20	Ignorance de la logique métier centrale située au milieu d'une procédure.
Génération stochastique	Prédiction probabiliste de texte.	Génération de code incohérente ; relancer le prompt produit une logique différente.

2.3 Le « sac de mots » vs. l'« arbre de logique »

Les LLM standard et les systèmes RAG vectoriels traitent le code principalement comme une séquence de jetons. Ils s'appuient sur la similarité sémantique — en vérifiant si les mots de la requête correspondent aux mots dans l'espace vectoriel du document. ¹⁷

Cependant, le code n'est pas du langage naturel. En langage naturel, « The cat sat on the mat » a un sens largement indépendant d'une phrase cinquante pages plus tôt. En logiciel, x = y + 1 n'a aucun sens à moins de connaître les définitions, les types et les états courants de x et de y. Ces définitions peuvent exister dans un fichier différent, un module différent, ou être héritées d'une classe parente. ⁵

Lorsqu'une IA « wrapper » récupère du contexte pour une requête du type « Refactorisez la logique de paiement », elle peut rapporter cinq chunks de code qui contiennent le mot « payment ». Elle manquera vraisemblablement le chunk nommé GlobalVarDef.cbl qui définit le taux d'imposition utilisé par la logique de paiement, parce que ce fichier ne mentionne jamais le mot « payment ».

Cette déconnexion représente l'écart fondamental entre la recherche textuelle et la compréhension structurelle . Pour combler cet écart, nous devons cesser de traiter le code comme de la littérature et commencer à le traiter comme un graphe. ²³

Chapitre 3 : La physique du logiciel –

Le code comme graphe

3.1 Le logiciel comme système relationnel

Chez Veriprajna, nous reconnaissons qu'un dépôt logiciel est fondamentalement une base de données relationnelle de logique . Chaque entité au sein de la base de code — variables, fonctions, classes, modules, schémas de base de données — existe dans un réseau dense de relations.

●​ Contenance : Un fichier contient une classe ; une classe contient une méthode ; une méthode contient une déclaration de variable.

●​ Héritage : La classe B hérite des propriétés et des méthodes de la classe A.

●​ Invocation : La méthode X appelle la méthode Y.

●​ Flux de données : La variable Z est modifiée par la fonction Q et lue par la fonction R.

Ces relations constituent la « vérité terrain » de l'application. Elles ne sont pas probabilistes ; elles sont déterministes. Si la méthode X appelle la méthode Y, c'est un fait dur, non une vraisemblance statistique. Les LLM standard opèrent dans le domaine probabiliste. Pour moderniser en toute sécurité les systèmes hérités, nous devons ancrer leurs capacités de génération probabiliste à la réalité déterministe de la structure du code. ⁷

3.2 L'arbre de syntaxe abstraite (AST)

L'unité fondatrice de cette compréhension structurelle est l'arbre de syntaxe abstraite (AST) . L' AST est une représentation arborescente de la structure syntaxique abstraite du code source. Contrairement à une chaîne brute de texte, un AST capture la hiérarchie et les règles grammaticales du langage. ²⁴

Par exemple, l'instruction COBOL : COMPUTE INTEREST = PRINCIPAL * RATE n'est pas seulement cinq mots. Dans un AST, c'est un AssignmentNode avec une Target (Interest) et une Expression. L'Expression est un MultiplicationNode avec un LeftOperand (Principal) et un RightOperand (Rate).26 En analysant le code hérité en AST, nous dépassons les ambiguïtés du texte. Nous pouvons identifier programmatiquement chaque usage de variable, chaque opération arithmétique et chaque branche de flot de contrôle. Cela nous permet de réaliser une ingénierie « round trip » — convertir le code en AST puis revenir au code sans perte de données — garantissant que notre analyse structurelle est exacte. ²⁷

Contrairement au « text chunking » utilisé dans le RAG standard — où un fichier est découpé à l'aveugle en segments de 500 jetons, scindant souvent une fonction en deux — l'analyse AST respecte les frontières logiques du code. Une fonction est traitée comme une unité discrète de logique, non comme une plage aléatoire de texte. ²³

3.3 Le graphe d'appels et la matrice de dépendances

Si l'AST représente la structure d'un seul fichier, le graphe d'appels représente le système nerveux de l'application entière. Il visualise le flot de contrôle, en cartographiant quels paragraphes ou sous-programmes en invoquent d'autres. ²⁹

Dans les systèmes COBOL hérités, les graphes d'appels sont souvent obscurcis par des appels dynamiques ou une logique GOTO qui crée du « spaghetti code ». Une analyse textuelle statique ne peut pas facilement résoudre où un GOTO LABEL_X atterrit si LABEL_X est défini dynamiquement ou conditionnellement.

En construisant un graphe d'appels rigoureux, Veriprajna identifie le « dead code » (code qui n'est jamais appelé) et les « God Classes » (modules trop fortement couplés). Cette analyse est critique pour découper les monolithes en microservices. Si nous ne connaissons pas la chaîne d'appels complète, nous ne pouvons pas extraire un service en toute sécurité ; nous risquons de laisser derrière une « référence pendante » qui causera un échec à l'exécution — exactement le scénario qui a frappé la banque dans notre étude de cas d'ouverture. ³¹

Tableau 3 : Analyse structurelle vs. analyse textuelle

Caractéristique	Analyse textuelle (IA standard)	Analyse structurelle (Veriprajna)
Unité d'analyse	Jeton / Mot	Nœud (élément AST)
Frontière de contexte	Limite arbitraire de jetons	Portée logique (Fonction/Classe)
Résolution des dépendances	Correspondance de mots-clés	Parcours de graphe
Traitement du GOTO	Traité comme chaîne de texte	Cartographie les arêtes de flot de contrôle
Exactitude	Probabiliste	Déterministe

3.4 Injection de dépendances et inversion

Les architectures Java modernes et cloud-native s'appuient fortement sur l'injection de dépendances (DI) et l' inversion de contrôle (IoC). Le COBOL hérité, à l'inverse, s'appuie sur des dépendances codées en dur et un état global. Passer de l'un à l'autre exige d'identifier chaque dépendance dans le graphe et de l'« inverser ».

Nous devons changer de paradigme, de « Le module A code en dur une connexion à la base de données B » à « Le module A accepte une connexion à la base de données comme paramètre. » Ce basculement architectural est impossible si l'IA ne peut pas voir la dépendance en premier lieu. Le graphe de connaissances rend ces dépendances explicites, permettant à l'IA de générer le code boilerplate DI nécessaire automatiquement, garantissant que le nouveau système est modulaire et testable. ⁴

Chapitre 4 : La Semantic Veriprajna Forge

4.1 Architecture du graphe de connaissances conscient du dépôt

La solution au syndrome « Lost in the Middle » et à la fragilité de la migration fondée sur le texte est le graphe de connaissances conscient du dépôt . C'est une base de données graphe unifiée qui combine la structure statique du code (AST, graphes d'appels) avec le sens sémantique de la logique métier (documentation, commentaires, intention des variables). ⁵

Veriprajna emploie un pipeline propriétaire, souvent désigné dans la recherche avancée comme une « Semantic Forge », pour construire cette intelligence. Ce n'est pas un processus ETL générique ; c'est un moteur conçu sur mesure pour la modernisation des systèmes hérités. ³³

4.2 Phase 1 : Analyse intelligente avec Tree-sitter

Nous utilisons des analyseurs robustes, principalement Tree-sitter, pour ingérer la base de code héritée. Ce processus prend en charge plus de 13 langages, dont COBOL, JCL, PL/I et Java. L'analyseur génère un AST pour chaque fichier du dépôt.

De façon cruciale, nous employons le chunking sémantique . Les pipelines RAG standard utilisent un « découpage naïf », coupant le texte tous les n jetons. Cela sépare fréquemment une signature de fonction de son corps ou une définition de variable de son usage, détruisant le contexte. Le chunking sémantique utilise l'AST pour identifier les frontières logiques. Nous découpons le code par SECTION, PARAGRAPH ou METHOD, garantissant que chaque nœud de notre graphe représente une unité de logique complète et exécutable. ²³

4.3 Phase 2 : Extraction des entités et des relations

Une fois les AST générés, la Semantic Forge extrait les entités et les relations pour peupler la base de données graphe (p. ex. Neo4j, Memgraph).

●​ Entités : Classes, paragraphes, variables, tables de base de données, points d'extrémité d'API.

●​ Relations :

○​ CALLS : Relie un paragraphe au sous-programme qu'il invoque.

○​ UPDATES_TABLE : Relie un bloc de logique à la table DB2 qu'il modifie.

○​ IMPORTS_COPYBOOK : Relie un fichier source à sa dépendance.

○​ DEFINES_VARIABLE : Relie une data division aux variables qu'elle crée.

Cette phase transforme le texte statique en une topologie dynamique. Nous pouvons désormais interroger le graphe : « Montrez-moi chaque paragraphe qui met à jour le champ CUSTOMER-ID. » Cette requête renvoie des résultats exacts instantanément, un exploit impossible avec grep ou la recherche vectorielle. ¹⁴

4.4 Phase 3 : Résolution d'entités et fusion

C'est le point de différenciation critique. Un analyseur standard voit ACCT-NUM dans le fichier A et ACCT-NUM dans le fichier B comme deux chaînes différentes. Notre système effectue une résolution de symboles . Il détermine que les deux se réfèrent à la même entrée dans un Copybook partagé. Il les fusionne en un seul nœud Variable dans le graphe.

De plus, nous effectuons une fusion intermodale . Si la base de code contient un document PDF d'exigences qui décrit l'« User API », et que le code contient une classe nommée UserAPI, le système calcule des embeddings pour reconnaître qu'il s'agit du même concept. Il fusionne le nœud de documentation avec le nœud de code. Cela relie l'intention (docs) à l' implémentation (code), fournissant à l'IA le « Pourquoi » aux côtés du « Comment ». ⁸

4.5 Phase 4 : Calcul de la fermeture transitive

L'« échec bancaire » a été causé par une dépendance transitive : A dépend de B, B dépend de C. L'IA a vu A mais a manqué C.

Le graphe de connaissances Veriprajna calcule la fermeture transitive . Lorsque le système analyse le module A, il ne s'arrête pas aux voisins directs. Il parcourt le graphe en profondeur (A -> B -> C) pour identifier la « racine de vérité » de chaque variable. Cela garantit que lorsque l'IA génère du code pour le module A, elle importe les définitions correctes depuis le module C, même si le module C est dans un répertoire ou un dépôt différent. ⁸

Chapitre 5 : Génération augmentée par récupération sur graphe (GraphRAG)

5.1 Les limitations du RAG vectoriel

La génération augmentée par récupération vectorielle (RAG) est le standard de l'industrie pour ajouter de la connaissance aux LLM. Elle convertit le texte en vecteurs (représentations numériques) et trouve des vecteurs similaires. Excellente pour interroger du texte non structuré comme les FAQ, elle est insuffisante pour le code.

●​ Renommage de variables : Si un développeur renomme Account en Acct, la similarité sémantique chute, même si la logique est identique.

●​ Logique vs. mots-clés : Chercher « Interest Calculation » peut manquer le calcul réel si la fonction s'appelle FNC-001 et ne contient aucun commentaire.

●​ Contexte fragmenté : Le RAG vectoriel récupère des « chunks » selon la similarité cosinus. Il peut récupérer un test unitaire et un commentaire d'UI, mais manquer la logique métier centrale parce que les noms de variables ne correspondent pas aux mots de la requête. ³⁶

5.2 L'avantage GraphRAG

GraphRAG opère sur la structure du graphe de connaissances, pas seulement sur la similarité textuelle.

1.​ Identification de l'ancre : Lorsqu'un utilisateur demande « Refactorisez la logique de paiement », le système utilise la recherche vectorielle pour trouver le point d'entrée (p. ex. le paragraphe ProcessPayment).

2.​ Parcours de graphe (expansion) : Au lieu de s'arrêter là, GraphRAG parcourt les arêtes du graphe. Il ramène :

○​ Les arêtes CALLS pour trouver les sous-programmes.

○​ Les arêtes READS pour trouver les définitions de variables.

○​ Les arêtes INCLUDES pour trouver les Copybooks.

3.​ Construction du contexte : Ces pièces connectées — qui peuvent être textuellement dissemblables mais sont logiquement inséparables — sont assemblées en un prompt cohérent.

Cette expansion de pertinence garantit que le LLM reçoit une tranche autonome et exécutable de logique. Il comprend non seulement le texte du calcul, mais sa mécanique. ³⁶

5.3 Raisonnement multi-sauts

La recherche montre que GraphRAG surpasse significativement le RAG vectoriel dans les tâches exigeant un « raisonnement multi-sauts » — relier des faits séparés par plusieurs étapes. En logiciel, presque chaque bogue est un échec de raisonnement multi-sauts (p. ex. A appelle B, B change X, C lit X. Si A change, C casse-t-il ?).

GraphRAG permet à l'IA de répondre à des questions complexes d'analyse d'impact : « Si je change la logique du taux d' intérêt dans le module A, quels écrans de reporting du module Z seront affectés ? » Le RAG vectoriel ne peut pas y répondre parce que le module A et le module Z ne partagent aucune similarité textuelle ; ils sont liés seulement par une chaîne d'appels de fonctions. Le graphe parcourt cette chaîne pour fournir une réponse définitive. ³⁸

Tableau 4 : RAG vectoriel vs. GraphRAG

Caractéristique	RAG vectoriel	GraphRAG
Clé de récupération	Similarité (distance cosinus)	Relation (arête de graphe)
Qualité du contexte	Rappel élevé, précision faible (Bruit)	Haute précision, contexte connecté

Raisonnement multi-sauts	Faible (manque les liens indirects)	Excellent (parcourt les chaînes)
Risque d'hallucination	Élevé (devine les liens manquants)	Faible (les liens récupérés sont explicites)
Meilleur cas d'usage	Texte non structuré (FAQ)	Systèmes structurés (code, biologie)

Chapitre 6 : Ingénierie de la migration – Plongée technique

6.1 Résoudre le piège de la « variable globale »

L'un des aspects les plus dangereux du COBOL est l'usage de variables globales définies dans la DATA DIVISION et modifiées par diverses instructions PERFORM tout au long du programme. En Java, les bonnes pratiques dictent l'encapsulation ; une méthode ne devrait pas s'appuyer sur un état caché.

La solution : Les agents de Veriprajna réalisent une analyse de flux de données sur le graphe. Nous retraçons le cycle de vie de chaque variable.

●​ Si un paragraphe CALC-TAX lit GROSS-INCOME, le graphe identifie GROSS-INCOME comme une dépendance d'entrée .

●​ Lors de la génération de la méthode Java calcTax(), l'IA ajoute explicitement BigDecimal grossIncome à la signature de la méthode.

●​ Elle met ensuite à jour l'appelant de la méthode pour lui passer la valeur correcte.

Ce refactoring automatique de l'« état global implicite » vers le « passage explicite de paramètres » prévient les bogues d'effets de bord qui ont frappé la banque dans notre étude de cas. ⁴

6.2 Déconstruire les spaghettis GOTO

L'un des obstacles les plus redoutables de la migration COBOL est l'instruction GOTO. GOTO permet à l' exécution du programme de sauter n'importe où, créant des flots de contrôle non linéaires qui sont un anathème pour la programmation structurée moderne. ⁴⁰ Java n'a pas d'instruction GOTO.

Traduire la logique GOTO exige plus qu'une traduction syntaxique ; cela exige un aplatissement du flot de contrôle .

1.​ Analyse de graphe : Nous cartographions les destinations GOTO comme arêtes dans le graphe de flot de contrôle (CFG).

2.​ Reconnaissance de motifs : Le graphe identifie des motifs.

○​ Un GOTO qui saute en arrière vers une étiquette antérieure est identifié comme une boucle .

○​ Un GOTO qui saute un bloc est identifié comme une conditionnelle (if/else).

○​ Un GOTO vers un paragraphe de sortie est un return .

3.​ Restructuration : L'IA, guidée par le graphe, refactorise ces sauts en boucles while, boucles do-while, ou instructions break/continue en Java.

Sans un graphe pour visualiser les « boucles » créées par GOTO, un LLM fondé sur le texte générera souvent un appel de fonction récursif qui mène à un StackOverflowError, ou hallucinera simplement un flot logique qui n'existe pas. ⁴

6.3 Traiter le « dead code »

Les systèmes hérités sont pleins de code qui n'est plus utilisé — anciennes promotions, produits retirés, routines de débogage. Migrer ce code est un gaspillage d'argent et ajoute de la surface d'attaque. L'IA fondée sur le texte migre tout ce qu'on lui donne ; elle ne peut pas distinguer entre le code actif et le code mort.

La solution : Le graphe d'appels identifie les nœuds inatteignables — paragraphes ou fichiers qui n'ont aucune arête entrante (aucun appelant). Le système de Veriprajna signale ce « dead code » pour suppression avant que la migration ne commence. Cela réduit typiquement la taille de la base de code de 20-30 %, entraînant des économies significatives et une architecture finale plus propre.31

Chapitre 7 : L'avenir agentique – IA profonde vs. wrappers superficiels

7.1 Au-delà du chatbot : le flux de travail agentique

Veriprajna ne déploie pas de « chatbots ». Nous déployons des agents d'IA autonomes . Un agent est un système capable de planifier, d'exécuter et de corriger ses actions sur la base du retour d'information. ²

Le flux de travail du wrapper superficiel :

1.​ Utilisateur : « Convertissez ce code. »

2.​ Wrapper : Envoie le texte à GPT-4.

3.​ Sortie : Renvoie du code Java.

4.​ Résultat : Le code échoue à compiler ou à s'exécuter. Le développeur débogue manuellement.

Le flux de travail de l'agent profond Veriprajna :

1.​ Planification : L'agent analyse l'AST du fichier COBOL cible. Il identifie les dépendances et interroge le graphe de connaissances.

2.​ Récupération : Il récupère le contexte GraphRAG nécessaire à la migration.

3.​ Génération : Il génère le code Java à l'aide d'un « Schematic-Constraint Decoder » qui applique les règles de syntaxe Java et la sûreté des types. ⁷

4.​ Vérification (la boucle) : L'agent compile le code Java généré dans un bac à sable.

5.​ Auto-correction : Si le compilateur lève une erreur (p. ex. « Variable not found »), l'agent lit l'erreur, interroge le graphe pour la dépendance manquante, et régénère le code.

6.​ Validation : Il exécute des tests unitaires (générés à partir des traces COBOL d'origine) pour garantir que la sortie correspond au comportement d'entrée.

Cette boucle compile-fix déplace le fardeau de la validation de l'humain vers l'IA, réduisant dramatiquement le coût du refactoring. ⁴²

7.2 Supervision human-in-the-loop

Si l'agent est autonome dans l'exécution, il est supervisé dans la stratégie. Le graphe de connaissances fournit l'interprétabilité . Contrairement à un réseau de neurones « boîte noire », le graphe permet aux développeurs de voir exactement pourquoi l'IA a pris une décision. « L'IA a importé com.bank.logic parce qu'elle a trouvé une dépendance sur COPYBOOK-X. »

Cette transparence est vitale pour les industries réglementées comme la banque, où chaque ligne de code doit être auditable. Nous passons de « Faites-moi confiance, je suis une IA » à « Voici la chaîne de citations pour cette logique ». ⁴³

Chapitre 8 : Conclusion et perspectives stratégiques

8.1 Le ROI de la conscience du dépôt

Les données McKinsey suggèrent que la GenAI peut réduire les tâches de codage de 50 %, mais seulement si elle est déployée correctement. ¹⁴ Le retour sur investissement (ROI) de l'approche fondée sur les graphes de Veriprajna est porté par l'élimination du retravail.

●​ Migration manuelle : Coût élevé, risque élevé, time-to-market lent.

●​ IA wrapper : Coût moyen (en raison du débogage des « hallucinations »), risque élevé (bogues cachés), time-to-market moyen.

●​ IA graphe-dépôt : Faible coût (automatisation), faible risque (vérification déterministe), time-to-market rapide.

En éliminant le surcoût de « commutation de contexte » — où les développeurs passent des heures à chercher où une variable est définie — Veriprajna augmente la productivité des développeurs de 2x à 3x par rapport aux outils d'IA standard. ²

8.2 Pérenniser via la modernisation continue

La modernisation n'est pas un événement unique ; c'est un cycle de vie. Une fois la base de code convertie en un graphe de connaissances, elle demeure un actif vivant. À mesure que le nouveau code Java évolue, le graphe est mis à jour en temps réel. Cela permet :

●​ Documentation automatisée : L'IA peut générer une documentation à jour pour le nouveau système en lisant le graphe. ⁴⁴

●​ Détection de dérive architecturale : Le système peut alerter les architectes si du nouveau code viole les règles de modularité définies dans le graphe. ⁴⁵

8.3 Le basculement structurel

La leçon de l'« échec bancaire » est claire : Le code n'est pas du texte. C'est un système complexe et interconnecté de logique. Tenter de le moderniser avec des outils qui ne comprennent que le texte, c'est comme essayer de naviguer dans une ville avec une liste de noms de rues mais sans carte. Vous serez « Lost in the Middle ».

Veriprajna offre la carte. En construisant des graphes de connaissances conscients du dépôt, nous fournissons à l'IA l'intelligence structurelle dont elle a besoin pour naviguer dans les complexités des systèmes hérités. Nous cartographions les dépendances, nous démêlons les nœuds, et nous livrons une modernisation qui fonctionne non seulement en syntaxe, mais dans la réalité.

Nous n'écrivons pas seulement du code ; nous faisons de la compréhension un objet d'ingénierie. C'est la différence entre un chatbot et un fournisseur de solutions. C'est l'avenir de la modernisation d'entreprise.

Veriprajna. Deep AI for Deep Solutions.

Ouvrages cités

1. 2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders, consulté le 10 décembre 2025, https://www.pragmaticcoders.com/resources/legacy-code-stats

2. Legacy App Modernization: AI Automation Slashes Costs & Time - SoftProdigy, consulté le 10 décembre 2025, https://softprodigy.com/ai-driven-legacy-app-modernization/

3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, consulté le 10 décembre 2025, https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-efectf

4. How We Use AI Agents for COBOL Migration and Mainframe Modernization | All things Azure - Microsoft Developer Blogs, consulté le 10 décembre 2025, https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

5. Bridging Code and Context: A Knowledge Graph-Based Repository-Level Code Generation, consulté le 10 décembre 2025, https://quantiphi.com/blog/bridging-code-and-context-a-knowledge-graph-based-repository-level-code-generation/

6. Structural-Semantic Code Graph (SSCG) - Emergent Mind, consulté le 10 décembre 2025, https://www.emergentmind.com/topics/structural-semantic-code-graph-sscg

7. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - ResearchGate, consulté le 10 décembre 2025, https://www.researchgate.net/publication/397521461_SemanticForge_Repository-Level_Code_Generation_through_Semantic_Knowledge_Graphs_and_Constraint_Satisfaction

8. RANGER: Repository‑level Agent for Graph‑Enhanced Retrieval - arXiv, consulté le 10 décembre 2025, https://arxiv.org/html/2509.25257v1

9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo, consulté le 10 décembre 2025, https://www.adalo.com/posts/cost-savings-from-replacing-legacy-tools-with-no-code-stats

10. The problems with migrating legacy code: Moving from COBOL to Java and how Metabob can help, consulté le 10 décembre 2025, https://metabob.com/blog-articles/the-problems-with-migrating-legacy-code-moving-from-cobol-to-java-and-how-metabob-can-help.html

11. 7 Signs Legacy System Modernisation Can't Wait Any Longer - Dreamix, consulté le 10 décembre 2025, https://dreamix.eu/insights/when-to-invest-in-legacy-system-modernisation/

12. How to plan a seamless COBOL to Java migration in 8 weeks? - OptiSol Business Solutions, consulté le 10 décembre 2025, https://www.optisolbusiness.com/insight/how-to-plan-a-seamless-cobol-to-java-migration-in-8-weeks

13. Application Modernization Statistics: Future-Proof Insights - eSparkBiz, consulté le 10 décembre 2025, https://www.esparkinfo.com/blog/application-modernization-statistics

14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid, consulté le 10 décembre 2025, https://sigmoidanalytics.medium.com/modernizing-legacy-architectures-using-genai-powered-knowledge-graphs-73d96169f6d7

15. How GPT Wrappers Can Accelerate Your AI Product Development - Synergy Labs, consulté le 10 décembre 2025, https://www.synergylabs.co/fr/blog/how-gpt-wrappers-can-accelerate-your-ai-product-development

16. The Ephemeral Scaffolding or Enduring Infrastructure? LLMs, Their Wrappers, and the Specter of a Dotcom Déjà Vu - Torome, consulté le 10 décembre 2025, https://torome.co.uk/Template/PDO3/the-ephemeral-scafolding-or-enduring-inffrastructure-llms-their-wrappers-and-the-specter-of-a-dotcom-deja-vu

17. GraphRAG vs. Vector RAG: Side-by-side comparison guide - Meilisearch, consulté le 10 décembre 2025, https://www.meilisearch.com/blog/graph-rag-vs-vector-rag

18. Lost in the Middle in LLMS. Why large language models ignore the… | by Cengizhan Bayram | Nov, 2025 | Medium, consulté le 10 décembre 2025, https://medium.com/@cenghanbayram35/lost-in-the-middle-in-llms-86e461dc7212

19. A practical guide to the Claude code context window size - eesel AI, consulté le 10 décembre 2025, https://www.eesel.ai/blog/claude-code-context-window-size

20. Lost in the Middle: How Language Models Use Long Contexts - MIT Press Direct, consulté le 10 décembre 2025, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

21. Why Language Models Are “Lost in the Middle” - Towards AI, consulté le 10 décembre 2025, https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

22. LLM Hallucinations – Definition, Examples and Potential Remedies - Software Mind, consulté le 10 décembre 2025, https://softwaremind.com/blog/llm-hallucinations-definition-examples-and-potential-remedies/

23. Repository GraphRAG MCP Server: A Deep Dive for AI Engineers, consulté le 10 décembre 2025, https://skywork.ai/skypage/en/repository-graphrag-mcp-server-ai-engineers/1978326852212269056

24. AST-Based Source Code Migration Through Symbols Replacement, consulté le 10 décembre 2025, https://www.computer.org/csdl/proceedings-article/csde/2022/10089298/1M7LebbRyEw

25. BMSD 2011, consulté le 10 décembre 2025, https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

26. Abstract Syntax Tree Creation - Compiler Design - Meegle, consulté le 10 décembre 2025, https://www.meegle.com/en_us/topics/compiler-design/abstract-syntax-tree-creation

27. AST (Abstract Syntax Tree) - by Dinis Cruz - Medium, consulté le 10 décembre 2025, https://medium.com/@dinis.cruz/ast-abstract-syntax-tree-538aa146c53b

28. Daily Papers - Hugging Face, consulté le 10 décembre 2025, https://huggingface.co/papers?q=outlier%20chunk%20handling

29. What is a Call Graph? And How to Generate them Automatically freeCodeCamp, consulté le 10 décembre 2025, https://www.freecodecamp.org/news/how-to-automate-call-graph-creation/

30. Generation of Call Graph for Java Higher Order Functions - IEEE Xplore, consulté le 10 décembre 2025, https://ieeexplore.ieee.org/document/9138056/

31. Enhancing Neural Code Representation with Additional Context - arXiv, consulté le 10 décembre 2025, https://arxiv.org/html/2510.12082v1

32. Can We Translate Code Better with LLMs and Call Graph Analysis? - IJCAI, consulté le 10 décembre 2025, https://www.ijcai.org/proceedings/2025/0848.pdf

33. Code Graph: From Visualization to Integration - FalkorDB, consulté le 10 décembre 2025, https://www.falkordb.com/blog/code-graph/

34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit, consulté le 10 décembre 2025, https://www.reddit.com/r/LocalLLaMA/comments/1mzvk44/codebase_to_knowledge_graph_generator/

35. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - arXiv, consulté le 10 décembre 2025, https://arxiv.org/html/2511.07584

36. RAG vs GraphRAG: Shared Goal & Key Differences - Memgraph, consulté le 10 décembre 2025, https://memgraph.com/blog/rag-vs-graphrag

37. Do You Really Need GraphRAG? A Practitioner's Guide Beyond the Hype, consulté le 10 décembre 2025, https://towardsdatascience.com/do-you-really-need-graphrag-a-practitioners-guide-beyond-the-hype/

38. Navigating the Nuances of GraphRAG vs. RAG - foojay, consulté le 10 décembre 2025, https://foojay.io/today/navigating-the-nuances-of-graphrag-vs-rag/

39. GraphRAG vs RAG: Which is Better? | by Mehul Gupta | Data Science in Your Pocket, consulté le 10 décembre 2025, https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

40. Why not GOTO Statement? [closed] - Stack Overflow, consulté le 10 décembre 2025, https://stackoverflow.com/questions/19766205/why-not-goto-statement

41. Alternative to a goto statement in Java - Stack Overflow, consulté le 10 décembre 2025, https://stackoverflow.com/questions/2430782/alternative-to-a-goto-statement-in-java

42. Legacy Code Modernization with Claude Code: Breaking Through Context Window Barriers, consulté le 10 décembre 2025, https://www.tribe.ai/applied-ai/legacy-code-modernization-with-claude-code-breaking-through-context-window-barriers

43. Legacy IT Modernization with AI | MITRE, consulté le 10 décembre 2025, https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

44. Documenting and Modernizing Legacy Codebases with C3 Generative AI, consulté le 10 décembre 2025, https://c3.ai/blog/documenting-and-modernizing-legacy-codebases-with-c3-generative-ai/

45. The AI revolution in application modernization: from manual burden to strategic advantage, consulté le 10 décembre 2025, https://vfunction.com/blog/ai-app-modernization-strategy/