Le bug de l'an 2038

On connaît la date de la fin des temps : le 19 janvier 2038, à 3 h 14 min et 7 s UTC. D’un coup, les horloges de milliards de machines vont revenir à zéro, sans manipulation ni piratage. Ou plutôt, elles vont remonter le temps… jusqu’au 13 décembre 1901, 20 h 45 min et 52 s. Cela paraît fou, un scénario de SF. Nous venons pourtant d’en avoir un aperçu indirect, en décembre dernier, avec la condamnation du fabricant de trains Alstom révélée par le journal L’Informé : la RATP lui reprochait justement d’avoir caché ce problème d’horloge, qui risque d’immobiliser un tiers du réseau parisien. L’affaire est en cours – Alstom, qui a fait appel, et la RATP n’ont pas souhaité nous parler. Ailleurs, les langues se délient, révélant l’ampleur d’un problème mondial, jusqu’ici largement passé sous les radars.

Urgence

“Oui, le passage de 2038 risque de provoquer de graves pannes dans de nombreux secteurs si l’évaluation et les mesures d’atténuation sont trop tardives”, lâche John Lange, informaticien dans le Colorado – fondateur du site Y2038.com, cet expert est l’un des premiers à avoir lancé l’alerte. “Bien que le problème soit connu des spécialistes, de nombreuses organisations, voire la plupart, ne le traitent pas avec l’urgence que cela mériterait. Un très grand nombre de structures sont exposées et seule une partie étonnamment faible en assure le suivi avec un financement dédié », analyse de son côté Trey Darley, un informaticien belge, fondateur de Proper Tools, un cabinet de conseil spécialisé dans les risques systémiques liés aux infrastructures. “Il faut qu’il y ait une prise de conscience, cela doit sortir de la sphère technique avec urgence”, s’inquiète un ingénieur français en informatique d’une entreprise spécialisée dans les systèmes embarqués, qui a préféré garder l’anonymat.

Pire que l’an 2000

Il suffit de creuser un peu pour s’apercevoir que ce “bug 2038” est connu depuis plus de vingt ans dans le monde des codeurs. Son origine est simple : un grand nombre de nos systèmes informatiques fonctionnent avec une date paramétrée qui permet de repérer des actions dans le temps (prêt bancaire, maintenance…). Et pour que tout soit harmonisé, une norme dite “heure Unix” ou “heure Posix” impose que cette date soit calculée en égrenant les secondes à partir du 1^er janvier 1970 (juste après l’invention du système d’exploitation Unix, en 1969). Par exemple, le 25 février 2026, date de sortie de ce numéro d’Epsiloon, il se sera écoulé 1 772 020 678 secondes. Sauf que cette date, exprimée en bits (0 ou 1), est souvent codée sur un nombre de bits limité, en l’occurrence 32 : 31 pour égrener les secondes qui s’écoulent et le 32^e pour préciser si on est avant ou après 1970. Le problème, avec ce système, c’est que le nombre le plus élevé s’écrit 01111111 11111111 11111111 11111111. Ce qui correspond au 19 janvier 2038, 3 h 14 min et 7 s donc. Et que la seconde suivante, le codage va afficher 10000000 00000000 00000000 00000000 : le 13 décembre 1901, la date la plus reculée possible dans le passé… “Nos systèmes informatiques comparent les chiffre, et une date future qui se retrouve d’un seul coup plus ancienne que la précédente induit des erreurs”, conclut Thierry Roger, directeur de recherche chez Alten, à Rennes.

On estime que le parc informatique concerné est 500 à 600 fois plus important que pour le bug de l’an 2000

