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 !

Des archives montrent qu'un employé du DOGE d'Elon Musk, surnommé « Big Balls », a fourni une assistance technique à un réseau de cybercriminels,
Suscitant des questions sur l'intégrité du personnel du DOGE

Le , par Mathis Lucas

10PARTAGES

7  0 
Le DOGE d'Elon de nouveau sous le feu des critiques après la publication d'un rapport accablant sur un membre du personnel surnommé « Big Balls ». Ce dernier aurait fourni des services informatiques à un acteur de la menace qui s'est vanté de faire du trafic de données volées et de cyberharcèlement d'un agent du FBI. Big Balls, de son vrai nom Edward Coristine, est l'un des membres les plus visibles du DOGE et dispose d'un accès illimité aux réseaux officiels des États-Unis. Elon Musk a défendu Big Balls dans un billet posté sur son réseau social X (ex-Twitter). Il n'est pas le premier employé du DOGE qui fait l'objet de controverses depuis la création de l'agence.

DOGE : un membre du personnel de l'agence avec des antécédents douteux

Elon Musk dirige le controversé département de l'efficacité gouvernemental (DOGE) créé par le président américain Donald Trump pour réduire la taille et les dépenses du gouvernement fédéral américain. Le milliardaire s'est alors entouré d'une équipe composée de personnes relativement très jeunes pour l'aider à accomplir cette mission. Cependant, l'intégrité de certains membres du personnel du DOGE est remise en cause par des révélations sur leur passé.

Edward Coristine est un jeune homme de 19 ans. On ne sait pas grand-chose sur lui. Son emploi au sein du DOGE lui permet d'avoir accès aux réseaux de nombreux services fédéraux, dont la Sécurité intérieure et l'Agence pour la cybersécurité et la sécurité des infrastructures.



Mais Reuters rapporte que deux ans avant de rejoindre le DOGE, alors qu'il était encore au lycée, Edward Coristine dirigeait une entreprise appelée DiamondCDN qui fournissait des services de réseau. En 2023, EGodly a remercié DiamondCDN pour son aide dans un message sur l'application de messagerie Telegram. Le rapport décrit EGodly comme un réseau de cybercriminels qui a revendiqué plusieurs campagnes de cyberattaques et de cyberharcèlement.

« Nous exprimons notre gratitude à nos précieux partenaires DiamondCDN pour nous avoir généreusement fourni leurs incroyables systèmes de protection DDoS et de mise en cache, qui nous permettent d'héberger et de protéger notre site Web en toute sécurité », indiquait le message posté EGodly sur Telegram. Le rapport de Reuters s'appuie sur des documents d'entreprise et des documents numériques examinés par le média et des messages Telegram.

Selon un fonctionnaire interrogé dans le cadre du rapport, Edward Coristine, aussi connu sous le pseudonyme de Big Balls, figure sur la liste des « conseillers principaux » du département d'État et de l'Agence pour la cybersécurité et la sécurité des infrastructures. Des critiques appellent à révoquer ses accès.

Le parcours d'Edward Coristine suscite de nombreuses préoccupations

Edward Coristine semble avoir été inscrit à l'université de Northeastern. Il a également passé trois mois chez Neuralink, la société d'Elon Musk spécialisée dans les interfaces cerveau-ordinateur, l'été dernier. Sur LinkedIn, Edward Coristine se décrit comme un « plombier bénévole (stagiaire) » au sein du gouvernement américain. Elon Musk a défendu le jeune homme dans un message publié sur X en février, déclarant à ses abonnés que « Big Balls est génial ».


Un registre des entreprises du Connecticut montre qu'un Edward Coristine a créé trois entreprises technologiques ou liées à l'informatique dont le principal lieu d'activité est le domicile de New Canaan, dans le Connecticut. L'une d'entre elles, Tesla.Sexy LLC, spécialisée dans les « services professionnels, scientifiques et technologiques », semble toujours en activité. Tout reste flou et Edward Coristine a refusé de répondre aux demandes de commentaire.

Sur Github, il est présenté comme le seul « membre » de DiamondCDN, maintenant été dissous. D'après un rapport de CNN, Edward Coristine avait été renvoyé de son stage dans une société de cybersécurité de l'Arizona après avoir été soupçonné d'avoir divulgué des informations confidentielles à un concurrent.

