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

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

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

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

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

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

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

Je m'inscris !

Le DOGE d'Elon Musk utiliserait l'IA pour espionner les communications de fonctionnaires fédéraux américains
Recherchant des propos perçus comme hostiles envers le président Donald Trump et son administration

Le , par Stéphane le calme

10PARTAGES

8  0 
Après la multiplication des projets avec l'IA au sein du gouvernement, le Département de l'Efficacité Gouvernementale (DOGE), dirigé par Elon Musk, est accusé d'utiliser l'intelligence artificielle (IA) pour surveiller les communications des employés fédéraux américains à la recherche de propos perçus comme hostiles envers le président Donald Trump et son administration. Des sources indiquent que cette surveillance inclut l'utilisation d'applications de communication internes telles que Microsoft Teams.

L'utilisation de l'IA par le DOGE, en particulier du chatbot Grok développé par Musk, soulève des préoccupations en matière de transparence et de légalité, notamment en ce qui concerne le respect des exigences fédérales en matière de conservation des documents. De plus, l'utilisation de l'application de messagerie chiffrée Signal, qui permet aux messages de disparaître, alimente les inquiétudes quant à la conformité aux réglementations fédérales.


Un vent glacial souffle sur les institutions fédérales américaines. Depuis la révélation selon laquelle le Département de l’Efficacité Gouvernementale (DOGE), dirigé par Elon Musk, utiliserait l’intelligence artificielle pour espionner les employés fédéraux, les critiques fusent, dénonçant une dérive autoritaire masquée derrière un vernis technologique.

Pour rappel, le Department of Government Efficiency (DOGE) est une initiative de la deuxième administration de Donald Trump aux États-Unis. Créé par un décret le 20 janvier 2025, le DOGE a pour objectif déclaré de « moderniser la technologie et les logiciels fédéraux afin de maximiser l'efficacité et la productivité du gouvernement ». Ses actions ont notamment consisté à organiser des licenciements massifs de travailleurs fédéraux, à accéder à des systèmes informatiques et à des données personnelles sensibles, et à réduire les financements liés aux programmes DEI (diversité, équité et inclusion), aux initiatives de lutte contre le changement climatique et à la recherche scientifique.

Un outil technologique, une arme politique ?

Selon plusieurs sources rapportées par Reuters et AP News, DOGE aurait recours à des outils d’IA, dont le chatbot Grok (issu des laboratoires de xAI, également fondé par Musk) pour analyser les communications internes des agences fédérales. Officiellement, l’objectif serait d’améliorer la productivité et de détecter les « inefficacités systémiques ». Officieusement, il s’agirait surtout d’identifier les employés « déloyaux » ou critiques envers l’administration actuelle et ses politiques.

Cette surveillance, qui toucherait des plateformes comme Microsoft Teams ou des applications de messagerie chiffrée comme Signal, suscite une inquiétude légitime : dans quelle mesure les technologies développées à des fins d’efficacité peuvent-elles devenir des instruments de répression silencieuse ? L’IA utilisée ne se contente pas de collecter des données : elle les interprète, les classe, et potentiellement les juge.

Dans son article, Reuters explique :

« Des responsables de l'administration Trump ont dit à certains employés du gouvernement américain que l'équipe de technologues du DOGE d'Elon Musk utilisait l'intelligence artificielle pour surveiller les communications d'au moins une agence fédérale à la recherche d'hostilité au président Donald Trump et à son programme, ont déclaré deux personnes ayant connaissance de l'affaire.

« Alors qu'une grande partie du Département de l'efficacité gouvernementale de Musk reste entourée de secret, la surveillance marquerait une utilisation extraordinaire de la technologie pour identifier les expressions de déloyauté perçue dans une main-d'œuvre déjà bouleversée par des licenciements généralisés et des coupes sombres dans les coûts.

« L'équipe du DOGE utilise également l'application Signal pour communiquer, selon une autre personne ayant une connaissance directe de l'affaire, ce qui pourrait constituer une violation des règles fédérales en matière de tenue de registres, car les messages peuvent être configurés pour disparaître au bout d'un certain temps. Et ils ont "fortement" déployé le chatbot Grok AI de Musk - un rival potentiel de ChatGPT - dans le cadre de leur travail de démantèlement du gouvernement fédéral, a déclaré cette personne. Reuters n'a pas pu déterminer exactement comment Grok était utilisé ».