Cette histoire rappelle bien sûr le bug de l’an 2000. Mais à l’époque, il s’agissait des années, codées en utilisant deux chiffres (99 pour 1999) – d’où le risque d’interpréter le 00 de 2000 comme un retour en 1900… Un problème anticipé et corrigé au prix de 150 milliards d’euros rien que pour l’Europe, et d’équipes mobilisées pendant une dizaine d’années. Tout à coup, l’échéance de 2038 ne paraît plus si lointaine. D’autant qu’aujourd’hui, le nombre d’objets interconnectés et potentiellement impactés est sans ­ommune mesure. “On estime que le parc d’objets informatiques concernés est environ 500 à 600 fois plus­important que celui de l’an 2000, même s’il n’existe pas de liste officielle, évalue Trey Darley. Cela donne une petite idée du périmètre qu’il va falloir mettre à jour.” Et surtout, d’après les spécialistes, la mobilisation pour 2038 n’est pas du tout du même ordre. “Nombreux sont ceux qui ignorent encore le problème… probablement parce qu’il est plus complexe que celui du passage du millénaire”, lâche Kenji Kono, professeur en informatique à l’université de Keio, qui travaille sur le sujet au Japon.

Tabou

De rares acteurs ont déjà réalisé le grand saut et l’ont fait savoir. Apple, par exemple, a annoncé avoir préparé ses matériels et logiciels dès 2015. Les équipes de Linux ont dévoilé en 2020 avoir apporté un correctif. Et c’est à peu près tout. Sur la vingtaine de structures que nous avons contactées (Google, Siemens, EDF, SNCF, ESA, Bosch, Orange…), la majorité n’a pas répondu ou a minima. “Nous ne pouvons malheureusement pas donner suite à votre demande”, nous dit le service de presse de Renault. “Chez Valeo, on connaît le sujet. Le risque est maîtrisé dans le domaine de l’auto car il y a depuis longtemps des standards pour anticiper ce type de problème. Nous n’avons pas d’autres informations à communiquer sur le sujet.” Même discours chez Capgemini : “La plupart des environnements ont évolué vers des architectures 64 bits ou des formats de temps alternatifs. Pour les systèmes qui seraient impactés, la méthodologie de correction sera similaire à celle utilisée pour le passage à l’an 2000, ce qui est bien maîtrisé par l’industrie”, assure Patrice Duboé, directeur des technologies et de l’innovation.

Dans le monde des informaticiens, on est tous au courant depuis longtemps, mais cela ne provoque pas de prise de conscience

Sauf que sur les forums spécialisés et du côté des développeurs informatiques, le discours est totalement différent. On entend parler de blocages, de pannes, de comportements difficilement prévisibles, d’effets en cascade, avec une inquiétude non dissimulée… “Cette histoire de 2038, on en parle entre nous car on sait que cela va se produire. D’ailleurs, il nous est arrivé pendant des tests de tomber sur la limite, ce qui prouve bien qu’un certain nombre de produits sur le marché sont vulnérables”, lâche notre ingénieur anonyme. “Tout le monde se doute bien qu’il va se passer quelque chose, mais cette connaissance du risque depuis les années 1980-1990 se limite au monde des développeurs, ce qui est un vrai problème”, confie Trey Darley. “Dans le monde des informaticiens, on est tous au courant depuis longtemps, mais cela ne provoque pas de prise de conscience. Ce sujet ne semble pas recevoir une attention spécifique pour l’instant”, déplore Yann Argotti, docteur en informatique, ingénieur chez Ampère, filiale électrique de Renault. 

Pas d’inventaire

Mais pourquoi avoir codé les dates en seulement 32 bits ? “Dans l’histoire de l’informatique, la mémoire a été systématiquement adressée sur une taille à un instant donné, en fonction des limites techniques de l’époque et du coût : on cherche toujours à gratter ce qui est possible en termes d’espace”, explique Gérard Berry, professeur émérite en informatique au Collège de France. Jusque dans les années 2000, ce codage en 32 bits s’est donc largement répandu. Et même si des systèmes à 64 bits sont désormais disponibles, il continue à être utilisé pour les équipements qui n’ont pas besoin de beaucoup de performances (capteurs, vannes…), avec l’idée que des mises à jour seront apportées en temps voulu.

