Connexion
Abonnez-vous

US : le DOGE veut migrer le code de la Sécurité sociale en urgence. Il est écrit en COBOL.

Mainframe

US : le DOGE veut migrer le code de la Sécurité sociale en urgence. Il est écrit en COBOL.

Le DOGE veut migrer les systèmes de la Sécurité sociale des États-Unis en quelques mois. Ces derniers sont codés en COBOL, un langage ancien et désormais peu programmé, mais réputé pour sa robustesse.

Le 01 avril à 10h13

Le « département de l’efficacité gouvernementale » des États-Unis (DOGE) est en train de constituer une équipe pour migrer l’intégralité des systèmes de la Sécurité Social locale en quelques mois. L’idée : se défaire des langages de programmation anciens sur lesquels ces systèmes reposent.

Le risque, comme le rapporte Wired : menacer l’intégrité de la totalité de l’architecture, et les allocations perçues par des dizaines de millions de personnes au passage. En pratique, le fidèle d’Elon Musk Steve Davis travaille déjà à sortir les systèmes de leur dépendance au langage COBOL.

COBOL : 66 bougies

À la suite des censures opérées par le gouvernement Trump, au moins un des sites qui saluait le travail de Grace Hopper est désormais hors ligne. Mais c’est bien cette docteure en mathématiques devenue informaticienne dans la Marine états-unienne qui a créé en 1959, avec les équipes du consortium sur les langages de systèmes de données (CODASYL), le COBOL (Common business oriented language). Comme son nom l’indique, il s’agissait de fournir un langage commun aux applications professionnelles.

Dans les vingt années qui suivent, le COBOL, standardisé en 1968, est adopté dans les administrations, le secteur bancaire, l’aviation, et ailleurs. 66 ans plus tard (et deux ans après sa dernière mise à jour ISO/IEC 1989:2023), il a été délaissé au profit de langages plus simples à manier pour quantités d’applications. Il garde toutefois de fidèles adeptes dans des secteurs critiques, dont les banques ou les administrations (y compris nos impôts ou notre Caisse d'Allocations familiales). En 2020, 80 % des transactions interpersonnelles réalisées aux États-Unis reposaient sur du COBOL, d’après Wealthsimple Magazine.

Les raisons du maintien du langage sont doubles : des enjeux de sécurité et de performance – COBOL a notamment été créé pour gérer rapidement de très grosses sommes de « transactions » – et son usage même, qui concerne généralement des applications centrales, vouées à rester en place une fois créées.

Le problème que cela pose : la pénurie de connaisseurs du COBOL force certaines entreprises à sortir d’anciens programmeurs de leur retraite pour les aider à faire évoluer leurs systèmes. Pour se représenter l’enjeu, des personnes qui sortaient du lycée en 1969 et devenaient programmeuses de COBOL partaient généralement à la retraite à la fin des années 2000, une fois la soixantaine atteinte.

5 ans pour le précédent projet de migration

C’est pour toutes ces raisons que le projet du DOGE soulève des questions. Auprès de Wired, de nombreux experts soulignent qu’une migration de l’ampleur prévue serait, de toutes manières, un projet énorme et risqué – l’infrastructure de la Sécurité sociale contient plus de 60 millions de lignes de codes en COBOL. Sa logique interne – c’est-à-dire les procédés qui fournissent des codes de Sécurité sociale, gèrent les paiements et calculent les montants à verser – est elle-même écrite en COBOL.

Dans le contexte actuel, la Sécurité sociale états-unienne est déjà sous pression : visée par des accusations de fraudes par Elon Musk lui-même – dont plusieurs des allégations se sont néanmoins prouvées, au mieux, trompeuses –, l’institution est spécifiquement visée par d’intenses coupes budgétaires. Depuis quelques semaines, son site web se retrouve fréquemment hors ligne, et l’attente téléphonique s’allonge, au point que le Washington Post parle de « chaos ».

Surtout, de précédents projets de migration ont déjà été envisagés, et la tâche s’avérait alors bien plus ardue qu’un projet de quelques mois. En 2017, l’agence avait elle-même annoncé un projet de remplacement de son système cœur, pour lequel elle cherchait des financements de centaines de millions de dollars. La durée annoncée du chantier, remplacé par des projets plus orientés vers le public en raison de la pandémie, était de cinq ans.

Et puis vient la question de l’efficacité, comme le détaille le journaliste Clive Thompson. Si des acteurs bancaires ou administratifs maintiennent leurs activités en COBOL malgré son ancienneté, c’est bien qu’ils ont pesé les risques. Le langage, on l’a dit, est très rapide. Par ailleurs, un nouveau système créé en quelques mois pour la Sécurité sociale a toutes les chances d’être plein de bugs, donc de planter en de multiples endroits. L’ancienneté du COBOL, en la matière, joue en sa faveur : au fil des décennies, les programmeurs ont eu le temps de débuger régulièrement.

Chez Next, on aimerait bien discuter avec des mainteneurs de mainframes et autres adeptes de COBOL français ou européens. Des contacts à nous recommander ?

Commentaires (132)

votre avatar
Le problème, c'est pas tant d'engager la sortie du langage actuel, vu la dette technique associée, c'est surtout de ne pas faire le nouveau à l'arrache...

Dans un monde moderne du développement où déjà ce qui était autrefois considéré comme beta est devenu la première release, et qui tend même à approcher de l'alpha, les risques sont juste énormes.

Avec un rouleau compresseur comme Musk aux commandes, c'est Grok qui va pondre le code, un gars de 22 ans qui va valider le code et ça sera déployé le mois prochain.
votre avatar
De toute façon, si ça plante, ce sera la faute d' employés DEI woke secrètement payés par Georges Soros...
votre avatar
Et ça va se faire hacker en combien de temps ?
votre avatar
Vu la compétence de l'équipe, la réponse est en ms. :bravo:
votre avatar
Je pense que nous avons tous pris l'habitude, depuis quelques années, que tout ce qui sort, que ce soit des logiciels ou jeux, n'est de toute manière jamais terminé à la sortie. J'ai comme le pressentiment que ça va encore être foireux.
votre avatar
Tu peux rajouter aussi le reste (voitures, etc.).
Vive la méthode agile ✌️
votre avatar
Tout à fait.

Cependant, l'idéologie néolibérale de notre monde économique veut que tout aille plus vite tout le temps (croissance infinie à accélération positive) : la R.A.C.H.E. n'y est donc jamais bien loin.

Le technologisme veut surtout rapporter tout les problèmes concernant de la technique à des problèmes techniques, quand bien même l'écrasante majorité des problèmes lors d'une évolution en groupe de toute taille relève généralement du domaine humain.
Les plus gros débiles, dont ceux du DOGE dans le cas présent, ignorent volontairement cela et se permettent toutes formes de violence afin d'aller plus vite en ne raisonnant qu'en termes mécaniques/techniques et/ou économiques/financiers : le néolibéralisme amenant au fascisme, démonstration éclatante non seulement de la compatibilité de cette idéologie avec un régime autoritaire… mais aussi et surtout tout simplement de sillons qu'elle creuse y menant tout droit !

Les 5 ans évoqués dans l'article ne m'étonnent pas, et je ne suis pas sur que le volume de lignes de code permettent de se faire une bonne idée de la complexité du système.

Car la Sécurité Sociale n'a fait que transposer au cours du temps des règles changeantes, plus ou moins précises, amenant à décider de manière plus ou moins déterministe l'ouverture ou non de certains droits… je pense que même d'un point de vue strictement fonctionnel, ce qui doit être fait est loin d'être clair et déterministe : il doit y a voir de sérieux cas de conflits, de contresens, et de résultats différant en fonction du chemin pris.

Quand bien même ce qui doit être fait serait clair, l'implémentation va dépendre énormément du langage, et rien ne dit que transposer la logique COBOL dans un autre langage est une mince affaire : je ne connais pas ce langage, mais je sais déjà qu'une telle transposition entre d'autres langages croisés peut tout simplement être cauchemardesque. Et vu son âge, les principes sous-jacents doivent être bien éloignés des standards de langages, même apparus dans les années 1980 (15/20 ans plus tard à l'époque), sans même parler des plus récents.

