Sharif HAMED , 02 avril 2026

Mardi 31 mars, Emmanuel Macron intervenait au sommet du GIE Carte Bancaire au Carrousel du Louvre. Son message était clair : la France et l’Europe ne peuvent pas se permettre de dépendre de Visa et Mastercard pour faire circuler leur argent.

Il a raison. Mais le débat public passe à côté de l’essentiel.

Ce que les médias ont retenu

Le discours a été largement couvert sous l’angle politique : souveraineté, indépendance, géopolitique. On a beaucoup parlé de Wero, de l’euro numérique, du cobadging. On a moins parlé de ce qui se passe réellement quand vous payez avec votre carte.

Et c’est précisément là que se situe le vrai sujet.

Ce que vous ne voyez pas quand vous payez

Quand une transaction par carte se déclenche, elle traverse plusieurs couches successives.

En surface : le réseau. Visa, Mastercard, ou CB selon votre carte. C’est la partie visible comme le logo dans le coin, le terminal du commerçant, le message d’autorisation en quelques secondes.

En dessous : les systèmes de votre banque. Autorisation, compensation, règlement. Des infrastructures construites sur des décennies, maintenues par des équipes spécialisées, tournant sur des environnements mainframe. Dans les grandes banques françaises telles que BNP Paribas, Société Générale, Crédit Agricole, ces systèmes reposent encore très largement sur du COBOL.

Cette couche profonde est souveraine. Elle l’a toujours été. Personne ne s’en empare, personne ne la contrôle depuis San Francisco ou New York.

Ce qui ne l’est pas, c’est le réseau par lequel la transaction transite avant d’y arriver.

La dépendance est déjà là

Ce n’est pas un risque futur. C’est une réalité présente. Sur les 21 pays de la zone euro, 13 dépendent exclusivement de réseaux non européens pour leurs paiements. En France, la part de marché du GIE CB est passée de près de 90% en 2021 à 63,6% au second semestre 2025. En quatre ans, presque 30 points perdus.

Le discours de Macron arrive donc dans un contexte où la tendance est déjà engagée et pas dans le bon sens.

Pourquoi reconstruire est si difficile

Créer une alternative crédible à Visa et Mastercard, ce n’est pas une question de volonté politique. C’est une question d’infrastructure.

Ces réseaux représentent des décennies d’investissement, des partenariats bancaires sur tous les continents, des systèmes de cybersécurité rodés par des milliards de transactions. Wero est une initiative sérieuse, mais elle part de zéro sur un marché où les habitudes des consommateurs et des commerçants sont déjà formées.

La vraie difficulté n’est pas technique. Elle est comportementale et géopolitique. Convaincre les banques de revenir au cobadging quand certaines avaient fait le choix stratégique du Visa only. Convaincre les consommateurs d’utiliser un nouvel outil quand leur carte actuelle fonctionne partout dans le monde.

Ce que ça dit sur la souveraineté en général

Ce débat illustre quelque chose de plus large : la souveraineté d’un système ne se lit pas à une seule couche.

On peut maîtriser parfaitement la technologie de traitement et perdre le contrôle du réseau de distribution. On peut avoir les meilleurs ingénieurs et dépendre d’une infrastructure étrangère pour atteindre ses propres clients.

C’est exactement ce qui s’est passé avec les paiements européens. La couche technique, profonde, historique, comme celle que les équipes mainframe maintiennent depuis quarante ans, est restée souveraine. C’est la couche réseau, plus récente, plus visible, qui a échappé.

La leçon pour les années qui viennent : construire de la souveraineté ne suffit pas. Il faut aussi la défendre couche par couche.

Article rédigé par
Sharif HAMED , 02 avril 2026

Sharif HAMED , 30 mars 2026

Du vendredi 3 au lundi 6 avril 2026, les virements bancaires entre établissements seront suspendus dans toute la zone euro. Quatre jours sans transferts SEPA classiques. La plupart des titres parleront de “blocage”. Certains diront “panne”. Ces mots sont inexacts. Ce n’est pas un incident. C’est de l’architecture.