Entre dystopie numérique et gouvernance musclée

Le retour en grâce de Donald Trump à la présidence en 2024 a donné lieu à une restructuration rapide et brutale de l’appareil fédéral. DOGE, agence nouvellement créée, incarne cette volonté de rationalisation et de contrôle centralisé. Mais en confiant des leviers aussi puissants à une technologie opaque, pilotée par une entreprise privée dirigée par un homme aussi polarisant qu’Elon Musk, la Maison-Blanche semble franchir une ligne rouge.

La crainte exprimée par plusieurs fonctionnaires et analystes politiques est celle d’un « maccarthysme algorithmique » : une époque où l’IA remplace le comité d’enquête, où les « ennemis de l’intérieur » sont détectés non par des faits, mais par des patterns de langage, des sentiments présumés, ou une simple plaisanterie dans un canal de discussion privé.

Cette surveillance intervient dans un contexte de réductions budgétaires et de suppressions de postes au sein de diverses agences fédérales, y compris l'Agence de Protection de l'Environnement (EPA). Des critiques, notamment des experts en éthique et des groupes de surveillance, considèrent ces actions comme un abus de pouvoir visant à réprimer les opinions dissidentes.

Ainsi, Kathleen Clark, experte en éthique gouvernementale à l'université Washington de St. Louis, a déclaré que l'utilisation par le DOGE de Signal, axée sur la protection de la vie privée, s'ajoute aux préoccupations croissantes concernant les pratiques en matière de sécurité des données après que de hauts responsables de l'administration Trump ont été critiqués le mois dernier pour avoir inclus par erreur un journaliste dans une discussion de groupe sur la planification à haut niveau d'opérations militaires au Yémen.

« S'ils utilisent Signal et ne sauvegardent pas chaque message dans des fichiers fédéraux, ils agissent de manière illégale », a-t-elle déclaré.

Les entretiens avec près de 20 personnes ayant connaissance des opérations de la DOGE et l'examen de centaines de pages de documents judiciaires issus de procès contestant l'accès de la DOGE aux données ont mis en évidence l'utilisation peu orthodoxe de l'IA et d'autres technologies dans les opérations du gouvernement fédéral.

À l'Agence de protection de l'environnement, par exemple, des responsables de l'EPA ont été informés par des personnes nommées par Trump que l'équipe de Musk mettait en œuvre l'IA pour surveiller les travailleurs, notamment en recherchant dans les communications un langage considéré comme hostile à Trump ou à Musk, ont déclaré les deux personnes.

L'EPA, qui applique des lois telles que la loi sur la pureté de l'air et œuvre à la protection de l'environnement, a fait l'objet d'un examen minutieux de la part de l'administration Trump. Depuis janvier, elle a mis près de 600 employés en congé et a déclaré qu'elle supprimerait 65 % de son budget, ce qui pourrait nécessiter d'autres réductions de personnel.

Des fonctionnaires nommés par Trump qui avaient pris des postes à l'EPA ont dit à des responsables que le DOGE utilisait l'IA pour surveiller les applications et les logiciels de communication, y compris Microsoft Teams, qui est largement utilisé pour les appels virtuels et les chats, ont déclaré les deux sources familières avec ces commentaires. « On nous a dit qu'ils recherchaient un langage anti-Trump ou anti-Musk », a déclaré une troisième source familière avec l'EPA.

Les fonctionnaires de Trump ont dit que le DOGE chercherait des personnes dont le travail ne correspondait pas à la mission de l'administration, ont déclaré les deux premières sources. « Faites attention à ce que vous dites, à ce que vous tapez et à ce que vous faites », a déclaré un responsable, selon l'une des sources.

