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.