Modernisation des mainframes hérités
70 à 80 % des projets de modernisation de mainframe échouent. Non pas parce que la technologie est mauvaise, mais parce que les outils traitent le code comme du texte plutôt que comme une topologie. Nous construisons la carte de votre base de code avant de toucher la moindre ligne, afin que votre migration réussisse là où d'autres ont englouti des millions sans rien livrer.
1,52 billion $
Dette technique aux États-Unis
Pragmatic Coders, 2025
10 %/an
Attrition de la main-d'œuvre COBOL
IEEE Spectrum, 2025
70 à 80 %
Taux d'échec de la modernisation
Méta-analyse du secteur, 2025
Les outils qui promettent « collez du COBOL, obtenez du Java » produisent du code qui compile. C'est la partie facile. La partie difficile, c'est le code qu'ils ne peuvent pas voir.
Prenons un programme de traitement de virements. Il contient une instruction COMPUTE utilisant une variable nommée TRN-LIMIT. Un assistant de codage par IA traduit l'instruction en une opération Java BigDecimal . Le code compile. Les tests unitaires passent.
En recette (UAT), la première transaction fait planter la vérification de cohérence de la base de données.
L'autopsie : TRN-LIMIT n'était pas défini dans le fichier source traduit par l'IA. Il était défini dans un copybook inclus des milliers de lignes plus tôt dans la chaîne d'exécution. Ce copybook contenait une clause REDEFINES , une construction COBOL qui permet d'interpréter une même adresse mémoire comme deux types de données différents selon un drapeau positionné dans un module complètement distinct.
L'IA a vu TRN-LIMIT comme un simple champ numérique et a supposé un type entier standard. Sur le mainframe, cette adresse mémoire contenait un décimal compacté (COMP-3). L'application Java a écrit 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.
Le code était syntaxiquement parfait. La défaillance venait d'une cécité contextuelle. L'IA a manqué une dépendance qui existait hors de son champ de vision.
Un seul programme COBOL peut référencer plus de 40 copybooks. Chaque copybook peut en COPY d'autres. Les définitions de variables peuvent se trouver à 5 niveaux de profondeur dans la chaîne d'inclusion. Les outils d'IA basés sur le texte n'en voient rien.
Votre COBOL ne s'exécute pas seul. CA-7 ou TWS planifient 2 000 à 5 000 jobs JCL avec des chaînes de dépendances. Le job A écrit un dataset que le job B lit à 2 h du matin. Migrez le COBOL mais oubliez le JCL, et la production casse à minuit.
Le décimal compacté COMP-3 de COBOL n'a pas d'équivalent en Java. Un Java double introduit des erreurs d'arrondi en virgule flottante. Même BigDecimal exige une configuration explicite du mode d'arrondi (HALF_EVEN) pour correspondre à la clause ROUNDED de COBOL. Un centime erroné se cumule sur des millions de transactions.
Chaque grand éditeur technologique vend désormais de la modernisation de mainframe. Voici ce que chacun livre réellement, et là où subsistent les lacunes.
| Éditeur / Approche | Ce qu'il fait | Coût typique | Ce qu'il manque |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | Traduction agentique de COBOL vers Java avec analyse de dépendances ADDI. Architecture multi-agents (agents Orchestrate, Architect, Code). Prend en charge PL/I et IMS. | 2 M$+ (licences entreprise + exigence z/OS) | ADDI s'exécute sur z/OS, créant une dépendance fournisseur pendant la migration. L'analyseur peine sur les constructions COBOL antérieures à 1985 (instructions ALTER). Pas de tests d'équivalence comportementale. Pas de cartographie des dépendances JCL. |
| Anthropic Claude Code | Analyse de code, documentation et cartographie de dépendances par IA. Solide dans les phases de découverte et d'exploration. Prend en charge la migration incrémentale et l'encapsulation par API. | Tarification API à l'usage | IA généraliste. Pas de graphe de connaissances intégré pour la résolution des dépendances transitives. Ne traite pas la planification JCL, les tests d'équivalence comportementale ni les pistes d'audit réglementaires. |
| Microsoft Azure Migration Factory | Agents agentiques modulaires via Semantic Kernel. Agents COBOL Expert + Java Expert. Cible Java Quarkus. Agent de migration Azure Copilot en préversion. | Consommation Azure + conseil | Dépendance Azure pour la plateforme cible. Les agents open source sont des implémentations de référence, non prêtes pour la production dans des environnements réglementés. Prise en charge limitée de CICS/IMS. |
| DXC Technology | Conversion automatique de code brevetée (COBOL/RPG/JCL vers Java). Des décennies d'expertise mainframe. Modèles de cloud hybride + mainframe-as-a-service. | 1 M$ à 10 M$+ | Outillage propriétaire, transparence limitée sur la logique de conversion. Orientation grandes entreprises. Des durées d'engagement de 18 à 36 mois sont courantes. |
| TCS / Infosys / Accenture | Pratiques de grands intégrateurs de systèmes avec des cadriciels propriétaires (MasterCraft, Cobalt). Équipes de livraison massives. Gestion de programme de bout en bout. | 500 K$ à 5 M$+ | Approche centrée sur la plateforme. Ils mettent en œuvre des outils éditeurs, ils ne construisent pas d'intelligence sur mesure. Surcoût du modèle d'engagement des grands intégrateurs. Un intégrateur a piloté une migration bancaire à 1 milliard AUD qui a pris 5 ans et doublé son budget. |
| Micro Focus (OpenText) Visual COBOL | Exécuter du COBOL nativement sur .NET/JVM. Point de départ pragmatique de type « strangler fig ». Leader du marché des compilateurs COBOL. | 200 K$ à 500 K$ de licences | Ce n'est pas de la modernisation, c'est du réhébergement. La logique COBOL reste du COBOL. La dette technique persiste. Ne résout pas le problème de main-d'œuvre. |
| Le « fait soi-même » avec de l'IA open source | LLM XMainframe (7B/10,5B de paramètres, 30 % meilleur que DeepSeek sur COBOL). Analyse syntaxique Tree-sitter. Pipelines personnalisés. | Temps d'ingénierie + infrastructure | Exige une expertise approfondie en COBOL + ingénierie de graphes. Aucun analyseur COBOL de qualité production ne couvre toutes les constructions d'IBM Enterprise COBOL v6.x. Risque élevé d'intégrer des lacunes d'analyse dès la fondation. |
Cinq capacités, chacune répondant à une lacune précise de la chaîne d'outils de modernisation. Nous sommes neutres vis-à-vis des fournisseurs : le graphe de connaissances fonctionne que votre cible soit AWS, Azure, GCP ou un Java sur site.
Nous ingérons vos sources COBOL, copybooks, bibliothèques JCL, exports du catalogue DB2, définitions de transactions CICS et hiérarchies de segments IMS dans une base de données de graphe unifiée. Chaque variable, chaque chaîne PERFORM, chaque clause REDEFINES, chaque dépendance batch devient une arête de graphe explicite. Nous optons pour Neo4j lorsque des requêtes complexes de fermeture transitive dominent le cas d'usage, et pour Memgraph lorsque la vitesse de parcours en temps réel importe pour l'exploration interactive.
Le graphe traite environ 200 K à 300 K lignes par jour lors de l'ingestion. Pour une base de code de 2 M de LOC, comptez 8 à 12 semaines entre la première ingestion et un graphe validé et interrogeable. Le résultat est un actif permanent : votre base de code comme une topologie consultable, et non des fichiers texte opaques.
Avant tout début de traduction de code, nous menons une analyse de graphe selon quatre dimensions : score de couplage (combien d'autres modules dépendent de celui-ci), densité de REDEFINES/COMP-3 (combien de pièges de types de données existent), pourcentage de code mort (généralement 20 à 30 % de la base de code) et criticité de planification batch (quels jobs JCL touchent ce module et quand).
Le résultat est une séquence d'extraction classée pour une migration de type strangler fig. Les modules au couplage le plus faible et aux types de données les plus simples sont extraits en premier. Les « programmes dieux » appelés par plus de 50 autres modules sont extraits en dernier. Ce séquencement fait la différence entre un déploiement maîtrisé et une défaillance en cascade.
Nos agents de traduction interrogent le graphe de connaissances avant de générer chaque module Java, récupérant la fermeture transitive complète des dépendances. L'agent voit la clause REDEFINES dans le copybook situé trois répertoires plus loin. Il voit la définition en décimal compacté qui détermine le comportement d'arrondi. Il génère du Java avec passage explicite de paramètres (injection de dépendances) au lieu de l'état global implicite du COBOL. Puis il compile dans un bac à sable, exécute des tests d'équivalence comportementale et s'auto-corrige.
Nous utilisons le modèle de fondation qui convient à la complexité du module. Pour les conversions simples de PERFORM vers méthode, un modèle plus petit fait l'affaire. Pour les modules à REDEFINES imbriqués, à spaghetti de GOTO nécessitant un aplatissement du flux de contrôle, ou à logique transactionnelle EXEC CICS embarquée, nous mobilisons le modèle le plus performant disponible et l'enrichissons du contexte complet du graphe.
La partie que la plupart des fournisseurs sautent et sur laquelle la plupart des migrations échouent. Nous construisons un système de validation à trois couches : des tests unitaires symboliques générés à partir des chemins de flux de contrôle dérivés du graphe, une rejouabilité de jeu de données de référence (golden dataset) utilisant des transactions de production capturées et comparées champ par champ avec une précision au centime près, et des exécutions parallèles en production où les deux systèmes traitent des transactions réelles pendant 30 à 90 jours avant la mise hors service du module mainframe.
Les calculs financiers exigent BigDecimal avec le mode d'arrondi HALF_EVEN pour correspondre à la clause ROUNDED de COBOL. Les calculs de dates exigent la gestion du format de date à 6 chiffres de COBOL (YYMMDD) avec une logique de fenêtrage de siècle. Nous intégrons ces règles de conversion dans le banc de test, et non dans des correctifs ad hoc découverts pendant la QA.
Nous analysons vos réseaux de jobs JCL, vos chaînes de dépendances CA-7/TWS/Control-M et vos séquences de traitement batch pour les intégrer au graphe de connaissances. Chaque job JCL devient un nœud relié par des arêtes aux programmes COBOL qu'il exécute, aux datasets qu'il lit et écrit, et aux conditions de planification dont il dépend (déclencheurs horaires, disponibilité des datasets, achèvement des prédécesseurs).
Lorsqu'un module COBOL migre vers Java, nous construisons simultanément la planification équivalente dans votre plateforme d'orchestration cible (Apache Airflow, AWS Step Functions, Azure Data Factory ou Control-M en distribué). La chaîne de dépendances est préservée et vérifiée par rapport à la définition CA-7/TWS d'origine. Une banque de taille intermédiaire typique a 2 000 à 5 000 jobs JCL. Nous les avons tous vus.
Une démonstration pas à pas de la manière dont la résolution de dépendances basée sur le graphe prévient le schéma d'échec de migration le plus courant.
L'analyseur traite PROG-WIRE-01.cbl, rencontre COPY CB-ACCT-LIMITS, et suit la chaîne d'inclusion. Il construit des nœuds AST pour chaque déclaration de variable, y compris celles des copybooks imbriqués sur 3 niveaux.
Le moteur de graphe crée des arêtes : PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT. Cela capture le fait que le type de données de TRN-LIMIT dépend d'un drapeau d'exécution situé dans un champ différent.
Le graphe parcourt vers l'extérieur : quels autres programmes font aussi COPY de CB-ACCT-LIMITS ? Quels programmes positionnent LIMIT-TYPE-FLAG ? Quels jobs JCL exécutent ces programmes, et dans quel ordre ? Le résultat est une chaîne d'impact complète. Changer la façon dont TRN-LIMIT est traduit affecte chaque programme de cette chaîne.
Lorsque l'agent de traduction traite PROG-WIRE-01, GraphRAG récupère non seulement le fichier source, mais aussi la définition du copybook, la relation REDEFINES, le champ drapeau et tous les programmes qui positionnent ce drapeau. L'agent génère une classe Java avec un motif d'union sûr en types : un objet TransactionLimit qui vérifie le drapeau avant d'interpréter les octets sous-jacents comme soit un BigDecimal (mode décimal compacté), soit une String (mode alphanumérique).
Sans le graphe : l'IA suppose que TRN-LIMIT est un simple champ numérique, génère un long en Java, et le premier virement corrompt la base de données. Avec le graphe : l'IA voit la chaîne de dépendances complète et génère du code sûr en types qui gère correctement les deux interprétations. C'est la différence entre une migration qui fonctionne en recette (UAT) et une qui fonctionne en production.
Quatre phases, chacune avec des livrables clairs. Nous ne devisons pas un calendrier de 3 ans pour ensuite disparaître. Chaque phase produit des artefacts que vous possédez et pouvez utiliser de manière indépendante.
Livrable : rapport d'évaluation + prototype préliminaire de graphe de connaissances
Livrable : graphe de connaissances interrogeable + séquence d'extraction classée + outil d'analyse d'impact
Livrable : modules Java migrés en production + graphe de connaissances mis à jour + équivalents de planification
Livrable : déploiement en production validé + dossier de documentation réglementaire + graphe mis à jour
Répondez à sept questions sur votre environnement. L'évaluation identifie votre niveau de maturité et les obstacles précis à traiter avant de lancer un engagement de migration, avec ou sans Veriprajna.
Pour une base de code de 2 M de LOC de complexité typique (IBM Enterprise COBOL v6.x, SQL embarqué DB2, plus de 500 copybooks), la construction du graphe prend 8 à 12 semaines. Les 3 premières semaines sont consacrées à la configuration et à la validation de l'analyseur. Les dialectes COBOL varient suffisamment pour que nous devions vérifier que l'analyseur gère votre usage spécifique de REDEFINES, d'OCCURS DEPENDING ON et des blocs EXEC CICS/SQL avant d'ingérer la base de code complète.
Les semaines 4 à 8 sont l'ingestion automatisée, l'extraction d'entités et la cartographie des relations. L'analyseur traite environ 200 K à 300 K lignes par jour, mais le goulot d'étranglement est la résolution d'entités, c'est-à-dire déterminer que ACCT-NUM dans le programme A et ACCT-NUM dans le copybook CB-ACCT-01 sont la même variable.
Les semaines 9 à 12 sont le calcul et la validation de la fermeture transitive. Nous effectuons des contrôles de complétude du graphe : chaque cible PERFORM doit se résoudre en un paragraphe, chaque instruction COPY doit se résoudre en un copybook, chaque référence de table DB2 doit correspondre à une définition de schéma. Les lacunes sont signalées pour une revue manuelle. Le résultat est un graphe de connaissances interrogeable où vous pouvez poser des questions comme « Que se passe-t-il si je change INTEREST-RATE dans CB-GLOBAL-01 ? » et obtenir une chaîne d'impact complète à travers chaque programme qui le référence, directement ou transitivement.
Oui, et nous le recommandons vivement. Le motif strangler fig est la seule approche au bilan éprouvé pour la migration de mainframe. Les réécritures complètes échouent dans 70 à 80 % des cas parce qu'elles tentent de tout remplacer simultanément, créant un unique point de défaillance massif.
Avec l'approche strangler fig, le graphe de connaissances identifie quels modules ont les scores de couplage les plus faibles, c'est-à-dire le moins de dépendances entrantes provenant d'autres modules. Ce sont vos candidats à l'extraction. Nous commençons généralement par des modules de reporting batch ou des routines de calcul autonomes qui lisent dans DB2 mais ne mettent pas à jour d'état partagé. Le nouveau service Java s'exécute aux côtés du mainframe. Le trafic de production est routé vers le nouveau service pour cette fonction spécifique pendant que le mainframe continue de gérer tout le reste. Vous validez l'équivalence comportementale sur des données de production réelles avant de mettre hors service le module COBOL.
La plupart des organisations extraient 15 à 20 modules la première année, réduisant la consommation MIPS de 20 à 30 % et générant assez d'économies pour financer la phase suivante. Le graphe de connaissances rend cela sûr car il vous montre le rayon d'impact de chaque extraction. Si le module A est appelé par 47 autres programmes, ce n'est pas votre premier candidat à l'extraction. Si le module B est appelé par 2 programmes et lit dans 1 table DB2, commencez par là.
C'est la couche où la plupart des projets de modernisation rencontrent des défaillances inattendues 6 à 12 mois après le démarrage. Vos programmes COBOL ne s'exécutent pas isolément. Ils sont orchestrés par des flux de jobs JCL gérés par CA-7, TWS (Tivoli Workload Scheduler) ou Control-M. Une banque de taille intermédiaire typique a 2 000 à 5 000 jobs JCL avec des chaînes de dépendances complexes : le job A doit s'achever avant le démarrage du job B, le job C ne s'exécute que le dernier jour ouvré du mois, le job D déclenche une transaction CICS qui met à jour un fichier VSAM lu par le job E.
Nous analysons le JCL en même temps que le COBOL dans le même graphe de connaissances. Chaque job JCL devient un nœud relié par des arêtes aux programmes COBOL qu'il exécute, aux datasets qu'il lit et écrit, et aux conditions de planification dont il dépend. Lorsque nous migrons un module COBOL vers Java, nous construisons simultanément la planification équivalente dans votre plateforme cible, qu'il s'agisse d'Apache Airflow, d'AWS Step Functions ou d'Azure Data Factory. La chaîne de dépendances est préservée et vérifiée par rapport à l'originale.
Nous avons vu des projets où la migration du code avait parfaitement réussi mais où la production a cassé parce que personne n'avait cartographié le job CA-7 qui exécutait une étape de prétraitement chaque nuit à 2 h du matin.
IBM Watsonx Code Assistant for Z (actuellement en v2.8.20, avec Project Bob à venir plus tard en 2026) est un produit solide doté d'une intégration mainframe profonde. Il requiert IBM ADDI (Application Discovery and Delivery Intelligence) pour construire son analyse de dépendances, et ADDI s'exécute sur z/OS. Cela signifie que votre outillage d'analyse de dépendances réside sur le mainframe même que vous essayez de quitter. Cela signifie aussi qu'IBM contrôle la couche d'analyse, ce qui crée une dépendance fournisseur pendant la phase la plus critique de la migration.
Notre graphe de connaissances s'exécute hors mainframe. Nous ingérons des exports de code source, des bibliothèques JCL, des exports du catalogue DB2 et des dépôts de copybooks. Le graphe réside dans votre environnement cloud ou votre infrastructure sur site, indépendamment des licences IBM. Deuxièmement, Watsonx se concentre sur la traduction de COBOL vers Java. Nous nous concentrons d'abord sur la compréhension, ensuite sur la traduction. Le graphe de connaissances est un actif permanent qui sert à l'analyse d'impact, à la génération de documentation et à la gouvernance architecturale bien après l'achèvement de la migration.
Troisièmement, l'analyseur COBOL d'ADDI présente des limitations documentées avec les constructions COBOL antérieures à 1985, en particulier les instructions ALTER et certains motifs REDEFINES imbriqués. Nous construisons des extensions d'analyseur personnalisées pour le dialecte de chaque client.
Enfin, la tarification d'IBM vise les grandes entreprises. Notre modèle d'engagement convient aux institutions de taille intermédiaire pour qui un engagement IBM à 2 M$+ n'entre pas dans le budget.
L'équivalence comportementale est l'endroit où la plupart des migrations assistées par IA s'effondrent. Du code qui compile et passe les tests unitaires peut tout de même produire des résultats erronés à cause de différences d'arrondi en décimal compacté, de discordances d'encodage EBCDIC-vers-ASCII ou de la sémantique de superposition mémoire de REDEFINES qui ne se traduit pas en objets Java.
Nous construisons un banc de validation à trois couches. La couche 1 est l'équivalence symbolique : nous générons à partir du graphe de connaissances des tests unitaires couvrant chaque branche du flux de contrôle COBOL d'origine, y compris les cas limites comme les montants négatifs, les protections contre la division par zéro et les calculs de dates bissextiles. La couche 2 est la rejouabilité de jeu de données de référence (golden dataset) : nous capturons un ensemble représentatif de transactions de production du mainframe (enregistrements d'entrée, lectures DB2, interactions CICS) et les rejouons à travers le nouveau service Java. Les sorties sont comparées champ par champ. Pour les calculs financiers, nous vérifions une précision au centime près en utilisant BigDecimal avec l'arrondi HALF_EVEN pour correspondre au comportement de la clause ROUNDED de COBOL.
La couche 3 est l'exécution parallèle en production : les deux systèmes traitent les mêmes transactions réelles simultanément pendant 30 à 90 jours. Les écarts sont journalisés, investigués et corrigés avant la mise hors service du module mainframe. C'est la phase la plus longue, mais c'est aussi celle qui attrape les cas limites accumulés sur 30 ans de production qu'aucune suite de tests ne peut pleinement anticiper.
DORA (Digital Operational Resilience Act) est pleinement en vigueur depuis le 17 janvier 2025, et il impacte directement toute entité financière réglementée de l'UE exploitant des systèmes mainframe. L'article 11 exige des cadres de gestion des risques TIC incluant des tests de résilience réguliers et des tests d'intrusion guidés par la menace fondés sur des scénarios d'attaque du monde réel. La plupart des environnements mainframe n'ont pas été conçus pour ce type de tests. Vous ne pouvez pas facilement déployer un environnement z/OS répliqué pour exécuter des tests d'intrusion sans coûts significatifs de licences et d'infrastructure.
DORA exige également des inventaires détaillés des actifs TIC, le signalement des incidents dans des délais spécifiques et la gestion des risques liés aux tiers pour les prestataires de services TIC critiques, ce qui inclut votre fournisseur de mainframe. La modernisation aide de deux façons. Premièrement, le graphe de connaissances lui-même sert d'inventaire des actifs TIC exigé par DORA. Il cartographie chaque programme, chaque flux de données, chaque dépendance externe. Les régulateurs peuvent l'interroger directement.
Deuxièmement, les composants migrés s'exécutant sur une infrastructure cloud sont intrinsèquement plus faciles à tester en résilience. Vous pouvez déployer des environnements de test à la demande, exécuter des scénarios de chaos engineering et valider les procédures de reprise sans affecter la production. Nous avons vu des institutions utiliser le graphe de connaissances comme preuve dans des examens réglementaires pour démontrer qu'elles comprennent leur patrimoine technologique, avant même l'achèvement de la migration.
La méthodologie qui sous-tend cette page de solution s'appuie sur nos recherches publiées concernant la modernisation des systèmes hérités et les architectures de graphes de connaissances.
Comment les graphes de connaissances conscients du dépôt et GraphRAG surmontent le syndrome « Lost in the Middle » qui fait échouer la traduction de code par IA sur les systèmes COBOL d'entreprise.
Une réduction de 20 à 30 % des MIPS la première année permet généralement d'économiser 500 K$ à 2 M$ par an pour une institution de taille intermédiaire.
L'évaluation par graphe de connaissances prend 4 à 6 semaines. Vous obtenez une carte complète des dépendances de votre base de code, un rapport de code mort et une séquence d'extraction classée, que vous poursuiviez la migration ou non. L'évaluation elle-même est un actif permanent.