Le jour où votre ordinateur est « né »
Vous avez peut-être déjà vu ça : un fichier récupéré sur un vieux disque dur, une photo prise par une caméra de surveillance, ou un appareil qui vient de redémarrer après une coupure de courant, et qui affiche une date de création complètement absurde : le 1er janvier 1970, parfois à minuit pile.
Ce n’est ni un bug isolé ni une coïncidence. C’est la trace d’un choix fait il y a plus de 50 ans, qui régit encore aujourd’hui la quasi-totalité des ordinateurs, smartphones, serveurs et objets connectés de la planète.
Le temps réduit à un seul nombre
La plupart des systèmes Unix et Unix-like (Linux, macOS, Android, et une bonne partie des langages de programmation comme C, Java, JavaScript ou Python) ne stockent pas une date sous la forme « 22 juillet 2026, 14h32 ». Ils stockent un simple nombre entier : le nombre de secondes écoulées depuis un instant de référence, choisi une bonne fois pour toutes. Cet instant s’appelle l’epoch Unix, et il correspond exactement au 1er janvier 1970 à 00h00m00s UTC.
Concrètement, quand votre ordinateur veut savoir « quelle heure est-il », il ne fait qu’une seule chose : additionner. Il prend le nombre de secondes écoulées depuis ce point zéro, et le reconvertit en jour, mois, année, heure, minute, seconde pour vous l’afficher de façon lisible. Toutes les dates, dans les coulisses, ne sont jamais que des grands nombres entiers.
Pourquoi cette méthode ? Parce qu’elle simplifie radicalement les calculs. Comparer deux dates, calculer une durée, trier des événements chronologiquement : tout devient une simple soustraction ou comparaison entre deux nombres, plutôt qu’une gymnastique avec des calendriers, des mois de longueurs différentes et des années bissextiles.
Pourquoi 1970, précisément ?
Contrairement à ce qu’on pourrait imaginer, il n’y a aucune signification particulière derrière cette date. Ni événement fondateur, ni symbole caché. Selon Dennis Ritchie lui-même, l’un des créateurs d’Unix aux laboratoires Bell, ce choix a été fait presque par commodité1.
La première version d’Unix, documentée en 1971, utilisait en réalité une autre référence : le 1er janvier 1971, avec un compteur qui s’incrémentait 60 fois par seconde (calé sur la fréquence du courant électrique américain). Problème : avec un entier de 32 bits, ce système saturait en un peu moins de deux ans et demi2. Les ingénieurs sont alors passés à un compteur en secondes plutôt qu’en soixantièmes de seconde, ce qui a considérablement élargi la plage de dates représentables. N’ayant plus besoin d’économiser chaque bit, ils en ont profité pour reculer le point de départ à une date ronde et facile à retenir : le 1er janvier 19703. Rien de plus.
Pourquoi vos appareils « reviennent » en 1970
Voilà l’explication du mystère du début de l’article. Quand un appareil électronique n’a plus aucune information fiable sur l’heure actuelle — une horloge interne dont la pile est morte, un redémarrage sans connexion réseau ni GPS pour se resynchroniser, une remise à zéro d’usine — il retombe par défaut sur le compteur à 0. Or, le compteur à 0, dans le système Unix, correspond très précisément au 1er janvier 1970 à minuit. L’appareil ne « sait » littéralement rien d’autre que ce point de départ tant qu’il n’a pas pu se resynchroniser avec une horloge fiable (serveur NTP, réseau mobile, GPS…).
C’est exactement le même principe qui explique pourquoi certaines caméras de surveillance bon marché, certains appareils photo ou certains routeurs affichent parfois des dates aberrantes après une coupure de courant : ils redémarrent tout simplement à l’instant zéro de leur horloge interne.
Le piège caché dans le nombre lui-même
Là où l’histoire devient vraiment intéressante, c’est que ce nombre de secondes n’est pas infini. Sur la majorité des systèmes conçus entre les années 1970 et le milieu des années 2000, il est stocké dans un entier signé de 32 bits — une case mémoire qui ne peut contenir qu’un nombre limité de valeurs, de -2 147 483 648 à +2 147 483 6474.
Traduit en dates, cet entier de 32 bits ne peut représenter que des instants compris entre le 13 décembre 1901 et… le 19 janvier 2038, à 03h14m07s UTC très précisément5
Une seconde plus tard, le compteur devrait afficher 2 147 483 648. Mais cette valeur n’existe tout simplement pas dans un entier signé de 32 bits : elle dépasse la capacité maximale de la case mémoire. Le nombre « déborde » et repart du bas de son échelle, à -2 147 483 648 — ce qui correspond, une fois reconverti en date, au 13 décembre 19014. En un instant, un système non corrigé croira avoir fait un bond de 137 ans dans le passé.
C’est ce qu’on appelle le bug de l’an 2038, parfois surnommé Y2K38 ou « l’Epochalypse », en écho direct au fameux bug de l’an 2000.
Y2K38 n’est pas tout à fait Y2K
La comparaison avec le bug de l’an 2000 est tentante, mais elle a ses limites. Le bug de l’an 2000 venait d’une convention humaine : par souci d’économie de mémoire, de nombreux programmes stockaient les années sur deux chiffres (« 99 » pour 1999), un choix de conception logicielle qu’il suffisait, en théorie, de corriger application par application.
Le bug de l’an 2038 est d’une autre nature : il est ancré dans un type de données fondamental du langage C (time_t), utilisé depuis des décennies par les systèmes d’exploitation, les systèmes de fichiers, les protocoles réseau et d’innombrables logiciels. Ce n’est donc pas seulement une question d’applications à corriger, mais potentiellement de systèmes entiers, parfois embarqués dans du matériel physique impossible à mettre à jour à distance.
Et le plus troublant, c’est que ce bug n’a pas attendu 2038 pour se manifester. Dès mai 2006, le logiciel serveur AOLServer configurait certaines requêtes pour ne « jamais » expirer, en fixant leur expiration un milliard de secondes dans le futur. Problème : un milliard de secondes après le 13 mai 2006 dépasse la limite de 2038. Résultat, ces requêtes calculaient une date d’expiration… déjà passée, et le logiciel plantait, plus de trente ans avant l’échéance officielle6. Plus récemment, une vulnérabilité affectant des systèmes de jauge de cuves à carburant a été documentée par l’agence américaine de cybersécurité CISA : falsifier l’horloge d’un de ces systèmes suffit à déclencher artificiellement le débordement de 2038, perturbant la surveillance des niveaux de carburant7.
Qui est concerné, et que fait-on pour l’éviter ?
La bonne nouvelle, c’est que la plupart des systèmes modernes ont déjà basculé vers un entier de 64 bits pour stocker le temps. Un tel entier peut compter les secondes pendant environ 292 milliards d’années avant de déborder à son tour — de quoi voir venir très largement5. Linux, macOS et Android ont, ou sont en train de finaliser, cette transition au niveau du noyau et des bibliothèques système.
Le vrai point de vigilance concerne les systèmes embarqués à très longue durée de vie et rarement mis à jour : automates industriels, équipements médicaux, systèmes de contrôle de bâtiments, infrastructures télécoms, certains équipements automobiles ou aéronautiques. Beaucoup tournent encore sur des processeurs 32 bits avec des logiciels écrits il y a plusieurs décennies, parfois par des entreprises qui n’existent plus. Un automate installé en 2015 avec une durée de vie prévue de 25 ans sera encore en service bien après 2038, sans qu’il soit toujours simple, ni même possible, de le mettre à jour.
La morale de l’histoire
Ce qui frappe, avec l’histoire de l’epoch Unix, c’est la façon dont une décision technique parfaitement anodine — un point de départ arbitraire, choisi par commodité en 1970, encodé dans une case mémoire dont la taille semblait alors largement suffisante — continue de façonner le monde numérique plus d’un demi-siècle plus tard. Personne, à l’époque, ne pensait sérieusement que du code écrit pour les débuts d’Unix tournerait encore sur des infrastructures critiques en 2038.
C’est sans doute la leçon la plus universelle de cette anecdote, et elle rejoint celle de Mariner 1 : dans l’informatique, les décisions qui semblent les plus insignifiantes sur le moment sont souvent celles qui pèsent le plus lourd des décennies plus tard.
Sources
- Jared Davis — January 1, 1970: The Day the Software Industry was Created, citant l’article de Farhad Manjoo dans Wired (2001)
- Baeldung on Linux — Why Was 1 January 1970 Used as the Epoch Time?
- Bitsight — Forward to the Past: The Y2K38 Problem Ahead
- Medium (Ushan Dilusha) — The Year 2038 Problem: A Ticking Time Bomb in Our Digital Infrastructure
- Wikipédia — Year 2038 problem
- 2038.wtf — The Y2038 Bug: What You Need to Know (incident AOLServer, mai 2006)
- y2k38compliant.com — The Year 2038 Problem, Why Y2K38 Compliance Matters (CVE-2025-55068, systèmes Dover Fueling Solutions)