---

Qu’est-ce que TARGET2, concrètement ?

TARGET2 est le système de règlement interbancaire de la zone euro. En termes simples, c’est le réseau qui permet aux banques de transférer des fonds entre elles de façon sécurisée. Sans lui, une banque ne peut pas envoyer d’argent vers un autre établissement.

Ce système est géré par la Banque centrale européenne et les banques centrales nationales. Il traite chaque jour ouvré des volumes considérables de transactions. Et comme tout système critique bien conçu, il dispose de fenêtres de fermeture programmées, notamment les jours fériés reconnus à l’échelle européenne. Le Vendredi saint et le lundi de Pâques en font partie.

Ce n’est pas une nouveauté. C’est le même scénario chaque année, à la même période. Un virement effectué le jeudi 2 avril après 16h30 ne sera visible sur le compte du destinataire qu’à partir du mardi 7 avril.

---

Les systèmes les plus critiques ne sont pas conçus pour fonctionner “toujours”. Ils sont conçus pour fonctionner de façon fiable, dans des fenêtres définies.

---

Ce que cet arrêt révèle sur les systèmes critiques

Ce qui est intéressant dans cet épisode, ce n’est pas la suspension elle-même. C’est ce qu’elle rend visible.

La robustesse d’une architecture ne se mesure pas à son uptime théorique. Elle se mesure à la clarté de ses règles de fonctionnement, y compris ses règles d’arrêt. Un système qui sait s’arrêter proprement est un système mature. Un système qui ne peut pas s’arrêter est un système fragile.

Dans les environnements COBOL et mainframe, cette logique est profondément ancrée. Les traitements batch sont planifiés. Les fenêtres d’exécution sont définies à l’avance. Les dépendances entre jobs sont documentées. Chaque composant sait ce qu’il doit faire, quand il doit le faire, et ce qui se passe s’il ne peut pas le faire.

Ce n’est pas de la rigidité. C’est de la maturité d’exploitation.

---

Le virement instantané : une réponse, pas un remplacement

Il existe une alternative opérationnelle pendant ces quatre jours : le virement instantané. Ce service permet de transférer de l’argent en quelques secondes, 24h/24 et 7j/7, y compris les jours fériés. Depuis début 2025, toutes les banques de la zone euro ont l’obligation de le proposer gratuitement.

Mais le virement instantané ne passe pas par TARGET2. Il s’appuie sur une infrastructure parallèle, avec ses propres règles, ses propres contraintes, ses propres limites de montant.

Ce n’est pas un remplacement du système existant. C’est un composant supplémentaire dans un écosystème de plus en plus complexe. Deux rails distincts, deux logiques différentes, deux ensembles de règles métier. Et derrière la gestion de ces règles, dans les systèmes des grandes banques françaises, on retrouve encore très souvent du COBOL.

---

Ce que ça implique pour les équipes techniques

Pour les développeurs et architectes qui travaillent sur des systèmes bancaires, cet arrêt annuel de TARGET2 est un cas d’usage concret à anticiper chaque année.

Il faut gérer correctement les dates de valeur pendant la période de fermeture, traiter les files d’attente de virements qui s’accumulent avant la reprise le mardi matin, et s’assurer que les batchs nocturnes qui s’appuient sur des confirmations interbancaires ne partent pas en erreur silencieuse pendant le week-end pascal.

Ce n’est pas un cas exceptionnel. C’est un cas récurrent, documenté, prévisible. Exactement le type de situation pour lequel les environnements mainframe ont été conçus : gérer la complexité métier dans le temps, sans approximation.

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

Sharif HAMED , 26 mars 2026

Épisode 5 de la série : L’expertise COBOL à l’ère de l’IA

Les quatre articles précédents ont posé le cadre. L’IA abaisse le coût d’exploration des systèmes COBOL. La valeur se déplace vers la maîtrise systémique. Les formations préparent à ce qui s’automatise, pas à ce qui reste humain.

