La migration COBOL qui compilait à la perfection — et qui a pourtant corrompu le grand livre

Le code était parfait. C'était bien là tout le problème.

Un programme de virement bancaire avait été traduit du COBOL vers le Java. Il compilait. Les tests unitaires passaient. Il franchissait chaque barrière que nous avions érigée pour détecter les erreurs. Puis, lors des tests de recette utilisateur, la toute première transaction a déclenché le contrôle de cohérence de la base de données et tout s'est effondré.

L'autopsie a pris plus de temps qu'elle n'aurait dû, parce que rien dans le Java ne semblait anormal. Le coupable était une variable appelée TRN-LIMIT. L'outil de traduction l'avait lue comme un nombre ordinaire et lui avait attribué un type entier standard. Mais TRN-LIMIT n'était jamais définie là où l'outil regardait. Elle était déclarée 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, et ce copybook comportait une clause REDEFINES : une construction COBOL qui permet de lire le même emplacement mémoire comme deux types de données complètement différents selon un indicateur défini tout à fait ailleurs. Sur le mainframe, cette adresse contenait un packed decimal. Le nouveau code Java a écrit du binaire corrompu dans la colonne de la base de données, et l'intégrité référentielle du grand livre a cédé.

Le code était syntaxiquement irréprochable. La défaillance était contextuelle. L'outil avait manqué une dépendance qui vivait hors de son champ de vision — et, dans la modernisation de COBOL hérité, c'est presque toujours ainsi que l'argent disparaît.

Les projets de modernisation ne meurent généralement pas du code que l'on voit. Ils meurent du code que l'outil n'a pas pu voir.

Voici l'histoire de la raison pour laquelle j'ai cessé de croire qu'une meilleure traduction était la réponse, et de ce que nous avons construit chez Veriprajna à la place.

Pourquoi « Collez du COBOL, obtenez du Java » fonctionne-t-il toujours si bien en démo ?

Si vous avez assisté à la moindre réunion de modernisation de mainframe ces deux dernières années, vous avez entendu l'argument de vente : collez votre COBOL, récupérez du Java. C'est séduisant parce que la démo marche toujours. Quelqu'un dépose un programme bien propre de 200 lignes, le modèle renvoie du Java clair et idiomatique, et toute la salle expire. Enfin.

Moi aussi j'y ai cru, un temps. Quand mon équipe s'y est attaquée pour la première fois, nous avons fait la chose évidente — nous avons essayé de rendre la traduction meilleure. Nous avons nourri les modèles de davantage de contexte, nous les avons ajustés aux particularités du COBOL, nous avons évalué la qualité des sorties. Il existe même un modèle ouvert affiné, appelé XMainframe, conçu spécifiquement pour cela, qui obtient un score environ 30 % supérieur aux modèles de code généralistes sur les tâches COBOL. Les traductions sont devenues plus propres. Le Java, plus lisible.

Et ça continuait de casser en recette. Encore et encore, sur exactement le genre de dépendance cachée qui avait coulé ce programme de virement. C'est le mois où j'ai compris que nous polissions la mauvaise chose. La qualité de la traduction n'a jamais été le goulot d'étranglement. Le code qui compile est la partie facile. La partie difficile, c'est le code que l'outil ne peut pas voir.

Les chiffres sur le sujet sont brutaux et constants : 70 à 80 % des projets de modernisation de mainframe échouent à atteindre leurs objectifs. Pas 70 % en retard — 70 % échouent. Le diagnostic habituel accuse une sous-estimation des tests ou une migration de données bâclée, et c'est bien réel. Mais sous presque tous se cache la même cause profonde que je venais de voir en direct : les outils traitent une base de code comme du texte à convertir, alors qu'il s'agit en réalité d'une topologie à comprendre.

Ce que « Collez du COBOL, obtenez du Java » ne peut pas voir

Une fois qu'on se met à chercher la cécité contextuelle, on la voit partout. Trois schémas nous ont fait tomber le plus souvent, et aucun n'est visible dans le fichier source que fixe un traducteur.

Commençons par le problème de copybook que j'ai déjà décrit. Un seul programme COBOL peut référencer plus de quarante copybooks, et ces copybooks en incluent d'autres, si bien que la vraie définition d'une variable peut se trouver plusieurs niveaux plus bas dans la chaîne d'inclusion. Un outil basé sur le texte lit l'instruction devant lui et en déduit un type. Il n'a aucun moyen de savoir que, dans un champ packed-decimal, cette déduction est silencieusement fausse.

