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 !

Des retraités déclarés morts par « erreur » par le DOGE d'Elon Musk ne peuvent plus bénéficier de la sécurité sociale ni utiliser leurs comptes bancaires
Tandis que Musk mène la guerre contre le gaspillage

Le , par Stéphane le calme

37PARTAGES

9  0 
C’est une situation surréaliste qui frappe des milliers d’Américains âgés : ils ont découvert que, pour l’administration, ils étaient morts alors qu’ils sont bien vivants. Depuis mars-avril 2025, de nombreux retraités et allocataires de la Social Security (Sécurité sociale américaine) voient soudain leurs pensions suspendues et leurs comptes bloqués, tout simplement parce qu’ils ont été radiés par erreur des registres officiels des vivants. À l’origine de ce fiasco : une initiative gouvernementale controversée pilotée par Elon Musk et surnommée DOGE (pour Department of Government Efficiency)​

L’équipe de Musk, chargée de traquer les paiements indus, a obtenu un accès aux bases de données de la Social Security et a entrepris de les « nettoyer » des bénéficiaires supposés décédés. Concrètement, les agents de la DOGE auraient contourné les protocoles de sécurité pour déplacer environ 4 millions de numéros de Sécurité sociale vers le fichier national des décès (Death Master File). Parmi ces millions de radiations figurent malheureusement de véritables vivants que la machine bureaucratique a « tués » par inadvertance.

Pourquoi une telle purge ? Elon Musk affirme depuis plusieurs mois que des millions d’Américains décédés continuent indûment de percevoir des prestations, ce qu’il juge emblématique du gaspillage public. Il a même avancé le chiffre extravagant de 20 millions de centenaires touchant une pension, alors qu’on ne recense qu’environ 100 000 centenaires aux États-Unis selon les statistiques de Pew Research.

Citation Envoyé par Elon Musk
Selon la base de données de la sécurité sociale, ce sont les nombres de personnes dans chaque tranche d'âge avec le champ de décès réglé sur FALSE !

Peut-être que Twilight est réel et qu'il y a beaucoup de vampires qui perçoivent des prestations de sécurité sociale 🤣🤣🤣🤣🤣.
[TWITTER]<blockquote class="twitter-tweet"><p lang="en" dir="ltr">According to the Social Security database, these are the numbers of people in each age bucket with the death field set to FALSE!<br><br>Maybe Twilight is real and there are a lot of vampires collecting Social Security 🤣🤣 <a href="https://t.co/ltb06VX98Z">pic.twitter.com/ltb06VX98Z</a></p>— Elon Musk (@elonmusk) <a href="https://twitter.com/elonmusk/status/1891350795452654076?ref_src=twsrc%5Etfw">February 17, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> [/TWITTER]

Sur la foi de ces allégations (démenties par les statisticiens), la DOGE a mis sur pieds une unité chargée de traquer fraudes et « morts-vivants » dans l’administration. En mars 2025, la DOGE a ainsi annoncé avoir identifié et supprimé d’un coup 3,2 millions de noms de la base de la Social Security – tous présentés comme âgés de plus de 120 ans – en les marquant « décédés ».


« Ces deux dernières semaines, @SocialSecurity a procédé à un important nettoyage de ses dossiers. Environ 3,2 millions de titulaires de numéros, tous répertoriés comme âgés de plus de 120 ans, ont été marqués comme décédés. Il reste encore du travail à faire », a déclaré l'agence dans un message sur X.

Mais très vite, des cas problématiques ont émergé : des bénéficiaires bien en deçà de 120 ans, bel et bien en vie, se sont retrouvés accidentellement rayés des listes.


Des conséquences dramatiques pour les « morts administratifs »

Pour les personnes touchées, être déclaré mort à tort par l’État est loin d’être anodin : « Quand ils vous enregistrent comme décédé, c’est toute votre vie qui s’arrête. Ça bloque vos paiements de voiture, vos crédits, votre identité est signalée… » explique un employé de la Social Security, décrivant l’enchaînement catastrophique qui frappe ces victimes​.

Du jour au lendemain, les versements mensuels cessent, l’accès aux comptes bancaires est coupé et les couvertures de santé comme Medicare sont annulées. Richard VanMetter, un physicien retraité de 76 ans, a ainsi découvert en février 2025 que le gouvernement l’avait déclaré mort lorsqu’il a voulu payer un simple sandwich et que sa carte bancaire a été refusée. « J’ai appelé ma banque, qui m’a dit que l’administration avait informé tous les organismes financiers que j’étais décédé », raconte-t-il au Washington Post. L’État avait même repris le dernier chèque de pension versé et coupé sa retraite à venir.

Il s'est rendu dans un bureau de la sécurité sociale où il passait ses vacances et a dit à l'agent de sécurité : « Bonjour, je suis mort ». La réponse qu'il a reçue a été : « Encore un ». Il dit avoir eu de la chance parce qu'il avait son passeport sur lui et que le bureau où il s'est rendu était réactif et bien pourvu en personnel. VanMetter se bat encore pour récupérer ses prestations : « C’est le fléau de mon existence », confie-t-il désabusé.

[TWITTER]<blockquote class="twitter-tweet"><p lang="en" dir="ltr">When government thinks you’re dead, it makes things hard - and DOGE may make it worse. Musk’s team has moved millions of Social Security numbers into the agency's deaths database, raising the risk of errors, by <a href="https://twitter.com/MerylKornfield?ref_src=twsrc%5Etfw">@MerylKornfield</a> <a href="https://twitter.com/FedGirlWaPo?ref_src=twsrc%5Etfw">@FedGirlWaPo</a> <a href="https://twitter.com/hannah_natanson?ref_src=twsrc%5Etfw">@hannah_natanson</a> <a href="https://t.co/0twTSB1N7H">https://t.co/0twTSB1N7H</a></p>— Juliet Eilperin (@eilperin) <a href="https://twitter.com/eilperin/status/1915052814033932459?ref_src=twsrc%5Etfw">April 23, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> [/TWITTER]