C’est bien. Mais un cadre sans gestes concrets, c’est une belle carte sans itinéraire.

Cet article est différent. Pas de thèse à défendre, pas de nuance à explorer. Des actions. Ce qu’un développeur COBOL junior et ce qu’un expert confirmé peuvent faire, maintenant, concrètement, pour construire la compétence qui comptera dans les cinq prochaines années.

Les deux profils ont des points de départ différents. Ils ont aussi, et c’est ce qui est intéressant, des angles morts symétriques.

---

Si vous débutez : construire large dès le départ

Le développeur COBOL junior a un avantage considérable que la plupart ne voient pas : il entre sur le terrain au moment exact où les règles changent. Il n’a pas d’habitudes à défaire. Il peut construire d’emblée le bon profil, celui qui sera précieux dans dix ans, pas celui qui l’était il y a dix ans.

Ne vous limitez pas à apprendre le langage, apprenez le système dans lequel il vit.

Dès les premières missions, posez des questions qui vont au-delà du code. Pourquoi ce traitement tourne-t-il la nuit et pas en journée ? Qui consomme le fichier produit par ce batch ? Que se passe-t-il si ce programme échoue à 3h du matin? Qui est appelé, quelle est la procédure, quel est l’impact métier ? Ces questions semblent simples. La plupart des juniors ne les posent pas parce qu’elles ne sont pas dans le ticket. Posez-les quand même.

Documentez ce que vous apprenez sur le système, pas seulement sur le code.

Il y a une différence entre documenter ce que fait un programme et documenter pourquoi il le fait ainsi. La première information est dans le code. La deuxième est dans les têtes, et elle disparaît quand les gens partent. Chaque fois que vous comprenez quelque chose sur l’histoire d’une règle, d’une contrainte, d’un choix technique, notez-le. Pas nécessairement pour le partager, pour vous d’abord. Cette documentation devient, avec le temps, une mémoire du système que personne d’autre ne possède.

Apprenez à parler à des gens qui ne savent pas ce qu’est un copybook.

L’une des compétences les plus rares et les plus précieuses dans l’écosystème COBOL, c’est la capacité à traduire entre le monde technique et le monde métier. Savoir expliquer à un directeur des opérations pourquoi une modification qui semble mineure présente un risque de production non négligeable. Savoir comprendre ce qu’un responsable métier appelle une “règle de calcul” et identifier où elle est encodée dans le système. Cette compétence de traduction ne s’acquiert que par la pratique, commencez tôt.

Familiarisez-vous avec DORA, le RGPD, les contraintes réglementaires de votre secteur.

Ce n’est pas du hors-sujet. La directive DORA, entrée en application en janvier 2025, impose des exigences de résilience opérationnelle aux institutions financières, y compris sur leurs systèmes legacy. Les contraintes RGPD sur des données conçues avant l’existence de ce concept créent des problèmes d’architecture que ni le code ni sa documentation ne résolvent seuls. Un développeur COBOL junior qui comprend ces enjeux est immédiatement différencié de celui qui ne voit que le code.

Ne choisissez pas vos missions uniquement pour la technique.

Une mission sur un système moins complexe techniquement mais qui vous expose à des projets de modernisation, à des décisions d’architecture, à des comités de pilotage vaut souvent plus pour votre trajectoire qu’une mission sur un système complexe où vous n’êtes qu’exécutant. Quand vous avez le choix, choisissez l’exposition plutôt que la complexité technique.

---

Si vous êtes confirmé : défaire ce qui vous a protégé jusqu’ici

Le développeur COBOL confirmé a construit sa valeur sur des années d’expérience réelle. C’est solide. Mais certaines habitudes qui ont bien fonctionné pendant longtemps deviennent des freins dans le nouveau contexte.

Rendez visible ce que vous savez.

L’une des stratégies implicites dans le monde legacy, souvent inconsciente, consiste à se rendre indispensable par la détention d’informations. Ne pas documenter, ne pas former, ne pas transmettre. Dans un monde où l’IA commence à cartographier ce qui était opaque, cette stratégie devient contre-productive. Celui qui ne partage pas son savoir est perçu comme un risque de dépendance, pas comme une ressource précieuse. Celui qui le partage et le structure devient l’architecte de la connaissance du système, une position autrement plus solide.