Enfin, il faut bien envisager la qualité du code, certainement éloignée de l'implémentation idéale : du code aux fonctionnalités simples, tout à fait récent, écrit sans qualités particulières d'architecture logicielle (voire en supposant leur absence), nécessite déjà un effort en temps important pour être amélioré.
Alors que penser d'un code dépassant les 60 ans, quand les notions d'architectures logicielles et les "standards" étaient soit inexistants, soit très éloignés des actuels…

La volonté d'aller vite ressemble furieusement à défoncer un mur à pleine vitesse sans se préoccuper des conséquences, car c'est le mur que l'on souhaite franchir.
Dans le meilleur des cas, j'entrevois une casse du système social sur laquelle une couvercle sera érigé, car fondamentalement, n'oublions pas que ce gouvernement-là n'a que faire de l'aide sociale.
Dans le pire des cas, un fiasco le mettant à l'arrêt purement et simplement, justifiant ainsi sa disparition sans autre forme de procès.

Une once d'humanité permet pourtant de se dire que si l'objectif n'était pas la violence d'un pouvoir dont des débiles sont ivres, alors la tâche pour améliorer cette chose est immense.
Si cela était mené par des humanistes, ce serait pourtant un projet qui pourrait être magnifique, et un beau succès inspirant rayonnant dans le monde.
votre avatar
"Chez Next, on aimerait bien discuter avec des mainteneurs de mainframes et autres adeptes de COBOL français ou européens. Des contacts à nous recommander ?"

L'invité d'une des vidéos de Micode qui traite le sujet du COBOL ?
votre avatar
Ah ben tiens, les grands esprits se rencontrent ^^ Je viens justement d'envoyer un mail à l'équipe avec le nom de cette personne (Gaetan ROELENS)

edit : lien vers la vidéo d'Underscore : youtube.com YouTube
votre avatar
Vous pouvez aussi tenter de contacter des profils linkedin employés chez Euro Information Développement (EID). C'est la filiale technique du Crédit Mutuel et ils ont une grosse partie de leur infra en Cobol.
votre avatar
comme toute les grosses banques (Crédit Agricole, BNP, BPCE, ..) :fumer:
Dans ferroviaire ou l'aérien doit y avoir des gens de chez ADP et/ou Air France, à la SNCF c'était encore utilisé pour le fonctionnement et la circulation des trains.
votre avatar
Ce n'est pas plutôt l'ADA pour tout ce qui est ferroviaire ?
votre avatar
L'ADA c'est pour Ariane 🚀
votre avatar
Sur les routes plutôt LADA : fr.wikipedia.org Wikipedia :transpi:
votre avatar
Le fait d'avoir vu cette vidéo il n'y a pas longtemps a renforcé mon idée que ce langage a largement encore sa raison d'exister, l'invité met justement en évidence la stabilité du code dans le temps, sa lisibilité, ... et que c'est très con de rejeter le cobol "parce que c'est vieux et prévu pour les cartes perforées". Au contraire c'est très performant, très verrouillé pour éviter les déboires habituels (bugs, hacks, ...), et on peut ensuite l'interfacer avec des trucs jolis si on veut.
Le problème c'est pas la dette technique mais le manque de développeurs actuels. Ca serait plus intelligent de former des gens pour ces langages ultra stables et parfaitement adaptés au besoin plutôt que de refaire des usines à gaz qui ne seront probablement pas mieux, demanderont 10 ou 100 fois les ressources matérielles et probablement humaines pour le suivi et les mises à jour.

Bordel, si un jour à la sortie de ma formation informatique on m'avait dit que j'en viendrait à soutenir le cobol, je ne l'aurai jamais cru :reflechis:
votre avatar
C'est ce qu'à fait Sopra (et fait ptet tjs). Il y a 10-15 ans, ils recrutaient des personnnes en recherche d'emploi avec des profils bac+5 pour les former au cobol.
votre avatar
En gros on a un contrat de travail tous les 25 ans... ma dernière édition de chaînes date de 1999 avec les mises à jour pour le bug de l'an 2000 dans les banques :D