L'EPA a reconnu dans un communiqué qu'elle « étudiait l'IA pour mieux optimiser les fonctions de l'agence et l'efficacité administrative », mais a précisé qu'elle n'utilisait pas l'IA « car elle prend des décisions en matière de personnel en concertation avec le ministère de l'environnement et de l'aménagement du territoire ». Elle n'a pas dit directement si elle utilisait l'IA pour surveiller les travailleurs. Musk a décrit la DOGE comme une initiative technologique visant à rendre le gouvernement fédéral américain plus efficace en ciblant les gaspillages, les fraudes et les abus. Il a déclaré que l'objectif était de réduire les dépenses de 1 000 milliards de dollars, soit 15 % du budget annuel des États-Unis.


Le DOGE d'Elon Musk remplace les employés fédéraux licenciés par un chatbot d'IA et automatise les tâches

L'année dernière, avant l'élection de Trump, Musk a suggéré que l'IA pourrait être utilisée pour remplacer les employés du gouvernement, selon une personne ayant une connaissance directe de ses commentaires. « Le concept était qu'en prenant les données du gouvernement, ils pourraient construire le système d'IA le plus dynamique qui soit », a déclaré la personne, ajoutant que l'IA pourrait alors « faire le travail ».

Le DOGE d'Elon Musk s'est récemment attaqué à la General Services Administration (GSA), l'agence qui gère les biens immobiliers fédéraux et...
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 Guesset
Expert confirmé https://www.developpez.com
Le 11/04/2025 à 23:04
Bonjour,

La migration du COBOL vers un autre langage sera aussi difficile pour des questions d'âge.
Les vieilles applications accumulent du code mort. Par exemple, une nouvelle règle s'impose, alors on développe un module pour la prendre en charge, mais on garde l'ancienne règle active pour traiter les dossiers en cours. Normalement, au bout d'un certain temps l'ancienne règle devrait être retirée, mais c'est rarement (jamais ?) fait. Et des scories s'accumulent.
Alors, faire une migration permettrait d'avoir, non pas une nouvelle application, mais une vieille application avec des habits neufs.

En outre, je suis toujours fasciné par notre aptitude à croire à la magie. Aujourd'hui cela s'appelle IA. Tous les outils ont leur intérêt et leur limitations.
L'IA a besoin de modèles construits sur la base de (très) nombreux exemples.
Mais des exemples de migrations COBOL vers C++ ou n'importe quoi, il n'y en pratiquement pas (même le simple accès aux sources COBOL des grosses applications est très protégé).
Donc pas de baguette magique. Et cela malgré la simplification outrancière que je fais en réduisant le problème à un portage entres langages alors que ce serait une migration de tout un écosystème.

Je pense que la solution passera par une duplication croisées des données dans une base actuelle. Puis de commencer des développements par modules autour de cette base. D'abord des fonctionnalités existantes pour vérifier la stabilité comportementale puis, peu à peu, sur de nouveaux modules. Avec un peu de chance, quand la réécriture sera complète, le langage cible sera lui aussi obsolète

Salutations
4  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 11/04/2025 à 17:03
Citation Envoyé par Artemus24 Voir le message
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.
Je ne code pas des monuments d'avant-guerre au marteau-burin, il s'agissait là d'un abus de langage, à l'évidence puisque le langage a été créé en 1959.
Après c'est vrai qu'en un demi-siècle d'existence, le langage a pu évoluer, c'est important de le souligner.

Citation Envoyé par Artemus24 Voir le message
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.
En effet, les quelques programmes C++ dont nous disposons sont exécutés sur des machines Windows et non sous nos VMS, même si j'ai du mal a comprendre où tu voulais en venir.
Et oui, globalement nous avons fait le même constat:
- Les développeurs juniors ne sont pas intéressés par le langage, mis à part pour toucher une paie commode.
- Les règles métiers accumulées depuis 40 ans sont difficilement traduisibles, surtout quand a l'époque la Qualité n'imposait pas une documentation rigoureuse.
- Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.

Mais je suis curieux de savoir quelle pertinence tu as vu sur ce point d'avoir été créé avant ou après les guerres ? Tu as l'air d'avoir quelque chose a dire sur les langages d'avant guerre et ça m'intéresserait de savoir.
2  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 11/04/2025 à 18:29
Citation Envoyé par Prox_13
En effet, les quelques programmes C++ dont nous disposons sont exécutés sur des machines Windows et non sous nos VMS, même si j'ai du mal a comprendre où tu voulais en venir.
Remplacer les gros ordinateur IBM VM/CMS JCL TSO ISP qui sont très performants, par des mini ordinateurs en migrant le COBOL vers du 'C/C++', risque d'être problématique du point de vue sécurité mais aussi en performance. C'est selon moi, peu réaliste.