Sauf que peu à peu, le suivi de la programmation de ces objets s’est perdu. Où sont-ils, ces systèmes à 32 bits ? Il y en a probablement des millions, des milliards partout dans le monde, dans les véhicules, les appareils médicaux, les capteurs de maisons, les imprimantes, les distributeurs automatiques… Leur durée de vie est longue et ce sont des systèmes embarqués, autonomes, qui souvent ne peuvent pas être mis à jour en ligne. Aucun inventaire, pas de suivi : leur existence et surtout leur mode de codage ne sont pas des informations bien répertoriées par les entreprises. En témoigne l’affaire RATP-Alstom : alors que l’entreprise avait mis en service de nouvelles rames MI09 en 2011, il lui a fallu six ans pour se rendre compte que certaines d’entre elles étaient vulnérables, et six mois encore pour cerner les 38 logiciels embarqués concernés – au passage, la RATP a découvert ­qu’Alstom avait tenté d’entrer manuellement une date supérieure à 2037… Il faut dire que l’accès à ces systèmes n’est pas forcément simple. “Prenez une grue, par exemple, illustre l’ingénieur anonyme. C’est le genre d’équipement qui a été conçu pour durer, mais qui n’a pas forcément de moyen de connexion à distance de type wifi, 4G… Si on veut la corriger, cela veut dire qu’il faut se déplacer et monter dessus !”

Savoir perdu

“On est dans le cas typique où la racine du problème est très simple mais la correction pas forcément”, résume Gérard Berry. De fait, les solutions pour éviter le bug sont bien identifiées et maîtrisées : basculer le codage de la date sur 64 bits pour repousser la limite du temps ; utiliser le 32^e bit pour coder au lieu de marquer le passé… Mais toutes soulèvent des difficultés pratiques. “Notamment parce qu’il n’existe pas de solution universelle et unique pour faire basculer tous les programmes avec le même procédé de mise à jour”, poursuit l’expert.

Ces programmes ont souvent été faits à la main par des ingénieurs qui ne sont plus là pour expliquer comment et où ils ont paramétré la date

Souvent, la seule manière de convertir un programme de 32 en 64 bits est de plonger dans le code source, décrypter les milliers de lignes et comprendre comment la date a été paramétrée. “Cela peut prendre des heures et des heures, en particulier si les codes sont anciens”, pointe Anne Barros, spécialiste de la résilience des systèmes à CentraleSupélec, à Paris. “Il est parfois très difficile de comprendre ce qu’il y a derrière un vieux programme pour peu qu’il ait été écrit de manière un peu artisanale, sans commentaires autour”, confirme Claude Baron, professeur en informatique à l’Institut national des sciences appliquées, l’INSA, à Toulouse.

“Ces programmes ont souvent été faits à la main, par des ingénieurs qui ne sont probablement plus là pour expliquer comment et où ils ont paramétré la date. Faire des conversions de ce type peut être plus délicat qu’il n’y paraît”, renchérit Gérard Berry. D’autant que les jeunes développeurs ne connaissent pas forcément certains vieux langages informatiques, comme le Cobol ou les instructions en assembleur. “Les langages utilisés dans les anciens systèmes embarqués n’étaient pas aussi développés et détaillés que ceux actuels du type Python, ce qui rend les mises à jour difficiles”, pointe Mathieu Acher, chercheur à l’Inria, l’institut de recherche en sciences et technologies du numérique. “Un programme informatique écrit en langage C et compilé il y a trente ans est très difficile à comprendre et à modifier. Le Web nous a apporté une grosse mémoire partagée, mais avant la connaissance restait plutôt à l’intérieur des entreprises, voire derrière les murs des codeurs”, raconte Thierry Roger.

Panne, arrêt, erreur

