Le bug de 2038 nous guette : et si on levait le nez de nos IA pour éviter le crash ?

Vous vous souvenez du 31 décembre 1999 ? Les supermarchés dévalisés, les survivalistes en herbe barricadés avec des boîtes de raviolis, et cette angoisse sourde alimentée par les JT : à minuit, les avions allaient tomber du ciel, les ascenseurs resteraient bloqués, et l'apocalypse numérique s'abattrait sur nous.

Finalement, rien de tout cela n'est arrivé.

Non pas parce que la menace était une vaste blague, mais parce que des armées d'ingénieurs ont passé des années à corriger le tir dans l'ombre, ligne de code par ligne de code. On a eu peur, on a agi, on a survécu.

Vingt-six ans plus tard, on a collectivement oublié les leçons de l'an 2000. L'ironie, c'est qu'une nouvelle date butoir approche à grands pas, comme nous le rappelle très justement un dossier du magazine Epsiloon : le bug de l'an 2038. Et cette fois, l'industrie regarde ailleurs.

La mécanique de la catastrophe annoncée.

Pour comprendre le problème, il faut remonter aux années 1970. À cette époque, les ingénieurs qui concevaient Unix (le système d'exploitation qui allait devenir l'ancêtre de Linux, macOS, Android et de l'essentiel de l'infrastructure serveur mondiale) avaient un problème pratique à résoudre : comment représenter le temps de façon simple et universelle pour les ordinateurs ?

Leur solution était élégante : compter le nombre de secondes écoulées depuis le 1er janvier 1970 à 00h00 UTC, une date arbitraire baptisée « l'époque Unix ».

Besoin de savoir quelle heure il est ? On récupère ce compteur, on fait le calcul, et voilà.
Simple, efficace, interopérable.

Le hic, c'est que ce compteur a été stocké sur un entier signé de 32 bits. En arithmétique binaire, ça représente 2 147 483 647 secondes maximum. Soit environ 68 ans à partir de 1970.

Le compte est vite fait : le 19 janvier 2038, à 03h14 et 07 secondes (heure universelle), ce compteur atteindra sa valeur maximale. La seconde suivante, il déborde. Il repart à zéro, ou plutôt dans le négatif selon les implémentations. Pour la machine, nous serons soudainement de retour le 13 décembre 1901.

C'est ce qu'on appelle l'« Epochalypse ».

How much time until the Epochalypse?

A countdown to the end of 32-bit unix time

Pourquoi c'est sérieux.

À ce stade, une question légitime se pose : est-ce qu'on ne parle pas d'un problème de geeks théorique, du genre à faire peur sur les forums spécialisés mais sans vrai impact sur la vie réelle ?

Non. Et voici pourquoi.

Unix et ses dérivés font tourner la quasi-totalité de l'infrastructure numérique critique de la planète. Les serveurs web, les routeurs, les commutateurs réseau, les systèmes embarqués industriels, les automates de centrales électriques, les équipements médicaux connectés, les bornes de paiement, les systèmes de navigation des transports... La liste est longue, et une partie significative de ces équipements tourne encore sur des architectures 32 bits ou sur du code hérité qui utilise des entiers de 32 bits pour gérer le temps. Même sur du matériel 64 bits.

Concrètement, imaginez qu'au moment fatidique, le système de gestion d'une centrale électrique croit soudainement être en 1901. Il cherche à appliquer des règles de fonctionnement qui n'existent pas pour cette date, rencontre des erreurs qu'il ne sait pas gérer, et s'arrête ou se comporte de façon imprévisible. Idem pour un système de contrôle du trafic aérien, pour un pacemaker connecté qui synchronise ses journaux d'événements avec un serveur, ou pour les systèmes bancaires qui calculent des échéances et des intérêts.

On parle de systèmes où un bug temporaire ne se traduit pas par une page d'erreur 404, mais par des coupures d'électricité, des transactions financières corrompues, ou des équipements médicaux qui cessent de fonctionner correctement.

Bref. C'est un peu la merde.

On sait comment le corriger, et c'est précisément le problème.

La solution technique n'est pas mystérieuse. Il « suffit » de migrer les systèmes concernés vers des entiers de 64 bits pour représenter le temps. Avec 64 bits, le compteur Unix ne déborde pas avant l'an 292 277 026 596. Autant dire que nos arrière-arrière-petits-enfants auront le temps de s'en préoccuper.

La plupart des systèmes d'exploitation modernes ont déjà migré. Linux sur 64 bits est au point depuis longtemps. Les iPhones et les Mac récents ne sont pas concernés. C'est là que s'arrête la bonne nouvelle.

Le vrai problème, c'est l'immense queue de distribution des systèmes « legacy » qui n'a pas migré, ne migrera peut-être jamais, et sur lesquels repose pourtant une partie critique de notre monde physique.

On parle de routeurs industriels déployés dans des usines au début des années 2000, de systèmes embarqués dans des satellites ou des équipements médicaux avec des cycles de vie de 15-20 ans, de code C et C++ écrit dans les années 1990 qui fait tourner des automates dans des raffineries ou des stations d'épuration.

