Je me souviens du bug de l’an 2000. Ce bon vieux Y2K, ce cauchemar marketing qui a fait vendre des milliards en audits inutiles et en mises à jour de dernière minute. Les médias en ont fait un film catastrophe, les entreprises ont paniqué, et au final… rien. Ou presque. Quelques distributeurs de billets en panne, des horodateurs qui ont cru revenir en 1900, et c’est à peu près tout. La montagne a accouché d’une souris, et tout le monde a rigolé en se disant que les informaticiens exagéraient.
Sauf que. Sauf que le vrai problème, celui qui va nous péter à la gueule, est encore devant nous. Et cette fois, il ne s’agit pas d’un simple affichage qui déconne ou d’un formulaire qui refuse une date. Non, le 19 janvier 2038 à 03:14:07 UTC, les systèmes qui utilisent des time_t 32 bits vont tout simplement… sauter. Comme un compteur kilométrique qui repasse à zéro après 999 999 km, mais en bien plus dramatique. Parce que là, ce n’est pas votre voiture qui va croire qu’elle a 20 ans de moins. C’est potentiellement des milliards de lignes de code, des infrastructures critiques, et des systèmes embarqués qui vont soudainement croire qu’on est en… 1901.
Le problème : 32 bits, c’est trop petit pour le temps
Pour comprendre le bug de 2038, il faut revenir aux bases. Un time_t en 32 bits, c’est un entier signé qui compte le nombre de secondes écoulées depuis le 1er janvier 1970 à minuit UTC. Le souci, c’est qu’un entier signé sur 32 bits ne peut représenter que des valeurs allant de -2 147 483 648 à 2 147 483 647. Et 2 147 483 647 secondes après le 1er janvier 1970, ça nous amène précisément au 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, le compteur déborde et repasse à -2 147 483 648, soit le 13 décembre 1901 à 20:45:52 UTC.
Autant dire que pour un système qui gère des rendez-vous médicaux, des transactions bancaires, ou des lancements de fusées, se retrouver projeté en 1901, c’est un peu gênant. Surtout que contrairement à Y2K, où le problème était souvent cosmétique (un affichage qui bugue, une comparaison de dates qui foire), là, c’est le cœur même de la représentation du temps qui est touché. Et quand le temps déconne, tout déconne.
Prenez un exemple simple : un système qui calcule la durée d’un prêt bancaire. Si la date de début est en 2037 et que la date de fin est en 2040, le calcul va soudainement donner une durée négative, parce que 2040 sera interprété comme 1904. Résultat : votre prêt est considéré comme remboursé avant même d’avoir été contracté. Amusant, non ?
Pourquoi c’est pire que Y2K (et pourquoi personne n’en parle)
Le bug de l’an 2000 avait un avantage : il était prévisible, visible, et surtout, il touchait principalement des systèmes qui manipulaient des dates sous forme de chaînes de caractères (comme DD/MM/YY). La solution était souvent simple : passer à 4 chiffres pour l’année, et hop, problème réglé. En 2038, c’est bien plus vicieux, parce que le problème est enfoui dans les entrailles des systèmes, là où personne ne regarde.
D’abord, parce que le time_t est utilisé partout. Dans les bases de données, dans les noyaux des systèmes d’exploitation, dans les bibliothèques standard du C, dans les protocoles réseau, dans les systèmes embarqués… Bref, partout où le temps est géré. Et contrairement à Y2K, où il suffisait de mettre à jour quelques lignes de code, là, il faut souvent recompiler des bibliothèques entières, mettre à jour des firmwares, ou pire, remplacer du matériel obsolète qui ne peut pas être mis à jour.
Ensuite, parce que le problème est déjà là, sous nos yeux, mais personne ne le voit. Combien de développeurs savent que leur système utilise un time_t 32 bits ? Combien ont testé le comportement de leur code au-delà de 2038 ? Spoiler : très peu. Et comme le bug ne se manifestera que dans 15 ans, tout le monde se dit qu’on a le temps. Sauf que non. Parce que les systèmes déployés aujourd’hui seront peut-être encore en service en 2038. Et que les développeurs qui écrivent du code aujourd’hui ne seront peut-être plus là pour le corriger.
Enfin, parce que la solution n’est pas aussi simple que « passer en 64 bits ». Sur un PC moderne, oui, c’est globalement ce qui s’est passé. Les systèmes 64 bits utilisent depuis longtemps des représentations du temps capables d’aller largement au-delà de 2038. Linux, Windows, macOS et les langages modernes ne vont donc pas collectivement exploser un mardi matin de janvier 2038. Vous pourrez probablement continuer à regarder des vidéos de chats pendant que le monde brûle. C’est rassurant.
Le vrai problème se trouve ailleurs : dans tout ce qu’on a installé, oublié, enfermé dans une armoire électrique et laissé tourner pendant vingt ans parce que « tant que ça marche, on n’y touche pas ». Et s’il existe une devise capable de résumer l’informatique industrielle, c’est probablement celle-là.
Votre PC sera probablement tranquille. Le vieux boîtier gris au sous-sol, beaucoup moins
Quand on parle du bug de 2038, imaginer des millions de PC Windows qui s’éteignent simultanément est probablement la mauvaise image. Les machines modernes sont majoritairement passées au 64 bits depuis longtemps. Le danger se cache plutôt dans les systèmes embarqués : routeurs, caméras IP, automates industriels, centrales d’alarme, systèmes de contrôle d’accès, équipements médicaux, NAS, vieux terminaux, appareils de mesure, infrastructures de transport et autres merveilles électroniques dont personne ne connaît plus vraiment le mot de passe administrateur.
Ces appareils ont souvent été conçus avec des processeurs 32 bits, un Linux embarqué, quelques bibliothèques C et une espérance de vie théorique de cinq ou dix ans. Puis quelqu’un les a installés dans une usine et, vingt-cinq ans plus tard, ils sont toujours là. Le fabricant a disparu, le firmware n’est plus maintenu depuis 2017 et la documentation technique se trouve probablement sur un CD-ROM dans le tiroir d’un technicien parti à la retraite.
Et c’est précisément ce genre de matériel qui peut poser problème. Pas parce qu’il est incapable de fonctionner en 2038, mais parce qu’il peut être incapable de comprendre 2038.
Imaginez une caméra de surveillance qui signe ses enregistrements avec un timestamp. Elle fonctionne parfaitement depuis quinze ans. Le 19 janvier 2038, elle continue peut-être à filmer, sauf que les nouvelles vidéos sont datées de décembre 1901. Le système de stockage considère alors qu’elles sont vieilles de 136 ans et les supprime immédiatement selon sa politique de rétention. Techniquement, tout fonctionne. C’est même ça qui est magnifique.
Le bug de 2038 peut arriver avant 2038
Et voici la partie amusante : nous n’avons même pas besoin d’attendre 2038.
Un programme n’a pas besoin que l’horloge système atteigne la date fatidique pour rencontrer le problème. Il suffit qu’il essaie de manipuler une date postérieure au 19 janvier 2038. Un certificat valable quinze ans, un contrat longue durée, une date d’expiration, une projection financière, une base de données qui calcule une échéance future… et bienvenue en 1901 avec trente-deux ans d’avance.
C’est exactement ce qui rend le sujet beaucoup moins théorique qu’il n’y paraît. Plus nous approchons de 2038, plus les logiciels qui travaillent avec des dates futures vont commencer à franchir la limite. Un système calculant aujourd’hui une échéance à vingt ans est déjà concerné. Pas besoin d’attendre le grand feu d’artifice à 03:14:08.
C’est un peu comme un mur placé en 2038 : le problème n’arrive pas uniquement lorsque vous percutez le mur. Il commence dès que vous essayez de regarder ce qu’il y a derrière.
Mais alors, pourquoi 64 bits règle le problème ?
Parce qu’avec 64 bits, on change complètement d’échelle. Un entier signé 64 bits peut stocker jusqu’à 9 223 372 036 854 775 807. Si on continue à compter les secondes depuis 1970 avec cette valeur, on obtient une plage de dates tellement gigantesque que l’humanité aura probablement d’autres soucis avant d’atteindre la limite.
On parle d’environ 292 milliards d’années dans chaque direction autour de l’époque Unix. À titre de comparaison, l’Univers a environ 13,8 milliards d’années. Avec un timestamp Unix signé sur 64 bits, nous avons donc une marge raisonnable. Si votre application PHP rencontre un overflow de timestamp dans 292 milliards d’années, vous pourrez ouvrir une issue GitHub. Avec un peu de chance, le mainteneur répondra « cannot reproduce ».
Sur les architectures 64 bits modernes, le problème est donc largement résolu. Mais passer time_t de 32 à 64 bits n’est pas toujours transparent. Cela peut modifier la taille de structures de données, casser des formats binaires, modifier des ABI ou poser des problèmes de compatibilité avec de vieux programmes qui supposent explicitement qu’un timestamp tient dans quatre octets.
Parce que oui : quelque part, quelqu’un a forcé un timestamp dans un int32_t. Et cette personne dort probablement très bien.
Linux a fait ses devoirs
Le monde Linux travaille sur le sujet depuis longtemps. Le problème le plus délicat concernait notamment les systèmes Linux 32 bits, puisque passer toute une architecture en 64 bits uniquement pour pouvoir afficher correctement la date en 2042 aurait été une solution quelque peu radicale.
Le noyau Linux et la glibc ont progressivement introduit la prise en charge de timestamps 64 bits sur les architectures 32 bits. Côté applications, il est donc possible de continuer à utiliser certains processeurs 32 bits tout en manipulant correctement des dates après 2038, à condition évidemment que les logiciels et bibliothèques aient été reconstruits avec les bonnes interfaces.
Et c’est dans ce petit « à condition » que se cache l’intégralité du problème.
Un noyau peut être compatible. La libc peut être compatible. Mais si l’application utilise une vieille bibliothèque qui stocke encore ses dates dans un entier signé 32 bits, vous avez simplement construit une magnifique autoroute 64 bits qui se termine sur un pont en bois.
Les bases de données ont aussi leurs petites casseroles
Et puisque rien n’est jamais simple en informatique, toutes les bases de données ne représentent pas les dates de la même manière.
MySQL et MariaDB constituent un bon exemple historique avec le type TIMESTAMP, longtemps intimement lié à la représentation Unix du temps et donc à une plage de valeurs limitée autour de 2038 selon les versions et les implémentations. Le type DATETIME, lui, suit une logique différente et dispose d’une plage beaucoup plus large.
Ce qui signifie qu’une application peut parfaitement tourner sur un serveur 64 bits flambant neuf, avec un Linux à jour, PHP dernière version, suffisamment de RAM pour faire tourner la NASA… et quand même avoir un problème avec 2038 parce qu’un schéma de base de données conçu quinze ans plus tôt utilise le mauvais type de colonne.
L’informatique est une discipline extraordinaire : on peut remplacer le serveur, le système d’exploitation, le processeur et le langage, puis se faire attaquer par une colonne SQL créée en 2009 par Kevin, stagiaire.
Et JavaScript dans tout ça ?
JavaScript, pour une fois, peut regarder les autres avec un petit sourire satisfait. Son objet Date n’utilise pas directement un entier Unix signé sur 32 bits : il représente traditionnellement le temps en millisecondes dans un Number. Sa plage utilisable va donc largement au-delà de 2038.
Python moderne n’est pas condamné non plus, pas plus que PHP sur les plateformes 64 bits actuelles. Bref, si vous développez aujourd’hui une application web Symfony sur un Linux 64 bits récent, vous n’avez probablement pas besoin de mettre « survivre à janvier 2038 » dans le prochain sprint Jira.
En revanche, si votre application communique avec un automate de 2006, importe des fichiers binaires produits par un logiciel propriétaire abandonné, utilise une vieille base de données ou dialogue avec un appareil embarqué dont le constructeur vous assure que « normalement ça devrait marcher », alors vous venez peut-être de trouver une occupation pour votre après-midi.
Comment savoir si on est concerné ?
La méthode la plus simple est aussi celle que personne n’a envie d’appliquer : tester.
Prenez les systèmes susceptibles d’être encore utilisés dans dix ou quinze ans et faites-leur manipuler des dates comme 2040, 2050 ou 2100. Pas uniquement afficher ces dates : les stocker, les relire, les comparer, calculer des durées, créer des fichiers, vérifier des certificats, exécuter des tâches planifiées et communiquer avec les autres composants du système.
Parce qu’un simple test du genre « j’ai tapé 2040 dans le formulaire et ça s’affiche » ne prouve absolument rien. Le frontend peut afficher 2040 pendant que le backend vient tranquillement d’enregistrer -2085978496 quelque part. L’interface est contente, la base de données est contente, tout le monde est content jusqu’au prochain redémarrage.
Il faut également regarder les formats d’échange. Une application parfaitement compatible 2038 peut transmettre son timestamp à un autre système qui, lui, le convertit en entier 32 bits. Votre code est correct, votre serveur est correct, mais l’API du fournisseur utilise une librairie compilée lorsque Nokia dominait encore le marché du téléphone portable.
Bonne chance pour le ticket support.
Alors, catastrophe mondiale le 19 janvier 2038 ?
Probablement pas.
Et c’est justement là que la comparaison avec Y2K devient intéressante. Si le 1er janvier 2000 s’est finalement plutôt bien passé, ce n’est pas parce que le problème était imaginaire. C’est aussi parce que des milliers d’entreprises et d’administrations avaient passé des années à chercher, tester et corriger leurs systèmes avant la date fatidique.
Le paradoxe des gros bugs prévisibles est assez cruel : quand les informaticiens font correctement leur boulot, rien ne se passe. Et puisque rien ne se passe, tout le monde conclut que le problème était exagéré.
C’est un peu comme payer quelqu’un pour renforcer un barrage avant une tempête, constater ensuite que le barrage n’a pas cédé, puis expliquer que les travaux étaient manifestement inutiles.
Pour 2038, il se passera probablement la même chose. Les systèmes importants seront progressivement corrigés ou remplacés. Les distributions Linux auront terminé leur transition. Les logiciels maintenus auront depuis longtemps abandonné les représentations problématiques. Et le 19 janvier 2038, la majorité d’Internet continuera probablement de fonctionner normalement.
Mais quelque part, dans une usine, un parking, un hôpital ou le sous-sol d’une administration, un vieux boîtier beige sous Linux 2.6 affichera soudainement :
13/12/1901 20:45:52
Un technicien regardera l’écran.
Il redémarrera la machine.
Ça ne changera rien.
Il appellera l’informatique.
Et quelqu’un dira la phrase qui traverse les générations :
« Pourtant, hier, ça marchait. »