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 !

Un lanceur d'alerte accuse des ingénieurs du DOGE de Musk d'avoir exfiltré environ 10 Go de données sensibles
Notamment des informations sur des activités syndicales et des secrets commerciaux

Le , par Stéphane le calme

100PARTAGES

9  0 
Un scandale de cybersécurité secoue actuellement les sphères gouvernementales américaines, mettant en cause le Département de l'Efficacité Gouvernementale (DOGE), dirigé par Elon Musk. Selon une plainte déposée par le lanceur d'alerte Daniel Berulis, technicien informatique au sein du National Labor Relations Board (NLRB), des membres de DOGE auraient obtenu un accès étendu aux systèmes informatiques de l'agence, permettant l'exfiltration de données sensibles.

Dans une déclaration sous serment, Berulis affirme que, dès mars 2025, les protocoles de journalisation du NLRB ont été altérés, et environ 10 gigaoctets de données confidentielles auraient été transférés hors des serveurs de l'agence. Ces informations incluraient des détails sur des activités syndicales, des informations commerciales sensibles et des témoignages privés. De plus, des tentatives de connexion depuis une adresse IP russe utilisant des identifiants valides ont été détectées, bien que bloquées par les politiques de sécurité géographiques en place.


Dans les premiers jours de mars, une équipe de conseillers du nouveau ministère de l'efficacité gouvernementale (DOGE) du président Trump est arrivée au siège du National Labor Relations Board, dans le sud-est de Washington. Cette petite agence fédérale indépendante enquête et statue sur les plaintes relatives aux pratiques de travail déloyales. Elle stocke des quantités de données potentiellement sensibles, qu'il s'agisse d'informations confidentielles sur des employés souhaitant former des syndicats ou d'informations commerciales exclusives.

Les employés du DOGE, qui sont dirigés par Elon Musk, conseiller de la Maison Blanche et PDG milliardaire de l'industrie technologique, semblaient vouloir accéder aux systèmes internes du NLRB. Ils ont déclaré que la mission générale de leur unité était d'examiner les données de l'agence pour s'assurer de leur conformité avec les politiques de la nouvelle administration et pour réduire les coûts et maximiser l'efficacité.

Les membres de l'équipe du DOGE ont demandé que leurs activités ne soient pas enregistrées sur le système