Si on avait de l'ADA en plus, on croirait presque être un 1er avril...
votre avatar
Ada ne serait pas si idiot que cela : c'est un des rares langages qui manipule nativement les nombres en virgule fixe. Et une grande banque suisse l'a utilisé. La sécurité apportée ne serait pas de trop quand on voit le fonctionnement de certains établissements financiers.
votre avatar
Elon Musk, adepte du Yakafokon, tant que ça ne l'impacte pas personnellement (et au passage, ils feront de grosses économies avec toutes les sommes qui ne seront plus versées dès que le nouveau système sera en rade, soit quelques secondes après avoir été lancé)
votre avatar
Il peut y avoir aussi des trop perçus, les gens lésés par des sommes plus faibles perçues vont-elles descendre dans la rue ? Je ne pense pas
votre avatar
ils vont demander à Grok et zou c'est dans la boite :troll:
votre avatar
Ils vont demander https://lovable.dev/ (on me dit dans l'oreillette que non c'est européen), mis en prod le lendemain et hacké trois jours après
votre avatar
Et surtout pour remplacer par quel langage ? Du javascript ? :fume:
votre avatar
C'est ca :D
Le COBOL, c'est un langage ancien, mais encore très loin d'être obsolète. Et surtout extrêmement stable, qui n'a pas besoin de 18 évolutions incompatibles entre elles pour évoluer.
votre avatar
À priori en Java :
https://www.wired.com/story/doge-rebuild-social-security-administration-cobol-benefits/
votre avatar
J'avais pris ça pour une blague quand j'avais vu la vidéo, mais en fait c'est la réalité. Punaise.
youtube.com YouTube
votre avatar
Le short aurait pu être un PA, étant donné qu'on n'a pas la date de sortie. Mais étant donné que dans le short ca parle d'un article sorti le 30 mars... https://futurism.com/elon-musk-rewriting-social-security-code-ai
votre avatar
Le JAVA sert déjà en tant qu'interface pour les banques, mais derrière c'est toujours du COBOL... Parce que JAVA n'est pas adapté pour les calculs en virgule fixe, en plus d'être régulièrement obsolète (contrairement à COBOL). Musk prouve encore une fois être un génie visionnaire!
votre avatar
Un exemple ?
Ptet que ce n'est pas seulement le langage, mais aussi la machine qui sait faire ou pas.
votre avatar
Il me semble que le java tourne dans une sorte de VM mais qu'on peut aussi le compiler pour un CPU natif pour la rapidité.
Donc a priori, aucun rapport avec la machine. Du java doit donner le même résultat quel que soit l'OS ou le matériel.
votre avatar
mais qu'on peut aussi le compiler pour un CPU natif pour la rapidité.
JNI ? Si tu veux un truc avec une syntaxe imbitable pour faire du quasi C dans du Java, c'est la bonne solution. Après, faut pas se plaindre si c'est instable et in-maintenable.
votre avatar
Il y a bien plus récent et maintenable que JNI pour avoir des performances natives en Java. Cela s'appelle GraalVM et cela compile le code Java en un binaire natif. Un Framework comme Quarkus permet de faire cela très facilement.
votre avatar
En fait, je répondais à Patch.
votre avatar
Exemple d'obsolescence de JAVA? Simple : les différentes versions qui ne sont pas compatibles entre elles, au point de devoir en avoir plusieurs sur une même machine pour faire fonctionner différentes applis. Et toutes ne sont pas forcément à jour niveau sécurité, surtout si ca ne concerne pas la dernière version en date.
votre avatar
au point de devoir en avoir plusieurs sur une même machine pour faire fonctionner différentes applis
Un peu comme python2 et python3 dans certaines distributions Linux...
votre avatar
Comme le dit @serpolet, c'est valable pour d'autres langages. Je dirais même que c'est valable pour tous les langages et framework. Windows, Linux : même combat.

Java possède des APIs pour ce genre de calcul. À chacun d'être au courant et de l'implémenter ou de se refaire un truc à sa sauce. C'est encore valable pour tous les terrains de jeu. Ex: ici et d'autres si on se donne la peine de chercher.

Mais ce n'est pas là où je voulais en venir.

Ce genre de calcul en virgule fixe n'est pas forcément le fait du langage, mais éventuellement de la machine. Ce n'est pas forcément le Cobol qui fait ces calculs à partir de nombre encodés en binaire, mais plutôt la compilation à partir du Cobol qui utilise des instructions processeur dédiées à ce genre de calcul.

Instructions qui savent traiter des représentations différentes de la sacrosainte représentation binaire. Et même d'avoir des choix de comportement pour ses instructions au niveau des arrondis par exemple. C'est un peu le même principe que l'accélération matérielle.

Donc un genre de processeur qui sait faire nativement... Au pif comme ça : IBM i et ses Px (P8, P9, P10, etc.). International Business Machine ; avec "Business" AKA comptabilité.

Ces systèmes sont bien évidement là où le Cobol tourne en grande majorité. C'est même un peu con de faire du Cobol sur un PC (quoique pas interdit ni impossible). Et bien évidement ce sont très souvent des genres de boites qui ont besoin d'un truc qui sait faire de la comptabilité de manière quasi native qui vont jeter leur dévolu dessus. Banque, assurance, escrocCorp, etc.

Je ne serais pas aussi catégorique sur le fait que ce soit toujours du Cobol derrière. Sur ces systèmes existe d'autres langages sachant exploiter la puissance de ces CPUs. Quoique je serais plutôt enclin à appeler ces processeurs des DbPU. L'approche d'IBM a été de faire une BDD et de construire la machine autour. Un peu comme de poser l'autoradio avant de créer la voiture. Sauf que dans le cas d'IBM i la puissance de la DB arrache tous les autres sur place (même une DB mal conçue et dieu sait qu...).
votre avatar
Ca l'est toujours. Et les banques sont emmerdées, maintenant qu'elles ne trouvent plus grand monde pour traiter du COBOL. Au point que si on maîtrise COBOL et JAVA, on est le roi du pétrole.
Ca en parle dans l'interview d'un coboliste par Underscore : youtube.com YouTube
votre avatar
Eh bien... Je suis certain qu'il n'y pas que du Cobol dans ces enseignes. Accordons-nous sur un désaccord de vécu. C'est souvent le fait que les clients qui se ressemblent sur le plan technique atterrissent chez les mêmes prestataires (ESN). Groupe A chez Alpha, groupe B...

Concernant cette nouvelle remarque. Le marché de l'emploi étant très con. Ainsi que l'entreprise dans son comportement. Les rois du pétrole ont du fil à retordre à mon humble avis.

Ces ambiances d'entreprise ont fait que les plus vieux sont partis à la retraite avec un doigt majeur levé.

Les plus jeunes qui arrivent font des burn out rapidement. Ceci pour toutes les mauvaises raisons qui peuvent jalonner le parcours d'un développeur saint d'esprit (au départ).

Aussi, ces jeunes à qui on apprend l'orthographe ne deviennent pas des poètes au sortir de formation. Loin de là. Ils rajoutent donc à la problématique par le fait de leur manque de maturité.

