Bug de l’an 2038 : nous allons atteindre une limite et cela menace des systèmes informatiques critiques

Le bug de l’an 2000 a marqué les esprits. Certains se souviennent de la fébrilité des derniers jours de décembre 1999, des mises à jour d’urgence, des prédictions catastrophistes. Finalement, le passage s’est fait sans dommages majeurs, en grande partie parce que les équipes techniques avaient anticipé le problème des années à l’avance. Un scénario comparable se profile pour 2038, avec une date précise déjà connue : le 19 janvier, à 03h14 et 7 secondes. Les spécialistes travaillent sur le sujet depuis les années 1990. Le grand public, lui, n’en a presque pas entendu parler.

Comprendre le problème à la racine

Pour saisir ce qui va se passer, il faut comprendre comment les systèmes informatiques représentent le temps. Depuis 1970, la plupart des ordinateurs ne stockent pas une date au sens calendaire du terme. Ils ne conservent pas en mémoire « jeudi 9 avril 2026 » comme nous l’écririons sur un agenda. À la place, ils comptent le nombre de secondes écoulées depuis le 1er janvier 1970 à minuit, ce moment de référence s’appelle l’époque Unix. À chaque seconde qui passe, un compteur interne augmente de un.

Ce choix technique est parfaitement raisonnable. Il simplifie les calculs de durée, les comparaisons de dates et les opérations arithmétiques sur le temps. Comparer deux dates revient simplement à comparer deux nombres entiers.

Le problème surgit avec les systèmes qui utilisent un entier signé de 32 bits pour stocker ce compteur. Un entier signé de 32 bits dispose d’une capacité maximale de 2 147 483 647 valeurs positives. Ce plafond sera atteint le 19 janvier 2038 à 03h14 et 7 secondes. À cet instant précis, le compteur débordera et repassera à sa valeur minimale négative, que le système interprétera comme une date correspondant au 13 décembre 1901.

Ce n’est pas un bug de programmation à proprement parler. C’est une limite structurelle du format de stockage choisi à une époque où personne n’anticipait que ces systèmes tourneraient encore des décennies plus tard. La solution existe et est connue depuis longtemps : passer à un entier de 64 bits, qui repousse l’échéance à l’an 292 277 026 596, autant dire indéfiniment. Le problème est que tous les systèmes en activité n’ont pas encore opéré cette migration.

VOIR AUSSI : Faut-il mentir aux IA pour obtenir de vraies réponses ? Le conseil surprenant d’un pionnier

Les secteurs industriels en première ligne

Les PC modernes ne sont pas concernés. Ils fonctionnent déjà en 64 bits et gèrent sans difficulté les dates au-delà de 2038. Le risque ne se situe pas là.

Il se concentre sur les systèmes embarqués, ces petits ordinateurs aux ressources contraintes, sans écran, intégrés dans des équipements industriels ou médicaux. Ce sont eux qui n’ont souvent pas les capacités mémoire ou de calcul nécessaires pour adopter le format 64 bits, et qui fonctionnent parfois depuis des décennies sans mise à jour majeure.

Les secteurs les plus exposés sont la chimie, les transports, l’énergie et l’informatique médicale. Ce dernier mérite une attention particulière. Les hôpitaux travaillent avec des parcs informatiques extrêmement hétérogènes : des équipements déployés dans les années 1990 cohabitent avec du matériel récent, et les ressources humaines et financières pour conduire des audits systématiques sont souvent insuffisantes. Un appareil médical embarqué fonctionnant sur un système 32 bits non mis à jour pourrait dysfonctionner à une date critique, dans un environnement où la fiabilité n’est pas négociable.

L’affaire de la RATP illustre concrètement les risques d’une mauvaise gestion du problème. En 2017, la régie autonome des transports parisiens a découvert par hasard qu’un tiers de ses rames de métro était concerné par ce bug. L’enquête a révélé que le constructeur Alstom avait délibérément intégré des lignes de code empêchant la saisie de dates postérieures à 2037, sans en informer son client. Le tribunal administratif de Paris a conclu que le vice avait été volontairement dissimulé. Cet exemple illustre un risque souvent sous-estimé : celui que le problème soit connu du fournisseur mais camouflé pour des raisons commerciales.

VOIR AUSSI : Pourquoi la fréquence des ordinateurs n’évolue plus depuis plus d’une décennie ?

Ce que les organisations doivent faire maintenant

Le vrai danger n’est pas une catastrophe soudaine survenant à minuit le 19 janvier 2038. C’est l’inaction progressive des acteurs qui ne savent pas, ou ne veulent pas savoir, qu’ils sont exposés.

La première étape est l’audit. Toute organisation opérant des systèmes embarqués doit dresser l’inventaire de ses équipements, identifier ceux qui tournent sur des architectures 32 bits, et évaluer leur capacité à représenter des dates au-delà de 2038. Ce travail est déjà en cours dans de nombreux secteurs industriels, mais il reste inégal selon les filières.

La deuxième étape concerne les contrats. Pour les systèmes qui ne peuvent pas être mis à jour par les équipes internes, la question se pose de savoir si le fournisseur d’origine dispose encore des codes sources du logiciel pour effectuer la correction. Dans certains cas, les logiciels embarqués ont été développés il y a trente ans par des entreprises qui n’existent plus. La correction devient alors un chantier de rétro-ingénierie coûteux et incertain.

Douze ans peuvent sembler un délai confortable. Ils ne le sont pas si l’on considère les cycles d’acquisition, de qualification et de déploiement propres aux équipements industriels lourds.