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 prévoit un hackathon pour créer une « méga API » pour faciliter l'accès aux données de l'IRS aux fournisseurs de services cloud,
Ce qui suscite des préoccupations en matière de sécurité

Le , par Mathis Lucas

29PARTAGES

4  0 
Les plans du DOGE d'Elon Musk visant à réécrire le code COBOL de l'administration de la sécurité sociale (SSA) suscitent déjà de nombreuses préoccupations. L'initiative est controversée, car elle pourrait mettre en péril l'intégrité du système et les prestations dont dépendent des dizaines de millions d'Américains. Malgré la polémique, le DOGE prévoit désormais d'organiser un hackathon axé sur la création d'une « méga API » qui permettra d'accéder aux données des contribuables. L'agence affirme que le projet permettra d'améliorer l'efficacité du système et de lutter contre la fraude, mais il inquiète les spécialistes et soulève des questions en matière de sécurité.

Deux employés du DOGE sont à la manette : Sam Corcos et Gavin Kliger. Sam Corcos est cofondateur et PDG de Levels, une startup spécialisée dans les technologies de la santé qui a des liens avec la société SpaceX d'Elon Musk. Gavin Kliger, quant à lui, a étudié à l'UC Berkeley jusqu'en 2020 et a travaillé dans la société d'IA Databricks avant de rejoindre le DOGE récemment en tant que conseiller spécial du directeur de l'Office of Personnel Management.

L'hackathon est prévu pour la semaine prochaine. Le but est de créer une « méga API » unique pour l'accès aux données de l'Internal Revenue Service (IRS). L'API permettra aux fournisseurs de services cloud d'accéder facilement aux données de l'IRS. Ces données comprennent, par exemple, les noms des contribuables, les adresses, les numéros de sécurité sociale, les déclarations de revenus, les informations sur l'emploi... Mais des inquiétudes demeurent.


Selon un rapport de Wired sur le sujet, l'API sera utilisée pour déplacer les données vers une plateforme cloud, potentiellement une plateforme tierce, qui servirait de « centre de lecture de tous les systèmes de l'IRS », ce qui signifie que toute personne y ayant accès pourrait consulter et éventuellement manipuler toutes les données de l'IRS en un seul endroit. Les plans du DOGE d'Elon Musk sont controversés. Et les employés de l'IRS tirent la sonnette d'alarme.

« Il s'agit en fait d'une porte ouverte contrôlée par Musk pour toutes les informations les plus sensibles des Américains, sans aucune des règles qui protègent normalement ces données », aurait déclaré à Wired un employé anonyme de l'IRS. Il tire la sonnette d'alarme sur les risques de ce projet.

Le DOGE d'Elon Musk a déjà réduit et brûlé des projets de modernisation dans d'autres agences, les remplaçant par des équipes plus petites et des délais plus serrés. À l'administration de la sécurité sociale, les représentants du DOGE prévoient de transférer toutes les données de l'agence des anciens langages de programmation comme le COBOL vers quelque chose comme Java. Toutefois, l'initiative met en péril de l'intégrité et la stabilité du système.

Un calendrier qui fait craindre un travail bâclé avec des conséquences graves

De nombreux experts s'interrogent sur la sécurité d'un tel projet. Une méga API pourrait potentiellement permettre à une personne y ayant accès d'exporter toutes les données de l'IRS vers les systèmes de son choix, y compris vers des entités privées. Si la personne avait également accès à d'autres ensembles de données interopérables dans des agences gouvernementales distinctes, elle pourrait les comparer aux données de l'IRS pour ses propres besoins.

Le DOGE vise à terminer le travail sur l'API en 30 jours. Mais un employé de l'IRS a déclaré que « ce délai n'est pas techniquement possible et qu'il paralyserait l'agence ». Les systèmes de l'IRS ont tous fait l'objet d'un processus d'approbation fastidieux pour garantir la sécurité des données des contribuables. Selon des sources interrogées dans le cadre du rapport, les systèmes qui les remplaceront devront probablement faire l'objet d'un examen approfondi.

Les employés de l'IRS craignent que les opérateurs du DOGE ne disposent pas des compétences nécessaires pour traiter les données de l'IRS. « Schématiser ces données et les comprendre prendrait des années. Le simple fait de réfléchir aux données prendrait beaucoup de temps, car ces personnes n'ont aucune expérience, non seulement du gouvernement, mais aussi de l'IRS, des impôts ou de quoi que ce soit d'autre », a déclaré un employé de l'IRS.

L'effort de consolidation des données s'aligne sur un décret signé par le président Donald Trump du 20 mars, qui a demandé aux agences d'éliminer les silos d'informations. Alors que le décret vise à lutter contre la fraude et le gaspillage, il pourrait également menacer la vie privée en consolidant les données personnelles hébergées sur différents systèmes dans un référentiel central. Le projet du DOGE expose les contribuables à des violations de données.

Le 1er mars, le Washington Post a rapporté que Sam Corcos avait poussé l'IRS à lever les restrictions qu'elle avait imposées à l'accès de Gavin Kliger à ses systèmes et avait proposé un accord pour partager les données de l'IRS avec l'ensemble du gouvernement américain. Une lettre adressée le 14 mars à l'IRS par le sénateur Ron Wyden et d'autres suggère que l'agence n'a pas cédé, puisqu'elle fait l'éloge de son « rejet légitime » des demandes du DOGE.

La lettre cite ensuite un autre article du Washington Post suggérant que « les fonctionnaires de l'administration Trump envisagent d'utiliser les données de l'IRS pour alimenter leur campagne de répression de l'immigration et d'efficacité du gouvernement ». Ces allégations ont déclenché un tollé.

Un partenaire connu pour ses activités controversées de collecte de données

Le plan de l’hackathon du DOGE prévoit de rassembler des « douzaines » d'ingénieurs de l'IRS à Washington pour construire l'API. Le DOGE d'Elon Musk devrait s'associer à un fournisseur tiers pour gérer certains aspects du projet. Selon Wired Palantir, une société de logiciels cofondée par Peter Thiel, entrepreneur milliardaire et associé de longue date d'Elon Musk, a été régulièrement citée par les représentants du DOGE comme un fournisseur potentiel.

Palantir est une société connue pour ses vastes travaux de collecte de données, de surveillance gouvernementale et d'analyse. Palantir a été cité dans plusieurs scandales d'abus de données aux États-Unis au cours de la dernière décennie. Palantir a travaillé pour le Pentagone et la CIA en Afghanistan et en Irak. La société d'exploitation de données de Peter Thiel a utilisé les outils de la campagne « War on Terror » à la suite des évènements du 11 septembre.

Palantir serait mêlé au scandale Cambridge Analytica. Il est notamment reproché à Palantir d'avoir participé à l'exploitation des données en envoyant ses propres employés en Grande-Bretagne. Palantir a déclaré que la société à une politique stricte concernant le travail sur les questions politiques, y compris les campagnes, et a montré des courriels dans lesquels il a rejeté la demande de Cambridge Analytica de travailler avec Palantir à plusieurs reprises.

Palantir a également été poursuivi par un leader du marché de l'analyse de données, la société de logiciels I2 inc. Ladite société reprochait à Palantir d'avoir détourné sa propriété intellectuelle par l'interm...
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
2  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.
1  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.
0  0