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

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
5 min
Société numérique
Société
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 ?
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
Commentaires (132)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 01/04/2025 à 09h59
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.
Le 01/04/2025 à 10h11
Le 01/04/2025 à 14h55
Le 01/04/2025 à 21h01
Le 02/04/2025 à 16h22
Le 02/04/2025 à 20h48
Vive la méthode agile ✌️
Modifié le 02/04/2025 à 19h55
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.
Le 01/04/2025 à 10h17
L'invité d'une des vidéos de Micode qui traite le sujet du COBOL ?
Modifié le 01/04/2025 à 10h30
edit : lien vers la vidéo d'Underscore :
Modifié le 01/04/2025 à 10h43
Le 01/04/2025 à 14h36
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.
Le 01/04/2025 à 15h04
Le 01/04/2025 à 16h48
Modifié le 01/04/2025 à 22h20
Le 02/04/2025 à 15h05
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
Le 03/04/2025 à 10h42
Modifié le 01/04/2025 à 10h29
Si on avait de l'ADA en plus, on croirait presque être un 1er avril...
Le 01/04/2025 à 13h04
Modifié le 01/04/2025 à 10h33
Le 01/04/2025 à 11h47
Le 01/04/2025 à 10h34
Modifié le 01/04/2025 à 11h49
Le 01/04/2025 à 10h34
Le 01/04/2025 à 12h17
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.
Le 01/04/2025 à 12h21
https://www.wired.com/story/doge-rebuild-social-security-administration-cobol-benefits/
Le 01/04/2025 à 13h16
Le 01/04/2025 à 13h48
Le 01/04/2025 à 13h50
Le 01/04/2025 à 18h20
Ptet que ce n'est pas seulement le langage, mais aussi la machine qui sait faire ou pas.
Le 01/04/2025 à 21h08
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.
Le 02/04/2025 à 11h29
Le 02/04/2025 à 22h07
Le 02/04/2025 à 12h54
Le 03/04/2025 à 16h13
Le 03/04/2025 à 16h46
Le 03/04/2025 à 22h58
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...).
Le 04/04/2025 à 09h38
Ca en parle dans l'interview d'un coboliste par Underscore :
Le 04/04/2025 à 11h31
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.
Le 04/04/2025 à 14h44
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.
Modifié le 01/04/2025 à 10h50
Modifié le 01/04/2025 à 14h24
(Je suis passé du côté fonctionnel, je ne suis pas à jour sur les API :) )
Le 01/04/2025 à 20h23
Dans ma boîte, on fait encore de nouveau pgm.
Un des premiers assureurs automobile
Le 03/04/2025 à 17h21
Que de souvenir de ces codes erreur
Modifié le 01/04/2025 à 10h52
É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).
Le 01/04/2025 à 10h57
Le 02/04/2025 à 10h07
Le 01/04/2025 à 10h59
Le 01/04/2025 à 15h14
Le 02/04/2025 à 11h34
Le 01/04/2025 à 11h07
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.
Le 01/04/2025 à 11h27
Le 01/04/2025 à 20h30
Le 03/04/2025 à 09h57
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...
Modifié le 01/04/2025 à 14h52
Scoop : Trump ordonne la réécriture de toutes les lignes du code Apollo ayant été écrites par des femmes !
Le 01/04/2025 à 11h35
Tout ça c'est des fakes NEWS XD
Le 01/04/2025 à 13h24
Le 01/04/2025 à 11h12
Qu'est-ce qui pourrait mal tourner ?
À part impacter négativement des personnes sans doute déjà dans la précarité ...
Le 01/04/2025 à 11h22
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...
Le 01/04/2025 à 11h44
Tu peux d'ailleurs faire du décimal en Python avec le module standard
decimal
:
TrueLe 01/04/2025 à 11h57
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.
Le 01/04/2025 à 17h06
Le 01/04/2025 à 23h51
Le 01/04/2025 à 11h27
Modifié le 01/04/2025 à 11h36
Le 01/04/2025 à 12h02
Le 01/04/2025 à 13h51
Le 01/04/2025 à 11h38
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.
Le 01/04/2025 à 11h44
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.
Le 01/04/2025 à 22h53
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.
Le 01/04/2025 à 11h49
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.
Le 01/04/2025 à 11h51
Bienvenue dans les années 80 😁
Le 01/04/2025 à 14h05
Ç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]
Le 01/04/2025 à 14h06
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
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...
Le 01/04/2025 à 11h52
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.
Le 01/04/2025 à 12h01
Le 01/04/2025 à 13h53
https://futurism.com/elon-musk-rewriting-social-security-code-ai
Le 01/04/2025 à 12h20
Modifié le 01/04/2025 à 12h41
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...
Le 01/04/2025 à 14h15
Ça donne ça
Modifié le 01/04/2025 à 14h27
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
Le 01/04/2025 à 12h51
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.
Le 01/04/2025 à 14h42
Modifié le 01/04/2025 à 13h12
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.
Le 01/04/2025 à 14h02
https://www.lapresse.ca/actualites/chroniques/2025-03-30/le-poisson-d-avril-est-devenu-notre-realite.php
Modifié le 01/04/2025 à 13h21
Le 01/04/2025 à 14h22
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.
Le 02/04/2025 à 21h04
Le 01/04/2025 à 14h39
Le 01/04/2025 à 16h34
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...
Le 01/04/2025 à 17h03
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.
Le 01/04/2025 à 19h00
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 ?
Le 01/04/2025 à 19h44
Le 01/04/2025 à 20h43
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é.
Le 01/04/2025 à 20h14
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
Le 01/04/2025 à 20h44
Merci pour le rappel.
Le 01/04/2025 à 22h03
Le 02/04/2025 à 22h25
Le 03/04/2025 à 10h52
Le 01/04/2025 à 18h32
Le 01/04/2025 à 19h21
* 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.
Le 01/04/2025 à 19h01
Le 01/04/2025 à 21h14
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
Le 01/04/2025 à 19h47
Le 01/04/2025 à 21h46
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.
Le 02/04/2025 à 05h13
- Louvois (armée)
- Sirhen (éducation nationale)
Le 02/04/2025 à 10h15
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)
Le 02/04/2025 à 16h36
Le 02/04/2025 à 15h44
Les zigotos n'ont pas confiance dans leur produit finalement ?
Bande de clowns !
Le 02/04/2025 à 16h10
Le 02/04/2025 à 17h53
Le 02/04/2025 à 19h50
Le 02/04/2025 à 20h36
Je bouffe ça depuis des années avec les Cloud provider.
Le 03/04/2025 à 09h21
Le 02/04/2025 à 16h25
Le 02/04/2025 à 17h54
Le 02/04/2025 à 21h48
Le 02/04/2025 à 22h35
Le 03/04/2025 à 04h53
Le 03/04/2025 à 09h34
C'était une super ambiance.
Le 02/04/2025 à 20h00
Je vais sur mes 30 ans de cobol ....
Le 02/04/2025 à 21h03
Je regrette pas d'avoir quitté tout ça !
Le 02/04/2025 à 21h28
Le 02/04/2025 à 21h47
Le 02/04/2025 à 21h03
Ç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
Le 02/04/2025 à 21h44
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.
Le 03/04/2025 à 09h26
Le 03/04/2025 à 09h43
Le 03/04/2025 à 11h56
Le 03/04/2025 à 16h25
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...
Modifié le 02/04/2025 à 21h58
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.
Modifié le 05/04/2025 à 20h02
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 ?
Le 03/04/2025 à 09h25
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).