Sharif HAMED , 12 mars 2026

Si vous avez lu les deux articles précédents de cette série, vous savez déjà que l’IA abaisse le coût d’exploration des systèmes COBOL et déplace la valeur de l’expertise vers la maîtrise systémique. Ce cadre, on l’a posé.

Cet article descend d’un niveau. Pas de thèse générale mais des situations concrètes. Trois dimensions précises du travail d’expert que les outils d’IA les plus avancés ne pourront pas couvrir, non pas par limitation technique temporaire, mais par nature.

Parce que “jamais” est un mot qui mérite d’être défendu.

1. La mémoire de ce qui n’a jamais été écrit

Voici quelque chose que tout expert COBOL d’expérience a rencontré au moins une fois.

Un paramètre dans le code, appelons-le WS-CTRL-SEUIL (controle de seuil), est fixé à une valeur qui semble arbitraire. Rien dans la documentation ne l’explique. Aucun commentaire dans le code. Le développeur qui l’a posé là a pris sa retraite en 2011.

Et pourtant, personne ne le touche. Pas par paresse.
Par instinct collectif : tout le monde sait que ce paramètre tient quelque chose en équilibre, sans que personne soit capable de dire exactement quoi.

Un outil d’IA peut lire ce paramètre. Il peut noter qu’il est utilisé dans trois modules différents, qu’il conditionne un branchement dans un traitement de fin de mois, qu’il n’a pas été modifié depuis 2009. Il peut même émettre une alerte sur ce point.

Ce qu’il ne peut pas faire : savoir que ce paramètre a été fixé ainsi à la suite d’un incident de production catastrophique survenu un dimanche de décembre 2008, qu’il a été modifié en urgence par une équipe épuisée, et que sa valeur actuelle est le résultat d’un compromis empirique jamais formalisé.
Pourquoi? Parce que personne n’a eu le temps de documenter, et que depuis, personne n’a osé rouvrir ce dossier.

Cette connaissance-là existe. Elle est réelle. Mais elle ne vit pas dans le code, elle vit dans les gens.

Et quand ces gens partent, elle disparaît avec eux. Sauf si quelqu’un a pris le temps, pendant des années, de la collecter, de la questionner, de la tester contre la réalité du système. C’est exactement ce que fait un expert du système, pas un expert du code.

L’IA ne peut pas reconstruire ce qui n’a jamais été encodé. Cette limite est structurelle, pas technique.

2. La décision sous incertitude irréductible

Il y a une scène qui se répète dans tous les projets de modernisation de systèmes critiques. Elle ressemble à ça.

L’analyse est faite. Les dépendances sont cartographiées. Le rapport est sur la table. Et quelqu’un, ca peut etre un chef de projet, un directeur technique, un architecte senior, doit répondre à une question simple en apparence :

“On y va ou on n’y va pas ?”

Ce moment est toujours inconfortable. Parce que l’information n’est jamais complète. Il y a toujours une zone d’ombre. Ca peut etre un comportement en production qu’on ne peut pas simuler parfaitement en recette, une dépendance externe qu’on n’a pas pu tester, un volume de données réelles qu’on n’a pas reproduit en environnement de qualification.

Décider dans cette situation, c’est assumer que quelque chose peut mal tourner et estimer que le risque est acceptable compte tenu de ce qu’on sait.

Aucun outil ne peut faire ça. Non pas parce qu’il manquerait d’information, mais parce que la décision implique d’engager sa responsabilité dans un contexte d’incertitude. Ce n’est pas un calcul. C’est un jugement.

Et un jugement suppose un sujet qui assume les conséquences de ce qu’il dit. L’IA n’a pas de conséquences. Elle n’est pas en astreinte le dimanche soir quand le batch échoue. Elle ne reçoit pas l’appel du directeur des opérations à 3h du matin. Elle ne vit pas avec la décision qu’elle a contribué à prendre.

L’expert, lui, si. Et c’est précisément cette exposition au risque réel qui fonde la valeur de son jugement.

3. La lecture de l’organisation autour du code

