On parle souvent du langage COBOL comme d’un dinosaure dont il faudrait se débarrasser. Omniprésent dans le domaine bancaire et les assurances notamment, il serait en décalage complet avec les standards modernes de la programmation. Qu’en est-il vraiment ? D’après les gardiens du temple interrogés par Next, c’est loin d’être aussi simple.

Pour les fêtes de fin d’année, Next vous offre cet article initialement paru le 18 juillet 2025 et réservé aux abonnés. Pour lire les prochains entretiens dès leur publication, abonnez-vous !

---

Pour comprendre la situation, il faut d’abord revenir aux origines. Le COBOL, pour COmmon Business Oriented Language, est un langage créé en 1959. Il a été développé par le Short Range Committee, qui incluait des représentants de l’industrie et du gouvernement américain. Son objectif était de créer un langage de programmation portable, orienté vers la gestion et facile à lire, s’inspirant de l’anglais courant.

Comme on peut le lire sur Wikipedia entre autres, cette création a largement teinté le COBOL. Le comité qui lui a donné naissance avait été rassemblé au Pentagone et réunissait trois agences du gouvernement américain : l’US Air Force, le David Taylor Basin et le National Institute of Standards (alors NBS, l’ancêtre du NIST actuel). L’informaticienne Grace Hopper, à qui l’on doit notamment le premier compilateur (A-0 System), est l’un de ses principaux architectes. Son langage FLOW-MATIC est la principale source d’inspiration du COBOL, avec le COMTRAN d’IBM.

Ce qu’est le COBOL

« Verbeux » est probablement l’adjectif qui revient le plus souvent pour décrire le COBOL. Voyons donc comment il s’articule.

Un programme COBOL est structuré en quatre divisions. La première, nommée Identification, contient des informations générales sur le programme : nom, auteur et date de compilation. La deuxième, Environment, décrit les environnements matériel et logiciel dans lesquels le programme va s’exécuter, dont la configuration des ordinateurs et les fichiers utilisés. Cette division est devenue moins utilisée avec le temps, grâce à l’évolution des compilateurs devenus capables de s’adapter à ces environnements.

La troisième division, Data, a pour mission de définir les données que le programme va utiliser. Il faut y indiquer si ce sont des variables, des structures de données et les paramètres. La définition des variables n’a rien de commun avec les langages d’aujourd’hui, car le COBOL utilise une structure en arborescence, l’imbrication étant pointée par des numéros de niveaux. La dernière division, Procedure, contient les instructions exécutables proprement dites. Elle est capitale, car elle code littéralement la logique métier du secteur dans lequel le programme va se retrouver.

Chacune de ces quatre divisions peut être découpée en sections, elles-mêmes composées de paragraphes. Et si l’on parle de paragraphes, c’est parce qu’ils contiennent… des phrases. Celles-ci peuvent être des instructions ou des clauses, terminées par un point. Si l’on ajoute que la syntaxe du COBOL est très proche de l’anglais, avec des instructions comme ADD, MOVE ou PERFORM, on obtient pratiquement un texte. « Verbeux » est donc le bon mot, car tout y fonctionne par mots-clés, mais c’est ainsi que le COBOL a été conçu : pour être lisible.

Un lien fort avec le matériel

Il faut tenir compte également du contexte matériel dans lequel le COBOL a été créé, notamment les écrans. On parle bien des moniteurs à tube cathodique avec les fameuses écritures vertes, avec un affichage sur 80 colonnes. Le COBOL est calqué sur cette organisation, héritée des cartes perforées.

Initialement, les six premières colonnes étaient ainsi dévolues au numéro de séquence. La colonne 7 correspondait à l’indicateur, les colonnes 8 à 11 aux en-têtes de divisions, sections, paragraphes et définitions de données de haut niveau, puis les colonnes 12 à 72 aux instructions. Les dernières colonnes étaient dévolues à l’identification du programme. Là encore, avec le temps et l’évolution des compilateurs, les programmes ont pu adopter petit à petit une structure plus libre.

Le COBOL est également indissociable des mainframes. Ils reposent sur le modèle d’une unité centrale particulièrement puissante desservant des terminaux légers. Dans ce domaine, IBM a joué un rôle majeur, étant aujourd’hui le seul grand pourvoyeur de mainframes, via ses produits zSeries. Si vous lisez entre les lignes, cela signifie que l’on peut aujourd’hui s’équiper avec du matériel neuf pour mettre en place… une solution COBOL. Les mainframes peuvent bien sûr être utilisés dans d’autres cas.

