Dans onze ans, des systèmes informatiques ne sauront plus compter le temps. Le bug de l’an 2038 a déjà fait des victimes, et sa réparation est en cours.
Vous vous souvenez du bug de l’an 2000 ? Les informaticiens, eux, en préparent un autre, moins connu du grand public mais pris très au sérieux : le bug de l’an 2038, surnommé « Y2038 » ou, avec un certain sens de l’humour, l’« Epochalypse ». La date est connue à la seconde près : le 19 janvier 2038 à 3 h 14 min 07 s en temps universel, soit 4 h 14 à Paris.
À ce moment-là, les systèmes qui stockent l’heure d’une certaine façon atteindront leur limite et pourraient brusquement se croire en décembre 1901. La plupart des ordinateurs et smartphones récents sont déjà à l’abri. Le danger se cache ailleurs.
📝 L’essentiel à retenir :
- Le bug touche les systèmes qui comptent le temps en secondes depuis le 1er janvier 1970 sur un entier de 32 bits.
- Le compteur atteint sa limite, 2 147 483 647 secondes, le 19 janvier 2038 à 3 h 14 min 07 s UTC.
- Le problème a déjà provoqué des pannes, dès 2006, sur des logiciels qui calculaient des dates lointaines.
- Linux, les grandes bibliothèques logicielles et Debian ont été corrigés, mais des systèmes embarqués anciens restent exposés.
Dans cet article :
Pourquoi 2038 ? Une histoire de compteur
Une grande partie des systèmes informatiques, notamment tous ceux issus de la famille Unix, dont Linux, Android ou macOS, mesurent le temps d’une façon très simple : ils comptent le nombre de secondes écoulées depuis le 1er janvier 1970 à minuit, en temps universel. On appelle cette date l’« epoch », d’où le surnom d’Epochalypse.
Pendant des décennies, ce compteur a été stocké dans un nombre entier « signé » de 32 bits. Ce format peut monter jusqu’à 2 147 483 647. Pas un de plus. Ce nombre de secondes après le 1er janvier 1970 tombe précisément le 19 janvier 2038 à 3 h 14 min 07 s UTC. La seconde suivante, le compteur déborde et repart de sa valeur la plus basse, ce qui correspond au 13 décembre 1901. Pour un système mal préparé, le temps fait soudain un bond de 136 ans en arrière.
Le 19 janvier 2038 à 3 h 14 min 08 s UTC, un compteur de 32 bits mal protégé affichera une date de décembre 1901.
Le bug a déjà frappé
On pourrait croire que le problème ne se posera qu’en 2038. Faux : tout logiciel qui manipule des dates futures peut le rencontrer bien avant. En 2006, le logiciel de serveur web AOLserver a ainsi connu des plantages parce qu’il fixait certains délais d’expiration à un milliard de secondes dans le futur, soit au-delà de 2038. Le calcul débordait, et le programme se mettait à dysfonctionner.
Le même risque concerne tous les calculs à long terme : échéanciers, contrats, certificats de sécurité, garanties. Plus on approche de 2038, plus les dates manipulées au quotidien franchissent la limite, et plus les bugs ont de chances d’apparaître dans des systèmes oubliés.
Ce qui a déjà été réparé
La solution est connue : passer à un compteur sur 64 bits, qui repousse la limite à environ 292 milliards d’années. Le travail est en cours depuis longtemps et plusieurs étapes majeures sont franchies.
| Logiciel ou système | Correction |
|---|---|
| Noyau Linux | Version 5.6, en 2020, prise en charge du temps 64 bits sur les systèmes 32 bits |
| Bibliothèque C GNU (glibc) | Version 2.34, en août 2021 |
| MySQL | Version 8.0.28, en janvier 2022 |
| Debian | Debian 13 « Trixie », publiée en août 2025, passe au temps 64 bits sur presque toutes ses architectures 32 bits |
Le chantier Debian est révélateur : basculer une distribution entière a demandé de recompiler des milliers de logiciels. Seule l’ancienne architecture i386 a été laissée de côté, pour préserver la compatibilité avec de vieux programmes. Côté grand public, les ordinateurs, tablettes et smartphones récents, qui fonctionnent en 64 bits, sont déjà protégés pour l’essentiel, y compris les distributions grand public comme Zorin OS, vers laquelle migrent de nombreux déçus de Windows.
Où se cache le vrai danger
Le problème, ce sont les appareils que personne ne met à jour. Des millions de systèmes embarqués fonctionnent encore avec des processeurs et des logiciels 32 bits : automates industriels, équipements réseau, caméras, appareils médicaux, distributeurs, calculateurs de véhicules. Certains auront plus de vingt ans en 2038 et ne recevront jamais de correctif. Des systèmes de fichiers anciens, comme ext2 et ext3 sous Linux, ou des bases de données qui stockent des horodatages sur 32 bits sont aussi concernés.
Il ne faut pas s’attendre à une apocalypse, mais plutôt à une série de pannes discrètes : un équipement qui refuse de démarrer, un journal d’événements qui devient incohérent, un certificat considéré comme expiré. Comme pour l’an 2000, tout l’enjeu est d’inventorier et de corriger avant l’échéance. Et comme en 2000, si tout se passe bien, on dira que c’était beaucoup de bruit pour rien.
Faut-il s’inquiéter pour son matériel ?
Pour un particulier, le risque est faible tant que ses appareils restent à jour. C’est un argument de plus pour ne pas garder éternellement un système abandonné par son éditeur, comme le rappelle le débat autour de la fin du support de Windows 10 et des alternatives Linux. Le monde Linux, souvent sous les projecteurs pour ses failles de sécurité récentes, a d’ailleurs été l’un des plus rapides à s’attaquer au problème de 2038.
Les entreprises, elles, ont tout intérêt à commencer dès maintenant l’inventaire de leurs équipements anciens. Les incidents informatiques coûtent cher, comme l’a rappelé la fuite de 630 Go de données d’Apple et de Tesla, et un bug de date dans un système critique pourrait ouvrir des failles inattendues. Il reste un peu plus de onze ans pour éviter que le 19 janvier 2038 ne devienne le « bug de l’an 2000 » de toute une génération d’ingénieurs.
BuzzWebzine est un média indépendant. Soutiens-nous en nous ajoutant à tes favoris sur Google Actualités :