Puis il y a l'arithmétique. Le packed decimal COMP-3 du COBOL n'a pas d'équivalent natif en Java. Optez pour un double et vous venez d'introduire de l'arrondi en virgule flottante dans un système qui manipule de l'argent. Même BigDecimal, l'outil correct, ne correspond pas au COBOL par défaut — vous devez explicitement fixer son mode d'arrondi à HALF_EVEN pour reproduire la clause ROUNDED du COBOL. Trompez-vous et vous voilà décalé d'un centime par transaction. Ce centime se cumule sur des millions de transactions jusqu'à ce que, des semaines plus tard, un rapport de rapprochement signale un écart que personne ne sait expliquer.

Le schéma que presque tout le monde oublie est celui qui met réellement la production à terre : votre COBOL ne s'exécute pas tout seul. Un ordonnanceur — CA-7 ou TWS — orchestre entre deux mille et cinq mille travaux batch, avec des chaînes de dépendances qui les traversent. Le travail A écrit un jeu de données à 1 h du matin que le travail B lit à 2 h. Vous pouvez migrer chaque ligne de COBOL à la perfection et faire quand même tomber la banque à minuit, parce que personne n'a cartographié le réseau de travaux. Le graphe de production n'a jamais été dans le code source. Il était dans le JCL.

Le travail qui casse la production à 2 h du matin n'est jamais celui que vous regardiez.

Voilà ce que j'entends par topologie. L'artefact qui fait réellement tourner votre entreprise est un réseau de relations — programmes, copybooks, jeux de données, travaux planifiés, tables DB2, transactions CICS — et le source COBOL n'en est qu'un seul brin.

Pourquoi j'ai cessé de faire confiance au traducteur et me suis mis à dessiner la carte

Le tournant, pour nous, a été de décider que la carte est le produit.

Avant de traduire la moindre ligne, nous construisons un graphe de connaissances de toute la base de code — chaque programme, chaque arête de copybook, chaque dépendance JCL, chaque transfert de jeu de données, chaque point de contact DB2 — et nous résolvons les relations transitives que les fichiers source dissimulent. Quand vous voyez qu'un programme possède plus de quarante arêtes de copybook et que l'une d'elles porte un REDEFINES à deux modules de distance, le désastre TRN-LIMIT ne se produit tout simplement pas, parce que vous saviez que le champ était packed decimal avant même de taper le premier caractère de Java.

Je tiens à être précis sur ce qui rend cela différent de ce que vend le reste du secteur, car le secteur est encombré et l'essentiel y est réellement bon sur la partie qu'il résout.

watsonx Code Assistant for Z d'IBM est l'acteur en place le plus sérieux — un système agentique, avec orchestration, agents d'architecture et de code, qui gère le COBOL-vers-Java et même le PL/I et l'IMS, et qui analyse la consommation CPU jusque dans les copybooks. C'est aussi un engagement de plus de 2 M$ qui tourne sur z/OS et s'appuie sur l'outillage ADDI d'IBM, ce qui vous enchaîne discrètement au mainframe pendant la migration censée vous en libérer. Il ne fait pas de tests d'équivalence comportementale, et il ne cartographie pas votre réseau de travaux JCL.

Puis vint le moment qui a redessiné tout le marché. En février 2026, Anthropic a publié un guide de modernisation COBOL pour Claude Code ; l'action d'IBM a chuté de 13,2 % le jour de l'annonce, et un réseau de partenaires de 100 M$ a suivi en mars. Claude Code excelle dans la découverte, la documentation et la lecture de code inconnu — vraiment utile dans les premières phases. Mais c'est un outil généraliste. Il n'a pas de graphe de connaissances intégré pour résoudre les dépendances transitives, et il ne prétend pas résoudre l'ordonnancement JCL, l'équivalence comportementale ou les pistes d'audit qu'une banque régulée doit produire.

L'usine de migration Azure de Microsoft cible Java Quarkus et verrouille votre plateforme cible sur Azure. Les grands intégrateurs de systèmes — DXC avec son moteur de conversion breveté, TCS avec MasterCraft, Infosys avec Cobalt, Accenture — mènent des prestations à 500 K$ jusqu'à plus de 5 M$ et déploient des outils de fournisseurs plutôt que de bâtir de l'intelligence sur votre système ; Accenture a dirigé la migration du cœur de la Commonwealth Bank of Australia, qui a coûté environ 749,9 millions de dollars et pris cinq ans. Et Visual COBOL de Micro Focus, souvent présenté comme un point de départ, n'est pas du tout de la modernisation — c'est du réhébergement. Votre COBOL reste du COBOL, simplement sur un nouvel environnement d'exécution. La dette technique et le problème de main-d'œuvre sont exactement là où vous les aviez laissés.

