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