Repositionnez-vous explicitement du côté des décisions.

Si vous êtes aujourd’hui principalement dans l’exécution, les corrections, les évolutions, la maintenance, c’est le moment de vous déplacer activement vers les projets qui impliquent des arbitrages. Rejoignez les comités de pilotage même comme observateur. Proposez des analyses de risque sur les projets de modernisation. Prenez position sur des décisions d’architecture. L’IA peut analyser, vous pouvez recommander, arbitrer, assumer. C’est là que se construit la différenciation.

Développez une vision transverse, pas seulement sur votre périmètre.

Beaucoup d’experts COBOL confirmés ont une connaissance très profonde d’un ou deux systèmes, et peu de visibilité sur l’écosystème dans lequel ces systèmes s’inscrivent. Or les projets de modernisation les plus complexes et les plus valorisés, sont précisément ceux qui nécessitent de comprendre les dépendances inter-applicatives, les impacts d’une transformation sur plusieurs systèmes, les risques de bout en bout. Investissez du temps pour comprendre les systèmes adjacents au vôtre, même superficiellement.

Construisez votre légitimité à l’extérieur de votre entreprise.

La valeur d’un expert COBOL confirmé était historiquement très liée à sa connaissance d’un système spécifique dans une organisation spécifique. C’est une valeur réelle, mais fragile car elle disparaît avec la mission. Construire une présence externe, un blog, une participation à des communautés comme La Communauté du COBOL, des prises de parole sur des sujets de fond, transforme une expertise contextualisée en une expertise reconnue. Ce n’est pas une question de visibilité pour la visibilité. C’est une question de résilience professionnelle.

Investissez dans ce que l’IA ne peut pas faire, délibérément.

Les trois dimensions identifiées dans l’article précédent, la mémoire implicite, la décision sous incertitude, la lecture organisationnelle, ne se développent pas par accident. Elles se cultivent par des gestes intentionnels : interviewer systématiquement les experts qui partent avant qu’ils partent, documenter les décisions prises et leurs justifications au-delà du ticket technique, passer du temps avec les équipes métier en dehors des projets actifs. Ce sont des investissements qui semblent improductifs à court terme. Et ce sont exactement les compétences qui seront précieuses à moyen terme.

---

Ce que les deux profils ont en commun

Junior ou confirmé, il y a un point commun à tous ceux qui construiront une position solide dans les cinq prochaines années : ils auront choisi de comprendre le système, pas seulement le code.

Ce déplacement est un choix actif. Il ne se produit pas naturellement dans un métier où la pression quotidienne est technique, où les tickets demandent des corrections de code, où la performance est mesurée en délai de résolution d’anomalies. Il faut décider de regarder plus large que ce qu’on vous demande de regarder.

L’IA va continuer de progresser sur la partie lisible du travail. Elle va rendre certains profils transparents, ceux dont la valeur reposait sur la rétention de connaissance plutôt que sur la profondeur du jugement.

Elle va aussi, mécaniquement, rendre plus précieux ceux qui habitent le territoire qu’elle ne peut pas couvrir.

Ce territoire existe. Il est vaste. Il attend ceux qui choisissent de l’explorer.

---

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

Cette série explore 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.
→ Article 3 : Les 3 choses que l’IA ne remplacera jamais dans le COBOL
→ Article 4 : Ce qu’une formation COBOL n’enseigne pas et que le terrain exige.

Sharif HAMED , 18 mars 2026

Les formations COBOL ont un problème. Pas celui qu’on croit.

On parle beaucoup de la pénurie de profils, trop peu de jeunes qui apprennent le langage, trop d’experts qui partent à la retraite sans transmission. C’est réel. Mais ce n’est pas le problème le plus urgent.