Reste les 'petits jeunes' chez les Coboliste. Donc un type d'au moins 40 ans. Eh bien, c'est tout simplement pas le profil recherché à cause de la bêtise crasse des RHs desdites boites.

Donc d'un côté, on a :
* Une enseigne qui est capturée dans le framework faute d'avoir suivi correctement les projets et d'avoir fait évoluer la chose. Faute de manager compétents ou ne voulant prendre aucun risque sur le temps où ils restent (~2 à 5 ans).
* Des départs à la retraite de la vieille garde avec plus ou moins de dettes techniques dans les soutes.
* Des jeunes qui, lorsqu'ils voient le bousin, se font vite du stress au point de se barrer assez vite ou de partir en sucette.
* Des RHs qui cherchent des jeunes à tout prix. Car plus malléables. Au contraire du besoin de personne plus mature qui eux pourraient bien changer la donne. Mais pas pour le même prix.

N'est pas roi du pétrole qui veut.


PS: J'avais déjà vu l'interview. À mon humble avis, l'interview ne représente pas l'ensemble du panorama, bien qu'elle apporte de bonnes information quand même.
votre avatar
Pour la dernière partie, on est bien d'accord, surtout côté RH... Je me souviens encore d'une annonce d'emploi pour un poste de dév Android dans je ne sais plus quelle boîte, rédigée par des RH, qui demandait mini 10 ans d'XP dév Android... Qui n'avait que 8 ans d'existence à l'époque :]

Mais pour COBOL, le fait que les jeunes se barrent vite vient toujours du fait qu'il manque énormément de personnel, et qu'il y a donc bien trop de boulot (et donc départ rapide ou burn out comme tu l'as évoqué). Et le cercle vicieux continue de plus belle vu qu'il n'y a toujours pas de formation en masse.
votre avatar
Moi je dis : 0C7. A l'époque, ça se debuggait à la mimine, le COBOL. Sinon, pour aujourd'hui, on peut aussi tenter un site web responsive design en FORTRAN, un article de presse sans IA, etc. :-D
votre avatar
Effectivement, il y a encore du boulot pour l'Agent 0C7. Moi je reste en IEBFR14.
(Je suis passé du côté fonctionnel, je ne suis pas à jour sur les API :) )
votre avatar
Que de souvenirs...
Dans ma boîte, on fait encore de nouveau pgm.
Un des premiers assureurs automobile
votre avatar
B37 : touché coulé

Que de souvenir de ces codes erreur :D
votre avatar
Chez Next, on aimerait bien discuter avec des mainteneurs de mainframes et autres adeptes de COBOL français ou européens. Des contacts à nous recommander ?
Je pense que votre pigiste Jean GEBAROWSKI est un bon point d'entrée pour trouver des contacts. D'après son profil LinkedIn, il a même dû pratiquer le COBOL en début de carrière ou y être confronté de près.

Édit ; et comme par hasard, il commente une minute avant moi, le temps que je vérifie mon intuition (et que je retrouve son nom que j'ai du mal à mémoriser).
votre avatar
Grillé, maintenant j'ai ton nom :windu: et mon nom est pas compliqué, j'ai juste eu moins de chance que ma femme (vu que son prenom est IA). Note : j'ai aussi eu une étudiante qui s'appelait Petya.
votre avatar
Me dis pas que son nom c'était Wiki.
votre avatar
Remplacer un système performant qui fonctionne (et qui a passé les certifications) pour un truc pondu à l'arrache comme tous les produits de Musk, je me demande ce qui pourrait aller mal.
votre avatar
Après quelques explosions, ça fonctionnera aussi bien que ses fusées.
votre avatar
Je demande à voir.
votre avatar
Pour se représenter l’enjeu, des personnes qui sortaient du lycée en 1969 et devenaient programmeuses de COBOL partaient généralement à la retraite à la fin des années 2000, une fois la soixantaine atteinte.
lycée en 1969, normalement à 17 ans => né en 1952. Retraite à 60 ans au plus tôt => 2012. Donc un peu plus que la fin des années 2000.
Mais surtout, ce ne sont pas les seules personnes qui ont pu apprendre le COBOL.

Le COBOL n'est pas un language très difficile à apprendre, mais il n'est pas des plus passionnants à pratiquer, en fait, c'est l'informatique de gestion pour lequel il est fait qui n'est pas très passionnante.
Il a par contre l'avantage d'être facile à lire même par des non informaticiens : il est facile de comprendre les calculs qui sont faits.
Trouver des gens pour programmer/maintenir des programmes en COBOL est simple : il suffit de les former puis de les payer assez cher pour qu'ils soient motivés.

Quant à la performance du COBOL, je ne voyais pas pourquoi il était dit plus performant, en fait c'est que dans la brève de Sébastien, il était comparé à JAVA qui n'est pas compilé en code natif mais en bytecode interprété par une machine virtuelle. On a tout un tas de languages qui n'ont pas ce défaut et qui auront des performances équivalentes.
votre avatar
Du point de vue de performance, c'est surtout au niveau des calculs en décimale fixe, si j'ai bien compris ce que j'ai lu/vu ici et là. Alors que la plupart des autres langages se sont spécialisés sur les floats.
votre avatar
Pas seulement bon sur le calcul simple, il tourne sur des machines qui sont optimisées pour gérer un trétra paxon d'utilisateur en //
votre avatar
OK, mais là, ce n'est plus le COBOL dont il est question mais l'hôte. Il est de fait que les mainframes (si on peut encore les appeler ainsi) qui font tourner du COBOL ont été optimisés au fil du temps à son usage. Et inversement, le COBOL a été "ajouré" en fonction des évolutions.

C'est un macrocosme entier.

Autant, le COBOL me rebute. Dès mes écolages, j'ai jamais vraiment aimé la verbosité et la rigueur d'encodage. J'en avais encore fait à la fin de mon précédent job car personne ne voulait ou pouvait coder en COBOL 74/85 alors (oui, c'était pour un ancien système IBM dans le monde le finance publique)

