Un nouveau bug menace l’informatique mondiale, celui de l’an 2000 n’était rien comparé à cette vraie bombe à retardement
Qui ne se souvient pas du bug de l’An 2000 ? Ce passage au siècle suivant auréolé de la peur d’une apocalypse informatique arbore désormais des airs d’hallucination collective – puisque le pire a été évité. Désormais, c’est une menace bien plus vicieuse qui plane sur des milliers – voire des milliards – de machines. Cette épée de Damoclès, c’est le bug de l’An 2038. Et les secondes de ce compte à rebours ne cessent de s’égrener…

- L’heure Unix ou quand une seconde de trop suffit à tout faire dérailler
- Le bug de l’An 2038 : une urgence mondiale bien plus complexe qu’en 2000
- Le véritable casse-tête des ingénieurs pour éviter les conséquences du bug de l’An 2038
- Entre omerta et responsabilité, le temps joue contre nous
- Commentaires
Le bug de l’An 2000. Si vous ne l’avez pas vécu, vous en avez a minima entendu parler : cette crainte d’un cataclysme informatique dû à l’encodage des années à deux chiffres plutôt que quatre. Tout cela pour économiser de la mémoire – eh oui, déjà à l’époque. 99 est pour 1999, mais 00 aurait marqué un retour à 1900 pour les machines. Un bug dans la matrice.
De ce passage au siècle suivant, l’on attendait l’apocalypse : réseaux bancaires gelés, appareils médicaux défaillants, satellites errants, pluie d’avions… Et finalement, rien. Mais rien à voir avec la prédiction de la fin du monde datée au 21 décembre 2012 : le bug de l’An 2000 était bel et bien réel. Cependant, une armada d’ingénieurs a permis de l’éviter grâce à dix années de travail acharné.
Il existe cependant une épée de Damoclès au-dessus de nos têtes, bien plus vicieuse, qui nous fera remonter le temps, sans aucun hack ni manipulation. Et le compte à rebours est déjà lancé. Voici le bug de l’An 2038.
L’heure Unix ou quand une seconde de trop suffit à tout faire dérailler
En 1969, des ingénieurs inventent l’heure Unix, afin que tous les ordinateurs puissent communiquer ensemble. Il s’agit d’un système de notation du temps qui repose sur le nombre total de secondes s’étant écoulées depuis un instant T. Cet instant-T zéro est baptisé l’Époque : il correspond au 1er janvier 1970 à minuit pile (UTC). Par exemple, à l’instant où nous rédigeons ces lignes (le 2 juin 2026 à 15 heures 29), l’horodatage Unix affiche1780406941 sur le site Timestamp.
Mais l’heure Unix est stockée sur un nombre entier codé en 32 bits. Et c’est là où le bât blesse, puisque ce nombre a une valeur maximale : 2147483647. Or elle sera atteinte le 19 janvier 2038 à 3 heures 14 et 7 secondes (UTC). Une seconde après, le compteur passera en nombre négatif pour revenir à la date connue par le système la plus lointaine : le 13 décembre 1901.
Si on ne l’empêche pas, nos machines s’en trouveront inéluctablement perturbées. Mais les ingénieurs l’ont déjà fait une fois, pourquoi pas une seconde ? De prime abord, on pourrait penser qu’il suffit de transformer l’essai du bug de l’an 2000. Après tout, il nous reste 12 ans avant 2038. Mais le paysage informatique s’est drastiquement métamorphosé depuis les années 1990 et des obstacles techniques et financiers se dressent devant nous – sans compter sur l’omerta qui auréole cet événement redouté.
Le bug de l’An 2038 : une urgence mondiale bien plus complexe qu’en 2000
Dans les années 1990, on savait où traquer le bug de l’an 2000. Aujourd’hui, Unix tournant partout, il s’agit d’une urgence mondiale : on estime qu’il y a 500 à 600 fois plus d’appareils concernés qu’il y a 26 ans, des box Internet, aux GPS, en passant par les IRM, les serveurs cloud ou encore les systèmes embarqués. Et c’est spécifiquement sur ces derniers que plane le danger. La date butoir du 19 janvier 2038 vous paraît-elle toujours aussi lointaine ?
Sur le papier, la solution est simple : basculer l’ensemble du parc informatique international vers un système 64 bits. Cela repousserait l’échéance de 292 milliards d’années. Mais en pratique, cela ne se fait pas en un claquement de doigts. Des obstacles de différentes natures se hissent devant nous.
Le véritable casse-tête des ingénieurs pour éviter les conséquences du bug de l’An 2038
Des difficultés techniques, d’abord. Il n’existe aucune solution universelle pour mettre automatiquement à jour tous les systèmes concernés. De plus, le temps s’est accompagné d’une perte de savoir. Premièrement car nous ne disposons pas d’un inventaire des systèmes 32 bits. Deuxièmement, il y a plusieurs années, les programmes en 32 bits étaient codés à la main dans des langages que ne maîtrisent pas nécessairement les jeunes développeurs, ce qui les rend difficiles à modifier. Sans oublier que la tendance à l’open source est nouvelle. De plus, le basculement du 32 au 64 bits est extrêmement chronophage – a fortiori en présence de code ancien.
Et il ne suffit pas d’effectuer le basculement : il faut ensuite veiller à la compatibilité des applications encodées en 32 bits. Une seule erreur de code peut faire dysfonctionner tout un programme. Avec le bug de l’An 2038, ce sont des pannes, de l’imprévisibilité et un effet domino qui sont pressentis du côté des développeurs – malgré le fait que les entreprises parlent de ce « bug » comme d’un problème connu et maîtrisé (quand elles acceptent de s’exprimer à ce sujet). S’il se produit, le bug de l’An 2038 ne sera pas sans effet : les ingénieurs l’ont déjà prouvé en provoquant l’échéance fatidique lors de tests.

Entre omerta et responsabilité, le temps joue contre nous
Ensuite, l’Humanité se heurte à des difficultés financières pour tenter d’éviter ce bug. Surtout : à qui revient la responsabilité ? C’est une affaire dont commencent déjà à se saisir la justice et la Loi. En témoigne le procès opposant la RATP au constructeur ferroviaire ALSTOM : la première s’est aperçue que certaines rames de métro ne pourraient être modifiées après 2037. La justice a tranché en sa faveur, condamnant ALSTOM à corriger ce problème sous trois ans.
On peut également mentionner la loi européenne sur la cyber-résilience, qui entrera en vigueur en 2027 après avoir été votée en 2024 : l’Europe pourrait ainsi exiger la mise à jour des systèmes embarqués pour que leur sécurité soit assurée pendant toute leur durée de vie.
Aujourd’hui, les verrous du déni et de l’omerta des grandes entreprises auxquels s’est heurtée la rédactrice en chef adjointe d’Epsiloon Magazine, Muriel Valin, lors de son enquête sont en train de sauter : cela nous a déjà fait perdre trop de temps – nous en reste-t-il seulement assez pour tenter de l’éviter ?
