Le 23 février 2026, le cours de l'action IBM a chuté de 13 % en une seule journée, sa plus forte baisse journalière depuis octobre 2000. La cause ? L'annonce d'un laboratoire d'IA affirmant pouvoir moderniser le COBOL. Les conseils d'administration des systèmes mainframe ont pris connaissance de cette annonce et se sont demandés si l'IA pouvait désormais convertir leur COBOL et leur permettre de se passer des mainframes. La réponse d'IBM, publiée le jour même, était sans équivoque : la traduction ne rend quasiment pas compte de la complexité réelle, qui réside dans l'architecture des données, le remplacement de l'environnement d'exécution, l'intégrité des transactions et les exigences non fonctionnelles inhérentes à la plateforme. Le marché avait confondu deux problèmes distincts et valorisé une solution à l'un comme s'il s'agissait d'une solution aux deux.
Les deux problèmes sont la compréhension et la traduction. Il ne s'agit pas de phases d'une même activité, mais de défis techniques distincts que l'IA relève avec des capacités et des risques différents. L'IA a considérablement réduit le coût de la compréhension du langage COBOL, mais pas celui de son remplacement. Cette distinction est cruciale, car les entreprises qui investissent dans la modernisation doivent savoir quel problème elles cherchent à résoudre, ce que l'IA apporte réellement à chaque problème et comment les travaux de vérification restants, indépendamment des outils d'IA, absorberont le budget libéré par les économies réalisées sur la compréhension et la traduction.
Les fondements structurels dont l'IA a besoin
SMART TS XL Elle identifie les programmes inaccessibles avant le début de la traduction par l'IA — vous traduisez donc ce qui est en cours d'exécution, et non ce qui existe.
EN SAVOIR PLUS…La distinction que le marché a mal interprétée
La compréhension et la traduction ne sont pas le même problème.
La compréhension est la discipline qui consiste à comprendre le fonctionnement et la raison d'être d'un code, en extrayant l'intention métier de son implémentation technique. Dans le contexte COBOL, comprendre signifie : quelles règles métier ce programme encode-t-il ? Quelles conditions régissent chaque chemin d'exécution ? Quelles données lit-il et produit-il ? Quels systèmes en aval dépendent de ses résultats ? De quelles informations un analyste métier aurait-il besoin pour rédiger les spécifications de son remplacement ? La compréhension porte sur la sémantique, c'est-à-dire le sens, et non sur la syntaxe.
La traduction est la discipline qui consiste à convertir du code d'un langage à un autre tout en préservant son comportement. Dans le contexte COBOL, traduire signifie produire du code Java (ou Python, ou Go) qui se comporte comme le code COBOL, pour toutes les entrées, dans toutes les conditions, avec une équivalence numérique suffisante pour les systèmes en aval qui utilisent les sorties. La traduction repose sur l'équivalence structurelle et comportementale : le nouveau code doit réussir tous les tests que l'ancien aurait réussis, y compris les tests pour les cas limites que le développeur initial avait envisagés et dont vous n'auriez peut-être jamais soupçonné l'existence.
| Dimension | Compréhension | Traduction |
|---|---|---|
| Réponse à la question | Que signifie ce code ? | Que fait exactement ce code ? |
| Le type de sortie | Langage naturel, documentation | Code exécutable |
| Conséquence de l'erreur | Corrigible par une relecture humaine | Incident de production |
| Capacité de l'IA | Solides, les titulaires d'un LLM excellent en prose | Faible, déterminisme requis |
| Contrainte d'échelle | Gérable avec des fenêtres contextuelles | L'échelle du portefeuille ne respecte pas la limite de contexte |
| Profil de risque | Faible, les erreurs sont vérifiables | En effet, les erreurs sont invisibles jusqu'à ce qu'elles se produisent. |
| Rôle humain | validateur et enrichisseur | Réviseur et vérificateur |
Ces problèmes sont liés – une certaine compréhension est nécessaire pour une bonne traduction –, mais il ne s'agit pas du même problème, et l'écart de capacités de l'IA entre les deux est considérable. La compréhension du code COBOL par l'IA est véritablement impressionnante. En revanche, la traduction du code COBOL en Java conforme aux spécifications de production par l'IA est extrêmement complexe, et la confusion qui règne sur le marché entre les deux explique pourquoi Gartner a prédit que plus de 70 % des projets de migration vers des systèmes mainframe lancés en 2026 n'atteindraient pas les objectifs fixés.
Là où la compréhension par l'IA porte réellement ses fruits
Le problème de la compréhension présente une caractéristique qui rend l'IA particulièrement adaptée : le résultat est du langage naturel, et la génération de langage naturel est le point fort des grands modèles de langage. Lorsqu'une IA lit un programme COBOL et produit sa documentation (description du fonctionnement du programme, explication des règles métier, énumération des flux de données), le résultat est un texte. Les erreurs dans ce texte sont corrigibles : un relecteur humain peut repérer une règle métier mal définie et la corriger sans aucune conséquence technique ultérieure. Le coût des erreurs de compréhension se limite à la correction de la documentation, et non à un incident de production.
Documentation des règles métier. Un modèle de langage complexe, présenté avec un bloc EVALUATE COBOL et contenant potentiellement des centaines de conditions WHEN accumulées au fil des décennies d'évolutions réglementaires, peut générer une description structurée de la signification de chaque condition en termes métier. Pour les programmes dont la documentation originale a disparu ou n'a jamais existé, cette documentation s'avère extrêmement précieuse. Un programme COBOL implémentant la logique de calcul des taxes dans 63 juridictions intègre les règles de ces juridictions dans sa structure EVALUATE ; l'IA peut les extraire et les documenter plus rapidement que n'importe quel processus manuel. Le résultat doit être validé par un expert du domaine, mais ce dernier valide la sortie de l'IA plutôt que de reconstruire les connaissances à partir de zéro, ce qui est beaucoup plus rapide.
Voici à quoi ressemble la compréhension de l'IA en pratique. Prenons comme exemple le code source COBOL suivant :
Cobol
EVALUATE TRUE
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'CA'
COMPUTE TAX-AMT = GROSS-AMT * 0.0725
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'TX'
COMPUTE TAX-AMT = GROSS-AMT * 0.0825
WHEN CUST-COUNTRY = 'UK'
COMPUTE TAX-AMT = GROSS-AMT * 0.20
WHEN CUST-COUNTRY = 'DE'
COMPUTE TAX-AMT = GROSS-AMT * 0.19
WHEN OTHER
MOVE ZERO TO TAX-AMT
END-EVALUATE.
Un LLM bien mené produit :
Business Rule: Tax Calculation
This paragraph applies jurisdiction-specific tax rates to GROSS-AMT:
- US/California: 7.25% (CA state sales tax)
- US/Texas: 8.25% (TX state sales tax)
- United Kingdom: 20% (UK VAT standard rate)
- Germany: 19% (DE MwSt standard rate)
- All other countries: tax-exempt (TAX-AMT = 0)
Note: No rate exists for other US states. Orders from NY, FL, IL
will be tax-exempt under current logic -- likely a gap requiring review.Ce résultat est véritablement précieux : il documente quatre règles métier, identifie une lacune probable (les États américains sans taux explicites) et ce, en quelques heures. Un expert du domaine l’examine, confirme la lacune et l’ajoute aux cas de test. La tâche de compréhension est ainsi accomplie avec succès.
Description des dépendances. Les outils d'analyse statique produisent des graphes de dépendances indiquant quels programmes s'appellent, quels copybooks sont partagés et quels jeux de données circulent entre eux. L'IA peut générer une description en langage naturel à partir de ce graphe : « CUSTPROC est appelé par 14 programmes, principalement lors du traitement par lots nocturne. Il partage CUSTMSTR avec 47 programmes et génère des données dans CUST-REPORT-FILE, qui sont utilisées par le flux de travail de reporting réglementaire. » Cette description est plus utile pour l'intégration et l'analyse de l'architecture qu'un simple graphe de dépendances, et l'IA la génère en quelques secondes à partir des données de dépendances structurées.
Génération de cas de test à partir du comportement observé. Une fois que l'IA a documenté le comportement du programme, elle peut générer des cas de test couvrant les chemins d'exécution documentés. Cela ne revient pas à prouver l'équivalence comportementale : les cas de test couvrent les chemins que l'IA a compris, et peuvent donc en omettre certains. Cependant, couvrir 60 % des chemins d'exécution grâce à des tests générés par l'IA est préférable à la couverture nulle de nombreux programmes existants, et constitue un point de départ pour l'ajout manuel de tests nécessaire à la validation de l'équivalence comportementale.
Reconnaissance de modèles dans des programmes similaires. Les vastes portefeuilles COBOL contiennent souvent de nombreux programmes structurellement similaires : même schéma de traitement appliqué à différentes entités, même calcul réglementaire paramétré différemment. L’IA peut identifier ces similarités parmi des milliers de programmes et les regrouper par type de modèle, permettant ainsi une stratégie de migration qui traite chaque modèle une seule fois et applique la solution de manière systématique, au lieu de considérer chaque programme comme unique.
Le point commun : les résultats de la compréhension par IA sont textuels, ces textes sont vérifiés par des humains, et cette vérification permet de corriger les erreurs avant qu’elles n’aient des conséquences techniques. Le profil de risque de la compréhension par IA est suffisamment faible pour que sa valeur ajoutée soit réelle et que ses erreurs soient gérables.
Quand la traduction automatique par IA fait des promesses excessives
La traduction présente une caractéristique qui la rend fondamentalement plus difficile pour l'IA que la compréhension : le résultat est du code exécutable, et ce code doit être irréprochable. Une traduction précise à 95 % produit un programme qui échoue pour 5 % des entrées, ce qui, dans un système de traitement des transactions financières, peut se traduire par une erreur de déclaration réglementaire, un écart de calcul de solde ou un problème de conformité. Le coût des erreurs de traduction ne se limite pas à une simple correction de la documentation ; il s'agit d'un incident de production.
L'échec de la précision numérique. L'arithmétique décimale compacte de COBOL (COMP-3) produit des résultats décimaux exacts. Celle de Java… double et Python float L'utilisation du format binaire à virgule flottante IEEE 754 ne permet pas de représenter exactement la plupart des fractions décimales. Un programme COBOL effectue les calculs suivants : 0.1 + 0.2 avec COMP-3 produit exactement 0.3Le même calcul en Java avec double produit 0.30000000000000004Pour une institution financière où ce calcul est exécuté 10 millions de fois par nuit pour les soumissions réglementaires, l'erreur cumulée n'est pas une simple curiosité liée aux nombres à virgule flottante, mais une anomalie dans les rapports financiers. Une traduction automatique par IA qui génère du Java sans gérer explicitement la conversion COMP-3 vers BigDecimal introduit systématiquement cette erreur, et ce pour chaque champ qu'elle traduit. double plutôt que des BigDecimal.
La différence de code est subtile ; la conséquence, elle, ne l’est pas :
Cobol
* COBOL: COMP-3 packed decimal -- exact arithmetic
77 UNIT-PRICE PIC S9(7)V99 COMP-3.
77 QUANTITY PIC S9(5) COMP-3.
77 LINE-TOTAL PIC S9(11)V99 COMP-3.
COMPUTE LINE-TOTAL = UNIT-PRICE * QUANTITY.
* UNIT-PRICE = 19.99, QUANTITY = 3
* LINE-TOTAL = exactly 59.97 -- no rounding error
Java
// Java: naive AI translation uses double -- introduces error
double unitPrice = 19.99;
int quantity = 3;
double lineTotal = unitPrice * quantity;
// lineTotal = 59.96999999999999... not 59.97
// Correct translation requires BigDecimal:
// BigDecimal lineTotal = new BigDecimal("19.99").multiply(new BigDecimal(3));Lors d'une transaction isolée, l'erreur est invisible. Sur 10 millions de transactions nocturnes, compilées dans un rapport de fonds propres réglementaires, elle représente un écart significatif. Une traduction automatique qui ne prend pas explicitement en compte les champs COMP-3 effectuera systématiquement cette substitution.
La dépendance aux options du compilateur. Un code source COBOL identique peut se comporter différemment selon les options du compilateur. Par exemple, NUMPROC(MIG) et NUMPROC(NOPFD) modifient la gestion des exceptions numériques. Les options RMODE, AMODE et DATA affectent l'adressage. Une IA qui traduit du code source COBOL sans connaître les options du compilateur utilisées traduit le code source, mais pas le comportement du programme. Le code Java traduit peut correspondre au code source, mais pas au comportement en production.
Le problème des hallucinations à grande échelle. Des recherches montrent que les modèles de type GPT-4 présentent des taux d'hallucinations de 33 à 60 % lors de tâches de traduction automatique, générant un code d'apparence plausible qui ajoute ou supprime des comportements absents du code source. Pour un programme comportant 847 conditions d'évaluation, un taux d'hallucinations de 5 % signifie qu'environ 42 conditions sont mal traduites. Ces 42 conditions représentent des règles métier que la traduction a enfreintes sans que le système ne s'en aperçoive. Sans un corpus de test complet couvrant toutes les conditions, ces erreurs restent indétectables jusqu'à ce que la combinaison d'entrées spécifique qui les déclenche soit mise en production.
Les enjeux en chiffres :
Error Type | Detection Point | Cost Range
--------------------|--------------------|------------------
Comprehension error | Human review | Hours to fix
Translation error | Test suite | Days to isolate
Translation error | Production | $10K-$500K+ incident
Equivalence gap | Regulatory audit | $50K-$5M+ penaltyL’asymétrie : les erreurs de compréhension sont détectées avant qu’elles n’aient des conséquences techniques. Les erreurs de traduction, quant à elles, passent inaperçues lors de la relecture et se révèlent cruciales en production, voire pire, lors d’une soumission réglementaire.
Le plafond de la fenêtre de contexte. L'assistant de code watsonx d'IBM pour Z atteint une précision structurelle de 80 % ou plus pour la traduction COBOL vers Java des programmes individuels au sein d'une fenêtre de contexte. Un portefeuille COBOL de 5 millions de lignes comprend des milliers de programmes, avec des dépendances inter-programmes qui s'étendent sur des programmes ne pouvant pas tous se trouver simultanément dans la même fenêtre de contexte. Un programme appelant un sous-programme dont l'interface est traduite par l'IA différemment des hypothèses du programme appelant crée une incompatibilité d'interface qu'aucune traduction prise individuellement ne permettrait de détecter. La traduction à l'échelle d'un portefeuille nécessite une compréhension transversale des programmes, et non une simple compréhension au sein de chacun d'eux.
Le problème de la traduction hors contexte. Un programme COBOL qui traite un événement métier spécifique le fait avec un contexte inhérent au système : la planification des traitements par lots qui détermine son exécution, les jeux de données nécessaires à son démarrage, l’ordre de traitement des enregistrements et les programmes en aval qui lisent sa sortie avant de s’exécuter. Une IA qui traduit le programme sans comprendre ce contexte traduit le code source, mais pas son rôle. Le code Java traduit peut être correct en interne et pourtant dysfonctionnel, car il s’exécute au mauvais moment, dans le mauvais ordre et sans les prérequis de données dont son homologue COBOL s’appuyait.
L'écart d'équivalence comportementale
Le problème le plus important que ni l'IA de compréhension ni l'IA de traduction ne résolvent est la preuve d'équivalence comportementale, c'est-à-dire la démonstration que le système modernisé produit les mêmes résultats que l'ancien système pour toutes les entrées importantes pour l'entreprise et ses organismes de réglementation.
L'équivalence comportementale ne relève pas des tests au sens classique du terme. Il ne s'agit pas de savoir si le nouveau système réussit les tests, car les tests d'un système COBOL existant sont souvent inexistants ou ne couvrent qu'une fraction des chemins d'exécution du programme. Il s'agit plutôt de déterminer si, pour chaque entrée reçue par le système de production, le système modernisé produit la même sortie. Et pour chaque entrée que le système de production pourrait recevoir à l'avenir, y compris les cas particuliers survenant uniquement lors de conditions de marché exceptionnelles, d'échéances réglementaires ou de situations spécifiques chez un client, le système modernisé produit-il un résultat équivalent ?
Répondre à cette question nécessite : une caractérisation du comportement du système existant tirée de son exécution réelle en production (et non de la documentation, ni du seul code source), un corpus de tests couvrant toute la gamme de ce comportement, et un cadre de comparaison permettant de déterminer ce que signifie « équivalent » pour des sorties dont la représentation diffère (EBCDIC vs UTF-8, décimal compressé vs BigDecimal, fichier batch vs enregistrement de base de données).
Les outils de traduction IA ne fournissent rien de tout cela. Le constat d'IBM est sans appel : la traduction ne rend quasiment pas compte de la complexité réelle de la modernisation. C'est au niveau de l'équivalence comportementale, de l'exécution en parallèle, du cadre de réconciliation et de la validation réglementaire que se concentrent les coûts et les risques, et c'est là que l'IA a le moins d'impact sur le coût total du programme. L'IA simplifie la première étape du projet de modernisation : la compréhension et la traduction initiale. Elle ne simplifie pas la seconde : la vérification, les tests d'équivalence et la validation en parallèle.
Le modèle correct : Fondements de l’analyse statique, couche sémantique de l’IA
La capacité de compréhension la plus efficace de l'IA ne repose pas sur l'IA seule, mais sur une IA s'appuyant sur une base structurelle fournie par l'analyse statique. Les limitations de la compréhension par l'IA (limites de la fenêtre de contexte, hallucinations face à une logique inter-programmes complexe, analyse probabiliste plutôt que déterministe) sont surmontées par l'analyse statique. Les limitations de l'analyse statique (elle produit des faits structurels mais pas de descriptions sémantiques) sont, quant à elles, surmontées par l'IA.
La répartition idéale des tâches : l’analyse statique garantit la certitude structurelle (déterministe, exhaustive, sans hallucinations). L’IA apporte la richesse sémantique (descriptions en langage naturel, reconnaissance de formes, génération de tests). Aucune des deux n’est suffisante à elle seule. C’est leur combinaison qui permet de répondre pleinement aux exigences de compréhension.
Le fondement structurel que fournit l'analyse statique :
Inventaire complet des programmes. Chaque programme du portefeuille est traité, y compris ceux non documentés et ceux que la fenêtre de contexte de l'IA ne pourrait jamais couvrir simultanément. L'analyse statique traite l'intégralité du portefeuille sans limitation de contexte.
Un graphe de dépendances précis. Chaque relation CALL, chaque relation COPY, chaque flux de données entre les programmes, doit être déterminé de manière déterministe à partir du code source, et non probabiliste à partir de données d'entraînement. Lorsqu'un outil de compréhension de l'IA décrit les dépendances d'un programme, cette description doit s'appuyer sur un graphe de dépendances issu d'une analyse statique, et non sur la capacité de l'IA à se souvenir de manière probabiliste des dépendances habituelles des programmes.
Identification du code mort. Les programmes inaccessibles depuis n'importe quel chemin d'exécution en production ne font pas partie du périmètre de modernisation. L'analyse statique les identifie avec certitude ; l'IA, elle, ne le peut pas, car elle ne dispose pas des traces d'exécution nécessaires pour distinguer le code actif du code mort par la seule analyse statique.
Inventaire des schémas de données. Chaque entrée FD, chaque copybook, chaque champ COMP-3 avec sa spécification de précision, extraits des artefacts sources plutôt que reconstruits à partir de la mémoire de données d'entraînement de l'IA de ce à quoi ressemblent généralement les définitions de champs COBOL.
À cette base structurelle s'ajoute la couche sémantique : les descriptions en langage naturel du fonctionnement de chaque programme, la documentation des règles métier, le récit des flux de données inter-programmes et la reconnaissance de formes qui regroupe les programmes similaires. Cette combinaison – la précision structurelle déterministe de l'analyse statique et la richesse sémantique en langage naturel de l'IA – constitue le modèle qui produit des résultats de compréhension fiables pour une équipe de modernisation.
Ce que cela signifie pour votre programme de modernisation
Répartition pratique des investissements en IA sur la base de cette analyse :
Investissez dans la compréhension par l'IA. Génération de documentation, extraction des règles métier, description des dépendances, génération de cas de test à partir du comportement documenté : autant d'applications de l'IA à forte valeur ajoutée et à faible risque qui permettent de raccourcir la phase traditionnellement manuelle, la plus coûteuse, de la modernisation. Il est essentiel de les réaliser en premier, avant la traduction, car la compréhension influence toutes les décisions ultérieures.
Utilisez la traduction automatique comme générateur d'ébauches, et non comme outil de finalisation. Elle produit un code Java ou Python de départ qu'un développeur examine, corrige et valide, et non un code prêt pour la production pouvant être déployé sans vérification humaine. Considérer le résultat de la traduction automatique comme une ébauche réduit les coûts de traduction tout en préservant la responsabilité humaine qu'exige la validation d'équivalence.
Ne prenez pas en compte les gains de temps liés à la traduction automatique dans le calcul des coûts de vérification. L'IA réduit le temps de production d'un programme traduit, mais pas celui nécessaire pour prouver son équivalence avec l'original. Prévoyez un budget pour la phase de vérification indépendamment des gains de temps liés à la traduction automatique, car la portée de la vérification reste la même même si la traduction est plus rapide.
Il est essentiel de commencer par établir une structure solide. Les outils de compréhension de l'IA qui ne reposent pas sur une telle structure (un graphe de dépendances précis, un inventaire complet des programmes et un inventaire des schémas de données) produisent une compréhension incomplète là où le code est le plus complexe. Les programmes qui nécessitent le plus l'intervention de l'IA sont généralement les plus complexes, les plus dépendants les uns des autres et ceux qui dépassent les capacités d'analyse précises de l'IA à partir du seul code source.
Comment SMART TS XL Prend en charge la compréhension COBOL améliorée par l'IA
SMART TS XL fournit les bases d'analyse structurelle qui permettent à l'IA de comprendre les portefeuilles COBOL avec précision plutôt que de manière probabiliste.
L' analyse statique du code produit les données structurelles au niveau du programme dont les outils de compréhension de l'IA ont besoin : chaque condition EVALUATE est énumérée, chaque formule COMPUTE est extraite et chaque mode d'accès aux données est caractérisé. Lorsque les outils de documentation de l'IA traitent le code source en utilisant ces données structurelles comme contexte, ils produisent des descriptions basées sur le contenu réel du code plutôt que sur le comportement typique de programmes similaires.
La cartographie des dépendances applicatives fournit le contexte inter-programmes que les fenêtres de contexte d'IA ne peuvent pas contenir simultanément. Un graphe de dépendances illustrant les 14 appelants de CUSTPROC, ses 47 partageurs de copybooks et ses 3 sorties de flux de données offre aux outils de compréhension d'IA une vision complète du rôle d'un programme dans le portefeuille, sans exiger que tous les programmes dépendants soient présents simultanément dans la même fenêtre de contexte.
L' analyse de modernisation du système existant produit l'inventaire du code mort et la distribution de la complexité que la compréhension par l'IA ne peut pas produire de manière fiable à elle seule : quels programmes sont inaccessibles en production (exclus du périmètre), quels programmes ont la plus grande complexité (où les erreurs de compréhension sont les plus coûteuses) et à quoi ressemble le périmètre de migration des données dérivé des entrées FD réelles plutôt que de la documentation.
La capacité de recherche d'entreprise rend l'inventaire structurel interrogeable à l'aide de l'IA pour faciliter la compréhension : trouver chaque programme qui implémente un modèle spécifique, chaque bloc EVALUATE avec plus de N conditions, chaque programme qui accède à un ensemble de données spécifique, des requêtes qui fondent la compréhension de l'IA sur des preuves structurelles plutôt que sur la probabilité des données d'entraînement.
Pour les organisations où l'IA fait désormais partie de la chaîne d'outils de modernisation, SMART TS XLL'analyse structurelle de [nom de l'entreprise] est la couche qui permet une compréhension précise de l'IA à l'échelle du portefeuille, en abordant la limite de la fenêtre de contexte, le risque d'hallucination sur la logique inter-programmes et l'écart de déterminisme qui sépare l'analyse structurelle de la génération probabiliste.
L'IA a changé le coût de la compréhension, pas celui de la preuve.
Ce qui a changé en 2026, c'est le coût de la compréhension. L'IA a considérablement réduit le coût et la rapidité de la compréhension du fonctionnement d'un programme COBOL, de la documentation de ses règles métier, de la caractérisation de son comportement et de la description de sa place dans le portefeuille de programmes. Il s'agit d'une contribution réelle et substantielle à l'économie de la modernisation. Pour les programmes dont la phase de compréhension exigeait auparavant des semaines de travail d'experts, l'IA peut générer une première ébauche de compréhension en quelques heures, que les experts examinent et affinent au lieu de repartir de zéro.
Ce qui n'a pas changé, c'est le coût de la validation. La validation de l'équivalence comportementale, l'exécution en parallèle, l'approbation réglementaire et la vérification de la migration des données restent inchangées par rapport à l'époque pré-IA, absorbant 40 à 50 % du budget de modernisation, quelle que soit la rapidité des phases de compréhension et de traduction. IBM avait vu juste le 23 février 2026 : la traduction ne rend quasiment pas compte de la complexité réelle. Cette complexité réside dans la vérification de l'équivalence comportementale, et elle ne se réduit pas avec l'accélération de la traduction.
Les organisations qui tirent pleinement parti de l'IA dans la modernisation de COBOL sont celles qui investissent dans la compréhension par l'IA, domaine où elle excelle véritablement, et qui considèrent la traduction automatique comme un point de départ pour la relecture humaine plutôt que comme un produit fini prêt à être déployé. Elles comprennent que la réduction des coûts en amont du projet n'entraîne pas nécessairement une réduction des coûts en aval. Elles mettent en place l'analyse structurelle fondamentale dont a besoin l'IA pour garantir la précision de la compréhension à l'échelle du portefeuille, là où se concentre le travail de compréhension le plus important.
