Le RER A et huit lignes de métro risquent l’arrêt total en 2038. Un défaut logiciel, imputé à Alstom, vient d’entraîner la condamnation de l’industriel français, qui l’avait dissimulé.
Je serai assez curieux de savoir quel est l’impact, ou du moins pourquoi saisir la bonne date sur le système du train et si important. Autant que je sache la date n’a pas de lien avec la conduite d’un matériel. Si je pourrais éventuellement comprendre sur certaines lignes comme la A ou cela serait nécessaire pour le système de séparation des trains, les Metros et Tramway sont eux bien plus simple.
Lors des échanges d’information avec le réseau, il y a sans doute pas mal de cas où les données sont associées à un timestamp, pour s’assurer de leur pertinence (recevoir une information sur un problème d’il y a 3 jours par exemple, c’est pas bien utile).
Il y a sans doute aussi des authentification/chiffrement qui s’appuient sur des certificats, certificats dont les durées de validités sont toujours bornées dans le temps. Ça tu peux en faire l’expérience tout simplement sur le web en HTTPS. Avance ou retarde la date de ton PC de dix ans, et hop, tu ne pourras plus aller sur Clubic par exemple (du moins, tu auras une alerte de sécurité, que ton navigateur t’autorisera peut-être à ignorer… mais dans un contexte industriel, souvent on n’autorise pas à passer outre les procédures de sécurité), parce que le certificat SSL a une fenêtre de validité réduite, d’à peine 90 jours :
Voilà ce que ça donne par exemple si je met la date au 10 octobre au lieu du 10 décembre :
5 « J'aime »
C’est juste que la date est codé sur un entier de 32bits, qui compte le nombre de secondes depuis le 1er janvier 1970 à minuit
3 « J'aime »
Le passage à un horodatage sur 64 bits repousse la date butoir se situant au dimanche 4 décembre 292 277 026 596 apr. J.-C. à 20 h 10 min 55 s UTC, soit environ 21 fois l’âge de l’Univers
ca devrait suffire 
5 « J'aime »
Ce qui m’étonne grandement c’est que ni Alstom, NI la RATP ait réagit alors que le soucis POSIX (bug de 2038) est connu depuis plus de 20 ans. Et confirmé par les tests destechos de la ratp en 2017.
Il y a un bi-laxisme évident.
1 « J'aime »
J’espère que la RATP a donné une médaille et une grosse prime à l’agent qui a découvert le bug.
Titre racoleur et abject juste pour nous amener à cliquer … c’est de pire en pire sur un paquets de sites qui sont devenus des catalogues publicitaires qui, parfois , insèrent des articles récupérés à droite et à gauche …
4 « J'aime »
1 « J'aime »
Merci pour l info ! C est ce qui manquait à l’article.
2 « J'aime »
Je serais déjà millionnaire si j’avais eu une prime sur chaque bug lourd détecté (an 2000 comme an 2038)!
Ce sont des problèmes connus et courants, avec des solutions faciles. Ca m’a donné pas mal de boulot juste avant 2000, les boites ne se réveillant en général qu’au dernier moment. 
Pour 2038, je serai trop vieux pour me faire de la thune… 
Il est même connu depuis l’origine de posix!
Mais à l’époque, on imaginait aucun système avec une telle durée de vie.
Et je suppose que pour le métro ça a été pareil, et ils ont bien prévu le coup avec la « sécurité » dans la saisie de date.
2 « J'aime »
Un technicien de la RATP tente de saisir une date supérieure à 2037
pourquoi ? 
le technicien connait ce bug de l’an 2038 ?
et ça ne concerne pas que la RATP, vu que le Y2038 est connu.
1 « J'aime »
Merci de respecter un minium de neutralité dans une affaire qui vise une entreprise française stratégique.
Alstom explique que le risque lié au « bug de l’an 2038 » était un problème informatique connu de longue date dans le secteur et documenté dès la fin des années 1990, et soutient que la RATP en avait connaissance.[1][2]
Ce qu’Alstom met en avant
- Alstom rappelle que le « bogue POSIX » de 2038, lié au comptage du temps en 32 bits, est décrit dans la documentation technique depuis 1999 et fait partie des risques connus par les informaticiens et les exploitants.[2][1]
- L’entreprise indique que l’échéance d’horodatage 2038 figure dans les normes et publications techniques, sous-entendant que la RATP ne pouvait ignorer l’existence théorique du problème.[1][2]
Ce que le tribunal répond à Alstom
- Les juges ont estimé que, même si le bug de 2038 était connu en général, la RATP n’avait pas une connaissance précise du vice affectant ces matériels particuliers, notamment le fait que les consoles ne permettent pas d’aller au‑delà de 2037.[3][2][1]
- Le tribunal considère qu’Alstom aurait dû proposer une solution plus pérenne (par exemple du 64 bits) et ne pas se contenter de masquer le problème en bloquant la date, ce qui a conduit à qualifier le défaut de « vice caché » et à condamner Alstom à identifier et corriger les logiciels concernés dans des délais imposés.[2][3][1]
2 « J'aime »
Pas impossible, c’est quand même une conaissance répendue chez les informaticiens. Et les tests aux limites, c’est aussi une bonne pratique!
C’est sûr!
@Binbin
En fait il faudrait surtout voir le cahier des charges et les spécifications (et qui les a faites et comment elles ont été validées). Il y a peut être un décalage entre ce qui est signé et l réalisation…
Souvent la justice estime que le devoir de conseil n’a pas été respecté quand un problème évident et évitable pour la MOA voir la MOE n’a pas été traité clairement en amont.
Et sinon, il semblerai logique que le support de ces consoles soit borné dans le temps et que d’ici la fin, le retrofit de ces rames soit obligatoires pour être mise au gout du jour. J’ai du mal à croire qu’une fois vendues dans les années 2000, contractuellement elles doivent durer près de 40 ans sans rien faire dessus… 
Il n’a rien découvert de nouveau
Clairement, le bug de 2038 était déjà évoqué dans l’actu high-tech… en 1999. En effet, les articles nous rassuraient sur l’apocalypse du fameux « bug de l’an 2000 » et évoquaient surtout ce problème du 32 bits d’ici 2038.
Et pourtant j’étais juste « un ado geek » à cette époque, alors que les ingénieurs d’Alstom n’y ai pas pensé me paraît assez honteux.
Après cela concerne peut-être les rames les plus anciennes et expliquerait pourquoi on nous évoque uniquement certaines lignes.