Le problème le plus urgent, c’est que les formations disponibles préparent bien à lire du COBOL. Elles préparent beaucoup moins bien à ce que le terrain exige réellement aujourd’hui.

Et ce décalage, dans le contexte de ce que l’IA est en train de rendre automatisable, devient structurellement dangereux pour ceux qui suivent ces parcours sans le savoir.

---

Une première semaine en production

Soit un développeur qui vient de terminer une formation sérieuse. Il connaît les divisions, les structures de données, le traitement de fichiers, les sous-programmes. Il a travaillé sur des exercices progressifs, résolu des cas pratiques, peut-être même intégré des notions de JCL et de CICS. Sa formation était bonne. Rigoureuse. Il est prêt.

Première semaine en production. On lui confie une évolution sur un module de calcul de prestations. Il lit le code, le comprend, identifie la modification à apporter. La modification est propre, logique, bien testée en recette.

Il la soumet à validation. Son référent technique lui pose une question simple : “Tu as vérifié l’impact sur les traitements de fin de mois ?”

Il n’y a pas pensé. Pas parce qu’il est incompétent, parce que personne ne lui a appris à poser cette question. Sa formation lui a appris à comprendre ce que fait un programme. Elle ne lui a pas appris à comprendre dans quoi ce programme vit.

Cette scène se répète partout où des développeurs COBOL formés récemment arrivent sur des systèmes critiques. Le problème n’est pas leur niveau technique. C’est la carte qu’on leur a donnée : précise sur le code, muette sur le reste.

---

Ce que les formations couvrent et où elles s’arrêtent

Les cursus disponibles aujourd’hui, comme celui d’IBM, Open Mainframe Project, formations universitaires ou en ligne, couvrent sérieusement leur périmètre. Syntaxe, structures de données, traitement de fichiers, interactions avec DB2, bases du JCL. Les meilleurs intègrent des pratiques modernes : Git, VSCode, CI/CD appliqués au COBOL.

C’est solide. C’est nécessaire.

Et c’est précisément là que le problème commence.

Parce que les formations enseignent ce qui est enseignable dans une salle de cours ou sur une plateforme en ligne : ce qui est mesurable, vérifiable, évaluable. La syntaxe a une bonne réponse. Un exercice de traitement de fichier a une solution correcte. On peut noter ça. On peut le certifier.

Ce qu’on ne peut pas certifier : la capacité à comprendre pourquoi ce traitement de fin de mois tourne à cette heure précise, avec cette contrainte de volume, pour honorer un contrat X signé il y a vingt ans avec un partenaire dont les équipes techniques ont elles-mêmes changé quatre fois depuis. Ça, ça ne s’évalue pas dans un QCM.

---

Le fossé que l’IA vient d’élargir

Il y a quelques semaines, j’explorais dans cette série la limite structurelle des outils d’IA face aux systèmes critiques. L’IA peut cartographier les dépendances, documenter les flux, identifier les modules risqués. Elle ne peut pas savoir ce que personne n’a jamais écrit.

Ce que je n’avais pas dit alors : les formations COBOL ont exactement le même angle mort.

Les études disponibles sur les projets de modernisation legacy sont convergentes, environ 70% des projets de réécriture complète échouent, souvent en dépassant largement les budgets initiaux (source: Opentext) . La cause principale n’est presque jamais la syntaxe. Elle est dans ce que la documentation ne dit pas : les règles métier implicites, les dépendances non tracées, les contraintes opérationnelles jamais formalisées.

Autrement dit : ce qui fait échouer les projets de modernisation, c’est exactement ce que les formations n’enseignent pas.

Et maintenant que l’IA automatise la partie lisible du travail, comme la lecture du code, la cartographie des dépendances, la génération de documentation, le fossé entre ce que les formations couvrent et ce que le terrain exige devient structurellement plus large, pas plus étroit.

Un développeur qui sort d’une formation COBOL solide aujourd’hui maîtrise ce que les outils vont progressivement prendre en charge. Ce qu’aucun outil ne prend en charge comme la lecture du système réel, le dialogue avec le métier, la décision sous pression, il ne l’a pas appris. Pas parce que sa formation était mauvaise. Parce que ce n’était pas son objet.