Un système COBOL critique n’existe pas dans le vide. Il vit dans une organisation. Ca peut être avec ses tensions internes, ses priorités contradictoires, ses équipes qui ne se parlent pas, ses décisions historiques jamais remises en question, et ses contraintes politiques que personne ne met par écrit.

Comprendre un système COBOL en profondeur, c’est comprendre tout ça.

Pourquoi ce module a-t-il été développé en interne alors que la logique métier identique existait déjà ailleurs ?
Parce qu’en 2003, la DSI et la direction métier ne se parlaient plus, et qu’il était plus rapide de réécrire que de négocier.

Pourquoi ce batch critique tourne-t-il à 3h du matin sur une fenêtre aussi contrainte ?
Parce que le contrat SLA avec un prestataire externe impose une livraison de fichier avant 5h, et que ce contrat date de 2001 et n’a jamais été renegocié.

Pourquoi cette règle de gestion est-elle codée en dur alors qu’elle devrait être paramétrable ?
Parce que le projet de paramétrage a été annulé mi-parcours en 2016, faute de budget, et que la solution provisoire est devenue permanente.

Ces informations n’apparaissent dans aucune documentation technique. Elles ne sont pas dans le code. Elles émergent des conversations, des réunions, de l’histoire partagée avec les équipes métier, de la mémoire des incidents.

Un outil d’IA, aussi puissant soit-il, travaille sur ce qui lui est fourni. Il peut analyser du code, des logs, des schémas de base de données, des fichiers de configuration.
Il ne peut pas assister à dix ans de réunions de comité de pilotage.
Il ne peut pas percevoir la tension dans la salle quand on évoque une refonte de ce module.
Il ne peut pas interpréter le silence d’un responsable métier quand on lui pose une question précise sur une règle de calcul.

Cette lecture-là est irremplaçable. Pas parce que l’IA n’est pas assez intelligente. Parce qu’elle n’est pas là.

Pourquoi “jamais” et pas “pas encore”

On me posera la question, alors autant y répondre directement.

Ces trois dimensions ne sont pas des limitations techniques en attente d’une prochaine version. Elles sont liées à quelque chose de plus fondamental : la responsabilité, la mémoire implicite et la présence dans une organisation humaine ne sont pas des problèmes d’analyse. Ce sont des réalités qui n’existent que parce qu’un être humain les porte et en assume les conséquences.

Un outil peut produire une recommandation. Il ne peut pas être tenu responsable de ses conséquences.
Un outil peut analyser ce qui est encodé. Il ne peut pas savoir ce qui ne l’a jamais été.
Un outil peut traiter ce qu’on lui fournit. Il ne peut pas avoir été présent pendant vingt ans dans une organisation.

Ces trois choses resteront humaines. Pas parce qu’on le décide. Parce que c’est leur nature.

Ce que ça change concrètement

Pour ceux qui font ce métier, ces trois dimensions définissent exactement ce sur quoi il vaut la peine d’investir.

La mémoire implicite se cultive en posant des questions à ceux qui partent avant qu’ils partent. En documentant non pas seulement ce que le système fait, mais pourquoi il le fait ainsi. En construisant une connaissance qui survit aux individus.

La décision sous incertitude se développe en acceptant d’être exposé, en portant des décisions difficiles plutôt qu’en les déviant vers le haut ou vers l’outil. En cultivant le courage technique.

La lecture organisationnelle se construit en sortant du code. En comprenant les enjeux métier des clients. En étant présent dans les conversations qui ne sont pas techniques.

L’IA va accélérer tout ce qui est analysable. Ce qui n’est pas analysable, parce que ça n’a jamais été écrit, parce que ça implique une responsabilité réelle, parce que ça vit dans les relations humaines, restera le territoire de ceux qui ont choisi de l’habiter.

Article rédigé par
Sharif HAMED , 12 mars 2026

Cet article fait partie d’une série sur l’évolution de l’expertise COBOL à l’ère de l’IA.
→ Article 1 : Claude Code, COBOL, IBM : ce que la chute du marché ne dit pas
→ Article 2 : Lire du COBOL devient facile. Être expert devient rare.