Citation Envoyé par Prox_13
- Les règles métiers accumulées depuis 40 ans sont difficilement traduisibles, surtout quand a l'époque la Qualité n'imposait pas une documentation rigoureuse.
Ce problème existe aussi dans les banques où l'on ne sait plus trop comment fonctionner des pans entiers de codes COBOL car il n'y a pas ou plus de documentations pour expliquer ce que ça fait réellement. Sans compter, le nombre considérable d'intervenant qui ont modifié le code, pas toujours d'une bonne manière. Bonjour pour faire une retroingérierie qui sera extrêment complexe, sans rien apporter de bénéfique au final.

[quote="Prox_13"]-Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.
Entièrement d'accord. Donc pourquoi changer quelque chose qui fonctionne parfaitement ?

Citation Envoyé par Prox_13
Mais je suis curieux de savoir quelle pertinence tu as vu sur ce point d'avoir été créé avant ou après les guerres ?
J'ai réagit sur le fait que le COBOL n'est pas apparu avant guerre mais en 1959.

Citation Envoyé par Prox_13
Tu as l'air d'avoir quelque chose a dire sur les langages d'avant guerre et ça m'intéresserait de savoir.
J'ai connu la fin des perforatrice et des cartes perforées pour écrire un programme. Le seul point positif est qu'à l'époque, on savait programmer car la place manquait et il fallait jongler dans des techniques qui ont totalement disparu aujourd'hui pour gérer la mémoire. C'est comparable entre la règle à calcule et les approximations que l'on faisaient à l'époque et l'avènement aujourd'hui des calculatrices et des ordinateurs qui nous ont simplifié grandement la tâche. Mais croire que la tâche sera plus simple de remplacer le COBOL est selon moi une erreur.
2  0 
Avatar de JPLAROCHE
Membre expérimenté https://www.developpez.com
Le 01/05/2025 à 19:57
TRÈS TRISTE TOUT ÇA
2  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 02/05/2025 à 13:41
Citation Envoyé par Artemus24 Voir le message
Remplacer les gros ordinateur IBM VM/CMS JCL TSO ISP qui sont très performants, par des mini ordinateurs en migrant le COBOL vers du 'C/C++', risque d'être problématique du point de vue sécurité mais aussi en performance. C'est selon moi, peu réaliste.
Je te rassure, nous sommes entièrement d'accord. Les "quelques programmes" que je cite ne sont pas représentatifs d'un ERP, et la majeure partie du code COBOL est transformé vers un autre langage qui va te donner de bonnes raisons d'être horripilé; Du Python.

Citation Envoyé par Artemus24 Voir le message
Ce problème existe aussi dans les banques où l'on ne sait plus trop comment fonctionner des pans entiers de codes COBOL car il n'y a pas ou plus de documentations pour expliquer ce que ça fait réellement. Sans compter, le nombre considérable d'intervenant qui ont modifié le code, pas toujours d'une bonne manière. Bonjour pour faire une retroingérierie qui sera extrêment complexe, sans rien apporter de bénéfique au final.
Citation Envoyé par Prox_13
-Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.
Citation Envoyé par Artemus24 Voir le message
Entièrement d'accord. Donc pourquoi changer quelque chose qui fonctionne parfaitement ?
Les deux problèmes se recoupent;

Transcoder des règles de gestion déjà inutiles en COBOL vers un langage peu efficace comme le Python est d'un part chronophage et inefficient en performance (si la procédure est utilisée).
Engager des développeurs COBOL en 2025 est couteux; Continuer de maintenir le systeme dans ce langage c'est l'assurance de tomber en pénurie de budget ou de main d’œuvre.

En tout cas, j'essaie de me mettre dans les bottes des personnes en charge de la migration du système pour y voir ces points, ca ne veut pas dire que je tombe d'accord avec la solution retenue.