---

Ce que le terrain exige et que les cursus ignorent

Trois compétences précises ne figurent dans aucun programme de formation COBOL, quel que soit son niveau.

Lire le système, pas seulement le programme. Il y a une différence fondamentale entre comprendre ce que fait un programme et comprendre ce que ce programme représente dans l’organisation qui en dépend. Pourquoi a-t-il été construit ainsi ? Qui en dépend ? Qu’est-ce qui se passe si il échoue à 3h du matin un dernier jour du mois ? Ces questions n’ont pas de réponse dans le code. Elles ont une réponse dans l’histoire du système et cette histoire s’acquiert sur le terrain, pas sur une plateforme d’apprentissage.

Naviguer dans l’incertitude plutôt que la résoudre. Un exercice pédagogique a une bonne réponse. Un système en production a des zones d’ombre permanentes. La compétence qui manque n’est pas de trouver la certitude, c’est de prendre de bonnes décisions en l’absence de certitude. Décider d’un déploiement quand les tests en recette sont bons mais que le volume réel n’a jamais été reproduit. Savoir quand dire “je ne sais pas” et quand dire “on y va quand même”. Cette compétence-là ne s’enseigne pas. Elle se développe par exposition répétée à des situations où l’erreur a des conséquences réelles.

Traduire entre le code et le métier. L’un des problèmes récurrents dans les projets de modernisation, documenté par des praticiens du secteur, c’est que les équipes travaillent sur des zones de code potentiellement jamais utilisées en production. Pourquoi? Parce que personne ne sait avec certitude quelles fonctions sont encore actives. Naviguer dans cette incertitude suppose de dialoguer avec des équipes métier qui ne parlent pas le même langage technique, de reconstituer ce que le code est supposé faire versus ce qu’il fait réellement, d’être à l’aise dans un espace où la vérité n’est ni dans le code ni dans la documentation mais quelque part entre les deux.

---

Ce que ça implique pour ceux qui sont concernés

Ce constat touche trois types de personnes différemment.

Pour ceux qui débutent, le message est simple : la formation est un point de départ, pas une destination. Ce que vous avez appris est nécessaire. Ce n’est pas suffisant. Dès vos premières missions, cherchez délibérément à comprendre au-delà du ticket qu’on vous donne. Posez des questions sur le système, pas seulement sur le code. Demandez à accompagner des projets de modernisation même sans en être le référent. Documentez ce que vous apprenez sur l’histoire du système, pas seulement sur sa structure.

Pour ceux qui sont déjà sur le terrain, la question est différente. Les compétences manquantes ne s’acquièrent pas avec un cours supplémentaire. Elles se construisent par des gestes intentionnels : interviewer les experts qui partent avant qu’ils partent, passer du temps avec les équipes métier en dehors des projets actifs, porter des décisions difficiles plutôt que les dévier vers le haut.

Pour les organisations qui forment et recrutent, une seule question mérite d’être posée explicitement : est-ce que ce profil sait lire du code, ou est-ce qu’il sait lire un système ? Aujourd’hui plus qu’avant, la nuance n’est pas anodine.

---

L’illusion de préparation

Il serait facile de lire cet article comme un constat pessimiste sur les formations. Ce n’est pas son propos.

Le vrai sujet est plus subtil : les meilleures formations COBOL disponibles aujourd’hui créent une illusion de préparation. Elles forment bien à ce qui est enseignable. Elles ne disent pas clairement ce qu’elles ne couvrent pas. Disons que le focus sera plus sur l’aspect syntaxe du langage.

Ce que l’IA est en train de faire, en automatisant la partie lisible du travail, c’est rendre cette illusion visible. Quand les outils prennent en charge la cartographie, la documentation et l’exploration, ce qui reste, comme la mémoire implicite, la décision sous incertitude, la lecture organisationnelle, devient soudainement le cœur du sujet.

Et c’est précisément ce que les formations n’enseignent pas.

