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.
Le réseau et les systèmes bancaires
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.
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.
À retenir
Période : vendredi 3 avril au lundi 6 avril 2026 inclus
Cause : fermeture programmée de TARGET2, le système interbancaire européen
Impact : les virements SEPA entre banques différentes sont suspendus
Ce qui fonctionne : virements internes (même banque) et virements instantanés
Conseil : anticiper tout paiement important avant le jeudi 2 avril, 16h30
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.
La prochaine fois qu’un article titrera “les virements sont bloqués”, lisez entre les lignes.
Ce que le grand public perçoit comme une panne est, dans la plupart des cas, le signe d’un système qui fonctionne exactement comme prévu. Avec ses règles, ses contraintes, ses fenêtres et ses dépendances.
La finance mondiale ne s’arrête pas parce qu’elle dysfonctionne. Elle s’arrête parce qu’elle est bien conçue.
É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.
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.
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.
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.
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.
Les deux types d’expertise COBOL
Ê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.
Timeline évolution de la valeur
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.
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.
Chute de l’action IBM suite à l’anonce d’Antropic de Claude Code sur le COBOL
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.
Ce que l’IA fait et ce qu’il ne fait pas
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.
Le déplacement de l’effort
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.
COBOL, 62 ans, testé positif au Coronavirus. Quelles sont les conséquences?
Cela fait déjà un an que nous traversons une crise planétaire. Elle aura impacté énormément de secteur dont celui du domaine informatique. Le phénomène marquant révélé dans ce milieu, c’est le manque de développeur dans le monde du Mainframe.
La pénurie de programmeurs Cobol a été mis en lumière dès lors que les premières évolutions de l’environnement des anciens systèmes ont été nécessaire dû à la Covid-19. L’un des pays qui en a le plus souffert n’est qu’autre que les États-Unis. Les obstacles rencontrés reflètent l’état d’esprit et la manière dont est perçu le Cobol en 2020/2021.
Courbe montrant le pic du chômage en 2020 – “Trumponomics en 7 graphiques” — REUTERS GRAPHICS
Effectivement, le manque de programmeur Cobol a été très marqué et même médiatisé. L’effet immédiat de la crise est la perte d’emploi qui va causer une augmentation de manière considérable le taux de chômage dans tout le pays (et dans le monde entier au passage). Le souci est que le système de gestion du chômage est géré par …. le Cobol! De tel changement nécessitent des mises à jours du système informatique.
C’est à ce moment précis que commence une série de mauvaises surprises. Premier constat, une grosse vague de développeur avait déjà pris leur retraite. Deuxième constat, il n’y a pas eu de remplacement prévu dû à cette vague. Troisième constat, il y a très peu de programmeurs Cobol disponible et pratiquement pas de jeune. Ce phénomène est dû au fait qu’un grand nombre d’Université n’enseigne plus ce langage estimant qu’il est devenu obsolète.
Le Gouverneur du New Jersey, Phil Murphy, à la recherche de programmeur COBOL
Cette mauvaise série a poussé les États concernés à médiatiser cette difficulté rencontrée afin d’avoir des renforts le plus rapidement possible. La solution express du moment est de rappeler les personnes volontaires et retraitées pour débloquer la situation. C’est une belle option mais seulement temporaire!
Cette crise sanitaire a la malheureuse réputation d’impacter les plus âgés (plus de 60 ans). On estime que la moyenne d’âge des experts Cobol se situe entre 55 et 60 ans. Ce qui fait que le domaine du Mainframe est directement touché par cette pandémie. Certains des développeurs les plus âgés ont contracté le virus, ce qui fait réduire encore plus les effectifs. De ce fait, la Covid-19 aura pointé du doigt le manque d’expert en Cobol et fait même affaiblir les équipes déjà en place.
La seule vraie solution est de former le plus grand nombre de développeur sur le langage afin d’assurer une relève et de transmettre le savoir et les compétences qui permettra de gérer les futurs projets. Que ce soit pour mettre à jour les systèmes actuels ou faire une potentielle migration vers un autre langage plus moderne, le nombre d’évolution ne désemplira pas.
Pourrions-nous éradiquer tous les symptômes dans le monde du Mainframe? Arriverons-nous à rectifier le tir et à apprendre de nos erreurs? Sommes-nous capable d’attirer plus de jeunes à ce langage longtemps considéré comme vieux et démodé? Une chose est sure, c’est que le Cobol reste un élément incontournable dans nos systèmes et aura un bel avenir devant lui. La Covid-19 a peut-être bien gagné cette petite bataille mais certainement pas la guerre. Espérons que les dispositifs mis en place porteront ces fruits et permettront de ne plus reproduire la même situation que nous avons traversé.
Sharif HAMED
J’espère que cet article vous a aidé à mieux comprendre comment est perçu le COBOL et les conséquences de cette perception. N’hésitez pas à partager si vous aimez et de donner votre avis sur le sujet. Cela m’encouragera à écrire d’autres articles concernant le monde du Mainframe.
Qui parle encore le Cobol, l’un des plus vieux langages informatiques ? Majoritairement cinquantenaires, les derniers développeurs partent petit à petit à la retraite, sans qu’ils soient remplacés. Problème : le Cobol est encore utilisé dans des infrastructures critiques, comme les banques.
« Nous sommes en l’an 3000, et l’humanité a enfin trouvé un moyen de ressusciter les personnes qui ont été cryogénisées », commence la blague. « La première femme à être ramenée est une développeuse, et elle n’en revient pas ! Elle pose beaucoup de questions, mais le médecin en chef arrive en courant et la coupe, ‘C’est urgent ! Une question de vie ou de mort ! Est ce que vous savez coder en Cobol ?’ ». Le Cobol, c’est de l’histoire ancienne, résument ceux qui savent encore l’écrire, un des tout premiers langages informatiques, un ancêtre vieux de plus de 60 ans, que peu de gens aujourd’hui maîtrisent.
Pourtant, le Cobol est partout : plus de 220 milliards de lignes de code existent encore aujourd’hui, auxquelles sont ajoutées plusieurs millions d’autres tous les ans. Aux États-Unis, où le Cobol structure la majorité des sites gouvernementaux, le manque d’experts du langage a entraîné de nombreux problèmes. À cause de la pandémie de Covid-19, un nombre record d’Américains se sont connectés sur l’équivalent de Pôle Emploi, faisant crasher le système. Seulement, personne n’a su le remettre en place dans l’immédiat, créant la panique au sein de certaines administrations et retardant de plusieurs semaines l’arrivée des aides financières.
En France, les demandes d’aides financières se sont faites par mail, en fournissant à l’organisme correspondant un formulaire comportant diverses informations. Il n’y a de ce fait pas eu de problèmes de saturation des sites du gouvernement, bien que le site de la sécurité sociale soit programmé en Cobol. La situation pourrait cependant vite devenir problématique : l’âge moyen des développeurs se situe autour de 55 ans.
Un langage universel
Le Cobol, abréviation de « common business-oriented language » et traduisible par « langage courant pour les affaires », est une création de l’armée américaine. En 1959, elle souhaite développer un langage commun aux premiers ordinateurs qui permettrait lui-même d’écrire de nouveaux programmes, ce qui était impossible jusque-là avec les langages existants. Le groupe de travail mis en place souhaite cependant que son utilisation ne soit pas réservée à l’armée et veut doter le Cobol de fonctions lui permettant d’être largement utilisé, et surtout simple à comprendre. La capitaine de l’armée Grace Hopper, qui sera surnommée plus tard la « grand-mère du Cobol », prévoit d’utiliser des commandes basées sur l’anglais plutôt que sur des expressions algébriques, le rendant facile à lire.
« Par exemple, si on veut retrouver un jeu de données en particulier, on utilise SEARCH, et si on veut l’afficher on utiliser DISPLAY, c’est plutôt intuitif », explique Véronique Gianfermi, une développeuse Cobol indépendante qui travaille dans les systèmes bancaires. « C’est un langage simple, efficace et robuste ». Ce sont ces qualités qui feront sa popularité : entre 1960 et 1980, le Cobol est le langage de référence, utilisé par les banques, les assurances, les compagnies aériennes, les impôts… Si sa popularité diminue au fil du temps avec l’arrivée de langages plus modernes, le Cobol reste toujours là, à faire tourner les back offices.
Vous utilisez du Cobol tous les jours sans même le savoir // Source : Unsplash / Jan Kolar
Aujourd’hui encore, plus de 70 % des distributeurs de billets et entre 60 et 80 % des activités des entreprises reposent sur des applications Cobol. « Une personne lambda a recours au moins 8 fois par jour à un système géré en Cobol, sans en avoir conscience », indique Philippe Fraysse, un spécialiste du Cobol qui édite un logiciel de développement pour le langage. C’est tout un écosystème, d’une complexité édifiante, qui a été construit depuis plus de 60 ans et représente aujourd’hui l’un des socles de l’informatique.
La pénurie ?
Alors pourquoi y a-t-il une pénurie de développeurs aux États-Unis ? Parce que le Cobol est dépassé. « Ça fait 30 ans qu’on dit que le Cobol est mort. Il est toujours là, mais ça fait 30 ans que personne ne veut en faire », résume Philippe à Numerama. C’est partout le même son de cloche : « les jeunes ne veulent pas faire ça », faisant que « les cobolistes », comme ils se surnomment, sont en grande majorité cinquantenaires, approchant de la retraite. Et personne ne se bouscule pour prendre leur place.
« Il n’y a cependant pas encore de pénurie en France », rassure Alain Dubois. Âgé de 71 ans, ce développeur admet cependant que son profil est recherché, et qu’il n’a jamais eu de mal à trouver du travail, malgré son âge. Véronique confirme : si elle n’a « jamais été accueillie comme le messie » en arrivant dans une entreprise, les missions Cobol sont légion. Ils ont tous les deux été formés au Cobol lors de son âge d’or, quand la « demande explosait et qu’on formait des gens en masse pour y répondre ».
POUR SE FORMER, IL FAUT DANS LA PLUPART DU TEMPS « APPRENDRE SUR LE TAS ».
Beaucoup de jeunes ayant suivi des études scientifiques, comme des biologistes ou des chimistes n’arrivant pas à trouver du travail à la sortie se tournent vers ces formations, dispensées de manière expéditive en seulement quelques mois. Encore un avantage du Cobol : grâce à sa syntaxe intuitive, pas besoin d’avoir au préalable de « bagage en informatique », détaille Véronique.
Aujourd’hui, les écoles ne dispensent plus de formation en Cobol. Pour se former, il faut dans la plupart du temps « apprendre sur le tas ». « Lors de mon apprentissage dans une filiale du Crédit Agricole, on m’a mis sur une mission d’archivage de relevé bancaire », raconte Momar Ndiaye. « Tous les systèmes déjà mis en place étaient en Cobol, du coup j’ai été obligé de m’y mettre ». Aujourd’hui âgé de 29 ans, il travaille comme consultant chez LCL et estime que les profils juniors sont une minorité, représentant seulement « 10 % des personnes connaissant le langage ».
Comme un minitel
« Personne ne veut travailler sur des missions Cobol en sortie d’école », déclare-t-il, « ils veulent des postes plus intéressants, sur du développement web ou des applications ». Il faut dire que le Cobol souffre d’une mauvaise image. « Ceux qui ne travaillent pas directement avec le langage sont persuadés que c’est un truc de vieux, que ce n’est pas une compétence d’avenir ». L’interface Cobol leur donne raison. Police de caractères austère, vert fluo sur fond noir, pas de souris… « L’aspect minitel refroidit les potentiels étudiants », reconnaît Serge Gueguen, un formateur Cobol depuis 20 ans.
De plus, « les missions Cobol ne sont pas mises en avant sur les sites de recrutement », reprend Momar, « parce que ce n’est pas un boulot tendance ». Les missions proposées peuvent sembler rébarbatives. Beaucoup de mises à jour, peu de développement, ou alors sur des projets de back-office bancaires… On ne peut pas créer de « trucs cool » en Cobol. « Mon fils commence déjà à me dire que Java est dépassé, qu’il veut travailler sur des langages développés par Google, alors le Cobol… », complète Véronique.
Momar a cependant fait le choix de continuer. « Je me suis vite dit que c’était intéressant de parler ce langage. Les banques ont beau développer de nouvelles applications en Java, la base reste en Cobol. Tout le monde a besoin de ce langage, les gens ne se rendent pas compte de l’étendue qu’il a dans la vie de tous les jours ». S’il a décidé de poursuivre, c’est également par calcul. « Pour l’instant, les missions Cobol sont mal payées, mais les développeurs vieillissent. Dans 10 ans, il n’y aura plus personne, et à ce moment-là, les banques seront prêtes à payer une fortune pour mes compétences ».
Des formations existent toujours, mais ne séduisent pas
Si les écoles ne forment plus au Cobol, il existe encore des formations disponibles pour les nouveaux cobolistes. Ils ne sont souvent pas là par choix. « On remarque que certaines entreprises recrutent des gens sans leur dire qu’ils vont faire du Cobol », annonce Serge. « On les affecte sur ces projets par surprise, forcément ils n’apprécient pas du tout ». Il travaille également avec beaucoup de particuliers en reconversion, « profils scientifiques à bac +5, qui décident de se mettre à l’informatique, mais qui n’ont aucune expérience préalable ». Comme beaucoup de leurs prédécesseurs, formés dans les années 80.
Mais ce n’est cette fois-ci pas parce que la demande explose, au contraire. « Nous avons moins de demandes depuis à peu près 5 ans. En 2019, nous avons formé 6 personnes. En 2018, personne ». Le peu de personnes formées est ensuite majoritairement embauché par des ESN (Entreprises de Service Numériques, anciennes SS2I), qui placent ensuite leurs cobolistes dans des banques afin d’assurer des mises à jour ponctuelles ou de nouveaux projets de développement. « On ne voit pas vraiment les nouveaux formés remplacer ceux qui partent à la retraite ».
Formés, mais pas experts
C’est justement là que le bât blesse : « les entreprises ont pris conscience du problème et forment leurs ingénieurs, mais ce sont des formations express, au rabais », explique Serge. La relative facilité d’apprentissage du Cobol cache un autre problème : la complexité de tout l’écosystème construit autour de ses applications. Chaque entreprise ayant son organisation propre, « un développeur très compétent met tout de même près de 4 ans à être optimal sur un autre système, qui aura d’autres règles de fonctionnement ».
De vieilles structures, construites sur des dizaines d’années par couches successives, des développeurs différents (« qui laissent parfois des passages codés de manière dégueulasse », nous confie l’un d’eux), et sans documentation. « La situation est pire lorsqu’il y a eu des rachats et des fusions. Les systèmes sont empilés de manière très complexe, avec beaucoup d’interactions entre eux », détaille François Chaix, qui développe des applications pour les institutions financières et côtoie le Cobol depuis plus d’une dizaine d’années . « Les systèmes informatiques, c’est le carbone 14 des banques ».
« QUAND TOUT LE MONDE TE DIT QU’UN LANGAGE EST MORT, ÇA NE MOTIVE PAS À RESTER »
Pour certains environnements très complexes, François reconnaît qu’il ne reste parfois « qu’un seul coboliste qui s’y connaît, mais pour d’autres il y en a 50 de disponibles ». « Le manque se situe seulement sur des parties très spéciales. Pour l’instant, je n’ai jamais vu quelqu’un qui ne savait pas vers qui se tourner », tempère-t-il. « Mais ça pourrait peut-être changer ».
Il est difficile de garder les gens sur des missions Cobol. Les profils juniors veulent autre chose, il y a beaucoup de turn over. Au total, les projets comptent en moyenne 8 ans de retard, selon François. « Quand tout le monde te dit qu’un langage est mort, ça ne motive pas à rester », résume Momar.
Le Cobol, un langage de la préhistoire de l’informatique ? // Source : Illustration de Lucie Benoit pour Numerama
Trop compliqué de migrer
Alors, pourquoi continuer en Cobol ? Migrer l’ensemble des données d’une banque vers un nouveau système informatique présente plusieurs problèmes d’envergure. Tout d’abord, le prix : « une opération comme ça coûterait plusieurs dizaines de millions d’euros, voire des centaines », estime François. Un changement de système nécessiterait en effet au préalable des années de travail, et représenterait un casse-tête. Serge est d’ailleurs catégorique, ces migrations sont extrêmement risquées. « Ce sont de vieilles lignes de codes, très peu documentées : il suffit qu’on oublie de remplacer une petite partie pour que tout soit perdu ».
En 2018, la banque anglaise TSB en a fait l’expérience. Après une erreur, près de 1,9 million de clients n’ont pas eu accès à leurs comptes pendant presque un mois, d’autres n’ont pas pu d’utiliser leurs cartes bancaires, tandis que certains ont eu accès pendant plusieurs jours aux comptes d’autres personnes. Une catastrophe, qui a coûté à TSB 330 millions de livres et plus de 80 000 clients.
« LA MÊME CHOSE VA ARRIVER À JAVA D’ICI 20 ANS »
Enfin, « pourquoi changer une méthode qui marche ? », demande Véronique. « Le Cobol est ultra robuste, quand tu as besoin de traiter des millions d’informations rapidement, c’est super solide et très rassurant ». Une machine de guerre, qui marche toujours 60 ans après sa conception. « La technologie peut sembler vieillotte, mais sur les nouvelles applications que nous développons, à chaque fois qu’il y a un problème, ça vient de la partie Java. Jamais du Cobol ».
Destiné à mourir, mais toujours vivant, le Cobol est un code à part entière chez les développeurs, à mi-chemin entre créature mythique et Renault 4L. « À un moment où à un autre, il n’y aura plus suffisamment de développeurs Cobol », confie Caroline Couturier, qui travaille à la direction informatique de LCL, « on s’y prépare ». « Il y a 5 ans, tout le monde disait que la pénurie arriverait maintenant. Nous y sommes, et tout va bien pour l’instant », déclare Serge, avant de lancer : « La date est impossible à prévoir, mais elle arrive ».
Peut-être pas aujourd’hui, ni demain, mais sûrement. « C’est normal, c’est le progrès. La même chose va arriver à Java d’ici 20 ans », prophétise-t-il.
Le déficit en compétences Cobol n'est ni aussi extrême ni aussi simple que l'on pourrait le penser. Pour maintenir leurs systèmes Cobol, les entreprises peuvent choisir entre la formation de ressources internes ou le recours à des consultants spécialisés. Ce qu'il faudrait savoir avant de franchir le pas.
Créé en 1950, Cobol a été spécialement conçu pour permettre à des non-spécialistes de programmer les ordinateurs qui commençaient à arriver dans le monde des échanges commerciaux. (Crédit : Microfocus)
Les besoins en compétences en Cobol se font périodiquement ressentir dès qu’une application installée depuis quelques décennies doit être modifiée. Des incidents qui défraient quelquefois la chronique comme c’est arrivé dans l’Etat du New Jersey lorsque l’administration n’a pas pu, au début de la pandémie, incorporer les dispositions du CARES Act apportant un complément financier aux personnes sans emploi. Le problème remonte à plus de 20 ans et les programmes Cobol sont toujours à l’oeuvre dans de nombreux systèmes d’information, à moitié compris par les entreprises qui continuent à s’appuyer sur eux après l’échec de coûteux projets engagés pour les remplacer. Et maintenant, de nombreux experts réfléchissent à de nouvelles façons d’aborder le problème et de développer des compétences pour travailler avec Cobol.
L’un des problèmes dans ce contexte, c’est que l’on suppose souvent l’existence de profils spécifiques comme si Cobol était quelque chose de bien différent du reste du monde de la programmation. Ce n’est pas le cas. Pour Mark Cresswell, PDG de LzLabs, c’est une fausse piste. Il rappelle que Cobol est juste une syntaxe pour exprimer des règles métiers. « La plupart des programmeurs sont polyglottes. Vous pouvez avoir une spécialisation ou être meilleur dans tel ou tel langage, mais vous ne vous direz pas que vous n’allez pas faire de C++ parce que vous êtes un programmeur Java. Comme tous les autres langages, Cobol a ses propres particularités ». Il faut garder en tête que Cobol signifie « Common business-oriented language », c’est un langage écrit pour les problématiques de gestion d’entreprise. Créé en 1950, il a été spécialement conçu pour permettre aux non-spécialistes de programmer les ordinateurs qui commençaient à arriver dans le monde des échanges commerciaux. « Il est censé être facile à lire et à comprendre », rappelle Emad Georgy, CTO de Georgy Technology Leadership. « Je pense qu’il y a cette énorme peur autour de lui parce qu’il fait fonctionner des systèmes assez critiques, mais en fait, en tant que programmeur, il est très facile à apprendre ».
Expertise sur IMS et CICS également requise
Cobol n’est pas construit autour d’une programmation orientée objet et manque de fonctionnalités d’héritage, de sorte que ceux qui se sont fait les dents sur les systèmes modernes auront en fait plus de facilités à le prendre en main que le contraire. Bien qu’il existe néanmoins des versions orientées objet de Cobol, elles ne sont pas utilisées dans les anciens systèmes qui utilisent Cobol en production tels qu’on peut les trouver le plus souvent. En réalité, quand on parle de « pénurie de compétences Cobol », c’est plutôt un raccourci pour désigner quelque chose de plus compliqué. On pourrait, par exemple, télécharger GnuCobol et commencer à jouer avec du code qui pourrait tourner ensuite sur une machine Linux familière, mais cela ne préparerait pas à l’expérience de travailler avec du code Cobol tel qu’il est utilisé en production dans son contexte d’origine.
« Apprendre Cobol est facile, mais ses applications requièrent une expertise rare avec les technologies plus anciennes telles que les systèmes de base de données IMS et CICS d’IBM », indique Michael Yurushkin, CTO et fondateur de BroutonLab. « Le principal défi n’est pas d’apprendre le langage, mais de disposer d’une expertise sur des technologies qui ont plusieurs décennies d’existence ». Mark Cresswell, de LzLabs, met en évidence le fait que les outils modernes utilisés ces dernières années par les développeurs ne s’appliquent tout simplement pas aux environnements mainframes. « Si je veux compiler et tester un programme, je n’appuie pas sur la petite flèche verte de la barre d’outils », fait-il remarquer. « J’exécute quelque chose qui s’appelle un travail par lots [batch job] qui fait une compilation et un lien. Lorsqu’il s’agit de configurer un environnement de test, je ne peux pas simplement lancer un container sur mon poste de travail pour tester mes modifications. Je dois parler aux administrateurs systèmes pour configurer des partitions avec des sous-système et des configurations. Tout cela allonge le cycle de développement et c’est tellement spécifique qu’il est très difficile de s’y retrouver pour quelqu’un qui est habitué à développer à la vitesse d’Internet sur des plateformes cloud ».
Démêler la logique du programme
Lorsque l’on a affaire à une application critique qui tourne depuis longtemps, démêler la logique du programme peut devenir le principal défi. « Tous ces systèmes ont été conçus au fil des décennies », souligne Ben Stevens, ingénieur en chef et architecte solution chez Art+Logic, qui a travaillé pendant des années dans des administrations gouvernementales qui s’appuyaient sur Cobol. « Si vous ne connaissez pas les tenants et les aboutissants, savoir programmer en Cobol ne servira pas à grand chose. Cela finit par devenir un projet de rétro-ingénierie sur lequel on agit en tant qu’archéologue. Même si vous connaissez le langage, c’est un peu comme si vous lisiez des textes anciens sans aucun contexte : d’accord, je peux traduire ce mot par tel mot, mais qu’est-ce-que cela signifie ? ».
Prenons le cas d’une entreprise qui utilise une base de code Cobol pour une application critique. Comment peut-elle s’assurer d’avoir accès aux compétences dont elle a besoin – tant en termes d’environnement de programmation et mainframe qu’en termes de logiques métier sous-jacente – pour maintenir son système opérationnel, au moins à court terme ? L’une des stratégies possibles consiste à travailler sur le développement de compétences en interne. Cela ne signifie pas de recruter de nouveaux programmeurs Cobol dès leur sortie de l’école (puisque cela n’existe pas). Cela ne signifie pas nécessairement non plus de retenir les anciens collaborateurs à temps complet alors qu’ils préféreraient prendre leur retraite. « Mon objectif pour mon équipe ne serait pas de leur apprendre Cobol, ce serait de leur apprendre mon système », expose Emad Georgy. « Le contexte est essentiel. Vous voulez qu’ils apprennent Cobol juste ce qu’il faut. Vous n’allez sans doute pas lancer de nouveaux projets en Cobol, il faudra donc investir au bon niveau de façon judicieuse ». L’une des façons de le faire est d’associer des développeurs internes intéressés aux ressources dont on dispose, en se concentrant sur les besoins métiers. Cela peut impliquer d’avoir des développeurs plus âgés qui ont travaillé sur l’application en question – peut-être toujours dans l’effectif ou peut-être rappelés en tant que sous-traitants – pour encadrer les plus jeunes.
Résoudre un problème spécifique en équipe
« J’aime avoir des cas d’usage ou des problèmes très spécifiques que nous essayons de résoudre avec l’apprentissage », explique M. Georgy. Par exemple en faisant travailler une équipe avec un collaborateur retraité qui vient quelques heures par semaine en leur disant : « Notre objectif d’ici la fin du mois, c’est de résoudre ce bug ». Bien sûr, les développeurs devront suivre une formation plus générale en Cobol et en programmation mainframe pour compléter ce qu’ils apprennent sur leurs propres systèmes. IBM a un intérêt évident à maintenir une masse critique de programmeurs Cobol sur le marché et propose un ensemble de ressources pédagogiques tels que des cours de programmation Cobol gratuits et des certifications de programmation mainframe. Ces temps de formation mobiliseront les équipes mais il est probable que l’investissement en vaut la peine. « Nos clients doivent également se rappeler que les applications critiques qui ont été optimisées sur les dernières décennies nécessitent elles aussi une maintenance », indique Barry Baker, vice-président logiciel sur l’activité IBM Z. S’imaginer que l’on peut le faire dans l’à peu près et sans investir dans des talents, c’est simplement une recette qui peut conduire au désastre, prévient-il.
Ne pas hésiter à demander de l’aide
Néanmoins, on peut se retrouver dans une situation où l’on ne dispose tout simplement pas des ressources internes pour surmonter son problème Cobol. Dans ce cas, on peut vouloir se tourner vers des consultants externes spécialisés dans les interventions sur les systèmes Cobol. C’est ce que fait une entreprise comme Chetu et les situations dans lesquelles elle est amenée à intervenir sont souvent assez désespérée. « Il y a eu de nombreux cas où le développeur principal de la plateforme legacy n’était plus dans l’entreprise », explique Pravin Vazirani, vice-président des opérations de Chetu. « Et la maintenance du système était faite par un développeur qui n’avait qu’une connaissance limitée du système et avait acquis juste assez d’expertise pour parvenir à faire fonctionner correctement les applications Cobol. On le voit généralement dans des endroits où l’on fait tourner des plateformes existantes avec peu ou pas de documentation appropriée ».
Pravin Vazirani pense que de nombreuses organisations, en particulier les plus petites, réaliseront des économies à long terme en recourant à des entreprises spécialisées comme la sienne. « L’expertise en développement Cobol n’est pas aussi courante en dehors des entreprises spécialisées dans les développements personnalisés, donc, à bien des égards, faire appel à l’une de ces firmes peut être moins coûteux et plus efficace plutôt que de recruter et de développer des talents internes », estime-t-il. « Et de nombreuses entreprises pourraient envisager de quitter leurs applications Cobol à plus ou moins long terme, de sorte que l’accent pourrait être davantage être mis sur l’acquisition de talents internes pouvant répondre aux besoins futurs de l’entreprise tandis qu’un tiers s’occuperait du système actuel ».
Article rédigé par Josh Fruhlinger / Infoworld (adapté par Maryse Gros)