Citation Envoyé par Artemus24 Voir le message
J'ai réagit sur le fait que le COBOL n'est pas apparu avant guerre mais en 1959.
J'ai connu la fin des perforatrice et des cartes perforées pour écrire un programme. Le seul point positif est qu'à l'époque, on savait programmer car la place manquait et il fallait jongler dans des techniques qui ont totalement disparu aujourd'hui pour gérer la mémoire. C'est comparable entre la règle à calcule et les approximations que l'on faisaient à l'époque et l'avènement aujourd'hui des calculatrices et des ordinateurs qui nous ont simplifié grandement la tâche. Mais croire que la tâche sera plus simple de remplacer le COBOL est selon moi une erreur.
Je me doutais que tu avais une chose intéressante a dire sous cette remarque. Et encore une fois, nous tombons d'accord sur le fait que le COBOL sera difficilement remplaçable, de surcroit par une couche de Python.
2  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 02/05/2025 à 14:04
J'ai fait mon activité professionnel dans les banques et un peu dans les assurances, au travers des SSII (ESN aujourd'hui). Le principale langage que j'ai utilisé est bien le COBOL que je trouve adapté pour de la gestion.

Citation Envoyé par Prox_13
et la majeure partie du code COBOL est transformé vers un autre langage qui va te donner de bonnes raisons d'être horripilé; Du Python.
Cela va dépendre de ce que l'on fait avec. Une grosse partie du développement en gestion est destiné à faire de la présentation de résultats, comme des états.
Par contre, c'est d'une stupidité si c'est le cœur même du métier car la performance n'est pas au rendez-vous, sans parler de la précision dans les calculs.

Citation Envoyé par Prox_13
Engager des développeurs COBOL en 2025 est couteux; Continuer de maintenir le système dans ce langage c'est l'assurance de tomber en pénurie de budget ou de main d’œuvre.
Je veux bien, mais tout réécrire couterait encore plus cher. Un des aspects que l'on maitrise le moins est justement la maintenance, que ce soit aujourd'hui, ou dans dix ans. Qui dit que le python sera encore d'actualité ? Et par quoi va-t-on le remplacer ? On va se retrouver avec un système totalement hétérogène ou plus personne n'osera mettre son nez dedans de peur de tout casser.
2  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 02/05/2025 à 16:31
Je ne préfère pas réveler le coeur de métier du système, par sécurité, ce serait possible de retrouver qui je suis ou pire, l'entreprise dans laquelle je travaille

Citation Envoyé par Artemus24 Voir le message
Cela va dépendre de ce que l'on fait avec. Une grosse partie du développement en gestion est destiné à faire de la présentation de résultats, comme des états.
Par contre, c'est d'une stupidité si c'est le cœur même du métier car la performance n'est pas au rendez-vous, sans parler de la précision dans les calculs.
Je suis peut-être a côté de la plaque par rapport à mes supérieurs hiérarchiques qui prennent ces décisions sur les technologies a adopter, mais le but est clair comme du cristal de roche :
Il faut remplacer tout code COBOL par du Python, par principe de facilité de maintenance. (Y compris les programmes-clés qui gèrent la majeure partie de la production.)

Personnellement, je serais plus d'avis de garder un cœur COBOL et un interfaçage en Python, ce qui permettrait de profiter des performances de COBOL, et comme tu le soulignes, la souplesse du Python. (Et sa modernité, car faire communiquer du COBOL avec des -nouvelles- technologies web est parfois complexe)

Citation Envoyé par Artemus24 Voir le message
Je veux bien, mais tout réécrire couterait encore plus cher. Un des aspects que l'on maitrise le moins est justement la maintenance, que ce soit aujourd'hui, ou dans dix ans. Qui dit que le python sera encore d'actualité ? Et par quoi va-t-on le remplacer ? On va se retrouver avec un système totalement hétérogène ou plus personne n'osera mettre son nez dedans de peur de tout casser.
Pour les 5 ans qui viennent, nous avons encore la chance d'avoir les anciens druides COBOL pour guider la migration. Après ça, c'est un saut de l'ange sur les questions que tu viens d'aborder.
2  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 02/05/2025 à 19:22
Il ne faut pas croire qu'il y a un consensus au niveau des entreprises pour le choix des langages. Chacun fait comme il lui plait, d'où une hétérogénéité en France dans une même corps de métier (bancaire, assurance).