Chacun de ces acteurs fait quelque chose de réel. Ce qu'aucun d'eux ne fait, c'est construire la topologie complète des dépendances — JCL, CICS, DB2, copybooks, et tout le reste — d'abord, indépendamment de toute plateforme cible, et traiter cette carte comme le socle sur lequel tout le reste repose.

La plupart des fournisseurs vous vendent un meilleur traducteur. La traduction n'a jamais été la partie qui a échoué.

L'horloge que personne ne peut arrêter

Voici la partie qui transforme cela d'un problème d'ingénierie en une urgence.

Les gens qui comprennent ces systèmes s'en vont. Le développeur COBOL moyen aux États-Unis a environ 55 ans. Chaque année, environ 10 % de cette main-d'œuvre part à la retraite, et 85 % des universités ont retiré le COBOL de leur cursus dès les années 1990, si bien que quasiment personne ne les remplace. Soixante pour cent des organisations affirment désormais que trouver des développeurs COBOL qualifiés est leur plus grand défi de modernisation — et 58 % des développeurs qui connaissent encore ces piles disent envisager de partir à cause d'elles.

Je me suis retrouvé face à la version de cela qui me hante : le pot de départ à la retraite de la seule personne qui comprenait vraiment la fenêtre batch. Tout le monde sourit, il y a un gâteau, et quelque part au fond de ma tête une voix dit ce savoir vient de franchir la porte et il n'est écrit nulle part. Un graphe de connaissances est, entre autres, un moyen de capturer ce qui est dans la tête de cette personne avant la fête — de faire survivre la carte des dépendances à ceux qui l'avaient mémorisée.

Et les enjeux ne sont ni minces ni abstraits. Environ 220 milliards de lignes de COBOL sont encore en production active. Il fait tourner 95 % des transactions de distributeurs automatiques et compense environ 3 000 milliards de dollars par jour. Quarante-trois pour cent des systèmes bancaires reposent dessus. La dette technique américaine est estimée à 1 520 milliards de dollars, et l'entreprise moyenne brûle environ 370 millions de dollars par an en inefficacité héritée, les sociétés de services financiers consacrant 70 à 75 % de leur budget informatique à simplement maintenir les vieux systèmes en vie. Les équipes qui réussissent la migration rapportent des retours de 114 à 225 % et environ 25 millions de dollars d'économies par an — mais ce gain n'existe que de l'autre côté d'une migration qui n'a pas échoué. C'est la rare modernisation où ne rien faire est l'option coûteuse.

Les nouveaux outils d'IA ne vont-ils pas simplement régler ça ?

C'est la question qu'on me pose le plus, et elle est légitime, surtout après que l'annonce d'Anthropic a donné l'impression que le problème venait tout juste d'être déclaré résolu.

Ma réponse honnête : les nouveaux outils ont rendu la phase de découverte radicalement plus rapide, et c'est un vrai progrès — je les utilise. Mais le fait que l'IA agentique devienne douée pour lire du COBOL ne change rien à ce qui tue réellement les projets. Gartner prévoit que 40 % des applications d'entreprise intégreront des agents d'IA spécialisés d'ici 2026 ; plus d'agents traduisant du code plus vite n'aide en rien s'ils sont tous aveugles à la même dépendance JCL. La vitesse sur le mauvais problème n'est qu'un moyen plus rapide d'atteindre la recette et d'y échouer.

L'autre question qu'on me pose porte sur la réglementation, et c'est celle que les banques de taille intermédiaire sous-estiment. Le règlement européen sur la résilience opérationnelle numérique — DORA — est entré en vigueur en janvier 2025 et exige une résilience opérationnelle et des tests d'intrusion pilotés par la menace que les systèmes hérités n'ont tout simplement jamais été conçus pour réussir. Aux États-Unis, les examinateurs de la FFIEC et de l'OCC traitent l'infrastructure vieillissante comme un manquement actif en matière de conformité, et les systèmes de plus de dix ans présentent une probabilité de violation environ trois fois plus élevée. Une migration incapable de produire une piste d'audit prouvant que le nouveau système se comporte à l'identique de l'ancien n'est pas une modernisation — c'est une nouvelle responsabilité assortie d'une meilleure syntaxe.