Partout dans le pays, des scènes ubuesques se répètent : des seniors se présentent en personne aux guichets de la Social Security avec pièce d’identité à la main pour clamer « Je ne suis pas mort, je suis bien vivant ! » Chaque bureau local doit entamer une procédure de « résurrection » administrative pour retirer ces citoyens de la liste des morts. « On va devoir ressusciter beaucoup de monde », anticipe ironiquement Rennie Glasgow, analyste technique depuis 15 ans à la Social Security. Il décrit un processus long de 3 à 4 jours en moyenne pour rétablir quelqu’un dans ses droits, tant le système est lourd : « Ce n’est pas aussi simple que de décocher une case ‘vivant’. On a parfois l’impression de devoir reconstruire tout le dossier informatique de la personne​ ».

En attendant, les intéressés restent sans revenus. Certains retraités modestes se retrouvent en grande détresse financière du fait de quelques jours de retard de pension. « Nous voyons tous les jours des gens venir avec leur carte d’identité dire qu’ils sont vivants, et en attendant ils se demandent comment ils vont manger le lendemain » témoigne un agent, soulignant l’angoisse de ces aînés privés de ressources​.

Des erreurs similaires en France dues à de simples fautes de frappe

Ce type d’erreur administrative kafkaïenne n’est pas propre aux États-Unis. En France, on recense régulièrement des cas de personnes déclarées mortes par méprise ou victimes de graves bévues dues à de banals fautes de frappe ou de saisie. Deux exemples récents illustrent comment une simple coquille peut bouleverser des vies et quelles mesures ont été prises pour y remédier.

Pension suspendue pour une retraitée « décédée » par erreur

En décembre 2024, Martine, 72 ans, une retraitée de Savoie, a eu la stupeur d’apprendre que l’administration la considérait comme morte depuis un mois et demi. Elle s’en est rendu compte en constatant que sa pension de retraite ne lui était plus versée. En réalité, Martine avait été confondue avec sa cousine décédée peu de temps auparavant : en gérant les démarches administratives liées au décès de cette cousine, son nom aurait été enregistré par erreur dans le fichier des personnes décédées.

Conséquence immédiate, la septuagénaire a dû prouver qu’elle était bien en vie pour recouvrer son dû. « Madame, vous êtes déclarée décédée… » lui a-t-on annoncé au guichet, alors même qu’elle parlait au fonctionnaire.

Pendant des semaines, Martine a multiplié les démarches et attestations pour être « ressuscitée » administrativement. Elle a fini par obtenir gain de cause et le versement de sa pension a repris, non sans difficultés. Son cas est loin d’être isolé : sur les deux dernières années, au moins une douzaine de Français ont été déclarés morts à tort de la même manière​.

Jean Poulain, retraité normand de 75 ans, a par exemple reçu un courrier officiel lui demandant… son propre acte de décès. « On suppose que je suis mort, et tout se retrouve bloqué : comptes bancaires, mutuelle, remboursement sécu… tout est bloqué », s’est indigné Poulain, qui a dû lui aussi prouver qu’il était bien en vie pour débloquer la situation. D’après la Caisse d’assurance retraite (Carsat), l’erreur provenait d’un agent administratif ayant saisi une mauvaise information informatique – une simple erreur humaine en somme.

Dans d’autres cas, c’est un homonyme décédé qui est en cause. « À l’origine de ces couacs : une erreur informatique commise par un agent, ou encore parfois une confusion avec une personne ayant le même nom », résume ainsi un responsable interrogé par TF1. Une fois l’erreur admise, les caisses procèdent généralement à la réactivation du dossier et au rattrapage des paiements manqués. Aucune sanction n’est prise...
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 
Avatar de _toma_
Membre éclairé https://www.developpez.com
Le 10/05/2025 à 1:47
Elon Musk au DOGE : réforme technocratique ou machine à espionner les syndicats ?

L'intervention du DOGE au NLRB au début du mois de mars 2025 soulève de sérieuses questions. Sous la direction d'Elon Musk, conseiller de la Maison Blanche, des équipes se sont présentées au siège de l'agence indépendante, prétextant un audit d'efficacité. Leur véritable objectif semblait cependant être l'accès aux systèmes contenant des informations hautement sensibles sur les mouvements syndicaux et les entreprises.

Ces événements mettent en lumière des pratiques administratives pour le moins douteuses. Le recours à des prétextes bureaucratiques pour justifier ce qui ressemble à une opération d'espionnage interne interroge profondément sur les méthodes et les intentions réelles du DOGE. Derrière le discours officiel d'optimisation se cacherait une volonté de contrôle informationnel aux implications potentiellement graves pour les libertés publiques.
En novembre 2024, spacex et amazon se sont retrouvées devant une cour de justice pour plaider l'inconstitutionnalité de la NLRB (l'équivalent de l'inspection du travail)
Pas de complot, juste des idées qui suivent leur cours.

https://next.ink/158528/amazon-et-sp...il-americaine/
1  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 11/05/2025 à 11:01
Citation Envoyé par Bruno Voir le message
L'ordinateur d'un ingénieur logiciel de la DOGE infecté par un logiciel malveillant de vol d'informations,
les cybercriminels capturent frappes clavier et données d'écran
Ah, ils utilisent Recall?
1  0