Faut-il se débarrasser des systèmes COBOL ?
Entre dédain et transmission des savoirs
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 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 ?
Commentaires (61)
Modifié le 18/07/2025 à 10h41
(Même si je suis passé côté BA/Métier depuis quelques temps)
Il y a eu quelques SS2I qui ont abusé un temps avec des salaires très bas après formation. J'ai connu des cas à peine au dessus du smic, tu m'étonne que les gens ne restent pas...
Le 18/07/2025 à 10h43
Du coup, bienvenue les problèmes ! Car c'était vraiment stable.
Le 21/07/2025 à 12h11
Le 18/07/2025 à 10h52
Le 18/07/2025 à 10h58
Sans être totalement sûr que la comparaison est pertinente vu que je ne fais pas de développement Android, ce nouveau langage serait à COBOL ce que Kotlin est à Java sur Android.
Ça ne résoudrait pas le problème de la maintenance de l’existant (ou du déverminage niveau assembleur) mais ça pourrait améliorer l’attrait pour les nouveaux développements en conservant les performances du COBOL pour les parties qui en ont besoin (puisqu’ils ont déjà la solution pour les interfaces clientes avec des langages plus classiques).
Le 18/07/2025 à 13h34
Voir même pourquoi ne pas créer un nouveau langage "moderne" qui soit parfaitement adapté aux besoins des banques, assurances et autres, et qui prennent en compte une évolution progressive au fil des années pour s'adapter aux besoins futures.
Là c'est un peu comme pour le dérèglement climatique: on a une dette énorme, mais des acteurs qui préfèrent fermer les yeux en disant "tant que ça marche on touche à rien". Plus on attend plus la dette sera insurmontable. Ce n'est absolument pas résilient !
Quoiqu'il en soit merci pour cet article et merci aux intervenants, c'est un sujet très intéressant.
Le 18/07/2025 à 15h21
Ceci dit, j'ai travaillé sur un système genre scratch pro (CoolGen) qui générait soit du C, soit du COBOL pour cibler le système. Cela, en 2002/2003. Donc ça a déjà été traité.
Le 19/07/2025 à 12h13
Et c'est là qua ça attaque. Les comptables (donc banque et assurance) sont intransigeant avec ça. Il leur faut le dispositif qui fait l'arrondi comme il le veulent (par ex). Et reproduire à l'identique l'existant des systèmes qu'ils ont déjà et avec la performance / résilience qui va avec. Y'en a pas 36 dans le monde qui font ça. Et ça coute un bras et une jambe.
Deuxièmement les langages sont souvent le fait des entreprises (et des crétins de doctorant dedans). Ce qui ne fait pas autorité et légitimité (dans le sens d'une IETF ou autre). Et c'est donc le marché qui décide. Avec les résultats qu'on connait. Splotch.
Une note : Vu la liste des langages existant dont certains sont plus présent pour dire "j'ai fait un langage dans mon doctorat de math" qu'autre chose, c'est pas forcément un nouveau langage qui va sauver la donne.
Le 21/07/2025 à 12h13
Pas juste l'absence d'une classe numérique avec des méthodes d'arrondis orientées bancaire sinon ce serai réglé depuis longtemps.
Le 21/07/2025 à 13h07
En fait pris à par le CPU (P9, P10 etc.) est comparable à d'autre CPUs grand public. Mais si on prend la machine en entier (HW et son OS qui met tout en cache mémoire), ça arrache.
Bon et puis Java c'est suivant le cas d'usage (EE, pur ou JavaFx). Quand on sait que ça utilise très bien le matériel aujourd'hui. Ça n'a rien à envier à d'autres langages. Je veux dire par là. Android... si c'est pas JavaLand... Je sais pas.
Modifié le 21/07/2025 à 14h17
La heap space c'est 64GO max, de mémoire, le Cobol c'est des call à d'autres sous programmes quasi à l'infini, sans besoin d'attendre le garbage collector pour récupérer de la ressource ou le lancement de la JVM pour en allouer de nouvelles. Et sans le coût en calcul du garbage collector.
Un mainframe on compte en dizaine de TO la mémoire, je lis que le z17 c'est 64TO au max donc le cobol pourra en tirer partie si le code est correctement factorisé et optimisé là où java, structurellement, ne peut pas faire aussi bien, je pense, à cause de sa JVM.
Après je ne suis pas spécialiste des mainframes. Les mainframes font aussi "nativement" du java donc peut être il y a des mécanismes de provisionnement mémoire et de libération mémoire optimisés pour Java... leur plus value étant la perf et la fiabilité, ils ont dû travailler sur la perf java aussi. J'avais lu jadis qu'ils avaient une fonction de garbage collection "à chaud" mais je n'ai jamais creusé et je ne sais pas si ça permet de rattraper Cobol ou si ça limite juste les dégâts.
Le 22/07/2025 à 09h18
Java est une plateforme plus qu'un langage. Il maximise le débit des traitements, pas la consommation mémoire ou autres. COBOL est sans doute plus adapté aux mainframes, et dans certains traitement ce doit être le meilleur choix.
Le 27/07/2025 à 11h45
Cobol "compile" en interne un entier, et le format de la déclaration de donnée stocke le nombre de décimales : en gros tout est calcul en centimes d'euros en entier, et à l'affichage la déclaration de données est analyse pour afficher le "." décimal au bon endroit.
Le BigDecimal semble faire ça : le problème est la lourdeur de Java : Cobol c'est nativement géré à la compilation le CPU bosse en entier et la FPU n'est jamais utilisé. En Java, il y'a un classe qui est instancié en objet, avec des méthodes de cast ou des opérateurs de calcul sont recodés, tout ça en compilé en javacode (qui ne compile pas grand chose), et ce code est interpreté pas la JVM.
Bref calculer la TVA de 50millions de factures en cobol va faire 50millions de multiplications entières totalement répartissable en plusieurs thread, puis une simple addition du total. Sans aucune autre erreur possible qu'un éventuel overflow.
En Java... j'ose pas trop imaginer le nombre de cycles CPU supplémentaires : pour instancier l'objet, réserver sa mémoire, appeler les méthodes pour faire le calcul voir le cast, marquer la mémoire utilisée comme disponible, + les appels du carbage collector régulièrement...
Le 18/07/2025 à 10h58
"On a créé des systèmes qui ont [...] une pérennité"
"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 comprends que nous n'avons pas la même définition de ce qu'est la pérennité.
Pour qu'un système soit pérenne, il ne suffit pas qu'il soit bien fait (i.e. dans les règles de l'art), mais que son avenir soit assuré. Ce qui n'est clairement pas le cas ici, et qu'on voit au travers de la 2nde citation
Bon, la définition donnée par le Robert me contredit un peu: "État, caractère de ce qui dure toujours, ou très longtemps"
Dans le cas des systèmes évoqués ici, on est dans le "très longtemps" à l'échelle informatique.
Mais ce qui était pérenne à l'époque ne l'est plus aujourd'hui du fait de manque de main-d'oeuvre qualifiée.
Le 18/07/2025 à 11h01
Il était lié à l'âge des applications, qui dataient du temps ou gagner un octet sur chaque item était i n d i s p e n s a b l e
Bref, des applications qui avaient le même âge que le COBOL. Mais je ne suis pas coboliste, et j'ai connu des systèmes avec bug de l'an 2000 avec 0 (zéro) COBOL dedans.
Le 18/07/2025 à 11h15
Mais bon, c'est plutôt un système qui "a été pérenne" , comme il le souligne, il manque quelque chose de crucial: des personnes qui maitrisent les systèmes... Sans cela, tous les systèmes COBOL actuels vont devenir très rapidement obsolètes :/
Dommage que les jeunes dev ne s'intéressent pas à ce langage, à mon avis, c'est un secteur où l'on doit bien gagner sa vie en tant que consultant
Le 18/07/2025 à 13h33
Le 18/07/2025 à 11h45
Merci
Le 18/07/2025 à 11h45
//HELLOJOB JOB (ACCT),'HELLO WORLD JOB',CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1)//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
Hello, World!
/*
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
Le 18/07/2025 à 13h49
Le 18/07/2025 à 15h54
Le 18/07/2025 à 12h28
Le 18/07/2025 à 13h08
Les SI maîtrisés sont plus une exception qu'une norme de mon expérience.
Le 18/07/2025 à 13h37
Là on sent vraiment le développeur qui est resté coincé dans les années 90 et qui n'a pas la moindre idée de ce qui se fait aujourd'hui. Les GAFAM traitent des volumes de données qui n'ont rien à envier aux banques, et pourtant aucun n'utilise Cobol.
Le 18/07/2025 à 14h30
Perso ca m'embêterait que mon Livret A retombe à 0 à cause d'un problème de double commit au moment où Cloudflare est tombé à cause d'AWS qui a perdu une région.
Si j'ai bien compris, le COBOL arrive avec son écosystème réfléchi depuis le transistor, jusqu'à la ligne de code fonctionnelle spécifique "informatique de gestion". A la fin, on a quelque chose d'assez limité, mais très performant.
Java... mais pourquoi...
Le 18/07/2025 à 16h04
Tu aurais vu quel langage concurrent?
* Python: un enfer à maintenir - peu portable (les dépendances utilisent des exécutables liés à l'OS, donc certaines bibliothèques fonctionnent sur Windows pas sur linux et vice-versa, ou sont incompatibles ARM)
* Javascript: peut être consommateur de ressources si mal utilisé
* Rust: pas assez de main d'oeuvre, complexe pour les tâches complexes
* C: non
* C++: peut-être, mais: lequel???
Le 18/07/2025 à 23h20
Je ne comprend pas qu'on utilise pas plus ce langage.
Le 23/07/2025 à 10h16
J'ai jamais compris l'avantage de Java alors que des langages bien plus stables, élégants et frugaux comme l'ADA existent
Le 18/07/2025 à 23h45
Aussi, dans le pratique à déployer, tu inclus le tomcat ou le jboss à installer, configurer et maintenir? Au mieux, rien de tout ca, mais il faut forcement un bout de code en shell pour lancer le jar avec les what-millards d'option de la jvm...
maintenu: comme quasiment tout les langages que tu cites.
portable: dans le cas présent, osef complet, il faut que ca tourne sur du x86_64 avec un OS bien défini, au pif, un Linux. Rien de bien compliqué à faire avec les autres langages.
cadré: C'est à dire? mettre un Xmx à 8Go pour un hello world pcq on veut être sure que ca plante pas? Et puis le Xms aussi comme ca on va gagner de la perf. Effectivement, c'est bien cadré. Ou bien galérer pour simplement envoyer des logs au format standard de l'OS.
qui consomme peu de ressources: arrivé à ce point là, je me demande si ton message n'était pas sur un ton humoristique que j'aurai raté. Lancer des VM avec de la RAM à gogo ou surdimensionner des pods pcq il faut faire tourner du java dedans. Les latences induites par le GC... Sincèrement, autant les autres points que tu donnes, y a débat. Mais sur celui de la perf, désolé mais c'est vraiment mauvais, ou tellement complexe que personne n'arrive à sortir du code performant.
et sur lequel on a facile à trouver de la main d'oeuvre: de la bonne main d'oeuvre?
Tu l'auras peut-être compris, je suis admin système. Et franchement le java, c'est vraiment la pire invention du 20ème siècle en informatique. Comme tu le dis, l'avantage, pour les sociétés, c'est de pouvoir en recruter à la pelle. Mais ca n'en fait absolument pas, à mon sens, un bon langage pour autant.
Je ne sais pas si tu l'as oublié volontairement ou pas: Golang?
- Accessible
- des lib pour presque tout
- une fois compilé, ca tourne nativement sans dépendance et sans jvm
- adapté aux conteneurs / micro services
- performant
- cross compilation ultra simple pour déployer sur de l'ARM par exemple
- beaucoup de développeurs
- goroutine/channel/marshall
- ...
Le 19/07/2025 à 09h08
Oui, je préfère ces langages, mais ils sont difficilement recommandables ...
La cross compilation, c'est inférieur à la portabilité de l'exécutable Java je trouve.
Et je suis totalement en désaccord sur Java: Java n'est pas la pire invention, loin de là. La base est saine, les JVM m'ont rarement posé de problème (on en choisit une, opensource de pref maintenant), le langage a évolué un peu lentement mais il est pas mal, un peu plus sûr que C#.
Le GC sur un soft correctement écrit, c'est pas un problème, et j'ai fait du Java sur 8Mo de RAM - le problème n'est pas le langage ou la JVM, c'est les libs que certains utilisent (tu es admin, mais est-ce que les devs ont consciences du nombre de copie en RAM des données que leurs bilbiothèques imposent - dont certaines sont depuis longtemps peu utiles face à des concepts intégrés dans la lib ou le langage ?)
Il a fait ses preuves dans l'embarqué comme dans les gros systèmes.
Par maintenu et cadré je parlais surtout de l'évolution des JVM et du langage.
Modifié le 19/07/2025 à 09h22
La cross compilation, c'est inférieur à la portabilité de l'exécutable Java je trouve (sauf cas très liés aux perfs)
Et je suis totalement en désaccord sur Java: Java n'est pas la pire invention, loin de là. La base est saine, les JVM m'ont rarement posé de problème (on en choisit une, opensource de pref maintenant), le langage a évolué un peu lentement mais il est pas mal, un peu plus sûr que C#.
La question de la licence dépend des choix de l'entreprise: si elle a choisi Oracle, elle est certainement ouverte niveau licence (tous les éditeurs ont leur modèle un peu "openbar")
Le GC sur un soft correctement écrit, c'est pas un problème, et j'ai fait du Java sur 8Mo de RAM - le problème n'est pas le langage ou la JVM, c'est les libs que certains utilisent (tu es admin, tu subis, mais est-ce que les devs ont consciences du nombre de copie en RAM des données que leurs bilbiothèques imposent - dont certaines sont depuis longtemps peu utiles face à des concepts intégrés dans la lib ou le langage ?)
Il a fait ses preuves dans l'embarqué comme dans les gros systèmes.
Par maintenu et cadré je parlais surtout de l'évolution des JVM et du langage.
Le 25/07/2025 à 09h20
Bon pour Java ça va un peu loin. Go a aussi des gros défauts. Tous les langages ont leur bons cotés et leurs défauts. Pour le GC, un petit log perso :
2025-07-18 11:14:36.546 [ LOG ] Heap size: 104Mo. Free memory before GC: 27Mo / Free memory after GC: 51Mo. Memory reclaimed : 24Mo. Execution time :35ms
En dessous de 100ms on ne voit rien pour la plupart des applis. Alors ça c'est un cas spécifique. Imaginons un "billing". Même si on le lance toutes les 5 minutes et de perdre 10 secondes, ça va pas tuer la perf. Même pour de plus grosses voilures en termes de RAM.
C'est comme partout : Il y a des bons vélos pour la course, des VTTs et des vélos pourris. Mais aussi des bons coureurs (les bons programmeurs/dev) et des mauvais (les quiches). Donc une quiche sur un bon vélo pro, ça cassera pas des briques.
Faut vivre avec.
Le 19/07/2025 à 12h46
Le 18/07/2025 à 14h34
Le 18/07/2025 à 22h13
Le 18/07/2025 à 23h50
Alors que si un matin, ton livret A est passé à 0, c'est plus la même histoire :)
Le 19/07/2025 à 09h47
Le 19/07/2025 à 10h44
Ce n'est effectivement pas comparable du tout en terme de criticité.
Modifié le 21/07/2025 à 12h31
Le 21/07/2025 à 16h01
Le 18/07/2025 à 15h09
Je précise que je ne connais pas le COBOL mais que j’ai été Scrum Master d’une équipe de COBOListe.
L’explication sur les nombre a virgule flottante n’est pas très claire je trouve.
Dans la plus part des langages utilise une forme «compressé» des nombres (signe × mantisse × base^exposant). Ça permet de couvrir une plus large plage de chiffre, aussi bien dans le négatif que positif. Le soucis avec cette «compression» c’est qu’elle peut entrainer des arrondis, surtout quand on mix des grand et petits chiffres. Genre «0,999 + 0,0008 = 1,000»
Le COBOL ne souffre pas de se soucis vu qu’il est a virgule fixe (entier + décimale) où chaque partie est codé séparément. Les calculs sont donc exact tant que l’on reste dans leur plage de codage. Au delà (division, fraction, … ) les règles d’arrondis sont connus et donc gérable par divers moyen.
Sur la capacité de traitement du COBOL c’est en effet assez impressionnant, mais la machine qui fait tourné ça est tout aussi impressionnant. Le fait que IBM soit quasiment l’unique dealer de ce genre de machine, fait que toute la chaine (logiciel + matériel) est super optimisé. C’est pas pour rien que les contrats d’utilisation de ces machines se fait traditionnellement a l’occupation CPU. Oui
Après le service après vente, n’a rien a voir. Tu peux tout a fait voir débarqué un tech IBM pour changer un CPU A CHAUD, la machine ne devant jamais s’arrêter. Les record d’uptime étant souvent trusté par ce genre de machine.
Sur le coté migration par «Scrum», je ne suis pas d’accord avec l’analyse des intervenant. Le but n’est jamais de remplacé «isoBug» un programme COBOL, mais souvent le découper et le remplacer petit a petit, en rénovant ses règles de gestions, souvent perdu et exclusivement dans le code je suis d’accord.
Coté recrutement, avoir une compétence COBOL / Java c’est un ticket en or et s’assurer de bosser à vie. Se mettre en indépendant est la meilleur solution pour en tirer un maximum.
Dans la boite où j’ai officié, tous les dev COBOL de France se voyait proposer un poste, ou au pire une mission. Les grosse ESN qui avait encore ce genre de profil se frottaient les mains et saignait le client sur le TJM.
Sinon ils avaient trouver une solution, peu satisfaisante, mais mieux que rien. Ils ont démarché une école à Rabat en leur proposant de monté une option COBOL en fin de cycle et de recruter tous ceux qui en sortaient. Ça attirait pas les foules, mais pour tout ceux qui voulait s’assurer un job et rembourser leur prêt étudiant rapidement, ça faisait l’affaire. Bon coté «turn over» ils avaient du mal a garder des gens plus de 2 ans. Mais au moins ça leur permettait de palier à leur besoin.
Le 18/07/2025 à 15h57
Les règles de calcul comptables impliquent des calculs à virgule fixe et parfois des arrondis particuliers.
Car 10.21*18.6 n'est pas égal à 189,906 si on se limite à 2 chiffres: c'est soit 189,91 (arrondi au plus proche) soit 189,90 (arrondi "bancaire" au pair le plus proche)
Dire que IBM est le seul est une méconnaissance du domaine. En fait les x86 sont des CISC parce qu'ils ont notamment des instructions pour le calcul BCD (binaire codé décimal).
Pourquoi le cobol? Parce que c'est l'un des seuls langages de haut niveau qui ont intégré ce type de notion au coeur du système (et pas avec une librairie - même standard comme BigDecimal dans Java)
SQL le prend en compte AUSSI (mais avec moins de subtilité sur les arrondis).
Sans ce support, le nombre d'opérations pour le calcul est décuplé.
C'est le même cas avec Fortan, parfaitement à l'aise avec les nombres à virgule, quand on fait la même chose en C ou pire - en python, le nombre d'opérations est horrible (notamment concernant les comparaisons et la gestion des 0 et epsilons)
En informatique, les langages les plus récents ont tendance à améliorer la productivité globale en complexifiant les tâches pointues.
Et le calcul à virgule est un sujet très mal compris (et de plus en plus mal il semblerait vu les erreurs de conception des langages "modernes" que sont JS et Python - qui lui a été potentiellement corrigé) - presque autant que la gestion de mémoire.
Par contre je ne sais pas si COBOL a suivi sur les 2 autres gros domaines: la gestion des chaînes de caractères et des caractères spéciaux et la gestion des dates...
Le 18/07/2025 à 17h13
Exemple avec un facteur d'échelle 2:
Le CPU voit la valeur 1453, mais elle signifie 14.53
Le 18/07/2025 à 18h47
Et oui, avec des entiers 64 bits on a une bonne façon de stocker des grands nombres.
Mais cela ne résout pas la question du support correct par le langage: il faut se farcir les différentes opérations et les ajustements en conséquence (notamment les arrondis).
Je plaidoyais surtout pour le côté dev.
Le 18/07/2025 à 18h48
Le 19/07/2025 à 03h16
On est tous ravis de disposer d'une bonne documentation, et personne ne veut la produire.
La contradiction avec la citation précédente est flagrante.
En ayant cet état d'esprit, on entretient le problème ! C'est fou à quel point cette mentalité est impossible à remettre en question, quand bien même leurs défenseurs ont parfaitement conscience du problème et de ses conséquences ! Le déni. La folie.
Considérer que "la documentation est le code" est un foutu caprice de développeur égoïste, qui n'a en plus généralement pas grand chose à carrer des règles métier qu'il sera à la fois incapable et non-volontaire de produire.
Exigeons du métier la documentation du cahier des charge/des attentes & de l'architecture fonctionnelle.
Exigeons de l'infrastructure la documentation de l'architecture matérielle, des systèmes & du réseau.
Exigeons des développeurs la documentation de l'architecture logicielle ainsi que du code.
---
L'argument du coût de maintien en conditions opérationnelles pour conserver du COBOL me laisse dubitatif. Les sources de matériel, les sources de systèmes, ainsi que les sources de main d’œuvre sont toutes limitées.
À ne regarder que le portefeuille, on ne gère pas le risque. Lorsque les coûts exploseront, il sera trop tard.
À moins que les coûts ne soient bricolés pour cacher l'inéluctable…
La volonté de sortir du COBOL ne résulte pas forcément du jeunisme.
D'ailleurs la personne doit se tromper de mot en employant "passéiste", qui est ici un contresens : je renvoie à sa définition.
Les langages plus modernes permettent surtout une architecture modulaire (attention : ce n'est pas automatique, mais doit résulter d'un véritable travail d'architectures !).
La transition si "coûteuse" n'est que la résultante de l'adressage d'un monolithe : effectuant tout ou rien, difficile de basculer progressivement sur des modules réécrits/reconçus… car le découpage en ces modules n'existent pas dans la version d'origine !
COBOL en tant que langage est un générateur de monolithes.
Argument classique de personnes technique adressant le problème comme étant technique.
C'est une composante du problème du technologisme.
Le problème de la maintenabilité est stratégique, par gestion des risques et brassage/découpage/assignation des responsabilités.
Modifié le 21/07/2025 à 17h12
Pas d'accord. Ce n'est pas un foutu caprice de développeur égoïste, c'est une réponse pragmatique à une situation impossible. Avoir une documentation à part à jour, cela signifie que TOUS les développeurs jouent le jeu, et connaisse la documentation sur le bout des doigts pour savoir ce qui doit être modifié et quand. Plus les équipes et les projets grandissent, moins c'est réalisable.
L'avantage de considérer le code comme la doc, c'est que le code c'est effectivement ce qui est exécuté. Quand ton programme ça fait 30 ans qu'il s'exécute et que les utilisateurs n'ont pas relevé d'objection, c'est lui qui fait autorité de facto.
Qui plus est, les bons tests unitaires (unitaire = fonctionnalité, et pas forcément une classe ou une méthode, , on trouve beaucoup de connerie à ce sujet) décrivent avec des mots ce que le code est censé faire et décrire ainsi les règles métiers. Couplé avec une méthodologie comme le TDD (qui permet de décrire ce que l'on veut avant de l'implémenter), et surtout l'automatisation des tests, on s'assure de manière quasi-certaine que les règles métiers sont correctement décrites ET qu'elles sont correctement implémentées.
Remplacer pour le plaisir de remplacer n'a pas de sens non plus. Ce n'est pas qu'une réponse d'ordre technique. Refaire, c'est prendre un risque. Quand le risque n'a pas de conséquence, il est prenable. Quand tu es dans la finance, un bogue, et cela peut coûter des milliards (de dollars, d'euros, ou autre).
La question de la maintenabilité recouvre deux aspects orthogonaux :
- est-ce que le code est dans un état maintenable ? Est-il bien structuré, lisible, ou est-ce un amas de spaghettis indémêlables ?
- est-ce que les outils existent toujours et sont maintenus ?
- est-ce que les compétences pour le maintenir existent ?
Le premier point est assez difficile à évaluer, surtout vue de l'extérieur. Il y a toutefois une métrique qui a tendance à ne pas tromper : celles du nombre de nouvelles fonctionnalités sans introduire de nouveaux bogues. Généralement, dans la finance, je crois qu'on peut considérer qu'ils ne sont pas trop mal vu l'âge des systèmes qui se compte en décennie.
Le 2e est à répondre par l'affirmatif aussi dans le cadre de COBOL.
C'est sur le 3e point généralement que cela pèche avec COBOL. Par "chance", ce n'est qu'un "problème" de formation. La plupart des entreprises externalisent ce genre de compétence. A elles de les interner, voire de fournir les formations nécessaires si besoin. Il y a plein de domaines pointus où la compétence n'existe quasiment pas et il faut le faire via de la formation.
Au delà de l'aspect risque, il y a l'aspect coût de dev (juste pour refaire). Quand tu as un programme qui fait des millions de lignes de code, tu ne le refais pas en 3 mois. Personnellement, j'ai bien envie de voir ce que va donner le programme lancé par Musk aux USA, où il voulait justement se débarrasser de COBOL en 6 mois. Il a pris le problème de la maintenabilité sans se soucier de la gestion des risques.
Au niveau gestion des risques, il y a également le 2e point à prendre en compte. Paradoxalement, c'est, de mon point de vue personnel, le point le plus problématique dans le cadre de COBOL. Il n'y a pas pléthore d'outils et de plateformes supportées et la (sur)vie de COBOL dépend principalement des orientations d'une seule entreprise. Pour moi, c'est ça le risque numéro 1 (surtout dans le contexte actuel, qu'est-ce qui se passe si l'Agent Orange ordonne à IBM d'arrêter de vendre son matos en Europe ?)
Le 19/07/2025 à 12h30
Et 2 parce que le monde entier dans le sens de toute la planète qui va se rebiffer. Et plus particulièrement parce que les "marchés" (les bourses) doivent fonctionner et s'interconnecter. Le brushing spatial ne fait pas le poids.
Ce genre de pratique; on a vu ce que cela donne avec les chinois qui se dotent de quoi fabriquer leur propres puces maintenant et peut être aussi avec l'Europe qui emboite dans la même direction mais plus "softement". Hello RISC-V...
Le 19/07/2025 à 15h05
Le point était surtout pour dire que cela pouvait changer du jour au lendemain. J'ai parlé de Trump, mais cela pourrait être un changement de stratégie, un rachat, ou que sais-je encore.
Le 19/07/2025 à 19h51
Perso, je ne parierai pas sur une décision raisonnable d'un personnage aussi aléatoire.
Le 19/07/2025 à 21h39
Pour une action sur IBM; là cela représentent des montants tellement colossaux qu'il n'aurait pas le temps de finir la phrase. Ça concerne toutes les banques et le assurances du monde entier sans parler des "grosse boites" et des salles de trading.
On a tué des président pour bien bien moins que cela.
Le 20/07/2025 à 08h50
Le 20/07/2025 à 17h23
On finit indubitablement avec une carto des éléments de l'appli et des principales fonctionnalités sans entrer dans le détail.
Si seulement il etait possible de sortir du sacro-saint word/excel pour la doc. En bancaire,j'ai bien connu un projet où on l'associait au code mais cela demande de la bonne coordination entre les intervenants techniques et fonctionnels, maisc'etait l'exception.
Le 20/07/2025 à 21h54
Modifié le 21/07/2025 à 10h44
Je mets word/confluence sur le même niveau de mauvais outil.
Modifié le 23/07/2025 à 10h29
Et j'ajouterai même une précision qui manque à 99% des docs sur du legacy que j'ai pu lire : que la documentation doive comporter la justification des choix techniques fait au moement du développement du projet et qu'ils soient explicités (exemple: choix de la techno X car budget restreint/l'équipe de dev n'était familière qu'avec cette techno/contrainte temporelle etc...). Cette justification explicitée permet des décennies plus tard de voir si la contrainte tient toujours et d'ajuster les évolutions si nécessaire.
In fine ce n'est pas le COBOL le problème, mais plutôt le manque de production (ou de conservation parfois) de documentation d'architecture et d'intention sur les projets développés à l'époque dans ce langage.
Le 21/07/2025 à 15h11
Particulièrement sous prétexte que les gens ont pas fait de la documentation et qu'on ne fait pas l'effort de former des gens.
C'est quand même nettement moins cher et moins chronophage de se sortir les doigts sur ses deux points que de tout reprendre depuis le début un peu partout.
Qui plus est en poussant l'image pour aller s'embourber dans du Java qui dans 30 ans sera éventuellement passé de mode pour X ou Y raisons. Mode: "Java c'est trop vieux! Et hop! On recommence tout!" (Oui, toujours en grossissant le trait.)
If it ain't broken, don't fix it. COBOL fait très bien ce pour quoi il est conçu, là où il est déployé, Juste foutons-lui la paix.
Pas la peine de vouloir réinventer le balai d'essuie-glaces sous prétexte qu'on sait faire des voitures électriques.
Le 24/07/2025 à 16h47
Modifié le 23/07/2025 à 10h30
Le 24/07/2025 à 19h21
Le 27/07/2025 à 11h25
pour le coup Java risque de mourir largement avant Cobol... (c'est pas déjà mort d'ailleurs ?)
Java me semble le pire choix pour remplacer un mainframe : mauvaise gestion du CPU, de la mémoire...Et problématique de licence avec Oracle qui fait nimp.
Tu paies cher la simplicité relative du langage, et te retrouves avec des impossibilités dés que tu pousses les curseurs plus loin qu'une simple IHM...
Bon on va pouvoir recycler les développeur ABAP de SAP : la syntaxe verbueuse est très similaire, le côté imbrication de
tas de m...spaghetti de code est le même. ABAP utilise aussi des PACK pour gérer proprement les arrondis de comptabilité...Et SAP (l'éditeur) pousse leeeeentement les devs vers la base de données in-memory (la plupart des logiques peuvent être portées directement par des CDS view). Même si 3/4 des projets de migration vers Hana ont une grosse partie "on ne s'est pas comment ça marche : on reprend le code ABAP tel-quel". (tient encore un point commu avec Cobol
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?