Connaissez-vous le bug de 2038 ? Le 19 janvier 2038, à 3 h 14 min et 7 s UTC, des de milliards de machines vont voyager dans le temps puisque leurs horloges vont passer au 13 décembre 1901, 20 h 45 min et 52 sec UTC. Il est à peu près certain qu’elles risquent alors de tomber en panne.
Le numéro de mars d’epsiloon propose un article de fond sur ce bug qui est connu depuis un bon moment par les informaticiens. Le problème se présente dans tous les appareils, dispositifs, machines et systèmes qui utilisent un codage 32 bits. Un bit est un 0 ou un 1, et dans un codage à 32 bits, une date est une combinaison de 31 0 et 1, le 32e bit servant à indiquer si la date est antérieure ou postérieure à la date de référence fixée au 1er janvier 1970. Le nombre le plus élevé que l’on peut écrire dans ce codage est 0 suivi de 31 1 (011111111111111111111111111111111), ce qui correspond au 19 janvier 2038, 3 h 14 min, 7 sec. La seconde suivante, le chiffre suivant est 1 suivi de 31 0 (10000000000000000000000000000000), ce qui correspond au 13 décembre 1901, 20 h 45, 52 sec dans ces systèmes.
Le problème rappelle le bug de l’an 2000 des systèmes qui indiquaient l’année avec deux chiffres (00) et où l’on craignait que le passage de 1999 à 2000 allait renvoyer les systèmes à 1900 et non à 2000. epsiloon précise que la correction de ce bug en Europe a coûté 150 milliards d’euros pendant une dizaine d’années. La correction du bug de 2038 ne sera pas aussi simple, le problème se présentant dans les puces et logiciels embarqués dans des milliards d’équipements : dispositifs médicaux (stimulateurs cardiaques, pompes à insuline, etc.), infrastructures industrielles et urbaines (barrages, grues, pompes à essence), trains, tramways, voitures, banques, distributeurs automatique, caméras de sécurité, compteurs électriques, routeurs, imprimantes, télécoms, etc.
Le problème a été découvert en 2017 lorsque la RATP, société de régie des transports en commun de France, a constaté lors d’une opération de maintenance qu’il lui était impossible d’entrer une date après 2037. Son fournisseur, Alstom (le fabricant du train léger d’Ottawa) a établi que le problème se trouvait au niveau du paramétrage du système. La saga judiciaire qui a suivi a permis d’établir que sur les 261 logiciels embarqués dans le réseau ferroviaire RER, « 38 étaient concernés par un bug qui pourrait les empêcher de fonctionner après 2037 ». L’affaire est connue depuis le début décembre 2025 à la suite d’une décision d’un tribunal obligeant Alstom à proposer une solution.
Après avoir décrit les enjeux de ce bug, le magazine énumère les solutions possibles, mais aucune n’est facile à mettre en oeuvre dans les équipements industriels existants ayant une durée de vie de 50 ans et plus comme des barrages. La meilleure solution est de passer à des systèmes 64 bits, ce qui est pratique pour tout ce qui est nouveau, mais comment corriger et valider les équipements existants comme des grues ou des barrages ? La complexité et l’ancienneté des systèmes, souvent mal documentés, risque d’avoir des répercussions inattendues.
epsiloon fêtera bientôt son cinquième anniversaire. Ce mensuel scientifique a été créé par les journalistes de la revue Science & Vie qui ont quitté cette à la suite de son rachat par Reworld Media pour protester contre la politique éditoriale visant à orienter Science & Vie « vers des contenus majoritairement publicitaires, via le recours à des fournisseurs de contenus publicitaires extérieurs », précise la page Wikipédia de S&V. Si l’actualité scientifique vous intéresse, découvrez epsiloon (epsiloon.com), un magazine sans publicité soutenu par ses lecteurs.