LEBIGDATA.FR I.A, Cloud & Cybersécurité
Le tribunal administratif de Paris a rendu sa décision le 13 novembre 2025. La justice accuse Alstom d’avoir intégré un système fragile dans des trains franciliens sans prévenir la RATP.
Il s’agit du fameux bug de l’an 2038. Et apparemment, est présent dans de nombreux matériels livrés entre 1989 et 2014. Explications.
Mais c’est quoi, un bug de l’an 2038 ?
Le bug de l’an 2038 provient d’une méthode de calcul du temps largement utilisée. Les systèmes concernés comptent les secondes depuis le 1er janvier 1970, grâce au timestamp Unix. Ce compteur atteint aujourd’hui plusieurs milliards de secondes sans difficulté.
Certaines architectures ne savent pas dépasser un seuil précis, fixé à un peu plus de deux milliards. Cette limite correspond à la date du 19 janvier 2038, peu après 4h du matin.
Une fois ce seuil franchi, la valeur bascule dans le négatif. La date affichée devient incohérente et les logiciels perdent leurs repères. Des systèmes modernes utilisent des solutions qui repoussent cette limite très loin dans le futur. Les architectures 64 bits ne rencontrent plus ce problème.
Le souci apparaît uniquement sur les systèmes en 32 bits signés. Or, le réseau francilien contient encore des équipements fondés sur cette technologie. Alstom a intégré ces systèmes lors de la conception de plusieurs matériels.
La justice estime alors que le constructeur n’a pas signalé cette faiblesse à la RATP. Ce qui place désormais l’exploitant public dans une situation délicate.
La RATP doit composer avec un parc vieillissant. Une partie des trains repose sur des logiciels incapables d’aller au-delà de 2038. Le recours judiciaire cherche à clarifier les responsabilités dans cette affaire technique. Le tribunal considère que la RATP peut invoquer la garantie des vices cachés
Comment la RATP a découvert le problème ?
Au fait, le souci a été remarqué en 2017 lors d’une opération de maintenance. Les équipes ont tenté d’enregistrer une date supérieure au seuil de 2038. Le système d’un modèle présent sur la ligne A du RER a refusé la requête. Cette limite inattendue a immédiatement attiré l’attention des techniciens.
La direction a alors demandé une analyse complète à Alstom. Le constructeur a examiné le modèle concerné pour comprendre l’origine du blocage. Les investigations ont mis en lumière 38 programmes embarqués touchés par la faille. La RATP a alors demandé une inspection plus large.
L’affaire a pris un autre tournant lors de cette nouvelle demande. Alstom a reconnu que la faille touchait un nombre important d’équipements livrés au fil des années. Le constructeur estime même que des matériels fournis pour des commandes publiques entre 1989 et 2014 pourraient être concernés. La portée dépasse largement le premier modèle examiné.
Le réseau francilien apparaît structurellement affecté. Neuf lignes de métro, une ligne de RER et six lignes de tramway pourraient rencontrer cette limite en 2038. L’exploitant public doit anticiper un plan de correction complexe. La justice demande un état des lieux complet et une stratégie de remédiation.
Alstom peut-il corriger le problème à temps ?
Eh bien, Alstom a expliqué ne pas pouvoir rendre les logiciels compatibles au-delà de 2038 en l’état. Selon Le Parisien, le constructeur affirme avoir suivi les recommandations de la RATP lors du choix initial. Les logiciels retenus étaient issus de solutions open source souvent conçues en 32 bits. Le constructeur a donc décidé de contester la décision rendue par la justice.
La décision du tribunal impose un calendrier strict. Alstom doit dresser un état complet des systèmes concernés dans un délai d’un an. Un retard entraînerait une pénalité mensuelle de 100 000 euros. Le constructeur devra ensuite présenter une solution technique dans les deux ans.
La mise en œuvre opérationnelle représentera une autre phase complexe. Alstom devra corriger l’ensemble du matériel dans un délai supplémentaire de deux ans. Le chantier devra être finalisé avant 2030 selon les conditions fixées. La pénalité passerait alors à un million d’euros par mois de retard.
L’enjeu concerne la continuité du réseau. Le parc doit être fonctionnel en 2038 pour éviter un blocage logiciel.
Restez à la pointe de l'information avec LEBIGDATA.FR !
- Partager l'article :