Toujours présent ? En 2025 ?!

Le COBOL serait largement présent dans le secteur bancaire, les assurances, les grandes administrations publiques, et même dans d’autres domaines comme la santé, l’automobile, les transports et la distribution. Il serait partout, mais on n’en entendrait jamais parler. Partout à quel point ?

Selon une enquête réalisée par Reuters en 2024, pas moins de 43 % des systèmes bancaires actuels seraient construits en COBOL. Une part énorme, qui se répercute dans les opérations courantes, puisque plus de 80 % des transactions par carte bancaire seraient traitées en COBOL. Dans les distributeurs automatiques, ce chiffre s’envole même à 95 %. Aujourd’hui, plus de 90 % des entreprises du classement Fortune 500 utiliseraient du COBOL de manière plus ou moins intensive.

Selon une étude menée par Micro Focus en 2022 et citée par DataScientest, il y aurait aujourd’hui 850 milliards de lignes de code écrites en COBOL en production. Un chiffre vertigineux, qui pose bien sûr la grande question : pourquoi ? L’interrogation est légitime, car si le COBOL est un vieux dinosaure, il devrait avoir été remplacé depuis longtemps. Après tout, tout évolue très vite en informatique et le matériel comme le logiciel ont fait des bonds spectaculaires en plusieurs décennies. Serait-ce une simple question d’inertie ?

« Pourquoi ne serait-il plus là ? »

Nous avons discuté avec plusieurs développeurs COBOL, que l’on nomme traditionnellement « cobolistes ». Tous présentent étrangement le même profil : ils ne se destinaient pas à ce langage. En fait, ils n’avaient même pas prévu de s’orienter vers l’informatique en particulier. Presque tous sont issus de la grande vague de recrutement des années 90, quand la peur du bug de l’an 2000 a provoqué une explosion de la demande. Car oui, ce bug de l’an 2000 était lié au COBOL.

Parmi ces cobolistes, Gatien Dupré se considère comme « un recyclé de l’informatique ». « Je n’étais absolument pas destiné à faire de l’informatique puisque je faisais des études en biotechnologie », nous explique-t-il. Mais les années 2000 sont arrivées, et avec elles le fameux bug ainsi que le passage à l’euro. « Deux changements majeurs qui devaient impacter le corps du système IT, notamment des grands groupes du tertiaire, les banques en premier », nous raconte le développeur, qui a été élu Mainframe Influencer deux années de suite par Planet Mainframe et IBM Champion 2025, et travaille aujourd’hui comme Chief Product Technical Officer chez Virtel.

Il casse d’abord une idée reçue : oui, il y a bien eu des projets pour se débarrasser des mainframes, ce que l’on nomme « downsizing ». C’était le cas par exemple en 2015 quand il travaillait à la Société Générale. Mais dans la plupart de ces projets, le même constat revenait, selon lui : le mainframe avait le meilleur TCO (coût du cycle de vie) et le système Z d’IBM avait encore de beaux jours devant lui. La question se posait depuis longtemps de savoir, face à une architecture conçue pour être pérenne, comment moderniser la pratique, car la façon de faire avait largement changé. Une réflexion qui l’a conduit à constituer une petite équipe pour travailler sur le sujet, aboutissant à une embauche chez IBM comme Product Manager sur une partie de la gamme DevOps nouvellement créée de l’entreprise.

À la question « Pourquoi le COBOL est-il toujours là », Gatien Dupré joue la contre-interrogation : « Pourquoi ne serait-il plus là ? ». Il développe : « Se demander pourquoi le COBOL est toujours là, c’est un peu pour moi une vision passéiste, qu’on a beaucoup entendue, notamment par les personnes qui pratiquent d’autres langages, principalement le Java ».

Il compare le COBOL au grand requin blanc : une relique de la préhistoire, mais qui existe encore parce qu’il « est parfaitement adapté à son milieu ». « Si le COBOL est toujours là, c’est qu’il s’est toujours adapté au plus près des besoins business. Il est fait pour le massive output, pour le traitement de grandes masses de données de manière efficace et performante », ajoute le développeur.

« On a créé des systèmes qui ont des dizaines d’années, donc qui ont une séniorité, une pérennité, une stabilité incontestables parce qu’ils ont été tunés au fil du temps par pas mal d’ingénieurs. Et derrière, au lieu de tout refabriquer pour arriver en définitive à peu près à la même chose – si on a de la chance en dépensant beaucoup d’argent – on peut directement exposer des choses qui fonctionnent et qui sont éprouvées », explique Gatien Dupré.

