IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le DOGE d'Elon Musk veut réécrire le code COBOL qui gère la sécurité sociale américaine en quelque mois. Cette base de code compte plus de 60 millions de lignes de COBOL
Ce qui met sa stabilité en péril

Le , par Stéphane le calme

63PARTAGES

18  0 
Le « Department of Government Efficiency » (DOGE) commence à constituer une équipe chargée de migrer les systèmes informatiques de l'administration de la sécurité sociale (SSA) en abandonnant l'un de ses plus anciens langages de programmation en l'espace de quelques mois, ce qui pourrait mettre en péril l'intégrité du système et les prestations dont dépendent des dizaines de millions d'Américains.

Les systèmes de la SSA reposent sur une infrastructure complexe, avec plus de 60 millions de lignes de code COBOL. Ce langage, créé dans les années 1950, a été largement adopté pour les applications de traitement de transactions sur les mainframes. Le « logiciel central » de la SSA, responsable de l'émission des numéros de sécurité sociale et de la gestion des paiements, est principalement écrit en COBOL. Une tentative de modernisation en 2017 avait prévu cinq ans pour remplacer ces systèmes, mais la pandémie de COVID-19 en 2020 a interrompu ces plans.


Le projet est organisé par le lieutenant d'Elon Musk, Steve Davis, et vise à faire migrer tous les systèmes SSA de COBOL, l'un des premiers langages de programmation courants orientés vers les entreprises, vers un remplaçant plus moderne comme Java, dans un délai serré de quelques mois.

En tout état de cause, une migration de cette taille et de cette ampleur serait une entreprise gigantesque, expliquent les experts, mais le délai accéléré risque d'entraver les paiements aux plus de 65 millions de personnes aux États-Unis qui perçoivent actuellement des prestations de sécurité sociale.

Risques associés à une migration rapide

Les experts expriment de vives inquiétudes quant à la rapidité de la migration envisagée. Une transition précipitée pourrait entraîner des défaillances systémiques, des paiements erronés, des sous-paiements, des paiements excessifs ou même des omissions de paiements pour les bénéficiaires. La complexité des systèmes existants nécessite des tests approfondis pour garantir l'exactitude des résultats après la migration. Certains techniciens de la SSA avertissent que des erreurs invisibles pourraient survenir, affectant potentiellement des millions d'Américains.

« Bien entendu, l'un des principaux risques n'est pas le sous-paiement ou le surpaiement en soi, mais le fait de ne pas payer quelqu'un du tout et de ne pas le savoir. Les erreurs et omissions invisibles », explique un technologue de la SSA.

La SSA fait l'objet d'un examen de plus en plus minutieux de la part de l'administration du président Donald Trump. En février, Musk s'en est pris à la SSA, affirmant à tort que l'agence était truffée de fraudes. Plus précisément, Musk a mis en avant des données qu'il aurait extraites du système et qui montraient que des personnes âgées de 150 ans aux États-Unis recevaient des allocations, ce qui n'est pas le cas en réalité. Au cours des dernières semaines, à la suite de coupes sombres opérées par le ministère de l'économie et des finances, la SSA a connu de fréquentes pannes de son site web et de longs délais d'attente au téléphone, comme l'a rapporté cette semaine le Washington Post.

Ce projet de migration n'est pas la première fois que la SSA tente de s'éloigner de COBOL : en 2017, la SSA a annoncé un plan visant à recevoir des centaines de millions de dollars de financement pour remplacer ses systèmes centraux. L'agence prévoyait qu'il faudrait environ cinq ans pour moderniser ces systèmes. En raison de la pandémie de coronavirus en 2020, l'agence s'est détournée de ce travail pour se concentrer sur des projets plus orientés vers le public.

Comme beaucoup d'anciens systèmes informatiques gouvernementaux, les systèmes SSA contiennent du code écrit en COBOL, un langage de programmation créé en partie dans les années 1950 par Grace Hopper, pionnière de l'informatique. Le ministère de la défense a essentiellement fait pression sur l'industrie privée pour qu'elle utilise le COBOL peu après sa création, ce qui a favorisé son adoption à grande échelle et en a fait l'un des langages les plus utilisés pour les ordinateurs centraux, c'est-à-dire les systèmes informatiques qui traitent et stockent rapidement de grandes quantités de données, dans les années soixante-dix. (Au moins un site web lié au ministère de la Défense faisant l'éloge des réalisations de Hopper n'est plus actif, probablement à la suite de la purge des reconnaissances militaires par le ministère de l'Intérieur de l'administration Trump).