Récemment, un employé du DOGE chargé a enfreint la politique du département américain du Trésor en faisant circuler une feuille de calcul contenant des informations personnelles à d'autres personnes de l'administration Trump, selon le dépôt d'un dossier au tribunal par un fonctionnaire fédéral.

Le DOGE a été jusque-là secoué par une série de scandales qui remettent en cause la fiabilité et l'intégrité du personnel de l'agence dirigée par Elon Musk. La sécurité des informations auxquelles Elon Musk et ses sbires ont accès suscite des inquiétudes. Un juge fédéral a récemment ordonné au DOGE de supprimer les données personnelles extraites de la Sécurité sociale. L'ordonnance bloque aussi l'accès illimité du DOGE aux dossiers de la Sécurité sociale.

Le département d'État n'a pas répondu aux messages concernant Edward Coristine. La CISA, qui est chargée de protéger les réseaux du gouvernement fédéral contre les cybercriminels et les espions étrangers, s'est refusée à tout commentaire. Le canal Telegram du groupe EGodly est inactif depuis l'année dernière ; les tentatives de Reuters pour obtenir des commentaires de huit personnes qui ont participé ou interagi avec EGodly ont été infructueuses.

Les agissements d'EGodly ont attiré l'attention des autorités fédérales

EGodly semble être un acteur de la menace prolifique. En 2023, EGodly s'est vanté sur son canal Telegram d'avoir détourné des numéros de téléphone, de s'être introduit dans des comptes de messagerie non spécifiés des forces de l'ordre en Amérique latine et en Europe de l'Est, et d'avoir volé des cryptomonnaies. Récemment, EGodly a diffusé sur Telegram les données personnelles d'un agent du FBI qui, d'après le groupe, enquêtait sur ses membres.

EGodly a fait circuler son numéro de téléphone, des photos de sa maison et d'autres informations privées. EGodly a également publié un enregistrement audio d'un canular téléphonique effectué sur le téléphone de l'agent, ainsi qu'une vidéo, filmée depuis l'intérieur d'une voiture, d'un inconnu passant de nuit devant la maison de l'agent à Wilmington, dans le Delaware. Ils ont été filmés en train de crier par la fenêtre : « Dieu dit que tu es une salope ! ».

L'agent du FBI visé par EGodly a déclaré à Reuters que le groupe avait attiré l'attention des forces de l'ordre en raison de son lien avec le « swatting », une pratique dangereuse qui consiste à lancer de faux appels d'urgence dans le but d'envoyer des équipes d'intervention d'urgence à des adresses ciblées.

Le fonctionnaire a qualifié les membres d'EGodly de « mauvaises personnes ». Une analyse des données numériques effectuée par Reuters a révélé qu'entre octobre 2022 et juin 2023, le site Web d'EGodly était lié à des adresses IP associées à DiamondCDN et à d'autres sociétés appartenant à Edward Coristine. Le rapport indique qu'au cours de cette période, certains visiteurs du site ont été confrontés à un « contrôle de sécurité » de DiamondCDN.

Le rapport n'a pas été en mesure de déterminer pendant combien de temps EGodly a utilisé DiamondCDN, ni si EGodly a payé la société d'Edward Coristine. Des copies archivées du site Web de DiamondCDN indiquent que l'entreprise envisageait d'avoir des clients payants et non payants.

Une autre victime d'EGodly et un chercheur en cybercriminalité qui a suivi le groupe ont déclaré qu'il est composé de « fraudeurs endurcis », citant la composition du groupe et la crédibilité de ses revendications. Tous deux ont demandé à ne pas être identifiés, par crainte de représailles.

Inquiétudes liées à l'accès de Big Balls aux réseaux gouvernementaux

Le rôle d'Edward Coristine au sein du DOGE ou des autres services gouvernementaux n'est pas tout à fait clair. Comme mentionné ci-dessus, il figure sur la liste des « conseillers principaux » du département d'État, de l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) et du département de la Sécurité intérieure. Selon un rapport de Wired, Edward Coristine figurerait aussi sur la liste des « experts » de l'Office of Personnel Management.

Bien que le lien...
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