Les velléités de remplacement ne sont d’ailleurs pas un phénomène nouveau : « Quand j’ai commencé ma carrière, les CTO voyaient dans le COBOL quelque chose qu’il fallait abattre, un élément contre-performant. Aujourd’hui, on a une approche beaucoup plus pragmatique, opérationnelle, qui vise à dire : utilisons la bonne technologie au bon endroit ».

Un langage vivant

Pour Gatien Dupré, il y a plusieurs raisons expliquant que COBOL soit toujours là. Ses performances d’abord, que l’on ne retrouve pas toujours selon lui dans d’autres langages, notamment le Java qu’il pratique également.

Autre avantage, la verbosité du langage et son codage de la logique métier : « On a des chaînes de traitement qui sont parfois historiques. Je parle par exemple des chaînes de traitement comptables. Tous les bilans, tous les traitements comptables des banques, par essence, sont faits au travers du langage COBOL. Quand on a un problème dans un traitement comptable, on doit pouvoir rapidement le déboguer. Et ça, c’est quelque chose qu’on est capable de faire sans l’aide d’aucun outil dans le code, parce que le langage est très verbeux ».

En outre, comme il nous l’explique et « contrairement à ce que croient beaucoup de gens, le Cobol est un langage vivant ». Le COBOL, dans sa version IBM qui est principalement utilisée dans les entreprises, en est à sa sixième version, nommée Enterprise V6 chez l’entreprise. « Aujourd’hui, on est à la version 6, qui est une version extrêmement disruptive. Vous pouvez faire par exemple de l’open banking avec COBOL. C’est-à-dire que vous pouvez exposer des API et consommer des services dans le système du COBOL, qui lui-même peut consommer aussi des services tiers venant d’ailleurs », ajoute l’ingénieur.

Les méthodes d’apprentissage et son utilisation ont largement évolué aussi. Il y a une opportunité selon lui pour incorporer des méthodes modernes, à travers notamment VS Code et le DevOps, l’automatisation des tests, la virtualisation des environnements, etc. On trouve même des assistants IA prenant en charge le COBOL, comme Watson X for Code Assistant chez IBM, Code Insight chez BMC, ou encore COBOL Colleague chez PhaseChange.

Le poids du passé

Le COBOL évolue, mais comment faire le lien entre passé et présent ? Comment préparer l’avenir ? Ces questions se posent d’autant plus que la grande vague d’embauches de la fin des années 90 débouche petit à petit sur un nombre croissant de départs à la retraite. En outre, l’apprentissage du Cobol aujourd’hui ne prépare qu’en partie à la gestion d’anciens projets qui, si leur code a évolué, constituent un empilement parfois vertigineux de couches successives.

« Si on se forme maintenant, donc en V6, comment faire pour affronter l’ancien code ? Il n’y a pas beaucoup de différences dans la sémantique, il y a simplement certaines failles, mais heureusement le compilateur met en avant les éléments qui ne sont plus compatibles. Mais rentrer dans la logique d’un programme existant, c’est toujours une gageure », confirme Gatien Dupré.

Cette cassure est soulignée également par Gaétan Roelens, développeur COBOL et chef de projet chez ArcelorMittal, et lui aussi venu au COBOL un peu par accident. Il s’est notamment fait connaitre en intervenant sur la chaine Underscore chez YouTube, sur le même sujet.

Contacté par Next, il comprend que le COBOL peut effrayer par sa verbosité ou son approche. « Bien sûr que les mainframes d’aujourd’hui n’ont rien à voir avec ceux de l’époque. Mais il ne faut pas négliger la syntaxe du COBOL. Elle date d’il y a 60 ans, elle parait absurde aujourd’hui. Et on ne peut pas le nier : on code toujours sur 80 colonnes, on n’a pas la souris. Au niveau de l’interface, c’est vieux, ça c’est clair. Le développeur, devant un écran de mainframe, il va halluciner. Ça fait vieillot, clairement. Par contre, ce qui tourne derrière, ce sont les super performances ».

La tentation du neuf

Tout effacer pour repartir sur une base neuve est une tentation constante, qui fait partie intégrante du solutionnisme technologique. Dans le cas du COBOL cependant, le langage embarque, lui, la logique métier. Plonger dans son code et reculer dans le temps revient à ouvrir un livre d’histoire sur l’évolution des pratiques du métier et leurs évolutions. Dans certains cas, cet historique est crucial. Dès lors, repartir sur une base neuve devient aussi complexe qu’onéreux, quand l’opération est possible.