En 2016, l'infrastructure de la SSA contenait plus de 60 millions de lignes de code écrites en COBOL

En 2016, l'infrastructure de la SSA contenait plus de 60 millions de lignes de code écrites en COBOL, et des millions d'autres dans d'autres langages de codage hérités, a constaté le bureau de l'inspecteur général de l'agence. En fait, les principaux systèmes programmatiques et l'architecture de la SSA n'ont pas été « substantiellement » mis à jour depuis les années 1980, lorsque l'agence a développé son propre système de base de données appelé MADAM (Master Data Access Method), qui était écrit en COBOL et en Assembleur, selon le plan de modernisation de la SSA de 2017.

La « logique » de base de la SSA est également écrite en grande partie en COBOL. Il s'agit du code qui émet les numéros de sécurité sociale, gère les paiements et calcule même le montant total que les bénéficiaires devraient recevoir pour différents services, explique un ancien technologue de haut niveau de la SSA qui a travaillé au bureau du directeur général de l'information. Même des changements mineurs peuvent entraîner des défaillances en cascade dans les programmes.

« Si l'on ne craint pas qu'un grand nombre de personnes ne reçoivent pas de prestations ou qu'elles reçoivent des prestations erronées, ou qu'elles reçoivent des droits erronés, ou qu'elles doivent attendre longtemps, alors il faut aller de l'avant », déclare Dan Hon, directeur de Very Little Gravitas, un cabinet de conseil en stratégie technologique qui aide les gouvernements à moderniser leurs services, à propos de la réalisation d'une telle migration dans un court laps de temps.

On ne sait pas exactement quand la migration du code commencera. Un document récent circulant parmi le personnel de la SSA et exposant les priorités de l'agence jusqu'au mois de mai ne le mentionne pas, citant à la place d'autres priorités telles que la résiliation de « contrats non essentiels » et l'adoption de l'intelligence artificielle pour « augmenter » la rédaction administrative et technique.

Au début du mois, au moins 10 agents de la DOGE travaillaient au sein de la SSA, dont un certain nombre d'ingénieurs jeunes et inexpérimentés tels que Luke Farritor et Ethan Shaotran. À ce moment-là, des sources ont indiqué que les agents de la DOGE se concentreraient sur la manière dont les gens s'identifient pour accéder à leurs prestations en ligne.


Le « Are You Alive Project »