Mais ce qui est est. On ne peut pas balayer d'un revers de main le passif COBOL comme le fait le DOGE...
votre avatar
Un instant, j'ai cru à un poisson d'avril...
Scoop : Trump ordonne la réécriture de toutes les lignes du code Apollo ayant été écrites par des femmes !
votre avatar
Mais c'est peut-être un poisson d'avril ?
Tout ça c'est des fakes NEWS XD
votre avatar
Pareil :stress: Cette journée est un vrai challenge
votre avatar
Une système qui gère les droits sociaux de millions de personnes, un vieux code en Cobol qui risque d'être réécrit par une IA ...
Qu'est-ce qui pourrait mal tourner ?
À part impacter négativement des personnes sans doute déjà dans la précarité ...
votre avatar
Sans avoir été beaucoup plus loin qu'un hello world en COBOL, une fonctionnalité majeure de ce langage qui va se perdre par rapport à l'immense majorité des langages modernes : les nombres à virgule fixe, par opposition aux flottants.
En cobol, 1,1 + 2,2 = 3,3.
Alors que si je prends Python par exemple :
In [1]: 1.1 + 2.2 == 3.3
Out[1]: False

Et ça, ça peut faire très mal. Bien sûr des bibliothèques sont disponibles pour gérer ça correctement, mais c'est tout de même plus difficile que si c'est intégré au langage, sans ce type de filet de sécurité, avec une migration suivant la méthode La Rache, on peut préparer le pop corn...
votre avatar
C'est pas plutôt un problème de base de représentation (binaire par défaut en Python vs décimale probablement en Cobol) ?

Tu peux d'ailleurs faire du décimal en Python avec le module standard decimal :
>> from decimal import Decimal
>> Decimal("1.1") + Decimal("2.2") == Decimal("3.3")
True
votre avatar
Exactement ce que je dis : "des bibliothèques sont disponibles pour gérer ça correctement".
Mais de base en Python 1.1 c'est un nombre flottant sans decorum. Oui avec decimal on peut le gérer, mais c'est un effort et c'est donc contre-intuitif.
J'aurais pu faire ce même exemple avec Java, C, C++, C#, Perl, PHP.
Au passage en Python decimal utilise en interne https://www.bytereef.org/mpdecimal/, une implémentation certes rapide, mais je serais curieux de voir sur un mainframe un benchmark entre un programme utilisant mpdecimal et un programme COBOL faisant les mêmes opérations.
votre avatar
ouais enfin bon, il suffit de tout multiplier par 100 et de rester en integer non ?
votre avatar
Non. Parce que on peut avoir besoin de calculer avec plus que 2 décimales.
votre avatar
C'est une news qui sentait très fortement le poisson, mais l'article de Wired est daté du 28 mars... Du coup, je ne sais pas quoi en penser.
votre avatar
pas un poisson d'avril !
votre avatar
Certes, mais si ça a l'air d'un poisson d'avril, c'est dire le niveau de sérieux du truc.
votre avatar
En prime pour remplacer le COBOL par du JAVA (pas un PA non plus)...
votre avatar
Un autre point qui n'est pas abordé, c'est qu'au fil des années la connaissance du métier (du fonctionnel) est diluée. A tel point, qu'en exagérant, elle n'existe plus que dans le code COBOL.
Lire la réglementation et tous les décrets, ne permet pas de reconstruire un système au comportement identique.
Exemple : certains décrets "temporaires" et expirés sont encore actifs dans le COBOL et les faits.

Et ce problème majeur ne dépend pas du COBOL.

Donc, nous sommes prudents dans nos réformes IT.
DOGE va peut-être se moquer du comportement existant, et à ce titre pourrait réécrire plus rapidement.
votre avatar
Le code est là pour représenter "numériquement" les textes législatifs.
Se planter dans une règle de gestion c'est contrevenir à un texte de lois. De là à penser que le DOGE puisse en profiter pour outrepasser la loi, m'enfin ils savent ce qu'ils font.
votre avatar
Aujourd'hui en France, des programmes de la sécurité sociale ne respectent pas toute la loi, par exemple il y a des décrets expirés et toujours appliqués.
Les assurés concernés et les professionnels de santé, tous s'attendent que ce comportement continue. Tout le monde a oublié l'expiration du décret original. Revenir à la loi déstabiliserait un secteur, une profession, un territoire ou les assurés.

Un DOGE qui coderait les décrets, rien que les décrets, serait dans la loi, irait vite, mais casserait les usages.

Après si le gouvernement est aussi en mode start-up, il peut légirer rapidement pour réparer les soucis... DOGE coder immédiatement. Et la situation s'améliorer "rapidement".

Cependant, c'est du social et les victimes les plus fragiles de ces ajustements pourraient ne pas faire face aux difficultés créés par la refonte. En santé, elles pourraient perdre une chance de guérison. Ce qui ne serait pas social.

La difficulté n'est pas de coder du métier, même rapidement, la difficulté c'est de maintenir le soutien social.

Mais comme le social n'est pas la priorité de DOGE, ils devraient y arriver, faire des économies, au prix de quelques erreurs et ajustements.
Ceux pris dans ces erreurs devront assurer financièrement, le temps de l'ajustement. Les plus fragiles, ceux qui dépendent du "bouclier" social et qui vont (temporairement) le perdre, vont vraiment souffrir.
votre avatar
Encore une fois avec le néofascisme ricain (pardon, les "disrupteurs 3.0"), crasher le bordel fait partie de la mission. Si tu remplaces par un truc qui marche ou que tu laisses le truc actuel en place, tu continues à payer les alloc qui vont bien, à rembourser les gens, etc... Alors que l'objectif est justement de sucrer de façon indiscriminée des thunes aux plus pauvres/fragiles/en galère. et donc de faire pression.

Dans une news vaguement liée, le DOGE a maintenant accès en écriture aux données de paiement des salaires des fonctionnaires et a déjà commencé à pas verser les salaires de certaines personnes qui leur ont timidement rappelé la loi.

Avoir le même pouvoir sur la sécu est juste un moyen de pression supplémentaire.
votre avatar
Dans ma boîte ce sont des spécialistes Cobol qui sont dans des environnements Z/OS et qui utilisent des base DB2.

Bienvenue dans les années 80 😁
votre avatar
Tiens ? De l'Informatique ...
Ça me rappelle les belles lignes régulières, au format imposé par l'héritage des cartes perforées, qui sortaient de la Logabax lx180 (imprimante à aiguille), noircissant le papier listing accordéon de milliers de lignes de GAP2...
Souvenirs
[reniflement nostalgique]
votre avatar
Tout pareil :)
Ah, on en a aussi sur AIX remarque.
Perso j'en ai fait un trimestre à l'IUT, j'ai pleuré et me suis promis de ne plus en refaire. Trop de ligne pour faire une addition:D. Suis passé en seconde année option IA, système et réseau.

