Pourquoi parler d'une catastrophe informatique prévue pour 2038 avec les outils mentaux de 2026, c'est à peu près aussi pertinent que de prédire la météo du 19 janvier prochain en regardant celle du 25 avril.
Préambule pour les esprits chagrins
Dans les semaines, mois et années qui viennent, vous allez assister à un spectacle. Une parade. Un défilé d'influenceurs Tech, de chaînes YouTube à miniatures jaunes hurlantes et de comptes X à 200 000 abonnés, qui vont tous, comme un seul homme, vous expliquer avec gravité que le bug de 2038 est pire que le bug de l'an 2000. Que personne n'en parle. Qu'eux, courageusement, brisent le silence. Qu'il faut s'inquiéter dès maintenant. Qu'il faut s'abonner pour la suite.
Ce billet n'est pas écrit dans cet esprit. Ce billet est écrit pour la raison inverse : vous donner de quoi comprendre tranquillement ce qui va, ne va pas, et pourrait éventuellement se passer en janvier 2038, en ayant à l'esprit que nous raisonnons en avril 2026 sur des objets qui n'existent pas encore, et que les ingénieurs qui les conçoivent ne sont, contrairement à la légende, ni amnésiques ni complètement idiots.
Allons-y.
Le bug, en deux paragraphes pour ceux qui débarquent
Le 19 janvier 2038, à 03:14:07 UTC précisément, un certain nombre de systèmes informatiques vont avoir un problème. La cause est mathématique et pas particulièrement mystérieuse : Unix — le système d'exploitation qui motorise la quasi-totalité du monde non-Windows, des serveurs aux smartphones Android en passant par les box Internet — compte le temps en secondes écoulées depuis le 1er janvier 1970 à minuit UTC. Cette date arbitraire s'appelle l'epoch, et le compteur qui tourne depuis a longtemps été stocké dans un entier signé sur 32 bits.
Or un entier signé 32 bits ne peut pas dépasser 2 147 483 647. Pile la valeur que prendra ce compteur au moment fatidique. À la seconde suivante, il déborde, le bit de signe bascule, et la machine croit soudain être le 13 décembre 1901 à 20:45:52 UTC. Bond en arrière de 136 ans. Voilà. C'est tout. Ce n'est pas un complot, ce n'est pas une faille de sécurité originelle, c'est juste un type de donnée qui arrive au bout de sa capacité, exactement comme votre disque dur de 1 To finit toujours par afficher "98 % d'espace utilisé" quoi que vous fassiez.
Pourquoi ce billet n'est pas un billet de panique
Voici le problème central des articles "OMG le bug de 2038", et il est intellectuellement embarrassant : on raisonne avec le matériel d'aujourd'hui pour parler d'un événement qui se produira dans douze ans. C'est intéressant comme exercice, mais c'est aussi totalement déconnecté de ce qui va vraiment se passer.
Reprenons. Le matériel grand public que vous utilisez en avril 2026 — votre smartphone, votre routeur Wi-Fi 6, votre Smart TV 4K, votre montre connectée — aura entre 12 et 15 ans en janvier 2038. Pour la majorité, il aura été mis à la déchetterie depuis longtemps, soit parce qu'il aura cessé de fonctionner, soit parce qu'il sera devenu trop lent pour le logiciel qui tourne dessus, soit parce qu'il aura été remplacé pour la simple raison que le constructeur ne le supporte plus. C'est triste, c'est consumériste, c'est un sujet en soi (et un autre billet à venir, peut-être), mais c'est la réalité du cycle de vie.
Le matériel qui sera en service en 2038 et qui n'existe pas encore aujourd'hui est, lui, en train d'être conçu en ce moment même par des gens qui sont parfaitement au courant du problème. Le bug Y2K38 est documenté depuis les années 1990. Les langages modernes (Java, JavaScript, Python 3, Go, Rust) gèrent nativement le temps en 64 bits depuis leur création ou presque. Le noyau Linux gère le temps 64 bits même sur les architectures 32 bits depuis la version 5.6, sortie en mars 2020. Les systèmes de fichiers modernes (ZFS, NTFS, ReFS) ont été conçus avec des timestamps 64 bits dès le départ. Les fonderies de silicium ont massivement migré vers les architectures 64 bits dans les années 2010. Et, pour prendre un exemple très concret cher aux makers : Espressif, qui produit l'omniprésent ESP32, est en train de migrer une partie de sa gamme vers RISC-V (ESP32-C3, C6, S3) avec un support natif des timestamps 64 bits dans son SDK.
Autrement dit : pour la grande majorité des objets que vous achèterez entre maintenant et 2038, le bug Y2K38 sera un non-événement. Comme l'an 2000 l'a été pour la quasi-totalité des PC qu'on a achetés en 2003 — non pas parce qu'on a fait des miracles entre 1999 et 2003, mais simplement parce qu'à un moment, on a remplacé le matériel.
Ce qui est déjà réglé, et ce qu'on peut tranquillement cocher
Faisons l'inventaire de ce qui n'est plus un sujet, parce que la liste est plus longue que ce que les marchands de panique racontent.
Côté systèmes d'exploitation grand public : Windows depuis le passage au XXIe siècle utilise un format temporel sur 64 bits qui n'est pas concerné. macOS et iOS utilisent du 64 bits sur tous les appareils modernes. Linux 64 bits a toujours été immune, et Linux 32 bits est traité depuis le kernel 5.6. Android moderne, idem. BSD, idem. Bref : votre poste de travail, votre serveur, votre téléphone récent, tout ça est OK.
Côté langages et runtimes : Java et JavaScript stockent les timestamps en long 64 bits depuis toujours, ce qui leur donne environ 292 millions d'années de marge. Python 3 utilise des entiers à précision arbitraire. Go utilise int64. Rust a son i64 natif. C/C++ moderne aussi, dès lors qu'on compile avec un time_t 64 bits — ce qui est le cas par défaut sur toute distribution Linux maintenue. Tout ça, c'est de l'acquis.
Côté bases de données : PostgreSQL gère nativement les timestamps au-delà de 2038. MySQL a corrigé son type TIMESTAMP à partir de la version 8.0.28 — pour les versions antérieures, la migration vers DATETIME ou BIGINT est triviale. SQLite stocke les dates en texte ISO ou en double, donc pas concerné. Les SGBD du monde Oracle, Microsoft SQL Server, MariaDB récentes : tous OK.
Côté systèmes de fichiers et protocoles réseau modernes : ZFS, NTFS, ReFS, F2FS sont conçus 64 bits. ext4 et XFS sont OK avec le flag bigtime activé (à vérifier sur les montages anciens). NFSv4 est OK. HTTP/2, HTTP/3, TLS 1.3 ne sont pas concernés. La plupart des protocoles modernes utilisent des formats de date 64 bits ou ISO.
Bref : si vous travaillez en 2026 sur du matériel et du logiciel à jour, vous n'avez rien à faire. Le problème a déjà été traité, en silence et progressivement, sur les dix dernières années.
Ce qui reste, et qui est intéressant
Là où ça devient sérieux, ce n'est pas dans le grand public ni dans les data centers cloud. C'est dans trois zones spécifiques que la presse tech mainstream ne sait pas couvrir parce qu'elles sont moches, lentes, et n'engagent pas de clics.
Zone 1 — Le legacy industriel non patchable
Le vrai talon d'Achille de Y2K38, ce sont les automates programmables, les systèmes SCADA, les IHM de gestion technique de bâtiment, les contrôleurs de procédés industriels installés dans les années 2000 et 2010 et qui sont conçus pour durer 20 à 40 ans. Une station d'épuration équipée en 2008, une chaîne de production de l'industrie agroalimentaire mise en service en 2012, un système de gestion centralisée du chauffage d'un bâtiment public, une jauge de cuve dans une station-service : tous ces équipements ont été calibrés pour une durée de vie qui les emmènera bien au-delà de 2038.
L'exemple récent et instructif, c'est celui des produits ProGauge de Dover Fueling Solutions — des jauges automatiques de cuves utilisées dans les stations-service. La CISA américaine a publié en 2025 la CVE-2025-55068, qui documente précisément une vulnérabilité de manipulation du temps système permettant un déni de service. Le fournisseur a patché. Combien de stations-service installeront le patch dans les douze prochaines années ? Mystère.
Ces équipements partagent trois caractéristiques qui les rendent quasiment intraitables :
- Le firmware est rarement updatable, soit parce qu'il est gravé en ROM, soit parce que la procédure de mise à jour exige une intervention physique d'un technicien certifié, soit parce que l'éditeur a tout simplement disparu.
- Le coût de remplacement est colossal : changer un automate Siemens dans une centrale, c'est potentiellement quelques semaines d'arrêt de production et un budget à six chiffres.
- Personne ne sait précisément ce qui est installé où : il n'existe pas, contrairement à Y2K, de base de données mondiale des équipements vulnérables. Chaque exploitant doit faire son propre inventaire, et la plupart ne l'ont pas fait.
C'est dans cette zone-là que se produiront, à mon avis, les vrais incidents Y2K38. Pas en 2038, d'ailleurs : dès maintenant, sur des systèmes qui font des calculs avec des dates futures (loyers à 30 ans, échéances de maintenance préventive, dates de péremption sur du long terme).
Zone 2 — L'IoT bas de gamme et les firmwares fantômes
Cas de figure très différent : les centaines de millions de petits appareils connectés vendus depuis dix ans avec un firmware Linux embarqué basé sur du logiciel non maintenu. La star incontestée de cette catégorie, c'est le serveur web Boa. Petit serveur HTTP écrit en C dans les années 1990 pour systèmes embarqués à très faibles ressources. Distribution officielle non maintenue depuis 2005. Et pourtant, encore aujourd'hui, on le retrouve sur des routeurs, modems, caméras IP, DVR, NVR, imprimantes, NAS d'entrée de gamme, IHM industrielles. BitSight a recensé environ 500 000 instances exposées sur Internet — et c'est juste la partie émergée.
Concrètement, ça veut dire que la caméra IP que vous avez achetée 30 € en 2018 sur un site dont vous avez oublié le nom, qui surveille votre garage et que vous n'avez plus jamais touchée depuis, fait probablement tourner du Boa sur du Linux 32 bits avec un time_t 32 bits. En 2038, elle se croira en 1901. Il est possible qu'elle continue à filmer normalement (les fonctions image ne dépendent pas du temps absolu). Il est aussi possible qu'elle refuse tous les certificats TLS et ne puisse plus se connecter au cloud. Ou qu'elle se mette à boucler sur un reboot continu parce qu'un compteur de uptime devient négatif. Personne ne le saura avant que ça arrive.
Dans la même catégorie : les vieilles Smart TV, les liseuses, les montres connectées d'avant 2018, les centrales d'alarme grand public, les babyphones connectés, les serrures à code, les ampoules Wi-Fi premier prix, les thermostats programmables anciens. Tout ce que personne ne pense à mettre à jour.
Zone 3 — Les certificats, les logs, et les choses qu'on ne voit pas
Dimension nouvelle par rapport à Y2K, et probablement sous-estimée : la cryptographie. Une grande partie des protocoles modernes (TLS, signatures électroniques, jetons d'authentification, certificats de code) reposent sur la comparaison de dates. Une autorité de certification émet un certificat avec une date de début et une date de fin de validité. Si la machine qui valide ce certificat se croit en 1901 ou en 2038 alors qu'on est en 2030, elle peut soit rejeter un certificat parfaitement valide, soit accepter un certificat expiré.
Conséquence : un appareil qui par ailleurs fonctionne très bien peut se retrouver complètement coupé du réseau parce qu'il ne fait plus confiance à rien. Ou pire — fait confiance à n'importe quoi.
Idem pour les logs et systèmes de surveillance qui indexent les événements par timestamp. Un SIEM qui reçoit des événements horodatés en 1901 va les classer comme "très anciens" et possiblement les ignorer. Un système de forensic qui doit reconstituer la chronologie d'une attaque va se retrouver avec des logs incohérents. Pas de panne spectaculaire, mais une dégradation silencieuse de la fiabilité.
Ce qui se passera vraiment, à mon humble avis
Pas un blackout planétaire à 03:14:08 UTC le 19 janvier 2038. Pas d'avions qui tombent. Pas de centrales qui explosent. Probablement même pas de gros titres dans la presse non spécialisée le lendemain.
Ce qui se passera, c'est plutôt une longue traînée de défaillances diffuses, étalée sur les années qui précèdent et qui suivent l'échéance. Ça a déjà commencé, d'ailleurs : en 2006, AOLServer a crashé parce qu'un timeout d'un milliard de secondes plaçait l'expiration au-delà de 2038. Plus récemment, plusieurs jeux mobiles refusent qu'on règle la date du téléphone au-delà de 2038, ce qui empêche les joueurs astucieux de tricher sur les périodes d'attente. Les banques traitent depuis longtemps des prêts sur 30 ans qui dépassent l'échéance, et il y a déjà eu plusieurs incidents documentés.
À mesure qu'on approche de 2038, ces incidents vont se multiplier. Une caméra IP qui tombe en boucle de reboot. Un système d'archives qui rejette les nouveaux fichiers. Un automate de péage qui refuse les cartes bleues parce qu'il ne valide plus le certificat du terminal. Un tableau de bord industriel qui affiche des durées négatives. Une sauvegarde corrompue parce qu'indexée par timestamp 32 bits qui a débordé. Aucun de ces incidents pris séparément ne fera la une. Tous, cumulés, représenteront un coût et un agacement bien réels.
Et le 19 janvier 2038 lui-même ? Probablement quelques pannes spectaculaires sur des trucs qu'on aura oubliés d'auditer (parce qu'il y aura toujours des trucs qu'on aura oubliés d'auditer), beaucoup d'articles de presse "tout va bien", quelques tweets ironiques de gens qui auront retrouvé leurs vieux articles de panique de 2026, et la vie continuera.
Pourquoi ce n'est pas "pire que Y2K", contrairement à ce qu'on va vous dire
Comparer les deux bugs en termes de "pire" ou "moins pire" est une erreur de catégorie. Ils ne sont pas comparables, parce qu'ils n'ont pas la même nature.
Y2K était massif, applicatif, et visible. Tout le monde savait quels systèmes étaient concernés (les applications de gestion en COBOL stockant les années sur deux chiffres), et tout le monde pouvait les auditer. Le problème était violent — un point précis dans le temps, une bascule simultanée — mais la réponse était claire : on inventorie, on patche, on teste. La mobilisation a été exemplaire, le coût astronomique (entre 300 et 600 milliards de dollars dans le monde), et le résultat largement positif.
Y2K38 est diffus, structurel, et invisible. Le problème ne touche pas une couche applicative qu'on peut auditer ligne par ligne, il touche les types de données fondamentaux qui parcourent toute la pile logicielle, du firmware jusqu'à la base de données. Et surtout, il touche massivement de l'embarqué qui ne sera pas patché parce que techniquement non patchable. La bonne nouvelle : il n'y aura pas de moment unique catastrophique. La mauvaise : il y aura un long ronron de défaillances ponctuelles, parfois critiques, qui s'étalera sur une décennie.
Ce n'est ni mieux ni pire. C'est différent. Et ça appelle une réponse différente : pas une mobilisation médiatique massive sur 2 ans façon mission Jospin, mais un inventaire patient, sectoriel, mené sur 10 ans par les opérateurs d'infrastructures critiques, les industriels, les éditeurs de progiciels métiers, et les administrations. Boulot peu glamour. Boulot qui ne se monétise pas en miniatures YouTube. Boulot qui se fait quand même, dans les coulisses, par des gens compétents que vous ne connaîtrez jamais.
Ce qu'il faut retenir, vraiment
Premièrement : si vous achetez aujourd'hui du matériel grand public à jour, vous n'avez rien de spécial à faire. Vos appareils ne seront probablement plus en service en 2038, et ceux qui le seront auront été conçus dans la connaissance du problème.
Deuxièmement : si vous êtes responsable d'une infrastructure IT — y compris une infrastructure modeste comme un homelab solide — un audit ciblé sur quelques points précis est une bonne idée. Quel time_t est utilisé sur vos VMs et conteneurs (getconf LONG_BIT et un petit programme C de trois lignes répondent à la question) ? Quels sont vos systèmes de fichiers et leurs flags ? Quelles versions de MySQL faites-vous tourner ? Quels protocoles NFS utilisez-vous ? Avez-vous des certificats avec des dates d'expiration au-delà de 2038 ? Rien de ça n'est urgent, mais tout ça mérite d'être noté.
Troisièmement : si vous êtes dans le monde industriel, dans le médical, ou dans toute infrastructure critique, c'est sur vous que repose le vrai travail. Les inventaires sont à mener maintenant. Les fournisseurs sont à interroger sur leur statut Y2K38. Les budgets de remplacement sont à arbitrer. Les vieux automates sur lesquels personne n'a touché depuis quinze ans, ce sont eux qui méritent l'attention.
Quatrièmement : ne croyez pas le premier influenceur Tech qui vous criera que c'est l'apocalypse. Ne croyez pas non plus celui qui vous dira que c'est totalement bidon. La vérité est, comme souvent, ennuyeuse et nuancée. Ce n'est ni un non-sujet ni une catastrophe. C'est un sujet d'ingénierie sérieux qui appelle une réponse sérieuse, distribuée et patiente. Pas un buzz.
Le vrai sujet, en sous-texte
Au fond, ce que Y2K38 met en lumière, ce n'est pas un bug. C'est une question politique et industrielle : que fait-on des objets numériques qu'on ne sait plus mettre à jour ?
Toute notre civilisation matérielle s'est construite sur l'idée qu'un objet, une fois fabriqué, vit sa vie sans qu'on s'en occupe. Une machine à laver des années 1980 lave encore. Une voiture entretenue de 1995 roule encore. Un téléphone à cadran de 1965 sonne encore. Le numérique a inversé cette logique : un objet connecté qui n'est pas mis à jour devient progressivement obsolète, vulnérable, voire dangereux. Et la question de la maintenance à long terme du parc numérique est aujourd'hui largement non résolue.
Y2K38 est une manifestation parmi d'autres de ce problème de fond. La fin du support Windows 10 en est une autre. L'abandon des Android par leur fabricant après deux ans en est une troisième. La disparition des éditeurs de logiciels métiers spécialisés qui laissent leurs clients avec des installations orphelines en est une quatrième. Le vrai sujet, ce n'est pas que les bits débordent en janvier 2038. C'est que nous avons construit une civilisation qui dépend d'objets numériques dont la durée de vie utile est structurellement inférieure à leur durée de vie physique, et qu'on ne sait pas — pour l'instant — quoi faire de ce décalage.
Ça, c'est un sujet bien plus important que de savoir si votre Smart TV de 2019 affichera la bonne date dans douze ans.