Des sources au sein de la SSA s'attendent à ce que le projet commence sérieusement une fois que la DOGE aura identifié et marqué les bénéficiaires restants comme décédés et connecté les bases de données disparates des agences. Dans une déclaration sous serment de l'administrateur intérimaire de la SSA, Leland Dudek, déposée jeudi au tribunal, il est dit qu'au moins deux agents de la DOGE travaillent actuellement sur un projet officiellement appelé « Are You Alive Project », qui vise ce que ces agents estiment être des paiements indus et des fraudes au sein du système de l'agence, en appelant des bénéficiaires individuels. L'agence se bat actuellement devant les tribunaux pour obtenir un accès illimité aux systèmes de la SSA afin d'achever ce travail. (Encore une fois, les personnes âgées de 150 ans ne perçoivent pas de prestations de sécurité sociale. Cet âge spécifique est probablement une bizarrerie de COBOL. Il ne comprend pas de type de date, de sorte que les dates sont souvent codées en fonction d'un point de référence spécifique - le 20 mai 1875, date d'une conférence internationale sur l'établissement de normes tenue à Paris, connue sous le nom de Convention du Mètre).

Utilisation de l'intelligence artificielle générative

Pour faciliter cette transition, la DOGE envisage d'utiliser l'intelligence artificielle générative afin...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 02/04/2025 à 22:11
salut à tous.

Citation Envoyé par Der§en
Sans avoir recours à l’IA, on peux parfaitement réécrire du code cobol vers d’autres langages !
Ca, c'est la théorie, mais dans la pratique, tu vas rencontrer des problèmes pour convertir des nombres.

Je ne sais pas si tu connais la représentation des nombres décimales dits condensés (COMP-3) en COBOL. C'est spécifique à COBOL et ça n'existe pas dans le langage 'C/C++'. J'ai eu jadis un problème avec la lire italienne où les montants étaient proches du maximum des 18 digits de sa représentation interne et étaient intraduisibles en langage 'C/C++' car ce langage ne le permettait pas.

Pour avoir fait beaucoup de maintenance en COBOL, il existe des sous-programmes écrits en assembleur pour résoudre des problèmes de calculs comme les taux. Je peux t'assurer qu'il y a beaucoup de spécificités propre au cobol que l'on ne peut pas convertir aussi facilement qu'on veut le croire, sans créer des problèmes qui vont engendrer des effets de bords ou encore des bugs alors que l'existent a déjà été épprouvé depuis fort longtemps.

Et je ne parle même pas des bases de données (DB2 sous IBM) ou encore du transactionnel (CICS) couplé à l'internet pour rendre plus conviviaux les terminaux sous internet. Une vrai usine à gaz ! J'ai, par le passé, fait beaucoup de migration et ce n'est pas aussi simple qu'on veut le croire.

Citation Envoyé par Fagus
Au pire, est ce si problématique de maintenir le code ?
Oui, car la maintenance coute très très chers aux entreprises et je ne parle même pas du manque de développeurs formés au COBOL, ni du métier du client. Remettre en cause un système informatique qui fonctionne parfaitement ne peut pas se faire en six mois alors qu'il a fallu plusieurs décénies pour en arriver là.

Citation Envoyé par Fagus
Les dév ça se forme,
Oui, en théorie, mais qui veut encore faire du COBOL aujourd'hui ? Peut-être des retraités car ils savent encore faire, et que la paye est intéressante. Mais un petit jeune ne sera pas intéressé à developper dans une technique de programmation qu'il ne connnait pas et ne veut pas apprendre. De loin, il préfère le WEB car il a été biberonné dès sa plus tendre enfance. Je rappelle qu'il n'existe pas de framework en COBOL où vous appelez la fonction qui va bien. Si vous avez besoin de quelque chose, vous devez la développer par vous-même. Et ces techniques ne sont plus du tout enseignés à l'école, ni d'ailleurs le COBOL.

Citation Envoyé par Fagus
et c'est sans doute préférable de manipuler des grandes quantités de calculs en cobol que dans la plupart des langages non ? surtout si on a besoin d'avoir des arrondis obéissant à des règles comptables plutôt que sur une accumulation d'imprécision du calcul flottant binaire.
Le flottant est destiné à des calculs scientifiques et non comptables où l'on a besoin d'avoir une réprésentation exacte et non approximative. Il y a des règles comptables, fiscales, financières sur les arrondis que l'on peut faire que si l'on maitrise la représentation des nombres en mémoire, ce que la plupart des langages modernes ne font plus. J'entends par là que si l'on a réellement besoin de 18 digits, on ne peut pas se permettre d'en perdre pour des problèmes d'arrondis.

Citation Envoyé par Prox_13
Et être capable de transcoder des monuments d'avant guerre en COBOL vers un langage actuel en préservant les règles de gestion et la performance du code, c'est une tâche aussi fastidieuse que complexe, qui requiert autant d'expérience que de rigueur.
Pourquoi d'avant guerre ? Le COBOL a été créé en 1959 et le premier COBOL que j'ai connu date de la version "68". Depuis, il y a eu beaucoup de progrès fait dans ce langage.

Les mainframes comme IBM fonctionnent pour des langages comme COBOL et ASSEMBLEUR IBM 370 et non sur du 'C/C++' dont les compilateurs ne doivent même pas exister sur ces machines. Il y a aussi la performance en terme de temps d'exécution que l'on ne retrouve sur des mini-ordinateurs qui sont trop lents, ni des problèmes de sécurités comme "RACF" sous IBM.

Citation Envoyé par Def44
Si l'être humain peut y arriver, aucun doute que l'IA le fera plus efficacement, et très rapidement.
Certainement pas car c'est essentiellement un problème non pas de conversion mais de faisabilité.
Il y a des astuces utilisés en COBOL qui nécessitent de repenser le code pour l'utiliser dans un nouveau langage. Il faudrait aussi comprendre ces astuces, ainsi que la façon de programmer dans les années 60. Bon courage à ceux qui vont mettre leur nez dans ce type de code.

Citation Envoyé par Jepamo
Nous ne sommes plus nombreux à connaitre le Cobol.
Il n'y a rien de complique à programmer dans ce langage mais faudrait aussi connaitre les astuces utilisées qui sont légions dans le domaine bancaire et de la finance. Je connais ce langage car je l'ai pratiqué pour des grands comptes en banque et en assurance et je peux assurer que le maitriser est autre chose que du 'C/C++'.

Citation Envoyé par Jepamo
S'ils partent dans cette optique, ils vont subir une grosse désillusion.
Il suffit de ce rendre compte des problèmes rencontrés avec "Louvois", le système informatique de l'armée française pour la paye des militaires. Ou encore celui utilisé pour le RSA où il y a fréquemment des erreurs ou des retards dans les paiements.

J'ai l'impression que ce DOGE va détruire les Etats-Unis sous le prétexte de faire des économies.

@+
5  1 
Avatar de TJ1985
Membre chevronné https://www.developpez.com
Le 02/04/2025 à 22:12
Mon premier gros mandat a été l'écriture de programmes de traduction COBOL-COBOL pour passer d'un environnent Honeywell Bull à VAX VMS. Il s'agissait aussi de passer d'une base de données réseau à une base relationnelle et donc d'adapter les requêtes en conséquence.
Nous bénéficiions de deux chefs de projets hyper-compétents, connaissant en détail les aspects métiers des applications à porter.
Malgré tout, la migration complète a pris deux ans à une équipe de sept personnes qui n'ont pas chômé.
En parallèle, une vaste équipe de jeunes ingénieurs sans connaissance métier était sensée réécrire l'ensemble des applications, en C++, Delphi, VB, Java en deux ou trois ans.
Total : après quasi-trente ans il a été possible de débrancher les systems VMS, longtemps donc après que DEC eut disparu.
Le choix le pire était encore Java, qui trimbale avec lui un énorme sac de contraintes d'organisation et une terrible dette de performances.
Le système originel tournait avec une puissance de l'ordre d'un Raspberry Pi, aujourd'hui la salle serveurs compte plus de 2000 machines...
Les prestations ont un peu augmenté, dans un domaine assez statique, la banque. Jamais pour justifier une telle inflation.
Donc, bon courage aux bénéficiaires des prestations du système actuel. Et en plus, il y a des bouts d'assembleur...
4  1 
Avatar de der§en
Membre expérimenté https://www.developpez.com
Le 30/03/2025 à 0:27
Sans avoir recours à l’IA, on peux parfaitement réécrire du code cobol vers d’autres langages !

Dans les années 90, à la bourse de paris, on avait développé un convertisseur qui prenait le code cobol issus des mainframes IBM, pour le convertir en langage C pour les VAX/VMS, cela a permis de migrer des millions de lignes de code !
7  5 
Avatar de calvaire
Expert éminent https://www.developpez.com
Le 31/03/2025 à 8:18
Citation Envoyé par Fagus Voir le message
Mais est-ce que c'est si intéressant que ça de convertir les bases de code de cobol, alors que ça marche et c'est performant, sachant que la conversion a un coût et des risques de régressions (il y a eu plusieurs histoires ici de migration ratée vers java avec des pertes de performance).
Alors qu'il existe des compilateurs comme gnuCOBOL qui permettent d'exécuter le code sur PC ?

Au pire, est ce si problématique de maintenir le code ? En regardant sur wikipedia, en cobol 2014 le langage est modernisé avec des types modernes et l'orientation objet. (il y a même un cobol 2023).

Les dév ça se forme, et c'est sans doute préférable de manipuler des grandes quantités de calculs en cobol que dans la plupart des langages non ? surtout si on a besoin d'avoir des arrondis obéissant à des règles comptables plutôt que sur une accumulation d'imprécision du calcul flottant binaire.

Quoique, en python, il y a le module decimal pour ça, et je viens de voir qu'il peut être utilisé en c et c++.
c'est tous le probleme justement.
Il faut trouver des dev pour faire du cobol, il y'en a peu et coutent cher.

Pour les dev c'est loin d’être une bonne affaire aussi, ok avec cobol ils peuvent trouver un taff mieux pays, mais cobol c'est rare et donc ils seront prisonnier de leurs boite. Un dev cobol va difficilement pouvoir retrouver un taff ailleurs, surtout en cas de layoff il sera dans la merde.
Pour un dev il vaut mieux se former dans des technos d'avenir, sa lui donnera un taff mieux payé et être attractif sur le marché du travail.

Ou alors négocier avec sa boite d’être dev cobol à mi temps ET aussi de faire autre chose de plus vendeur sur le cv, mais pour la boite ca coute encore plus cher ce deal.
Au final la migration apparait comme une bonne solution pour l'avenir de la boite. Car un salarié sa reste pas longtemps dans une boite, 2-5ans. Trouver des devs cobols tous les 2-3 ans, c'est chaud.

Perso j'ai toujours travaillé sur des technos d'avenir, j'ai toujours choisis mes postes en fonction de ca (en plus du salaire). Ca m'a toujours garantie des portes ouvertes auprès des entreprises et des salaires attractifs.
J'ai toujours poussé en interne a utiliser et travailler sur les technos les plus vendeurs sur le cv. Il faut toujours préparer son prochain job, même si il arrivera jamais ou dans 10ans, ou... dans 1 semaine par surprise car la boite a décidé de te virer.

en 2025, Cobol reste une bonne compétence pour le salaire si on habite dans un gros bassin d'emploi comme paris, mais ne surtout pas s'enfermer que la dedans et développer d'autres expertises.
7  5 
Avatar de christiandocker
Futur Membre du Club https://www.developpez.com
Le 03/04/2025 à 11:58
Musk se croit une fois encore au dessus du lot ... mais il ne sait pas que des migrations existent déjà qu'il serait bon d'utiliser.

C'est ancien, ça date d'environ 30 années ! Mais cela a déjà été réalisé à grande échelle.

Se rapprocher des SSII française pour éviter d'inventer le fil à couper le beurre !
2  0 
Avatar de TJ1985
Membre chevronné https://www.developpez.com
Le 05/04/2025 à 11:45
En fait, lorsqu'on parle d'application "COBOL", nous n'avons pas forcément la même image. Lorsque je travaillais dans cet environnement, sous VMS, une application COBOL c'était :

- Un compilateur et un langage normé.
- Un gestionnaire de fenêtres (mode caractères). Il y en avait trois chez DEC, mon favori étant DEC Forms, qui fut choisi.
- Un moniteur transactionnel, ACMS.
- Une base de données relationnelle, RdB.
- Un langage de scripts systèmes, DCL.

Ajoutons un dictionnaire centralisé qui marchait plus ou moins, un éditeur puissant (TPU puis LSE), la gestion des sources (MMS / CMS).

Les applications s'exécutaient sur un cluster VAX, puis AXP, etc, suivant l'évolution des technologies. Le cluster assurait la tolérance aux pannes et la répartition de charge.

Aujourd'hui, je ne sais pas si la notion de moniteur transactionnel existe toujours. Dans le cas contraire, ça veut dire qu'il faut développer une couche de colle entre les modules provenant de COBOL, simplement pour implanter la logique métier qui se cachait dans le moniteur.

Bien sûr, je n'ai l'expérience que d'un "gros" environnement. COBOL est un langage suffisamment complet pour avoir permis des développements complexes monolithiques, sans outils externes. Il emporte en fait tout ce qui était nécessaire à une application de gestion de l'époque (File Section, Screen Section, Report Section) et pouvait très bien travailler tout seul, j'en ai eu plusieurs preuves, constatées et commises.

Lorsque mon client a décidé de quitter C2IHB pour DEC, une guerre des chefs a eu lieu : L'ancien tenait pour une conversion des applications, le nouveau affirmait pouvoir tout réécrire en deux ans... Donc, après trente ans les derniers modules convertis ont finalement pu être débranchés !

Un point : 60 millions de lignes de code, pour du COBOL, ce n'est pas énorme. Un programme fait très facilement 1000 lignes pour dire bonjour. Un programme "utile" fait facilement 10'000 lignes. On arrive donc à 6'000 modules, ce qui n'est pas rien mais pas effrayant non plus.

Ceci pour dire que les évaluations données par Musk me semblent aussi fiables que ses prévisions de disponibilité de l'AutoPilot Tesla...

Quant à moi, j'ai lu Bill Gates, je lis Paul Allen, déçu par Lazarus je me mets à l'Assembleur, Na ! ;-D
2  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 30/03/2025 à 21:32
Mais est-ce que c'est si intéressant que ça de convertir les bases de code de cobol, alors que ça marche et c'est performant, sachant que la conversion a un coût et des risques de régressions (il y a eu plusieurs histoires ici de migration ratée vers java avec des pertes de performance).
Alors qu'il existe des compilateurs comme gnuCOBOL qui permettent d'exécuter le code sur PC ?

Au pire, est ce si problématique de maintenir le code ? En regardant sur wikipedia, en cobol 2014 le langage est modernisé avec des types modernes et l'orientation objet. (il y a même un cobol 2023).

Les dév ça se forme, et c'est sans doute préférable de manipuler des grandes quantités de calculs en cobol que dans la plupart des langages non ? surtout si on a besoin d'avoir des arrondis obéissant à des règles comptables plutôt que sur une accumulation d'imprécision du calcul flottant binaire.

Quoique, en python, il y a le module decimal pour ça, et je viens de voir qu'il peut être utilisé en c et c++.
7  6 
Avatar de Def44
Nouveau Candidat au Club https://www.developpez.com
Le 05/04/2025 à 0:51
Certainement pas car c'est essentiellement un problème non pas de conversion mais de faisabilité.
Il y a des astuces utilisés en COBOL qui nécessitent de repenser le code pour l'utiliser dans un nouveau langage. Il faudrait aussi comprendre ces astuces, ainsi que la façon de programmer dans les années 60. Bon courage à ceux qui vont mettre leur nez dans ce type de code.
Visiblement t'aimes quoter les gens et répondre hors sujet. Je dis que c'est faisable, tu me dis que "c'est pas une question de conversion mais de faisabilité".

Sinon, tu as mis le nez dans les innovations IA des dernières semaines / derniers mois ? la progression est hallucinante, et on utilise des IA pour gérer des IA, de sorte que le problème du contexte (c'est le seul réel problème ici) peut être contourné. Visiblement c'est même pas ce qui t'inquiète.
Si tu crois qu'une IA est incapable de "repenser le code", c'est que, je pense, tu ne t'es vraiment pas intéressé au sujet.

Si ce n'est pas impossible c'est donc faisable, qu'importe la complexité.
1  0 
Avatar de jepamo
Nouveau Candidat au Club https://www.developpez.com
Le 02/04/2025 à 16:00
Nous ne sommes plus nombreux à connaitre le Cobol.
Et faire le portage de 60 millions de ligne de code, en espérant obtenir à minima la même qualité, cela ne se fait pas d'un coup de baguette magique en quelques mois.
S'ils partent dans cette optique, ils vont subir une grosse désillusion.
3  4 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 31/03/2025 à 13:20
Citation Envoyé par der§en Voir le message
Sans avoir recours à l’IA, on peux parfaitement réécrire du code cobol vers d’autres langages !

Dans les années 90, à la bourse de paris, on avait développé un convertisseur qui prenait le code cobol issus des mainframes IBM, pour le convertir en langage C pour les VAX/VMS, cela a permis de migrer des millions de lignes de code !
Malheureusement, travaillant dans une entreprise qui peine a migrer son ERP de COBOL (VMS) vers des langages modernes, c'est beaucoup d'heures-homme qui doivent y passer et comme l'explique l'ami Calvaire ci-dessus, c'est extrêmement difficile de trouver des développeurs COBOL bons et formés sur les nouvelles technos sans débourser une fortune. (Si ça peut donner des idées à certains, d'ailleurs.)
L'accès a un environnement de dev COBOL reste, malgré tout, une chose assez rare. Et être capable de transcoder des monuments d'avant guerre en COBOL vers un langage actuel en préservant les règles de gestion et la performance du code, c'est une tâche aussi fastidieuse que complexe, qui requiert autant d'expérience que de rigueur.

Il faut aussi prendre en compte le fait que les systèmes vieillots ont l'effet "big ball of mud", avec des générations de développeurs qui se sont succédés avec chacun leurs façons de programmer, malgré un format similaire sous jacent.
Au final, ayant essayé de développer un convertisseur COBOL, c'est compliqué de trouver un algorithme suffisamment générique pour plaire a tous.
3  6