« Je pense que les systèmes sont devenus trop gros, on n’arrive pas à migrer, on n’a pas de solution encore pour migrer des systèmes aussi gros. La méthode Scrum agile ne marche pas pour ce genre de projet aussi énorme. Ça va dériver dans le temps et ne jamais se terminer. Et si on veut faire des projets à l’ancienne, avec des deadlines, etc., on n’arrive pas à caser tout dans le budget », abonde ainsi Gaétan Roelens.

Il poursuit : « Ensuite, les règles de gestion qui ont été codées à l’intérieur depuis 60 ans ne sont plus maîtrisées par les utilisateurs. Si on prend l’exemple d’un projet XY, on va dire « Bon, alors maintenant, à la place de ce qui tourne, on va vous mettre ce projet. Donnez-nous toutes les règles de gestion pour les recoder dans le projet XY ». Les utilisateurs vont dire : « On ne sait plus. On ne sait pas. Oui ça fonctionne, mais on ne sait pas ce qu’il y a derrière ». Donc dans ce cas-là, il faut refaire toute une rétro-analyse. Et rien que l’analyse du COBOL pour extraire toutes les règles codées, ça va coûter aussi cher que le projet en lui-même ».

Ce qui revient, en somme, à chercher dans le code le cahier des charges. Un problème autant qu’un avantage selon le développeur, car la documentation a souvent tendance à disparaitre, là où le code est toujours là. Et, si lui aussi note l’adaptation à l’IA et l’arrivée d’outils pour le COBOL, il s’agit surtout d’écrire du nouveau code, pas d’analyser l’existant.

« Là où je travaille en ce moment, il y a 4 000 programmes, tous imbriqués entre eux. Et ce n’est pas une grosse architecture. L’IA est incapable de gérer ça pour l’instant », indique Gaétan Roelens. Une IA capable d’analyser 4 000 programmes et d’en décrire les imbrications pourrait-elle être considérée comme révolutionnaire ? « Clairement, parce qu’il faudrait que l’IA comprenne tout. Chez ArcelorMittal, par exemple, elle devrait comprendre ce qu’est une bobine, dans quel rouleau elle passe, etc. C’est la logique métier et elle est présente dans le code. C’est le code en COBOL qui va dire que telle bobine d’acier doit passer à telle date dans telle machine, dans tel rouleau, qu’elle ait telle épaisseur, etc. ».

Une approche hybride

Si le langage évolue et que l’approche se veut plus pragmatique, une approche hybride peut-elle être envisagée ? Pour Julien Eliès, autre développeur COBOL avec qui nous avons discuté, c’est une évidence.

« En France, le COBOL est encore assez utilisé, dans les banques et assurances bien sûr, mais aussi dans pas mal de PME et dans la santé. Souvent, ces sont des applicatifs qui datent des années 90. Dans l’entreprise où je suis, c’est en train d’être réécrit : l’interface applicative est refaite en Java, mais c’est bien le Cobol derrière qui fait les traitements ».

Lui aussi pose la question : « Pourquoi changer ce qui fonctionne ? C’est une question de masse historique, de nombre de milliards de lignes de code. Ce serait très long, très coûteux, alors que le COBOL marche. Et il marche même très bien. Quand vous voulez traiter des millions, voire des milliards, de transactions financières dans les banques et qu’il faut le faire entre 20h le soir et 6h le lendemain matin. Je n’ai pas encore vu Java le faire, alors que sur des gros systèmes, il n’y a pas de problème avec COBOL ».

Il attire d’ailleurs notre attention sur un autre critère qui a rendu le COBOL si précieux dans le domaine financier et explique qu’il soit toujours là : « Il y a aussi un problème de gestion du numérique, de typage de variables. En Java, il n’y a pas de numérique à nombre de décimales fixes. On a un entier, on a un décimal, mais le nombre de décimales n’est pas fixe. C’est Java qui va le décider en fonction de son utilisation. Alors que pour des calculs financiers notamment, on a vraiment besoin que les nombres soient définis avec 2 ou 5 décimales, et que ce soit toujours la même chose. Sinon on tombe sur des arrondis qui peuvent générer des coûts conséquents quand on parle de millions voire de milliards d’euros ».

