Une horloge qui n’est en réalité qu’un seul nombre
Presque tous les appareils que vous avez touchés aujourd’hui s’accordent sur un nombre. Pas sur l’heure de votre ville, ni sur votre calendrier, ni sur votre fuseau : un unique nombre entier qui compte les secondes écoulées depuis minuit le 1ᵉʳ janvier 1970, en UTC. Ce nombre s’appelle le temps Unix, et c’est en ce moment un nombre à dix chiffres qui augmente de un chaque seconde.
L’idée est élégante. Au lieu de stocker « mardi, 15 heures à Paris », avec toutes ses règles humaines, une machine enregistre quelque chose comme 1771200000. Un instant, un nombre, sans ambiguïté. Votre serveur à Francfort, votre téléphone à Dakar et un capteur dans une usine s’accordent dessus même si leurs horloges murales affichent des choses différentes. Vous pouvez voir le nombre actuel et le traduire en date lisible dans notre convertisseur de timestamp Unix.
Le problème, c’est qu’un nombre qui ne fait que monter finit par manquer de place. Et pour une manière très précise et très répandue de stocker le temps Unix, nous savons exactement quand : 03:14:07 UTC, le 19 janvier 2038.
Pourquoi 1970
Le point de départ, appelé « époque » (epoch), est le 1ᵉʳ janvier 1970. Rien de cosmique. Au début des années 1970, les ingénieurs qui construisaient Unix aux Bell Labs avaient besoin d’une date zéro pratique et récente, et un début de décennie bien rond faisait l’affaire. Les instants antérieurs à 1970 sont simplement représentés par des nombres négatifs.
Cette décision modeste s’est répandue dans tout le monde numérique. Aujourd’hui, le temps Unix se trouve dans des bases de données, des protocoles réseau, des systèmes de fichiers, des journaux et le firmware d’appareils que leurs créateurs n’avaient jamais imaginés. La date d’origine n’a presque jamais d’importance. Ce qui compte, c’est l’espace que l’ordinateur a réservé pour ranger le nombre.
Le nombre qui s’épuise
Pendant des décennies, la façon courante de stocker le temps Unix a été un entier signé de 32 bits. « Signé » signifie qu’un bit sert à distinguer les nombres positifs des négatifs, ce qui laisse une valeur maximale de 2 147 483 647. C’est le nombre de secondes que ce compteur peut contenir.
Ajoutez 2 147 483 647 secondes à minuit en 1970 et vous arrivez à 03:14:07 UTC, le mardi 19 janvier 2038. Une seconde de plus et le compteur déborde. Comme le bit de signe bascule, le nombre ne passe pas à 2 147 483 648 : il devient négatif et atterrit le 13 décembre 1901. Pensez au compteur kilométrique d’une vieille voiture qui passe de 999999 à 000000, sauf qu’ici la voiture réapparaît soudain au siècle précédent.
Un détail ravit les passionnés : l’heure limite est 03:14:07, soit 3, 14, 7, un clin d’œil aux premiers chiffres de pi. Le temps Unix compte plusieurs de ces instants célébrés, et celui de 2038 est simplement le premier qui casse des choses au lieu d’orner un tee-shirt.
| Valeur de temps Unix | Instant (UTC) | Pourquoi on s’en souvient |
|---|---|---|
| 0 | 1ᵉʳ janvier 1970, 00:00:00 | L’époque : la seconde zéro dont tout dépend. |
| 1 000 000 000 | 9 septembre 2001, 01:46:40 | Le « Unix billennium », célébré par les programmeurs. |
| 1 234 567 890 | 13 février 2009, 23:31:30 | Un compte à chiffres ordonnés ; il y a eu de vraies fêtes. |
| 2 147 483 647 | 19 janvier 2038, 03:14:07 | Le plafond des 32 bits signés : le problème de l’an 2038. |
Pourquoi ce n’est pas le bug de l’an 2000 déguisé
On est tenté de ranger cela à côté du bug de l’an 2000 et de passer à autre chose. Mais ce sont deux problèmes différents. Le bug de l’an 2000 était une convention humaine : les logiciels stockaient les années sur deux chiffres, donc « 99 » devenait « 00 » et l’ordinateur ne savait plus si c’était 1900 ou 2000. C’était un problème de format, surtout dans la couche où les gens lisent et écrivent les dates.
L’an 2038 est plus profond. Il ne s’agit pas de l’affichage d’une date, mais de l’unité fondamentale avec laquelle la machine compte le temps. On ne le corrige pas en écrivant des années à quatre chiffres à l’écran ; il faut agrandir le récipient qui contient le nombre lui-même.
| An 2000 | An 2038 | |
|---|---|---|
| Racine du problème | Années stockées sur deux chiffres | Secondes stockées sur 32 bits signés |
| Couche concernée | Format et présentation | Le type de donnée et le stockage sous-jacent |
| Solution typique | Utiliser des années à quatre chiffres | Utiliser des entiers de 64 bits pour le temps |
| Plus difficile à changer | Logique applicative | Formats sur disque, protocoles et vieux appareils |
Le plus étrange : 2038 casse déjà des choses
L’erreur subtile est de croire à une falaise lointaine. Ce n’en est pas une. Tout système qui calcule des dates vers l’avenir franchit déjà la frontière de 2038 aujourd’hui. Un prêt sur trente ans signé en 2026 calcule des échéances postérieures à 2038. Un certificat, une garantie, une police d’assurance ou un abonnement de longue durée font une arithmétique qui dépasse la limite bien avant que la date n’arrive.
C’est pourquoi on a déjà vu des pannes isolées : un système qui tente de représenter « dans vingt ans » dans un entier de 32 bits obtient soudain une date de 1901, un délai négatif ou une erreur inexplicable. L’an 2038 n’attend pas 2038. Il arrive plus tôt pour tout code qui regarde assez loin devant lui.
Où ça fait vraiment mal, et où non
Bonne nouvelle : votre ordinateur portable et votre téléphone sont presque certainement épargnés. Les systèmes d’exploitation modernes en 64 bits stockent déjà le temps Unix sur des entiers de 64 bits. JavaScript compte le temps en millisecondes dans un nombre à virgule flottante qui ne pose pas de problème avant des centaines de milliers d’années. Python utilise des entiers de précision illimitée. Pour la plupart des logiciels à jour, 2038 n’est qu’une note de bas de page.
Le danger vit ailleurs : dans les appareils 32 bits à longue durée de vie et aux mises à jour rares. Routeurs, automates industriels, compteurs intelligents, équipements médicaux, calculateurs de voiture et capteurs qu’on installe et qu’on oublie pendant vingt ou trente ans. Et aussi dans les formats : champs de date fixes de 32 bits à l’intérieur de fichiers, de protocoles réseau, de vieux systèmes de fichiers et de colonnes de bases de données conçues il y a longtemps. Le processeur peut être prêt, mais les données enregistrées dans l’ancien format ne se corrigent pas toutes seules.
Le correctif est ennuyeux, et c’est tant mieux
La solution principale est simple à énoncer : stocker le temps dans un entier signé de 64 bits au lieu de 32. Cela porte la portée du compteur à environ 292 milliards d’années, bien au-delà de l’âge de l’univers. Pas besoin d’inventer quoi que ce soit ; il suffit de donner plus de place au nombre.
Une grande partie de ce travail est déjà faite. Le noyau Linux a consacré des années à rendre sûres face à 2038 même les plateformes 32 bits, les bibliothèques standard ont été mises à jour et les BSD ont fait de même. Le plus dur n’est pas le processeur, mais les données au repos : migrer des formats de fichiers, des protocoles et de vieux appareils sans casser tout ce qui en dépend déjà. C’est un travail discret, peu glamour et profondément utile ; exactement ce que doit être une bonne ingénierie d’infrastructure.
Ce que vous pouvez faire
- Vérifiez si votre langage ou votre base de données stocke le temps sur 32 ou 64 bits, surtout sur les systèmes anciens.
- Repérez tout endroit où vous calculez des dates à des années ou décennies de distance ; ce code franchit 2038 dès aujourd’hui.
- Examinez les appareils embarqués et les firmwares à longue durée de vie, là où les mises à jour sont rares.
- Traitez les dates sur disque et dans les protocoles comme des contrats : changer la taille d’un champ de temps affecte tout ce qui le lit.
- Testez l’horloge de votre système au-delà de 2038 dans un environnement contrôlé pour voir ce qui casse avant que cela ne compte.
Un nombre qu’il vaut la peine de surveiller
Le problème de l’an 2038 rappelle utilement que le temps numérique est un choix humain, pas une loi naturelle. Nous avons décidé de compter des secondes, décidé de partir de 1970 et décidé du nombre de bits à y consacrer. Chacune de ces décisions était raisonnable au moment où elle a été prise, et chacune laisse une trace qui dure des décennies.
Pendant ce temps, le compteur monte en silence, une seconde par seconde. Si vous êtes curieux de le voir, regardez le nombre actuel dans notre convertisseur de timestamp Unix, confirmez la date du jour ou calculez le temps restant jusqu’à une date future avec le calculateur de délais. Et si les bugs de temps qui cassent déjà des logiciels aujourd’hui vous intéressent, notre guide des bugs de date et d’heure les plus courants poursuit l’histoire.