Comme je l'ai dit, l'avantage du COBOL repose sur le "COMP-3" que l'on nomme le format "packed decimal" où l'on utilise la représentation DCB (décimal codé binaire). Je ne suis plus très au courant de ce qui se fait dans les langages d'aujourd'hui. Ce n'est plus trop mon centre d'intérêt. Mais avons encore nous ce type de format dans Python ? La précision doit être absolue dans le domaine bancaire, et non faire des arrondis.

Citation Envoyé par Prox_13
Il faut remplacer tout code COBOL par du Python, par principe de facilité de maintenance. (Y compris les programmes-clés qui gèrent la majeure partie de la production.)
Remplacer le COBOL, cela se comprend aisément puisqu'il y a de moins en moins de compétences en ce domaine sur le marché du travail. Ce langage n'est plus enseigné à l'école. Donc, comment résoudre ce problème ? La solution la plus basique est de migrer vers un nouveau langage qui répond aux attentes de coûts de la maintenance. Oui, mais, où trouver la compétence du corps de métier du client ? Cela ne va pas se faire aussi facilement qu'on veut le croire. Il y a surtout le problème de la sécurité, qui est cruciale, mais aussi celui des performances. Je me rappelle que faire tourner sur des mini ordinateurs prenait pour valider une journée, un peu plus de 24 heures. C'était à l'époque dans une phase de mise au point, et les performances n'étaient pas du tout au rendez-vous. C'était il y a un peu plus de vingt-cinq ans.

Il ne faut pas s'engouffrer dans un langage parce qu'on le connait et qu'il existe partout de la compétence. En premier lieu, je trouve idiot d'utiliser un langage interprété au lieu d'un langage compilé. Ensuite, y-a-t-il un quelconque format "packed decimal" dans le langage choisit ? Quelles sont les performances et surtout quelle machine va-t-on faire les traitements de production ? Et la sécurité dans tout ça ?

Je ne parle ici que du cœur du métier, pas de ce qui est à la périphérie, ce qui complexifie le système d'information. On peut aussi se demander si les gros systèmes comme IBM sont encore fait pour ce type de traitement.

Je ne suis plus trop dans le coup, et je ne sais pas ce qui se fait de mieux en ce domaine.
2  0 
Avatar de Guesset
Expert confirmé https://www.developpez.com
Le 02/05/2025 à 22:52
Bonjour,

Les langages interprétés sont très biens pour développer rapidement la glue des appels de fonctions de bibliothèques écrites dans un langage compilé (en général C ou C++). Les utiliser intégralement pour des projets de grandes tailles n'est pas très pertinent car ils sont aussi peu performants qu'ils sont faciles à mettre en œuvre. Ce n'est pas un problème intrinsèque au langage mais au type d'outil qui le transforme en exécutable.

Jadis on utilisait le DCB non pas pour la seule précision mais parce que les processeurs savaient les traiter en natif et que les valeurs restaient lisibles humainement ce qui n'est pas le cas des codes binaires.
Aujourd'hui on utiliserait des types à virgules fixes qui sont en fait des entiers sur lesquels on plaque une virgule à une position donnée. Ce n'est pas lisible humainement mais ce n'est plus un problème. Et la taille est plus économique que le DCB qui utilise 4 bits par décades donc 36 bits pour 1 milliard contre 30 bits en binaire. De plus les temps de calcul sont très rapides ce qui ne serait pas le cas s'il fallait émuler le DCB.

Salutations
2  0 
Avatar de Heaven_4u
Futur Membre du Club https://www.developpez.com
Le 07/05/2025 à 12:10
Est-ce que nous avons la mémoire courte?

On a juste à penser au travail énorme de réécriture de code fait pour le fameux bug de l'an 2000.

Je fairais un cours de refresher dans cette techno main frame et Cobol pour finir ma carriere comme consultant Cobol. Ca serait payant j'en suis sur
1  0