Mais ceci dit, comme pour le Z, un jeune motivé peut faire une belle carrière. Pas prêt de mourir et très peu de profils...
votre avatar
Encore une fois avec le néofascisme ricain (pardon, les "disrupteurs 3.0"), crasher le bordel fait partie de la mission. Si tu remplaces par un truc qui marche ou que tu laisses le truc actuel en place, tu continues à payer les alloc qui vont bien, à rembourser les gens, etc... Alors que l'objectif est justement de sucrer de façon indiscriminée des thunes aux plus pauvres/fragiles/en galère. et donc de faire pression.

Dans une news vaguement liée, le DOGE a maintenant accès en écriture aux données de paiement des salaires des fonctionnaires et a déjà commencé à pas verser les salaires de certaines personnes qui leur ont timidement rappelé la loi.

Avoir le même pouvoir sur la sécu est juste un moyen de pression supplémentaire.
votre avatar
Je ne suis pas certain que ce soit bien la news du premier avril :stress:
votre avatar
Ce n'est pas une news du 1er avril, je confirme...
https://futurism.com/elon-musk-rewriting-social-security-code-ai
votre avatar
Alors que dans le même temps GCC 15 arrive avec un frontend Cobol...
votre avatar
Va falloir lancer la news connexe de ce jour particulier: "Musk lance ses Dumb-Kids) pour passer le noyau Linux de C à Rust en un mois!"
:roule2:

PS: Bug niveau liens, le ')' final se mélange les pinceaux avec celui du format... Pas possible d'ajouter un \ ou autre truc usuel pour lui faire bouffer un lien OK...
votre avatar
coder la parenthèse fermante par & # 41 ; (sans les espaces), mais oui, c'est relou.
Ça donne ça
votre avatar
remplace la parenthèse ")" de l'url par %29