Ceux qui l’ont compris avant les autres ont une longueur d’avance. Pas parce qu’ils ont suivi une meilleure formation. Parce qu’ils ont arrêté de confondre la carte avec le territoire.

---

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

Cette série explore 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.
→ Article 3 : Les 3 choses que l’IA ne remplacera jamais dans le COBOL

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.

Sharif HAMED , 05 mars 2026

Fin février 2026, l’annonce d’Anthropic autour de Claude Code provoquait une réaction immédiate sur les marchés. IBM perdait 13% en une séance. Le message implicite semblait être : si l’IA peut lire du COBOL, les experts qui en vivent sont menacés.

J’ai analysé ce que cette réaction révèle, et ce qu’elle cache, dans un article précédent. Je vous invite à le lire si vous ne l’avez pas encore fait : Claude Code, COBOL, IBM : ce que la chute du marché ne dit pas.

Ce que je veux traiter ici est différent. Non pas ce que ça signifie pour IBM ou pour le marché du legacy, mais ce que ça signifie pour vous. Pour ceux qui font ce métier, qui vivent de cette expertise, qui se demandent ce que vaut encore leur savoir-faire dans ce nouveau contexte.

La réponse est inconfortable. Elle est aussi, selon moi, porteuse d’une vraie opportunité, pour ceux qui veulent bien la voir.

Il existe deux types d’experts COBOL. L’IA ne les menace pas également.

Voici une distinction que personne ne formule clairement, mais que tout le monde ressent confusément dans les équipes legacy.

Le premier type maîtrise le langage. Il navigue dans un programme de dix mille lignes, retrace des appels de sous-programme, démêle des copybooks imbriqués, décode une logique accumulée sur vingt ans. C’est une compétence réelle, longue à acquérir, qui demande de la rigueur et de l’expérience.

C’est aussi, soyons directs, une compétence de lecture. Et la lecture, c’est précisément ce que les outils comme Claude Code, IBM watsonx Code Assistant ou les offres AWS sur le legacy sont en train d’automatiser.

Le second type comprend ce que fait le système. Pas seulement ce que fait le code. Ce que signifie une modification sur un traitement de fin de mois. Ce qui se passe si on touche à cette variable de contrôle partagée entre sept applications. Ce qu’on risque en basculant ce batch en production un mercredi soir plutôt qu’un dimanche matin. Pourquoi ce paramètre est à cette valeur précise alors que rien dans le code ne l’explique, mais que tout le monde a peur d’y toucher depuis 2014.

Cette connaissance-là ne se lit pas dans le code. Elle se construit par l’expérience. Par les incidents. Par les projets qui ont failli mal tourner. Par des années passées à la frontière entre le technique et le métier, entre le développement et la production.

L’IA automatise progressivement la première catégorie. Elle ne touche pas à la seconde.

Le problème, et c’est là que l’inconfort commence, c’est que beaucoup de ceux qui se réclamaient de “l’expertise COBOL” n’appartenaient qu’à la première. Leur valeur sur le marché reposait sur la rareté de ce qui est en train de devenir accessible. Pas sur la profondeur de ce qu’ils comprenaient réellement.

Être indispensable par l’opacité n’est pas la même chose qu’être indispensable par la compétence

Il y a une posture que les gens du legacy connaissent bien, même s’ils n’en parlent pas volontiers : se rendre difficile à remplacer en rendant les systèmes difficiles à comprendre pour les autres.

Documentation volontairement incomplète. Connaissances gardées en silo. Refus de former des successeurs. Systèmes entretenus dans un état d’opacité qui garantit la dépendance du client.

C’est une stratégie. Elle a fonctionné pendant des décennies dans l’écosystème legacy, où la pénurie de compétences rendait les clients captifs.

L’IA ne remplace pas ces profils. Elle les rend transparents.

Quand un outil peut cartographier en quelques heures ce qu’on gardait jalousement opaque depuis des années, la valeur perçue s’effondre. Non pas parce que la compétence a disparu, mais parce que la stratégie de rétention qui la masquait est devenue inopérante.