Un cauchemar. D’autant qu’un changement sur une simple ligne de programmation peut casser un système, voire en bloquer d’autres qui y sont connectés. “Quand on modifie un code du système d’exploitation pour stocker l’heure en 64 bits, il faut surveiller la compatibilité avec les applications qui utilisent encore l’heure en 32 bits”, alerte Arnd Bergmann, informaticien allemand chez Linaro. On imagine le risque pour les appareils critiques ou sensibles, comme les appareils médicaux, les barrages… Le pire étant qu’on ne sait pas ce qui se passera quand arrivera la date fatidique. “D’un objet à l’autre, on a du mal à prévoir : panne, arrêt, erreur… Ce n’est pas quelque chose que l’on arrive à anticiper tant les systèmes sont disparates”, prévient l’ingénieur anonyme. Au Japon, Kenji Kono a mené l’étude sur 32 921 projets programmés en langage C et publiés sur la plateforme GitHub, entre 2012 et 2018 : 7,35 % d’entre eux étaient vulnérables au bug de 2038 et, suivant les programmes, les différents effets étaient suffisamment dangereux pour entraîner des plantages de systèmes logiciels.

Des entreprises dans le déni

Face à cela, les entreprises ont tendance à être dans le déni. “Celles qui découvrent qu’elles ont un problème n’ont aucune raison de l’annoncer avant de l’avoir résolu – ou avant que cela ne devienne le problème de quelqu’un d’autre, regrette Trey Darley. La plupart des défaillances sont découvertes lors de tests, et corrigées discrètement.” Mais certains assument, comme KDDI, géant japonais des télécoms, qui a avoué avoir surfacturé par erreur des clients sur des appels passés entre le 10 janvier et le 25 février 2004, à cause du bug – le système utilisant des unités de 0,5 s au lieu de 1 s, le bug s’est manifesté plus tôt. Pedro Umbelino, chercheur chez BitSight, cite aussi le cas d’AOL, le fournisseur d’accès à Internet américain, en 2006. Nous avons retrouvé l’ingénieur qui a géré l’affaire à l’époque, Dossy Shiobara, qui a depuis quitté l’entreprise : “Tout a commencé quand un problème étrange a affecté nos serveurs, témoigne-t-il. L’un de mes experts a fini par découvrir que cela venait d’un bug lié à notre codage de date sur 32 bits, mais il nous a fallu cinq jours pour trouver la cause et la solution.” Plus récemment, en 2022, Trey Darley signale l’entreprise suisse Proton, à l’origine de la messagerie Proton Mail, dont le calendrier en ligne bloquait quand les utilisateurs voulaient paramétrer une date au-delà de 2038.

Un schisme

Un peu partout dans le monde, des codeurs et des chercheurs commencent à se fédérer pour alerter. Fin 2025, lors d’une réunion de l’Union internationale des télécommunications, à Genève, les membres d’un groupe de travail ont approuvé un document exigeant une coordination mondiale sur ce sujet. “Il s’agit de la première initiative internationalement reconnue de ce type”, salue Trey Darley, l’un des rédacteurs du document avec Pedro Umbelino. En parallèle, la loi européenne sur la cyberrésilience pourrait inciter à prendre le risque au sérieux : votée en 2024 et mise en application en 2027, elle devrait exiger que les systèmes embarqués puissent être mis à jour pour garantir une sécurité tout au long de leur cycle de vie… “Cette histoire illustre le problème récurrent du partage des connaissances entre le monde de l’informatique d’un côté, et le monde de la physique et du matériel de l’autre, regrette Gérard Berry. On peut même parler de schisme entre les ingénieurs qui conçoivent les équipements et ceux qui paramètrent les logiciels.”

Reste que le nerf de la guerre n’est pas seulement technique, il est aussi financier. Qui est responsable ? Qui doit payer ? L’intégrateur, le fournisseur, le sous-traitant ? Dans l’affaire RATP-Alstom, les juges ont tranché. Le compte à rebours est lancé : au moment où nous publions cette enquête, il ne reste plus que 4 375 jours 17 h 24 min et 55 s pour tenter de résoudre le bug de l’an 2038.