edit : encore grillé (ça n'arrête pas en ce moment), mais moi c'est mieux parce que c'est de l'encodage pour url UTF-8 et pas simplement html :langue:
votre avatar
Plutôt qu'aller chercher des retraités pour le maintenir (ce qui repousse le problème à plus tard), pourquoi ne pas leur demander de former de nouveaux jeunes ? Il suffit de bien les payer, mais quel que soit le salaire ça sera toujours moins cher que tout refaire.

Le principal risque est la dispo de la main d'oeuvre. Il n'y a donc aucune raison technique (notamment de performances ou de sécurité) qui justifie ce choix de changer.
votre avatar
Mais mon bon monsieur, il n'y a plus d'argent dans les banques et les assurances, alors on fait réaliser les développements en Europe de l'est, au Maghreb et en Inde. On va pas payer cher des développeurs français... :mad2:
votre avatar
C'est ça qui est beau avec le "trumpisme", le 1er avril c'est quasiment tous les jours.
Ceci étant, l'intention reste cohérente : réécrire l'histoire, réécrire le code, réécrire le principe de la "démocratie" ...

edit : cette illustration de Flock conserve cette justesse imparable à chaque publication.
votre avatar
En effet. C'est d'ailleurs pourquoi Lapresse.ca ne fera pas de PA cette année, pour la même explication que toi :
https://www.lapresse.ca/actualites/chroniques/2025-03-30/le-poisson-d-avril-est-devenu-notre-realite.php
votre avatar
EDIT: double post
votre avatar
Franchement, pour faire du cobol quotidiennement sur z/os et as400 depuis des années, c'est un langage plutôt simple. Après ça ne nous empêche pas de monter des usines à gaz 😂
Mais ce n'est pas tant le langage qui est un problème que les règles metier et techniques qui finissent par être oubliées...
Et avoir un vieux code, c'est à la fois un code qui a été éprouvé mais aussi un code plein de verrues pour répondre aux évolutions diverses.
votre avatar
C'est ça le problème, des verrues dans tous les sens, et du code peu ou pas commenté/documenté
votre avatar
Je suis impressionné par la taille de 60M de lignes de code, c'est immense. Je suppose qu'il y a beaucoup de technique, mais la complexité legislative doit etre un de ces fourre tout. Au bout d'un moment des règles de gestions - fines mais + simples seraient les bienvenues
votre avatar
On n'arrive même plus à savoir si c'est un article poisson d'avril ou pas tellement l'actu est Gorafisée.
Je ne sais que penser.

Peut-être que si le système plante, les gens se réveilleront sur les guignols à leur tête.
Et encore...
votre avatar
Un petit mot sur les perfs du COBOL : Java fait du bytecode tournant sur une JVM qui doit gérer la mémoire (processus long et coûteux en CPU, en général) dans les multiples appels dans les couches qui se superposent comme un mille-feuilles (z'avez déjà vu un dump Java ?). Donc vous multiplies les appels systèmes coûteux en empilant des couches... On ne peut pas attendre des perfs de compétition avec ça. Côté lisibilité, c'est guère mieux, le code étant réparti dans plein de morceaux (certes, on peut aussi écrire comme un cochon en COBOL ou dans n'importe quel langage). Pour moi, Java est très mauvais quel que soit l'usage, on peut faire beaucoup performant, réutilisable et clair avec d'autres langages. Le seul intérêt de Java était son interopérabilité annoncée mais en pratique c'est un désastre (il faut parfois multiplier les versions de JVM sur une même machine pour faire tourner correctement le bousin).

Pour revenir à COBOL, la compilation revient quasiment à traduire le code COBOL en langage machine ; la gestion de la mémoire est décrite de façon déclarative (surtout dans les vieux COBOL et donc dans les vieux programmes qui constituent une partie non négligeable de l'existant). Résultat : un programme bien pensé tourne très vite et sans problème de gestion de mémoire. Donc réécrire du COBOL n'est pas rentable, a priori, surtout qu'effectivement la "logique" (les règles de gestion) risquent de souffrir d'une traduction (automatique ou pas, d'ailleurs) dans un autre langage.

Plus il y aura de code source à traduire, plus la traduction risquera d'être truffée d'erreurs. Or ce qu'oublient nos amis du DOGE (et d'autres...) c'est que la qualité du code produit est liée à la qualité du résultat et des tests ! Je pense aussi, pour comparer, aux programmes de calculs scientifiques qui mettent disons 1 heure à tout calculer mais qui prennent des jours ou des mois à vérifier. Partant du principe qu'une IA fera forcément des erreurs mais sans qu'on sache où, le résultat risque d'être d'une précision... comment dire... trumpienne.

next.ink Next
votre avatar
Petite question. Étant donné que Cobol n'utilise pas les nombres flottants et ne peut donc pas avoir accès aux unités flottantes des CPU modernes, comment est-ce gérer au niveau langage machine ?

Les mainframes disposent de CPUs avec des unités spécialisées à ce type de calcul ? Ou bien le compilateur COBOL contient ce qu'il faut pour ce genre de calculs à la manière des libraires type MPC ?
votre avatar
Pourquoi voudrais-tu utiliser des flottants, avec des erreurs d'arrondi à chaque étape, pour gérer du pognon ?
votre avatar
Parce que tant que ça augmente mon solde, ça me va :D

Blague à part, ce n'était pas le sens de ma question. Ma question porte sur comment le compilateur Cobol gère les nombres décimaux en langage machine par pure curiosité.
votre avatar
Il y a plusieurs représentations des nombres en cobol.
Les comp-1 et comp-2 sont des formats à virgule flottante sur 4 et 8 octets. Mais on les utilise rarement, historiquement on leur préfère le format comp-3 qui est aussi compris nativement par le processeur, il stocke le nombre en BCD (Binary Coded Decimal) qui a l'avantage d'être lisible directement en hexadécimal :
(0102030C)comp-3 = + 102030 (le dernier caractère C indique un nombre positif, D négatif)
(1234567D)comp-3 = - 1234567
votre avatar
J'avais oublié cette histoire de BCD :roll:

Merci pour le rappel.
votre avatar
https://www.tiktok.com/@ditespourquoiadultes/video/7487842003842075926?_r=1&_t=ZN-8vAwsXPqoKc
votre avatar
Cela fait un moment que tu n'as pas dû faire de Java. Sans dire que c'est le meilleur des langages, c'est loin d'être le pire. Les dernières versions ont bien amélioré les choses et depuis que l'on peut compiler en natif via GraalVM, les performances ne sont plus un problème. Le problème ici n'est pas tant le langage choisi que la manière complétement abrutie de procéder. Tu pourras prendre tous les langages existants, réécrire 60 millions de lignes de code probablement pas vraiment testé et avec des spécifications lacunaires, le tout en quelques mois, cela sera forcément un désastre.
votre avatar
Beaucoup d'entreprises restent bloquées sur du HotSpot traditionnel pour des raisons de coût, de compatibilité, et surtout parce que les grandes entreprises (hors Tech) sont assez frileuses pour changer qqch qui marche, même si ça n'est pas parfait et, dans le contexte mentionné, il y aura forcément un énorme travail d'optimisation à produire rien que pour ça. Mais on est d'accord que la traduction d'un langage à l'autre sans objectif réel et concret va aboutir sur une boucherie sans nom, indépendamment des questions de performance.
votre avatar
Quand je travaillais chez BNP Paribas les programmeurs COBOL m’ont dit: « ne laisse jamais personne t’apprendre le COBOL. Sinon tu vas en faire toute ta vie. »
votre avatar
Plus tard, lors d’un entretien d’embauche dans une société de service:
* Je vois un trou de 2 ans dans votre CV, qu’avez-vous fait?
* J’étais au chômage, n’allez pas croire que j’ai développé en COBOL pendant cette période.
votre avatar
Musk veut faire réécrire une infra de COBOL vers Java? Ça rappelle quand il a voulu migrer l’infra de Paypal d’Unix (lequel?) vers Windows: selon Fortune (et d’autres sources), c’est pour ça (ou une des raisons) qu’il s’est fait virer du poste de CEO.
Musk became CEO of the combined company and decided it was time for a technological overhaul. Specifically, he wanted to toss out Unix and put everything on a Microsoft platform.
That may sound innocent enough to laypeople but not to Unix zealots like Levchin and his team. A holy war ensued. Musk lost. The board fired him and brought back Thiel while Musk was on a flight to Australia for his first vacation in years.
votre avatar
Ici c'est juste parce qu'il est passé pour un con avec les gens né en 1875 et qui sont dans le système.

Alors que c'est juste une date de naissance inconnue (donc "null") qui est traduit par une date de naissance 20/05/1875 (l'EPOCH de COBOL)

Mais merci pour le rappel de cet article :yes:
votre avatar
Chez Next, on aimerait bien discuter avec des mainteneurs de mainframes et autres adeptes de COBOL français ou européens. Des contacts à nous recommander ?
Si ça vous intéresse, à une époque en France il y avait Metaware qui se spécialisait dans la conversion de systèmes anciennes, notamment en COBOL, vers des technos plus modernes. Ils ont été rachetés par Inetum, je ne sais pas trop ce que c'est devenu ensuite.
votre avatar
C’est un chantier colossal. Et pas juste parce que c’est en COBOL. Et qu’il y’a des millions de lignes de code.
Des trouzaines de règles et d’algorithmes, des logiques qui tiennent à un fil, que plus personne ne sait ni comment ni pourquoi c’est fait. Des couches géologiques de règlementations empilée, dépilées, des liens improbables entre les strates.
On appuie sur le bouton, ça marche. Touche à un truc qui semblait ne rien à voir, ça marche plus et c’est le blocage pour des millions de personnes.

Demandez à la sécurité sociale de notre pays.

Bonne chance.
votre avatar
En France aussi on a connu des fiascos de réécriture:
- Louvois (armée)
- Sirhen (éducation nationale)
votre avatar
Avant: une sécurité sociale fonctionnant en cobol avec des milliers de batches .

Après: 150 hello world en Java, Python et Go capables de se connecter à une DB mysql sur AWS (et plus de sécurité sociale)
votre avatar
Non, une base Oracle :
next.ink Next
votre avatar
Attendez, en ce moment la mode dans l'IT est de vendre du code généré par IA en disant que ça sera d'enfer et résorbera toute la dette technique.

Les zigotos n'ont pas confiance dans leur produit finalement ?

Bande de clowns !
votre avatar
résorbera toute la dette technique.
Pas vraiment, mais du coup c'est ton LLM qui "paiera" la dette technique (ça doit sûrement tenir le coup un moment, vu que la plupart des modèles peuvent pisser du code à grande vitesse, et pour la plupart des managers qui ne voient que leurs indicateurs, ça le fait).
votre avatar
Je pense que tu n'as pas saisi l'ironie de mon propos.
votre avatar
Si si, mais d'un autre côté, on peut penser (dans la méthode connue de la fuite en avant) que c'est l'IA qui rattrapera le truc, jusqu'au moment où ça ne sera plus possible (en espérant être sur un autre poste quand ça arrivera).
votre avatar
Dans la position d'un éditeur qui est là pour vendre sa merde, y'a pas de problème. Suffit de dire que ça sera fait dans une nouvelle version ou que c'est une feature en preview.

Je bouffe ça depuis des années avec les Cloud provider.
votre avatar
Dans la position d'un éditeur qui est là pour vendre sa merde
Malencontreusement, c'est le but de la plupart des boîtes qui sont dans le très court terme. Surtout les ESN et encore plus les startups.
votre avatar
La question est : existe-t-il suffisamment de code COBOL open-source pour l'apprentissage des LLM ? Je ne suis pas certain que siphoner github & co. soit suffisant !
votre avatar
Bof, on nous vendait ça pour d'autres technos plus ou moins exotiques... Donc bon.
votre avatar
Ouais enfin quand je vois le nombre d'hallucination de LLM, y compris pour des langages répandus, ou parfois le déraillement complet (arrêt en plein milieu d'une méthode, il en commence une autre), je me dis que sur un langage avec aussi peu de contenu public que le COBOL, ça promet ^^
votre avatar
Tu penses franchement que la qualité intéresse ce troupeau d'imbéciles qui est juste là en mode cost-killer ? Honnêtement, je suis surpris de voir que cette solution n'a pas été proposée vu leur niveau de réflexion.
votre avatar
Ah c'est sur que si on met de côté la qualité... :mdr:
votre avatar
Pour le coup, je ne fais que relater des expériences vécues l'année dernière... :craint:

C'était une super ambiance.
votre avatar
Le COBOL c'est pour les vrais :phibee:


Je vais sur mes 30 ans de cobol .... :phibee: * 30 :fume:
votre avatar
Les vrais codaient en Natural. Le COBOL c'était pour les noobs qui avaient besoin de coloration syntaxique :D

Je regrette pas d'avoir quitté tout ça !
votre avatar
Moi, je codais en assembleur 😛
votre avatar
En pointilleux, je faisais du pacbase. (Déjà le temps qu'on a mis pour le faire disparaître, humm ...)
votre avatar
C est quand même formidable de voir que sur un site come NEXT, on se plaint que des gens cherchent à remplacer du code basé sur un langage vieux de 60ans… avec pour argument: va y avoir des bugs !
Ça va être compliqué d avoir des boites comme Tesla, SpaceX, Google, NVIDIA, etc en France avec ce genre de raisonnement j ai l impression :francais:
votre avatar
Tu es fait erreur sur le raisonnement ;)

Le problème n'est pas de remplacer un langage par un autre. Le problème est de vouloir remplacer un langage par un autre de manière précipitée (quelques mois).

Les paradigmes de programmation d'aujourd'hui sont très différents des paradigmes "d'hier". Il ne peut donc s'agir d'une simple traduction d'un langage dans un autre, mais bien d'une réécriture. Réécriture qui pose donc plusieurs problèmes :
- la base du code qui est immense
- base qui cumule des décennies d'évolutions (ce qui est absolument énorme en informatique)
- une bonne partie des règles métiers qui sont encore utilisées aujourd'hui (à tort ou à raison, par exemple, lorsqu'il s'agit de décrets qui ne sont plus applicables par exemple) mais qui ne sont pas documentées.

Croire qu'il suffit de "décider que" pour que "ça se fasse", c'est juste une hérésie. Quiconque ayant un minimum d'expérience dans le développement logiciel sait à quel point ce genre de réécriture est extrêmement délicate.

A prendre aussi en compte les conséquences des problèmes que pourraient générer des bogues sur ce genre de systèmes, et les délais pour les résoudre. Et là, c'est pas sur le DOGE avec ses objectifs à la con sur qui on va taper, mais sur ceux qui auront écrit le code / réaliser la transition.
votre avatar
Et tu oublies qu'il faudra tout certifier à nouveau, ce qui ne se fait pas non plus en un claquement de doigts.
votre avatar
Qu'entends-tu par certifier ? Qui certifie le logiciel de la Sécurité sociale aux USA ?
votre avatar
Tu as raison, j'étais parti dans les services bancaires à force qu'on parle de COBOL. Ceci dit, ce genre de service pourrait gagné à être certifié sur des normes de qualité (et de preuve pour ses modules les plus critiques).
votre avatar
Même sans avoir d'expérience dans le dév logiciel.
Mon expérience totale se limite à un Hello World pour un test serveur installé dans un réseau physique virtuellement créé dans Cisco Packet Tracer. Donc, littéralement, rien. Et je suis déjà au courant que c'est plus que délicat...
votre avatar
Ça va être compliqué d avoir des boites comme Tesla, SpaceX, Google, NVIDIA, etc en France avec ce genre de raisonnement j ai l impression :francais:
Je ne vois pas le rapport.
On ne parle pas d’un CRM à la con ou d’un système de reporting financier à la noix.
On parle de systèmes tentaculaires, avec un historique à gérer, et dont dépendent des millions d’assurés. En cas de problème, les conséquences sont autres que le DAF groupe qui n’a pas ses derniers chiffres corrects sortant de son bousin (ils sont de toute façon tripatouillés hors système pour coller à la réalité souhaitée) ou d’un commercial qui n’a pas les bonnes infos de son prospect (la boîte s’en remettra).
C’est peut être parce qu’une partie du lectorat de Next a justement une vision un peu plus fine de ce que peut représenter l’opération que le côté : c’est bas ben et désuet on va tout changer et moderniser par des technos dernier-cri en quelques mois rencontre un certain scepticisme quant à la pleine réussite d’un tel projet.
votre avatar
Exactement ce que je dis ! Si on t avait dit y a 15ans qu on allait creer notre propre fusee via une société privée pour lancer des satellites on aurait tout ris… et les ricains eux, bah ils le font ! Evidemment que ca durera pas 3 mois et evidemment qu il y aura des problèmes… et alors ?
Ce qu il faut surtout regarder c est le bénéfice a long terme… c est la que j attends la communauté NEXT 😁… perso Cobble c est une map de Counter Strike nan ?
votre avatar
En mettant de côté les boîtes de la silicon valley qui te vendent des produits beta voire alpha depuis 25 ans, les autres ne font pas tout à l'arrache (exemple de nvidia : tu conçois comme une bouse, une fois que tu as sorti 5 millions de puces bugguées, t'es mort).

On peut parler de Dassault, Dassault Systèmes, et Thalès si tu veux (qui profitent, mais moins que les géants américains, d'un marché captif en France).

US : le DOGE veut migrer le code de la Sécurité sociale en urgence. Il est écrit en COBOL.

  • COBOL : 66 bougies

  • 5 ans pour le précédent projet de migration

Fermer