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