Voilà pourquoi les tests d'équivalence comportementale comptent autant que la carte. La technique est simple à décrire et difficile à bien faire : capturer les entrées et sorties réelles du système hérité — un jeu de données de référence — et les rejouer contre le nouveau jusqu'à ce que le comportement corresponde, cas limite par cas limite. Ces cas limites, accumulés sur des décennies, encodent souvent une logique réglementaire qui n'existe nulle part ailleurs — ni dans une spécification, ni dans la tête de quelqu'un, uniquement dans le code en cours d'exécution. J'ai vu cela mordre un assureur plus fort qu'une banque : la règle de tarification qui ne se déclenche que pour un avenant de police de 1998, le calcul de réserve pour sinistres dont personne de vivant ne sait expliquer l'arrondi mais dont chaque audit dépend. Perdez-les silencieusement et vous découvrirez lesquels comptaient le jour où un régulateur posera la question.

Quelle brique retirez-vous en premier ?

Une fois que vous avez la carte, elle vous dit quelque chose qu'aucun traducteur ne peut vous dire : où il est sûr de commencer.

La stratégie dominante aujourd'hui — à juste titre — est le figuier étrangleur : au lieu d'une réécriture d'un seul coup, vous extrayez une capacité à la fois, faites tourner l'ancien et le nouveau côte à côte, et conservez le système hérité comme repli vivant jusqu'à ce que la nouvelle pièce ait gagné la confiance. Mais chaque fournisseur qui recommande le figuier étrangleur omet la question la plus difficile — quel module étranglez-vous en premier ? Choisissez-en un fortement couplé et vous avez recréé le risque du big-bang avec des étapes en plus.

Le graphe de connaissances y répond directement. Il fait remonter les modules au couplage le plus faible — ceux qui ont le moins de dépendances entrantes — pour que vous puissiez extraire une vraie pièce du système, prouver l'approche et bâtir la confiance de l'organisation avant de toucher au cœur dangereux. La carte n'est pas seulement une assurance contre la défaillance TRN-LIMIT. C'est le plan de séquençage.

Nous avons construit tout cela — le graphe de connaissances des dépendances, le séquençage par figuier étrangleur, le banc d'essai d'équivalence comportementale, délibérément indépendant de toute plateforme cible — au sein de la pratique de modernisation de COBOL hérité de Veriprajna, ciblée précisément sur les banques et assureurs de taille intermédiaire que les acteurs en place au plancher de 2 M$ et les intégrateurs à sept chiffres jugent trop petits pour s'en soucier.

Ce sur quoi je suis honnête

Je ne prétendrai pas que la technologie résout tout, car les échecs les plus coûteux que j'ai vus n'avaient rien de technique.

Aucun outil — le nôtre inclus — ne règle l'adhésion de l'organisation, ne nettoie des années de mauvaises données, ni ne gagne le combat politique consistant à convaincre deux cents développeurs de changer leur façon de travailler. Le marché devrait passer d'environ 9 milliards de dollars en 2026 au double d'ici la fin de la décennie précisément parce qu'une si grande part de la dépense va à la couche humaine et organisationnelle, et non au compilateur. Et aucun analyseur syntaxique au monde, open-source ou commercial, ne couvre parfaitement chaque construction du COBOL d'entreprise d'IBM — les instructions ALTER antérieures à 1985, les REDEFINES les plus profonds. Quiconque vous dit le contraire vous vend l'écart. La technologie est nécessaire. Elle n'a jamais été suffisante.

Mais la part que la technologie peut assumer, elle doit l'assumer entièrement. La raison pour laquelle les migrations engloutissent des millions et ne livrent rien tient rarement à ce que quelqu'un ait écrit du mauvais Java. C'est qu'ils ont traduit un système qu'ils n'avaient jamais réellement cartographié — convertissant des brins d'un réseau tandis que le réseau lui-même restait invisible jusqu'à la nuit où il s'est déchiré.

Dessinez la carte d'abord. Un système qui a survécu à ceux qui l'ont écrit ne pardonne pas une dépendance manquée, et il n'existe aucune version de ce travail qui soit sûre avant de pouvoir voir ce qui se connecte à quoi. Nous l'avons appris d'un grand livre défait par un seul champ packed-decimal dont personne ne soupçonnait l'existence. Trouvez ces champs avant qu'ils ne vous trouvent.