Le 19 janvier 2038 à 3h14 et 7 secondes UTC, un certain nombre de machines vont croire, l’espace d’une seconde, qu’elles viennent de remonter le temps jusqu’en décembre 1901. Ce n’est ni une panne électrique ni le fruit d’un piratage informatique. C’est l’aboutissement mathématique d’une décision prise par une poignée d’ingénieurs, dans un laboratoire du New Jersey, il y a plus de cinquante ans.

L’histoire commence avec Unix, développé aux Bell Labs à la fin des années 1960. Pour compter le temps, ses créateurs ont opté pour une méthode simple : additionner les secondes écoulées depuis un point de départ fixé au 1er janvier 1970 à 00h00 UTC. Il découle d’un choix ancien et central de l’informatique Unix, qui compte le nombre de secondes écoulées depuis le 1er janvier 1970 à 00 h 00 min 00 s UTC. Ce compteur, stocké dans un entier signé de 32 bits, ne pouvait techniquement pas dépasser une certaine valeur. Personne, à l’époque, n’imaginait qu’Unix survivrait encore soixante-dix ans plus tard, disséminé dans des milliards d’objets qui n’existaient même pas dans les rêves les plus fous de ses concepteurs.

Sommaire

1. Une limite mathématique, fixée au dixième de seconde près
2. Le vrai obstacle : des milliards d’objets qu’on ne peut pas mettre à jour
3. Une facture qui pourrait dépasser celle du bug de l’an 2000

Une limite mathématique, fixée au dixième de seconde près

Le calcul est implacable. Tant que cette valeur est stockée dans un entier signé de 32 bits, sa borne supérieure reste fixée à 2 147 483 647 secondes, ce qui correspond exactement au 19 janvier 2038 à 03 h 14 min 07 s UTC. Passé ce seuil, le bit de signe bascule et le compteur devient négatif. Résultat ? La seconde suivante, écrite en binaire, représente −2 147 483 648 en complément à deux, soit plus de 2 milliards de secondes avant 1970, précisément le 13 décembre 1901 à 20 h 45 min 52 s.

Concrètement, une machine encore dépendante de ce format ne s’arrête pas de fonctionner. Elle continue de tourner, mais persuadée d’être dans les premières années du XXe siècle. Un certificat de sécurité expiré depuis 137 ans, une facturation qui recalcule des intérêts sur plus d’un siècle, un système de contrôle d’accès qui refuse d’ouvrir une porte parce que sa date de validité est « dans le passé »… les scénarios concrets ne manquent pas. Et le problème peut même surgir bien avant l’échéance : des erreurs peuvent apparaître dès qu’un logiciel manipule des dates lointaines, calcule des échéances, attribue une durée de vie à des données ou génère des certificats valables très longtemps.

Fait amusant, tous les systèmes Unix ne sont pas logés à la même enseigne. Sur ceux de type Unix représentant le temps par un entier de 32 bits non signé, conforme à la norme POSIX, la date limite est repoussée à 2106 et non à 2038, mais ces systèmes restent minoritaires. Une nuance de taille, souvent oubliée dans les versions les plus alarmistes de cette histoire.

Le vrai obstacle : des milliards d’objets qu’on ne peut pas mettre à jour

Voilà où l’affaire devient réellement compliquée. Passer à un entier 64 bits résout le problème pour des durées si vertigineuses qu’elles dépassent l’entendement. Le format s’est diffusé bien au-delà des ordinateurs de bureau : automates industriels, compteurs électriques intelligents, boîtiers réseau, caméras de surveillance, dispositifs médicaux, calculateurs embarqués dans l’automobile. Le risque ne vient pas du fait que le processeur soit en 32 bits, mais du fait que le micrologiciel est figé, que le fabricant n’existera peut-être plus en 2038, et que la durée de vie de l’appareil traverse cette échéance.

C’est là toute la différence avec un simple correctif logiciel. Mettre à jour un smartphone ou un serveur cloud, c’est une opération de routine. Recompiler le firmware d’un automate industriel installé dans une usine depuis vingt ans, retrouver le code source d’un boîtier réseau dont le fabricant a disparu, ou remplacer physiquement un compteur enterré sous la voirie d’une ville, c’est une tout autre paire de manches. Beaucoup de systèmes embarqués en 32 bits font face à des contraintes de ressources limitées, de code hérité et de durées de vie prolongées, souvent comprises entre dix et vingt ans. Certains équipements installés aujourd’hui seront encore en service en 2038, sans que personne n’ait prévu de les toucher d’ici là.

Les systèmes de fichiers illustrent bien cette transition, encore loin d’être achevée. La documentation du noyau Linux indique par exemple que l’ancien format V4 de XFS ne peut pas stocker des horodatages au-delà de 2038, ce qui a conduit à sa dépréciation au profit du format V5. Le noyau Linux avance aussi de son côté : plusieurs interfaces historiques ont été remplacées parce que leur champ de temps déborde en 2038 sur les architectures 32 bits, et le noyau recommande désormais des équivalents sur 64 bits. Un travail patient, mené correctif après correctif depuis des années.

Une facture qui pourrait dépasser celle du bug de l’an 2000

La comparaison avec le fameux bug de l’an 2000 revient sans cesse, et pour cause. Ce précédent avait coûté plusieurs centaines de milliards d’euros au niveau mondial, rien que pour corriger des dates codées sur deux chiffres. Le problème de 2038 s’annonce d’une nature différente, et potentiellement plus retors, parce qu’il ne touche pas seulement des bases de données centralisées mais des objets physiques disséminés partout, souvent invisibles, parfois oubliés au fond d’une chaufferie ou d’un réseau électrique.

Les grands éditeurs, eux, ont largement anticipé. La quasi-totalité des ordinateurs, serveurs et smartphones vendus depuis le début des années 2020 tournent déjà sur des architectures 64 bits, rendant le problème structurellement caduc pour ce segment. Mais l’informatique moderne repose aussi sur un océan d’appareils invisibles, ceux qu’on installe une fois et qu’on ne revoit jamais : capteurs industriels, terminaux de paiement anciens, équipements médicaux certifiés pour ne pas être modifiés sans repasser par des mois d’homologation.

Reste une question que peu de monde ose poser franchement : qui, en 2038, saura encore qu’un distributeur automatique, un ascenseur ou une vanne de barrage tourne sur un composant électronique conçu dans les années 2000, jamais mis à jour, et sur le point de croire qu’on est revenu sous la présidence de William McKinley ?

Sources : cnc-expertise.com | tangente-mag.com