Pourquoi le COBOL traduit par l'IA fait planter votre base de données

Le problème

Une grande banque a demandé à l'IA de réécrire trente ans de COBOL en Java. L'IA a traduit la syntaxe parfaitement. Le code a compilé. Les tests unitaires sont passés. Puis la première transaction a fait planter la base de données.

La défaillance n'avait rien à voir avec du mauvais code. Le Java était grammaticalement impeccable. Le problème était une dépendance cachée — une variable nommée TRN-LIMIT définie dans un fichier d'en-tête partagé situé à des milliers de lignes du code que l'IA a réellement traduit. Ce fichier d'en-tête contenait une clause REDEFINES, une fonctionnalité COBOL qui permet à une même adresse mémoire de stocker deux types de données différents selon un indicateur défini dans un module totalement distinct. L'IA n'a jamais vu rien de tout cela. Elle a traité TRN-LIMIT comme un simple nombre. En réalité, il s'agissait d'un décimal condensé (packed decimal). Cette discordance a poussé l'application Java à écrire des données binaires corrompues dans la base de données, déclenchant une défaillance d'intégrité référentielle.

Ce cas n'est pas une exception. Les recherches montrent que 70 % à 80 % des projets de modernisation du legacy n'atteignent pas leurs objectifs. Votre organisation fait probablement tourner des systèmes critiques sur du code plus ancien que la plupart de vos employés. Si vous planifiez une migration — ou si vous êtes déjà en pleine migration — ce schéma de défaillance doit vous préoccuper profondément. L'IA n'a pas fait de faute de frappe. Elle a manqué une relation qu'elle ne pouvait pas voir. C'est un type de risque fondamentalement différent, et la plupart des outils actuels n'y ont aucune réponse.

Pourquoi cela compte pour votre entreprise

L'exposition financière ici est énorme, et elle touche chaque ligne de votre bilan.

La dette technique des seuls États-Unis a atteint environ 1 520 milliards de dollars. Si votre organisation exploite des systèmes legacy, vous portez dès maintenant une part de ce fardeau. Environ 80 % des budgets informatiques fédéraux partent en exploitation et maintenance — ne laissant que 20 % pour tout ce qui est nouveau. Le secteur bancaire est particulièrement exposé : 43 % des systèmes bancaires tournent encore sur COBOL, et ces systèmes traitent 95 % de toutes les transactions aux distributeurs automatiques.

Voici ce que cela signifie pour votre profil de risque :

• L'exposition de sécurité triple. Les systèmes de plus de dix ans sont statistiquement trois fois plus susceptibles de subir une violation de données que les applications modernes. Chaque trimestre où vous retardez la modernisation, votre surface d'attaque s'agrandit.
• La conformité se durcit. Des réglementations comme le RGPD et DORA exigent des rapports en temps réel et des contrôles de confidentialité des données. Les systèmes legacy n'ont pas été conçus pour ces exigences. Votre incapacité à vous adapter devient un risque de conformité que vos régulateurs finiront par remarquer.
• Vos experts partent. Les développeurs qui ont écrit ces systèmes partent à la retraite. Cinquante-huit pour cent des développeurs déclarent envisager de démissionner à cause des piles technologiques legacy. Quand le savoir institutionnel franchit la porte, vos coûts de maintenance grimpent encore.
• Les migrations ratées gaspillent des millions. Avec un taux d'échec de 70-80 %, les probabilités jouent contre vous. Une migration bâclée ne coûte pas seulement le budget du projet — elle entame la confiance dans votre direction technologique et retarde les capacités métier que vos équipes attendent.

Votre conseil d'administration veut la transformation numérique. Vos régulateurs veulent des contrôles modernes. Votre budget est déjà tendu juste pour faire tourner la maison. Vous ne pouvez pas vous permettre une migration qui échoue en silence.

Ce qui se passe réellement sous le capot

Pour comprendre pourquoi l'IA standard échoue là-dessus, imaginez votre base de code comme une ville. Chaque fonction, chaque variable et chaque table de base de données est un bâtiment. Les connexions entre eux — quelle fonction appelle laquelle, quelle variable alimente quel calcul — sont les routes.

Imaginez maintenant que vous tendiez à quelqu'un l'annuaire téléphonique de tous les bâtiments de la ville et que vous lui demandiez de repenser le réseau de transport. Il a les noms et les adresses, mais aucune carte. Il ne peut pas voir quelles routes relient quels bâtiments. C'est exactement ce que fait un outil de codage IA standard avec votre code. Il lit le texte mais ne peut pas voir la structure.

Cette défaillance technique précise s'appelle l'effet « Lost in the Middle ». Les grands modèles de langage — les moteurs d'IA derrière des outils comme les assistants de codage — traitent le texte grâce à un mécanisme d'attention. La recherche a démontré que ces modèles font preuve d'une forte capacité de rappel pour les informations situées au début et à la fin d'une longue entrée, mais que leurs performances chutent brutalement pour les informations enfouies au milieu. Dans un programme COBOL qui s'étend sur des milliers de lignes et référence des fichiers externes, les définitions de variables critiques se trouvent souvent précisément dans cet angle mort.