Des équipements qui ne se mettent pas à jour via une notification, dont les fabricants d'origine ont parfois disparu, et dont personne ne connaît vraiment l'étendue précise.

C'est ce que les ingénieurs appellent la « dette technique » : du code fonctionnel, qui rend service, mais qui accumule silencieusement des risques au fil du temps parce que personne n'a eu le budget, le temps, ni l'incentive pour le moderniser.

L'aveuglement collectif.

Et c'est là que le tableau devient vraiment préoccupant. Parce que le bug de 2038, on le connaît depuis longtemps. Des informaticiens tirent la sonnette d'alarme depuis les années 2000. Il y a eu des patchs, des migrations, des articles. Mais il y a aussi eu une forme d'indifférence croissante, et 2038 semblait si loin...

Et pif paf pouf : voilà l'IA.

Aujourd'hui, l'industrie tech a les yeux rivés sur un seul et unique horizon : l'intelligence artificielle. On s'extasie devant des agents capables de générer des vidéos bluffantes, d'automatiser des workflows entiers, de produire du code en quelques secondes. Les investissements se concentrent, les talents se dirigent vers les équipes IA, et les conférences ne parlent plus que de LLMs, d'agents autonomes et de benchmarks.

Ce n'est pas un jugement de valeur : l'IA transforme effectivement les usages en profondeur, et il est normal que l'industrie s'y consacre massivement. Mais pendant ce temps, dans les sous-sols de notre infrastructure numérique, des millions de lignes de vieux code en C ou en C++ continuent de faire tourner le monde réel. Silencieusement. Invisiblement. Et avec une date d'expiration qui se rapproche.

Qui va s'occuper de repérer et mettre à jour ces systèmes si tous les ingénieurs système compétents sont mobilisés sur l'optimisation de modèles de langage ? Les IA elles-mêmes ? Le hardware enfoui dans un vieux barrage hydraulique ou un satellite ne se mettra pas à jour avec un abonnement ChatGPT. Et même si des outils d'IA pouvaient aider à analyser du code legacy (ce qu'ils font déjà partiellement), encore faut-il que quelqu'un pilote le processus, valide les corrections, et prenne la décision de déployer sur des systèmes critiques.

Ce travail de fond, discret, peu glamour, peu visible sur LinkedIn, est exactement ce qui a sauvé la mise en l'an 2000.

Ce que l'an 2000 aurait dû nous apprendre

Le passage à l'an 2000 a coûté entre 300 et 600 milliards de dollars à l'échelle mondiale, selon les estimations. Une somme astronomique, mobilisée en quelques années, pour un problème que beaucoup avaient longtemps minimisé.

Rétrospectivement, c'est l'un des meilleurs retours sur investissement de l'histoire de l'informatique. Parce que ça a fonctionné. On a identifié l'étendue du problème, on a mobilisé les ressources, on a priorisé les systèmes critiques, et on a corrigé avant que la catastrophe arrive. La méthode n'avait rien d'héroïque : inventaire, priorisation, migration, test, déploiement. Du travail d'ingénieur classique, appliqué méthodiquement à une échelle massive.

La leçon que l'industrie aurait dû retenir : les problèmes de dette technique ne disparaissent pas. Ils s'accumulent, puis ils explosent à date fixe si on ne les traite pas. Et plus on attend, plus la migration est coûteuse et risquée, parce que les personnes qui connaissent les vieux systèmes partent à la retraite, les documentations se perdent, et les dépendances cachées se multiplient.

Le bug de 2038, c'est précisément ce type de problème. La date est connue. La solution technique est connue. Ce qui manque, c'est la volonté collective de s'y attaquer sérieusement avant qu'il soit trop tard.

Jamais le vendredi... et surtout pas en 2038

Sur jamaislevendredi, il y la règle d'or du web : on ne déploie jamais en prod à la veille du week-end. Pourquoi ? Parce que l'informatique exige de l'anticipation, de la prudence, et du temps pour réparer quand ça casse. Un déploiement précipité à 17h un vendredi, c'est la garantie de passer son week-end à gérer une crise.

Et qui veut faire ça ? Personne.

Le bug de 2038 tombera un mardi. Mais si nous continuons à ignorer la plomberie de nos systèmes pour ne regarder que les belles interfaces générées par l'IA, ce jour-là aura le goût amer du pire vendredi de l'histoire de la tech.

Il reste douze ans. C'est à la fois beaucoup et très peu pour ce type de migration, surtout quand on parle de systèmes embarqués dans des infrastructures physiques aux cycles de mise à jour décennaux.

L'an 2000 nous a prouvé une chose : on peut éviter une catastrophe mondiale à condition de s'y prendre à l'avance et de valoriser le travail de l'ombre de ceux qui maintiennent l'existant. Il est grand temps de lever collectivement les yeux de nos agents virtuels, de rechausser nos bottes d'ingénieurs système, et d'aller faire le ménage dans nos vieilles boucles temporelles.

Sinon, cette fois-ci, les avions pourraient bien tomber pour de vrai.