Mais d'après une déclaration officielle du lanceur d'alerte partagée avec le Congrès et d'autres superviseurs fédéraux, des entretiens ultérieurs avec le lanceur d'alerte et des enregistrements de communications internes, les membres du personnel technique ont été alarmés par ce que les ingénieurs du DOGE ont fait lorsqu'ils ont obtenu l'accès, en particulier lorsque ces membres du personnel ont remarqué un pic dans les données quittant l'agence. Il est possible que ces données contiennent des informations sensibles sur les syndicats, des affaires juridiques en cours et des secrets d'entreprise (des données qui, selon quatre experts en droit du travail, ne devraient presque jamais quitter le NLRB et qui n'ont rien à voir avec l'amélioration de l'efficacité du gouvernement ou la réduction des dépenses).

Pendant ce temps, selon la divulgation et les enregistrements de communications internes, les membres de l'équipe du DOGE ont demandé que leurs activités ne soient pas enregistrées sur le système et ont ensuite semblé essayer de brouiller les pistes, en désactivant les outils de surveillance et en supprimant manuellement les enregistrements de leur accès (un comportement évasif que plusieurs experts en cybersécurité ont comparé à ce que pourraient faire des pirates informatiques criminels ou parrainés par un État).

Les employés se sont inquiétés du fait que les données confidentielles de la NLRB pouvaient être exposées, en particulier après avoir commencé à détecter des tentatives de connexion suspectes à partir d'une adresse IP en Russie, selon la divulgation. Finalement, le service informatique a lancé un examen formel de ce qu'il considérait comme une violation grave et continue de la sécurité ou comme une suppression potentiellement illégale d'informations personnellement identifiables. Le lanceur d'alerte estime que l'activité suspecte justifie une enquête plus approfondie de la part d'agences disposant de plus de ressources, telles que l'Agence pour la cybersécurité et la sécurité des infrastructures (Cybersecurity and Infrastructure Security Agency) ou le FBI.


Une manne pour les entreprises

Les experts en droit du travail craignent que si les données sont divulguées, elles pourraient faire l'objet d'abus, notamment de la part d'entreprises privées qui ont des affaires devant l'agence et qui pourraient obtenir des informations sur des témoignages préjudiciables, des dirigeants syndicaux, des stratégies juridiques et des données internes sur les concurrents (SpaceX de Musk en fait partie). Cela pourrait également intimider les lanceurs d'alerte qui pourraient s'exprimer sur des pratiques de travail déloyales, et cela pourrait semer la méfiance quant à l'indépendance du NLRB, ont-ils déclaré.

Les nouvelles révélations sur les activités du DOGE au sein de l'agence du travail proviennent d'un lanceur d'alerte du service informatique du NLRB, qui a fait part de ses inquiétudes au Congrès et au Bureau du conseiller spécial des États-Unis dans un rapport détaillé. Pendant ce temps, ses tentatives pour soulever des problèmes en interne au sein du NLRB ont conduit quelqu'un à « scotcher physiquement une note menaçante » sur sa porte, qui comprenait des informations personnelles sensibles et des photos de lui promenant son chien qui semblaient avoir été prises avec un drone, selon une lettre d'accompagnement jointe à sa déclaration déposée par son avocat, Andrew Bakaj, de l'organisation à but non lucratif Whistleblower Aid.

Elon Musk et la NLRB s'affronte devant les tribunaux

Musk est actuellement engagé dans une bataille juridique avec le NLRB au sujet de la capacité de l'agence à faire respecter le droit du travail. Les avocats de SpaceX, la société de Musk, ont fait valoir devant un tribunal en novembre que la structure du NLRB était inconstitutionnelle.

Une décision défavorable à l'agence pourrait réduire considérablement son pouvoir.

La bataille juridique a commencé après que le NLRB a accusé SpaceX de licencier illégalement des employés qui avaient publiquement critiqué Musk.

L'organisation à but non lucratif Whistleblower Aid, qui représente Berulis sur le plan juridique, a transmis sa déclaration sous serment dans une lettre adressée aux sénateurs Tom Cotton et Mark Warner. Tom Cotton et Mark Warner, respectivement premier républicain et premier démocrate de la commission sénatoriale sur le renseignement. Il a demandé à la commission d'enquêter sur cette affaire.

La lettre décrit les actions du DOGE comme pouvant constituer une « violation importante de la cybersécurité qui a probablement exposé et continue d'exposer notre gouvernement aux services de renseignement étrangers et aux adversaires de notre nation ».

Berulis a déclaré à Reuters lors d'une interview mardi que les données en question comprennent des informations commerciales exclusives provenant de concurrents, d'organisations syndicales et de défendeurs de pratiques déloyales de travail, ainsi que leurs revendications, y compris des déclarations sous serment privées. « Ce type de pic est extrêmement inhabituel car les données ne quittent presque jamais directement les bases de données du NLRB », a déclaré Berulis dans sa déclaration sous serment.

Berulis affirme dans sa déclaration sous serment qu'il y a eu des tentatives de connexion aux systèmes du NLRB à partir d'une adresse IP en Russie dans les jours qui ont suivi l'accès aux systèmes par le DOGE. Il a déclaré à Reuters mardi que les tentatives de connexion comprenaient apparemment des combinaisons correctes de nom d'utilisateur et de mot de passe, mais qu'elles avaient été rejetées par des politiques d'accès conditionnel liées à la localisation.

La déclaration sous serment de Berulis indique que ses efforts et ceux de son collègue pour enquêter officiellement et alerter l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) ont été interrompus par des supérieurs sans explication.

Alors que lui et ses collègues se préparaient à transmettre les informations qu'ils avaient recueillies à la CISA, il a reçu une note menaçante scotchée à la porte de son domicile, accompagnée de photographies de lui se promenant dans son quartier, prises par un drone, a déclaré Andrew Bakaj, conseiller juridique principal de Whistleblower Aid, dans sa soumission à Cotton et Warner.

« Contrairement à ce qui s'est passé auparavant, les gens ont peur de s'exprimer par crainte de représailles », a déclaré Berulis à Reuters. « Nous voyons des données qui sont traditionnellement protégées par les normes les plus strictes du gouvernement américain être prises et les personnes qui essaient d'empêcher cela, les personnes qui disent non, sont éliminées les unes après les autres ».

Le DOGE d'Elon Musk aurait réduit les effectifs des organismes de surveillance chargés d'enquêter sur les Teslas autonomes

Tesla est dans la tourmente avec une chute brutale de 55 % de ses actions par rapport à leur sommet de mi-décembre. Dans le même temps, les logiciels Autopilot et Full Self-Driving de Tesla font l'objet d'une enquête fédérale de la part de la NHTSA en raison de défaillances techniques qui ont conduit à des accidents graves, parfois mortels. Mais un rapport souligne que le DOGE d'Elon Musk s'en est pris au personnel chargé d'examiner la sécurité des véhicules autonomes comme ceux que Tesla veut construits. Environ 4 % du personnel de la NHTSA auraient été licenciés, une décision que les critiques considèrent comme un conflit d'intérêts.

Les critiques affirment qu'Elon Musk est mal placé pour diriger le DOGE. Dans un message publié en février sur X (ex-Twitter), l'ancien secrétaire au travail Robert Reich, qui a servi dans l'administration Clinton, a écrit : « la NHTSA est la dernière agence fédérale à être touchée par les licenciements du DOGE. C'est cette même agence qui a enquêté sur les accidents impliquant les voitures autonomes de Tesla. Il n'a jamais été question d'efficacité ».

Le sénateur démocrate Chris Murphy, du Connecticut, est également de cet avis...
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 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