Quand l'IA manque une définition, elle ne s'arrête pas pour demander. Elle devine. Elle comble le vide avec quelque chose de statistiquement plausible mais factuellement faux. Dans la terminologie de l'IA, cela s'appelle une hallucination. Dans votre système bancaire, cela signifie que l'IA peut supposer qu'une variable est un entier alors qu'elle est en réalité un décimal condensé (packed decimal). Cette seule supposition erronée peut corrompre des données financières, rompre l'intégrité de la base de données et arrêter un système de transactions. Votre code compile. Vos tests passent. Votre environnement de production échoue.

Ce qui fonctionne (et ce qui ne fonctionne pas)

Commençons par ce que vos équipes ont probablement déjà essayé ou envisagé — et pourquoi chaque approche reste insuffisante.

Lift and Shift (réhébergement) : vous déplacez l'application compilée vers un émulateur cloud. Cela change votre facture d'hébergement mais préserve chaque ligne de code legacy emmêlé. Vous transportez toute la dette technique dans un nouvel environnement et n'acquerez aucune de la souplesse du cloud.

Réécriture manuelle : vous engagez des développeurs pour tout réécrire à la main en Java. C'est d'une lenteur douloureuse, d'un coût astronomique, et cela dépend de votre capacité à trouver des personnes qui comprennent à la fois le COBOL et l'architecture moderne. Avec vos experts COBOL partant à la retraite, cela devient plus difficile chaque année.

Outils d'encapsulation IA : vous pointez un assistant de codage IA commercial vers votre base de code. Il traduit la syntaxe rapidement. Mais comme le montre la défaillance de la banque, il manque les dépendances inter-fichiers, hallucine des définitions de variables et produit du code qui semble correct mais se comporte mal.

Voici ce qui fonctionne réellement — une approche basée sur les graphes qui traite votre code comme un système connecté plutôt que comme une pile de fichiers texte :

1. Analysez la structure, pas seulement le texte. Au lieu de découper votre code en tranches de texte arbitraires, vous analysez chaque fichier en un arbre qui représente sa structure logique — chaque variable, chaque fonction, chaque branche de flux de contrôle. Cela garantit que l'IA respecte les frontières de votre code. Une fonction est traitée comme une unité de logique complète, pas comme une tranche de texte aléatoire.

2. Construisez une carte de chaque relation. Vous extrayez chaque connexion de votre base de code — quels modules appellent quelles sous-routines, quels fichiers définissent quelles variables, quelles fonctions mettent à jour quelles tables de base de données — et vous les stockez dans un graphe de connaissances. Quand l'IA doit traduire une fonction de paiement, elle ne se contente pas d'attraper du texte qui mentionne « paiement ». Elle suit la chaîne de dépendances réelle pour intégrer chaque définition de variable, chaque en-tête partagé et chaque impact en aval. C'est ce que Veriprajna appelle un Repository-Aware Knowledge Graph, et il résout directement le problème du « Lost in the Middle ».

3. Vérifiez chaque sortie par rapport à la carte. L'IA génère du code Java, puis le compile dans un bac à sable. Si le compilateur lève une erreur — disons, une variable manquante — le système interroge le graphe, trouve la dépendance et régénère le code. Cette boucle compiler-corriger tourne automatiquement. Vos développeurs examinent des sorties vérifiées, pas des suppositions brutes de l'IA.

L'avantage qui compte le plus pour vos équipes de conformité et d'audit : chaque décision prise par l'IA est traçable. Le graphe de connaissances enregistre exactement pourquoi l'IA a importé une bibliothèque spécifique ou défini une variable d'une certaine manière. Au lieu d'une boîte noire, vous obtenez une chaîne de citations. Vos auditeurs peuvent voir la piste logique de chaque ligne de code généré.

Cette approche élimine aussi le gaspillage avant même que la migration ne commence. Le graphe de connaissances identifie le code mort — des fonctions que rien dans votre système n'appelle réellement. Supprimer le code mort réduit généralement la base de code de 20-30 %, ce qui signifie des coûts de migration plus faibles et un système final plus propre.

Pour les organisations du secteur des services financiers soumises à la surveillance réglementaire, ce genre de transparence n'est pas facultatif. Et si votre modernisation exige de tracer la lignée des données entre les systèmes, chez Veriprajna, les capacités de provenance et de traçabilité des données étendent la même approche par graphe à l'ensemble de votre pipeline de données.

Vous pouvez lire l'analyse technique complète pour les détails d'ingénierie, ou explorer la version interactive pour une présentation visuelle du fonctionnement du graphe de connaissances en pratique.