Il casse d’ailleurs une autre idée reçue : la mise en place du virement instantané dans les banques n’était pas tant un problème de COBOL que d’architecture. « Oui le COBOL était utilisé dans des traitements asynchrones et des batchs de nuit. Ça répondait dans la dizaine de secondes ou dans la minute. Ce n’était pas idéal pour les virements instantanés, qui engendrent des traitements complexes. Mais c’est surtout un problème d’architecture, car rien n’empêche d’avoir une interface web qui appelle un programme Cobol, qui répondra en quelques dixièmes de seconde ».

Lui aussi estime qu’un programme fonctionnel en COBOL ne devrait pas être remplacé : « Si vous avez un existant COBOL qui marche, qui fait le job, et qu’on peut brancher avec une interface moderne, pourquoi réécrire ? Ça coûterait cher, ça générerait probablement beaucoup d’erreurs, beaucoup de bugs à corriger, pour peu d’avantages ». Tout en précisant, en riant : « Mais bon, nous les cobolistes, on est de vieux ronchons ».

Transmission du flambeau :  c’est compliqué !

Comme beaucoup de « cobolistes », Gaétan Roelens nous expose ses craintes sur la passation des connaissances entre l’ancienne génération de sachants et la nouvelle : « C’est vrai que jusqu’à maintenant, on s’appuyait sur les gens de cette génération-là. Quand j’avais un problème vraiment trop complexe pour moi, j’allais les voir. Et aujourd’hui, ils sont partis. Je vous avoue que des fois on est bien embêtés », nous confie le développeur.

Comment faire alors ? « On bricole parfois. On ne peut plus aller aussi loin qu’avant, aussi au fond. Avant, si on avait un bug, on allait creuser jusqu’au bout, voir d’où venait le bug. Des fois, on devait aller dans la partie assembleur du COBOL, du z/OS, etc. Mais aujourd’hui, presque plus personne ne sait le faire. Donc, si on a un bug et qu’on n’arrive pas à trouver, on contourne le problème. On va faire autre chose, mais on ne résout pas vraiment le problème. C’est sûr que ça dégrade les performances ».

« On arrive toujours à se débrouiller, mais ce n’est pas une situation idéale. Si on pouvait avoir encore des experts aujourd’hui, des jeunes qui montent en compétences, ce serait top, mais ce n’est pas ce que je remarque. Je remarque plus une rareté des experts en COBOL. Ce sont souvent les SSII qui forment. Après, on peut toujours faire appel aux Golden Tickets d’IBM. Eux, ils ont quand même des experts. Mais bon, c’est cher », poursuit Gaétan Roelens.

Le chef de projet nous indique avoir accepté l’invitation d’Underscore pour cette raison : attirer l’attention, faire la promotion de COBOL, casser l’idée reçue d’un langage figé et encourager les plus jeunes générations à se lancer. Comme Gatien Dupré, il s’inquiète de ce que les jeunes développeurs n’ont souvent jamais entendu parler du langage. Et, quand ils le connaissent, ils en ont souvent une vision mâtinée d’une couche de dédain chronologique : « c’est vieux, donc c’est nul ».

Même volonté chez Gatien Dupré : « Le conseil que je donne aux jeunes développeurs, c’est : intéressez-vous au COBOL et à l’informatique de gestion parce que c’est une mine d’or. Avec la vague des papy-boomers, le renouveau générationnel est une préoccupation que pas mal de gens ont. Pour nous, en COBOL, effectivement, il y a ce fossé générationnel : quand les derniers développeurs seniors partiront à la retraite, on aura peu de mid-seniors qui permettront d’accompagner ». On retrouve ainsi le problème de transmission des savoirs, en plus du simple apprentissage du langage.

Julien Eliès confirme lui aussi : « Parmi les cobolistes, je suis considéré comme jeune alors que je viens d’avoir 50 ans, donc c’est sûr qu’on va en manquer. Dans l’absolu, ce n’est pas compliqué de former un coboliste. Du moment qu’on a touché à un langage de programmation, qu’on sait ce que c’est un algorithme, en moins d’un mois, on a compris ce que c’était COBOL. Ce qui est compliqué c’est de maintenir des applicatifs qui ont 40 ans, sur lesquels des centaines de personnes sont intervenues, et dont on a souvent perdu la documentation ».

De fait, pour les trois cobolistes, il n’y a aucune raison technique de remplacer les programmes COBOL existants s’ils donnent satisfaction. En revanche, le problème de la transmission des savoirs et de l’appropriation des projets existants est un vaste problème posant la question de la maintenabilité du code. Même si pour les développeurs interrogés, la thématique n’est pas nouvelle : quand les entreprises ont des besoins, une solution finit en principe par émerger.