Auteur Sujet: Le bug du 19 janvier 2038 à 3 h 14 min 8 s pourait impacter des trains / métros (Lu 352 fois)

mirtouf · « **le:** **Aujourd'hui** à 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.

basilix · « **Réponse #1 le:** **Aujourd'hui** à 15:36:37 »

C'est si difficile à corriger ?

Citer

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

alain_p · « **Réponse #2 le:** **Aujourd'hui** à 15:37:19 »

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

Mjules · « **Réponse #3 le:** **Aujourd'hui** à 15:52:08 »

Citation de: alain_p le Aujourd'hui à 15:37:19

(...)
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.

vivien · « **Réponse #4 le:** **Aujourd'hui** à 15:59:06 »

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

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.

basilix · « **Réponse #5 le:** **Aujourd'hui** à 17:43:14 »

@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 !

Citation de: vivien

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.

Citation de: lemondeinformatique

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. »

Citation de: ChatGPT

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 ».

Citation de: vivien

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.

Citation de: lemondeinformatique

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 ».

hwti · « **Réponse #6 le:** **Aujourd'hui** à 20:10:22 »

Citation de: alain_p le Aujourd'hui à 15:37:19

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.

vivien · « **Réponse #7 le:** **Aujourd'hui** à 21:54:43 »

Citation de: hwti le Aujourd'hui à 20:10:22

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, 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) 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.

alain_p · « **Réponse #8 le:** **Aujourd'hui** à 22:35:17 »

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.