La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: mirtouf le 06 décembre 2025 à 14:53:06
-
Le RER A et 8 lignes de métro bloqués en 2038 ? Alstom condamné à réparer un bug sur ses rames
Information l'Informé (Thierry Mestayer) : https://www.linforme.com/transports-auto/article/le-rer-a-et-8-lignes-de-metro-bloques-en-2038-alstom-condamne-a-reparer-un-bug-sur-ses-rames_3478.html
Extraits :
La RATP s’estime lésée par un problème logiciel grave qui pourrait empêcher ses voitures de circuler au-delà de 2037. Le fabricant, qui ne l’a pour l’instant pas corrigé, va devoir trouver une solution au risque de perdre gros.
[...]
La mise en service du nouveau matériel [MI09] s’étant déroulée sans accroc, la surprise a été grande quand des agents de la Régie ont découvert, le 5 octobre 2017, un vice caché dans les logiciels des nouvelles voitures. Lors d’une maintenance technique, ils se sont aperçus qu’ils ne pouvaient pas entrer une date supérieure à 2037 sur la console informatique d’une rame MI09. En fait, Alstom a conçu le système d’information embarqué des nouveaux trains avec « des calculateurs 32 bits signé », ne permettant le codage de la date et l’heure que jusqu’au 19 janvier 2038 à 3h14’7'', échéance dite « Echéance d’Horodatage 2038 ». Un bug bien connu des informaticiens, qui empêcherait ici la RATP de faire circuler les voitures à partir de cette date.
[...]
Mais, l’affaire ne s’arrête pas au RER A. Par précaution, la RATP a demandé que la défaillance logicielle constatée sur le matériel MI09 soit étudiée sur les autres matériels commandés au constructeur. L’analyse réalisée par Alstom a confirmé qu’un nombre conséquent était porteur du bug Posix. Lors d’une réunion contradictoire le 19 novembre 2018, Alstom Transport a révélé que cette faille pouvait concerner la totalité des matériels qu’elle a fournis dans le cadre de commandes publiques entre 1989 et 2014. À la suite, la RATP a été informée que le bug affectait les matériels utilisés pour huit lignes de métro : le MF01 (qui équipe la ligne 2 du métro parisien, la 5 et la 9), le nouveau MP 89 (les lignes 6 et 4), le MP05 (la ligne 1) et le MP 14 (les lignes 4, 11 et 14). Il était aussi présent sur le MI2N, utilisé sur la ligne de RER A, et sur trois tramways circulant sur six lignes différentes : le TW03 (la ligne T3 et T3b), TW07 (la T5), le TW09 (la T6) et le TW 10 (les T7 et T8). Soit au total, plus d’un tiers du réseau RATP.
[...]
Au terme de l’instruction, les magistrats ont rejeté tous les arguments du constructeur en confirmant que la plainte est recevable, qu’elle n’est pas prescrite, que la RATP est en droit de faire jouer « la garantie des vices cachés » et que « la responsabilité de la société Alstom Transport doit être engagée ». Constatant que « la mise à jour de l’horodatage des logiciels est d’une telle complexité qu’elle n’a pas encore fait l’objet d’une solution technique à ce jour », le tribunal ordonne à Alstom de réaliser, dans un délai très contraint, un état des lieux et de proposer des solutions. Ce chantier va nécessiter un grand nombre d’heures de travail pour les ingénieurs d’Alstom, afin de corriger le software voire peut-être aussi les équipements.
On verra si tout cela est résolu d'ici 2030 mais la décision risque de faire tache d'huile.
-
C'est si difficile à corriger ?
En ce qui concerne les processeurs 32 bits (notamment les systèmes embarqués), il semble que la solution en cours d’adoption par la GlibC et le kernel soit de basculer
sur un type time_t de 64 bits. Après mise à jour de la bibliothèque C et du noyau, il suffira de recompiler les applications pour que le système survive à l’année 2038.
Attention néanmoins aux applications qui stockent en fichiers et rechargent des données binaires (par exemple le contenu d’une structure avec un champ de type time_t)
qui nécessiteront un traitement plus complexe.
Source : Développement système sous Linux, 5e éd., de Christophe Blaess
-
Intéressant. On sait que le "bug" était présent dans les systèmes Linux (c'est un peu comme le bug de l'an 2000, où les anciens logiciels codaient la date sur 2 chiffres pour gagner de la place). Mais qu'il puisse être présent dans les logiciels d'Alsthom, c'est une découverte.
Qu'il puisse être présent sur d'anciens systèmes, cela se comprend, cela doit faire une dizaine d'années qu'on en parle sérieusement, sinon la date paraissait encore lointaine. Qu'il soit présent sur des matériels récents, c'est beaucoup plus surprenant. Et je ne vois pas de raison qu'Alsthom ne puisse pas upgrader les logiciels récents pour qu'ils passent la date de 2038.
https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038
-
(...)
Qu'il puisse être présent sur d'anciens systèmes, cela se comprend, cela doit faire une dizaine d'années qu'on en parle sérieusement, sinon la date paraissait encore lointaine. Qu'il soit présent sur des matériels récents, c'est beaucoup plus surprenant. Et je ne vois pas de raison qu'Alsthom ne puisse pas upgrader les logiciels récents pour qu'ils passent la date de 2038.
https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038
C'est ce qui me laisse perplexe aussi. Que le matériel produit entre 1998 et 2014 soit affecté parait assez « normal », on a commencé à en parler assez « récemment », par exemple, l'article anglais de wikipedia date de 2005 (le français de 2006) et une des premières références est de 1999.
Mais le bug a été découvert en 2017, il y a 8 ans et ils n'auraient toujours pas de solution d'après l'article.
-
Le bug du 19 janvier 2038 à 3 h 14 min 8 s, temps universel, est connu depuis longtemps. On en parlait déjà en 1999 alors que le bug des ordinateurs qui stockent l'année sur 2 chiffres (Les Unix n'étaient pas impactés par ce bug, mais par celui de 2038).
Le bug de 2038 ne concerne que les systèmes d'exploitations 32 bits qui stockent la date sur 32 bits signé comme un nombre de secondes écoulées depuis le 1ᵉʳ janvier 1970 à 0 heure en temps universel.
Un nombre signé peut être négatif si le premier bit est un 1.
19 janvier 2038 à 3 h 14 min 7 s = 2 147 483 647 secondes (01111111 11111111 11111111 11111111 en binaire)
19 janvier 2038 à 3 h 14 min 8 s on passera à 10000000 00000000 00000000 00000000 en binaire, soit −2 147 483 648 secondes (13 décembre 1901 à 20 h 45 min 52 s)
Les systèmes d'exploitation 64 bits stockent la date en 64 bits et ne sont pas impactés (tous les programmes compilés en 64 bits utilisent un time_t 64bits). Votre PC n'est donc pas concerné (il peut être présent dans des logiciels qui stocke la date dans des fichiers, comme par exemple le format ZIP).
Longtemps (moi aussi), on a pensé que les systèmes d'exploitations 64 bits auront totalement remplacé les systèmes 32 bits en 2038. Le fait que la RATP porte en 2017 en justice un bug qui n'interviendra que 20 ans plus tard montre le contraire : certains systèmes ont une durée de vie très longue. Le trains du RER B, MI-79, mis en service en servie à partir de 1980 seront encore en service pour au moins 5 ans.
J'ai quand même un doute sur le fait que l'informatique des rames RATP concernées ne soit pas remplacée lors de la rénovation à mi-vie ou beaucoup de choses sont changées. La ligne 14 vient de changer son système de conduite autonome (juste avant les JO de Paris 2024, c'était un pré-requis pour l'extension de la ligne). De mémoire, on était avant la bascule sur un Motorola 68040, microprocesseur 32 bits utilisé par les premiers Mac. Les RER A MI 09 ont été mis en service entre 2011 à 2017. Ils devraient donc avoir une rénovation mi-vie entre 2031 et 2037 ou je pense que l'informatique sera modernisée.
S'il y a eu rapidement des correctifs pour passer la date en 64 bits sur des systèmes 32 bits, ce qui n'est pas simple, c'est tous les programmes et bibliothèques doivent tous utiliser la même taille de stockage pour time_t. Comme vous pouvez le deviner, il existe des milliers de logiciels concernés et aucun moyen de faire une transition : tout doit changer en même temps.
Un article récent : Pour éviter le bug de 2038, Debian bascule son horloge en 64 bits (https://www.lemondeinformatique.fr/actualites/lire-pour-eviter-le-bug-de-2038-debian-bascule-son-horloge-en-64-bits-97567.html)
J'ai par contre du mal à comprendre, vu que Debian 13 (Trixie), publiée le 9 août 2025, a supprimé l'architecture Intel 32 bits et que les versions 64 bits ont dès le début codé la date sur 64 bits.
Il serait intéressant d'avoir les retours de la SNCF, qui a du également faire quelques tests. Il ne fait aucun doute que le bug n'est pas limité au périmétre RATP. Le bug pourait aussi être présente dans l'aviation.
-
@vivien : L'hyperlien de ton message renvoie sur un autre sujet. [edit vivien : corrigé]
https://www.lemondeinformatique.fr/actualites/lire-pour-eviter-le-bug-de-2038-debian-bascule-son-horloge-en-64-bits-97567.html
Intéressant !
S'il y a eu rapidement des correctifs pour passer la date en 64 bits sur des systèmes 32 bits, ce qui n'est pas simple, c'est tous les programmes et bibliothèques doivent tous utiliser la même taille de stockage pour time_t.
Comme vous pouvez le deviner, il existe des milliers de logiciels concernés et aucun moyen de faire une transition : tout doit changer en même temps.
Une des solutions pour éviter ce risque est de remplacer le stockage des dates par des variables 64 bits au lieu de 32 bits. Elle accorde un répit confortable de plus de 292 milliards d’années. Mais pour les mainteneurs de Debian,
cette tâche s’est révélée ardue. En effet, il a été nécessaire de travailler sur 6 500 paquets et en une seule fois, car cela impliquait également une modification de l’interface binaire d’application (ABI). Cette dernière agit
entre deux composants logiciels pour gérer l’allocation des registres et l’agencement de la mémoire.
Hyperlien : Article « Pour éviter le bug de 2038, Debian bascule son horloge en 64 bits. (https://www.lemondeinformatique.fr/actualites/lire-pour-eviter-le-bug-de-2038-debian-bascule-son-horloge-en-64-bits-97567.html) »
Résumé simple
- Oui, time_t est un typedef.
- Non, ça ne casse pas directement la compilation.
- Mais changer time_t → change la taille de dizaines de structures glibc → casse :
- assertions,
- sérialisations binaires,
- bindings de langages,
- offsets mémoire,
- ABI complète,
- dépendances de bibliothèques.
C’est pour ça qu’on dit que « certains paquets cassent ».
J'ai par contre du mal à comprendre, vu que Debian 13 (Trixie), publiée le 9 août 2025, a supprimé l'architecture Intel 32 bits et que les versions 64 bits ont dès le début codé la date sur 64 bits.
Il ajoute que « la plupart des calculs, notamment ceux utilisant Debian ou ses dérivés, sont désormais réalisés sur du matériel 64 bits, où ce problème ne se pose pas. Cependant, de nombreux calculs 32 bits,
plus coûteux, sont encore disponibles et sont encore livrés sur des terminaux (automobile, IoT, téléviseurs, routeurs, contrôle d'usine, surveillance/contrôle de bâtiments, téléphones Android bon marché, etc.),
dont une partie fonctionne probablement sous Debian ou ses dérivés ».
-
Qu'il puisse être présent sur d'anciens systèmes, cela se comprend, cela doit faire une dizaine d'années qu'on en parle sérieusement, sinon la date paraissait encore lointaine. Qu'il soit présent sur des matériels récents, c'est beaucoup plus surprenant. Et je ne vois pas de raison qu'Alsthom ne puisse pas upgrader les logiciels récents pour qu'ils passent la date de 2038.
Quand il est question de matériels de 1989, je doute que le cahier des charges demande un fonctionnement pendant 50 ans, donc ça se comprend.
En revanche pour tout ce qui est postérieur à l'an 2010, non seulement il y aurait dû avoir le souvenir de l'an 2000, mais en plus le problème arriverait avant 30 ans (qui est une durée standard pour du matériel ferroviaire).
La mise à jour de logiciels est probablement très compliquée : vieux systèmes, fournisseurs tiers, possiblement des formats de fichier ou de stockage de données à faire évoluer...
C'est une raison de plus qui aurait dû justifier une bonne conception des matériels récents comme le MI09, le faire après coup va couter bien plus cher.
-
avant 30 ans (qui est une durée standard pour du matériel ferroviaire).
30 ans, c'est un peu court (sauf si tu parles de la rénovation à mi-vie).
Je donne un exemple, les métros des lignes 3, 3bis, 10 et 12 est le MF67 (https://fr.wikipedia.org/wiki/MF_67), mise en service entre 1967 à 1978.
Certaines rames qui circulent en 2025 ont déjà roulé pendant 58 ans (on ne dépasse normalement pas les 60 ans).
Après, il existe du matériel, qui à cause d'erreurs, ont une courte durée de vie. Je pense au MI 2N Eole (ou Z 22500) (https://fr.wikipedia.org/wiki/Z_22500) qui en version SNCF circulent sur la ligne E et sont en train d'être retiré sans avoir de nouvelles affectations. C'est du matériel mis en service entre 1996 à 2000. Quand je vois circuler tous les jours du vieux matériel pour les TER Bourgogne-Franche-Comté (il y a des Z 5600 de 1982 au départ de la gare de Lyon et des trains corail avec locomotive qui accuse bien les années depuis la gare de Bercy en plus de matériel plus moderne), je me dis que les MI 2N seraient appréciés par rapport au Z 5600.
-
Bon, on va espérer que ce n'est pas la même chose pour les centrales nucléaires, construites dans les années 70 et 80, et qui sont sensées aller bien au delà de 2038, et qui comportent du matériel Alsthom, par exemple des turbines.
-
30 ans, c'est un peu court (sauf si tu parles de la rénovation à mi-vie).
Je donne un exemple, les métros des lignes 3, 3bis, 10 et 12 est le MF67 (https://fr.wikipedia.org/wiki/MF_67), mise en service entre 1967 à 1978.
Certaines rames qui circulent en 2025 ont déjà roulé pendant 58 ans (on ne dépasse normalement pas les 60 ans).
Après, il existe du matériel, qui à cause d'erreurs, ont une courte durée de vie. Je pense au MI 2N Eole (ou Z 22500) (https://fr.wikipedia.org/wiki/Z_22500) qui en version SNCF circulent sur la ligne E et sont en train d'être retiré sans avoir de nouvelles affectations. C'est du matériel mis en service entre 1996 à 2000. Quand je vois circuler tous les jours du vieux matériel pour les TER Bourgogne-Franche-Comté (il y a des Z 5600 de 1982 au départ de la gare de Lyon et des trains corail avec locomotive qui accuse bien les années depuis la gare de Bercy en plus de matériel plus moderne), je me dis que les MI 2N seraient appréciés par rapport au Z 5600.
J'avais ce chiffre en tête pour du matériel moderne (je sais par exemple que les corails ont duré bien plus longtemps), mais en fait c'est plutôt pour les TGV.
Les vieilles rames de métro ou autres ne sont pas vraiment représentatives, ce n'est pas informatisé.
J'ai du mal à imaginer qu'un système moderne puisse durer 50-60 ans, donc si les caisses restent exploitées ce sera peut-être en remplaçant toute l'électronique.
-
Aujourd'hui, il y a une rénovation à mi-vie avec démontage intégral des trains (et changement de tout ce qui est électronique / informatique / sièges / décoration) et il est question pour le matériel moderne de faire des rénovations à tiers-vie, donc 3 rénovations dans la vie du matériel.
Rénovation à mi-vie d'un TGV : (c'est à cette occasion qu'il peut devenir un Ouigo, il n'y a pas de TGV neuf en Ouigo, ce sont toujours des TGV inOui qui sortent d'une rénovation mi-vie)
https://www.youtube.com/watch?v=rZp9aP32db0
Un train qui a une durée de vie moins de 30 ans (généralement sans avoir eu de rénovation mi-vie), c'est une anomalie, que ce soit pour des RER (MI 2N Éole du RER E) ou des TGV (TGV Atlantique) :
https://www.youtube.com/watch?v=gE9Hj3jomJc
Pour le MI 2N Éole du RER E, le matériel n'était pas adapté au mass-transit et la conduite autonome (avec conducteur) NExTEO qui va être mis en place sur le RER B, RER D et RER E (les 3 lignes vont voir leur matériel roulant renouvelé). La page Wikipédia explique bien qu'ils ont cherché des débouchés pour ce matériel, mais il n'a pas été trouvé. Par exemple sur le RER C, cela aurait nécessité un rehaussement complet des quais.
https://www.youtube.com/watch?v=NCSY1u9LVO4
-
Aujourd'hui, il y a une rénovation à mi-vie avec démontage intégral des trains (et changement de tout ce qui est électronique / informatique / sièges / décoration) et il est question pour le matériel moderne de faire des rénovations à tiers-vie, donc 3 rénovations dans la vie du matériel.
Les aménagement intérieur (sièges, prises, ...) et l’électronique de l'information voyageur, oui.
L'électronique liée à la conduite du train, je ne sais pas si elle est remplacée par quelque chose de plus récent, surtout sur des modèles à motorisation répartie.
Tu dis bien que les MI2N Eole n'étaient pas adaptables à NExTEO.
-
Sans vouloir faire dévier le sujet, NExTEO étant remisé aux calendes grecques, les Z22500 auraient pu encore rouler quelques années de plus moyennant un rafraichissement bienvenu.
-
Pou revenir sur le sujet :
La RATP s’estime lésée par un problème logiciel grave qui pourrait empêcher ses voitures de circuler au-delà de 2037. Le fabricant, qui ne l’a pour l’instant pas corrigé, va devoir trouver une solution au risque de perdre gros.
Alstom a 5 ans à Alstom pour corriger le logiciel. Tout retard donnera lieu à une amende d'un million d'euros par mois.
Un état des lieux devra être fait d'ici à un an.
Alstom a annoncé faire appel de la décision.
Je ne suis pas sûr que la correction soit si couteuse à réaliser, une mise à jour logicielle pourait suffire. Ce sont par contre peut-être les certifications nécessaires qui vont être couteuses.
D'autres opérateurs pourraient demander la correction, il n'est évidemment pas limité au périmètre RATP.
Ce qui est bien c'est que s'y prendre en 2025, cela laisse plus de 11 ans pour corriger le problème, c'est royal.
-
Je pense qu'on doit trouver des systèmes embarqués temps réels pour lesquels le fabricant va sans doute répondre: le produit est EOL, aucun support même payant ne vous sera fourni, veuillez le remplacer avant 2038.
Pour les systèmes Linux, une mise à niveau vers un noyau > 5.6 sera nécessaire et devrait être possible moyennant des frais de développement surtout s'il y a des SDK employés qui ne sont plus maintenus pour être compatibles avec l'ABI qui gère time_t en 64 bits.
-
Dans 50 ans probablement: "La fonction freinage d'urgence avant arrivé en gare si le conducteur perd connaissance était basé sur une librairie halluciné par IA" :o
-
Dans le domaine du ferroviaire, tout ce qui est sécurité est redondé, testé et re-testé. Le niveau d'exigence n'est pas si éloigné de celui de l'aérien.
Je crois que le dispositif homme mort est testé à chaque sortie de garage.
Franchement, je sais que quel que soit le niveau d'automatisation des lignes (niveau 2 pour NExTEO pour les tronçons central des RER B, D et E ou Niveau 4 pour plusieurs lignes de métro), la sécurité sera toujours assurée peu importe les événements.
Quand il y a une catastrophe, il y a une série d'erreurs humaines et des dispositifs techniques qui n'ont pas joué leur rôle qui est impressionnant.
https://www.youtube.com/watch?v=sx6gAVGj45M
-
Dans 50 ans probablement: "La fonction freinage d'urgence avant arrivé en gare si le conducteur perd connaissance était basé sur une librairie halluciné par IA" :o
J'ai trop pensé à toi sur ce nouveau problème pour Alstom (sans aucun lien avec le bug du 19 janvier 2038) : Problème sur le freinage d'urgence, qui a déjà provoqué un accident de tramway à Strasbourg :
(https://lafibre.info/images/transport/202512_beatt_freinage_urgence_alstom_1.avif)
(https://lafibre.info/images/transport/202512_beatt_freinage_urgence_alstom_2.avif)