C’est différent d’être remplacé. Mais pour celui qui en vit, le résultat est le même.

Ce que le contexte actuel exige concrètement

L’environnement dans lequel vivent ces systèmes COBOL s’est radicalement complexifié ces dernières années. Et c’est ce changement-là, plus encore que l’IA, qui redéfinit ce que “être expert” veut dire.

Prenons un exemple réaliste, le type de situation que rencontrent régulièrement les équipes impliquées dans des projets de modernisation.

Une direction technique décide de faire évoluer un traitement de règlement critique. L’IA produit une cartographie complète en quelques heures. On sait ce qui appelle quoi, quels modules sont partagés, où se situent les risques de rupture. Excellent point de départ.

Puis quelqu’un pose la vraie question : “On peut migrer ça vers le cloud ?”

Et la réponse honnête ne se trouve dans aucune documentation générée automatiquement. Elle ressemble à ça : ce traitement tourne en batch à 3h du matin parce que les volumes l’imposent. Si on le passe en temps réel, les pics de charge dépassent ce que l’infrastructure cloud peut absorber à ce stade. L’équipe SRE n’est pas dimensionnée pour gérer ça en production. La directive DORA, entrée en application en janvier 2025 pour les institutions financières, impose des exigences de résilience opérationnelle que ce scénario ne satisfait pas encore. Et le contrat client exige une disponibilité de 99,95%.

Donc : pas maintenant, pas comme ça, pas sans un plan de renforcement de l’équipe et une évolution de l’architecture de déploiement.

Cette réponse engage une responsabilité. Elle suppose une compréhension qui dépasse le code, elle intègre l’exploitation, le contexte réglementaire, les contraintes contractuelles et une vision de ce que l’organisation est réellement capable de faire.

L’IA explore. L’expert arbitre et assume.

Ce que ça change pour une carrière dans le legacy

Ce déplacement n’est pas théorique. Il change concrètement la manière dont les profils sont évalués et rémunérés.

Les équipes qui consolident leur position sont celles qui ont fait le mouvement avant qu’on le leur demande. Elles ont développé une culture production solide. Elles comprennent les enjeux métier de leurs clients, pas seulement la technique. Elles savent dialoguer avec des équipes cloud-native qui n’ont jamais ouvert un terminal COBOL. Elles peuvent porter une décision d’architecture devant un comité de direction, en défendant les arbitrages avec des arguments qui vont au-delà du code.

En résumé : elles sont passées de lire le système à comprendre ce qu’on risque en le faisant évoluer.

Ce profil-là est plus rare aujourd’hui qu’il y a cinq ans. Pas moins.

Les profils qui souffriront sont ceux dont la valeur reposait sur la rétention de connaissance plutôt que sur la qualité du jugement. La stratégie de l’opacité protectrice est structurellement fragilisée. Ce n’est pas une menace abstraite, c’est une évolution déjà en cours dans les appels d’offres et les renouvellements de contrats.

Ce que je retiens

Dans quelques années, lire du COBOL sera une compétence ordinaire. Les outils continueront de progresser. La barrière d’entrée continuera de s’abaisser.

Ce qui ne deviendra pas ordinaire : savoir quoi faire de ce qu’on a lu.

La compréhension d’un système critique avec ses fragilités, ses contraintes opérationnelles, ses dépendances non documentées, sa logique métier accumulée sur des décennies, ne s’automatise pas. Elle se construit. Par l’expérience, les incidents, les projets qui ont failli mal tourner.

Pour ceux qui ont investi dans cette profondeur-là, l’IA n’est pas une menace. C’est un accélérateur : elle supprime le travail d’exploration répétitif et libère du temps pour ce qui demande réellement du jugement.

Pour les autres, le moment est venu de faire un choix, avant que ce choix soit fait à leur place.

Dans les systèmes critiques, la question n’a jamais été de comprendre le code.
Elle a toujours été de comprendre ce qu’on risque.
Et cette compétence-là ne se délègue pas à un modèle.

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

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