Sharif HAMED , 25 Fevrier 2026
L’annonce d’Anthropic autour de Claude Code, un outil capable d’analyser et d’explorer des bases de code complexes, y compris du COBOL, a immédiatement suscité des réactions.
Dans les heures qui ont suivi, l’action IBM reculait nettement.
Pour beaucoup, le message semblait clair : si l’IA peut comprendre le COBOL, alors une partie du modèle économique du legacy serait menacée.
Mais la réalité est plus subtile.
Oui, les modèles d’IA sont désormais capables d’ingérer de très grands volumes de code, d’identifier des dépendances, de cartographier des flux et de produire de la documentation structurée à une vitesse inédite.
Par contre, cela ne signifie pas qu’ils comprennent un système critique au sens opérationnel du terme.
La question n’est donc pas de savoir si l’IA peut lire le COBOL.
Elle le peut.
La question est plus exigeante :
comprend-elle réellement le système qu’elle analyse ?
Ce que l’IA sait réellement faire
Sur le plan technique, les progrès sont réels.
Des outils comme Claude Code peuvent :
- parcourir des millions de lignes,
- relier des programmes,
- identifier des copybooks,
- reconstruire des chaînes d’appel,
- proposer une vue structurée d’un périmètre applicatif.
Là où une équipe mettait des semaines à explorer un domaine, une première cartographie peut désormais être obtenue en quelques heures.
Ils produisent aussi de la documentation.
Ils résument des modules.
Ils expliquent des flux.
Pour des environnements où la documentation est lacunaire ou obsolète, c’est un gain considérable.
Mais ces capacités ont un périmètre.
Dans la pratique, un système COBOL ne vit pas seul.
Il dépend de JCL, de traitements batch, de CICS, de SQL embarqué, de paramétrages externes, de tables métiers et de conventions internes parfois anciennes. La logique réelle est souvent répartie entre code, configuration et exploitation.
Une analyse automatisée donne une base.
Elle ne remplace pas la validation par ceux qui connaissent le système en production.
Lire n’est pas maîtriser
Un système critique n’est pas seulement un ensemble de programmes.
C’est le résultat d’années d’évolutions, d’exceptions métier, de contraintes réglementaires et d’arbitrages techniques. Certaines règles ne sont écrites nulle part. Elles existent dans les usages, dans les contrôles, dans les reprises, dans les anomalies historiques.
Dans un système critique, le code n’est pas toujours la source de vérité complète.
La vérité s’exprime en production.
Comprendre un module ne signifie pas comprendre comment il se comporte sous charge.
Cartographier un flux ne signifie pas anticiper ses effets en situation dégradée.
Générer une documentation ne signifie pas assumer les conséquences d’une modification.
C’est là que se situe la frontière.
L’IA accélère la lecture.
Elle ne porte pas la responsabilité.
Le vrai changement : la fin du coût de compréhension
Pendant des décennies, la principale difficulté du legacy n’a pas été son exécution, mais sa compréhension.
Avant de transformer un système COBOL, il fallait :
- D’abord le décoder.
- Reconstruire sa logique.
- Identifier ses dépendances.
- Évaluer ses impacts.
Cette phase représentait une part importante du coût et du risque des projets.
C’est précisément ce point que l’IA modifie.
La barrière d’entrée liée à la lecture du code diminue.
L’accès à la structure du système devient plus rapide.
Mais comprendre plus vite ne veut pas dire comprendre totalement.
La complexité métier reste.
Les contraintes réglementaires restent.
La responsabilité opérationnelle reste.
Ce que l’IA change réellement, c’est l’équilibre des efforts.
Moins de temps consacré à “où agir”.
Plus d’attention portée à “quoi changer” et “comment sécuriser”.
La vitesse augmente.
L’exigence de maîtrise demeure.
Ce que cela change pour le monde COBOL
Le COBOL ne disparaît pas parce qu’il devient lisible.
Au contraire, ces outils peuvent faciliter certains projets de modernisation en réduisant l’incertitude initiale. Un système mieux cartographié est un système plus visible.
Le rôle des experts évolue.
Moins centré sur la lecture ligne à ligne.
Plus orienté vers l’interprétation, l’architecture et la sécurisation des évolutions.
Le besoin d’expertise ne baisse pas mécaniquement.
Il se déplace vers des compétences plus systémiques : compréhension métier, gouvernance du changement, validation et mise en production.
Quant au consulting legacy, une partie de la valeur historiquement liée à la reconstruction de connaissance pourrait être partiellement automatisée.
Mais la transformation d’un système critique ne se limite jamais à son analyse.
Elle engage des choix.
Et ces choix engagent des responsabilités.
La frontière qui demeure
L’IA peut lire le COBOL.
Elle peut en expliquer la structure.
Elle peut en accélérer l’exploration.
Mais un système critique n’est pas seulement du code.
C’est un équilibre entre logique métier, contraintes techniques et responsabilité opérationnelle.
Un équilibre qui ne se délègue pas à un modèle.
Lire vite n’a jamais été le problème.
Décider juste, si.
Article rédigé par
Sharif HAMED , 25 février 2026
