2038 : les équipements connectés seront-ils prêts pour ce rendez-vous ?

Quand les machines durent plus longtemps que leur support logiciel

Un technicien observe une machine industrielle dont l'écran signale une fin de support logiciel et un redémarrage impossible.

En octobre 2026, une cyberattaque touchant des équipements frigorifiques de supermarchés rappelait une réalité devenue familière : derrière une machine très matérielle se cache parfois tout un système informatique. Nous en parlions dans « Chaîne du froid dans les supermarchés : quand le contrôle à distance devient perte de contrôle ». Mais les connexions et les intrusions ne sont pas les seules sources de fragilité. Certaines machines pourraient rencontrer un autre problème, annoncé depuis longtemps, simplement parce qu'elles ne sauraient plus correctement lire l'heure.

Le rendez-vous est fixé au 19 janvier 2038. Pas de panique : il ne s'agit ni de prévoir l'arrêt général des réfrigérateurs ni de réserver dès maintenant une place au musée pour votre grille-pain connecté. En revanche, cette date nous invite à regarder autrement la durée de vie des objets que nous confions à l'informatique.

Une seconde de trop

Dans de nombreux programmes, l'heure est représentée par le nombre de secondes écoulées depuis le 1er janvier 1970 (début de l'heure Unix, qui sert de référence temporelle standard en informatique). Lorsque ce nombre est stocké dans un entier signé de 32 bits, il ne peut dépasser 2,15 milliards de secondes. Cette limite sera atteinte le 19 janvier 2038 à 03 h 14 min 07 s, en temps universel (UTC).

La seconde suivante, certains systèmes pourraient interpréter la date comme un retour en décembre 1901 (valeur maximale en négatif). D'autres rejetteront l'information ou produiront un calcul erroné. C'est ce qu'on appelle le bug de l'an 2038, ou Y2038.

Il existe des solutions, notamment l'emploi de représentations du temps sur 64 bits. Surtout, tous les appareils dotés d'un processeur 32 bits ne sont pas menacés : tout dépend de la façon dont l'équipement et ses logiciels manipulent les dates.

Une erreur d'horodatage ne signifie pas non plus qu'un moteur s'arrêtera ou qu'un thermostat cessera de réguler une température. Mais elle pourrait perturber un historique, une alarme programmée, une supervision ou un échange de données. Pour un équipement isolé, ce serait peut-être une curiosité. Pour une installation dépendant de multiples automatismes, le diagnostic pourrait devenir plus délicat.

Et 2038 n'est même pas la prochaine échéance : dans une moindre mesure, dès le 7 février 2036, un autre compteur temporel atteindra sa limite, celui du protocole NTP (Network Time Protocol), utilisé pour synchroniser les horloges des équipements informatiques. Ce protocole prévoit un mécanisme de changement d'ère, mais encore faut-il que les logiciels l'appliquent correctement.

Décidément, le temps ne simplifie pas toujours la vie des informaticiens.

Des corrections déjà engagées

Le risque n'est pas seulement hypothétique pour les industriels. Des constructeurs comme Axis Communications, spécialiste des équipements de sécurité connectés, et A. Eberle, dans le domaine de la mesure et de la régulation électriques, ont publiquement identifié le problème et engagé des démarches d'évaluation et de correction pour les équipements concernés. Leur anticipation montre que 2038 se prépare déjà.

L'enjeu est encore plus vaste pour les systèmes d'exploitation. Linux est présent dans une multitude d'équipements embarqués et constitue aussi une des grandes bases logicielles des serveurs informatiques. Le projet Debian, qui développe une distribution de Linux, a ainsi entrepris une transition importante vers une représentation du temps sur 64 bits.

Cette mobilisation est rassurante, mais elle révèle aussi la difficulté de l'opération. Sur certaines architectures 32 bits, les changements apportés aux bibliothèques peuvent rendre nécessaire la recompilation et la vérification de logiciels tiers, avec un risque d'incompatibilités, voire d'erreurs de données difficiles à détecter. Corriger les fondations ne suffit donc pas : encore faut-il adapter ce qui repose dessus, puis faire parvenir les versions corrigées jusqu'aux machines en service.

Le précédent de l'an 2000

Tout cela a un air de déjà-vu : le fameux bug de l'an 2000, ou Y2K. À l'époque, de nombreux programmes représentaient l'année avec deux chiffres. Le passage de 99 à 00 soulevait une question assez simple à comprendre et parfois très compliquée à résoudre.

Les entreprises et les administrations ont consacré des efforts considérables à rechercher, corriger et tester les systèmes concernés. Aux États-Unis, les 24 principales administrations fédérales avaient ainsi porté la conformité déclarée de leurs systèmes informatiques critiques à 99,9 % fin 1999.

Puis le 1er janvier 2000 est arrivé, sans catastrophe générale. Faut-il en conclure que l'alerte était excessive ? Ce serait oublier que les précautions prises ont précisément contribué à limiter les incidents.

Y2038 présente une parenté évidente : un défaut prévisible, connu de longue date, dont les effets peuvent être anticipés. Pourtant, il ne bénéficie pas aujourd'hui de l'attention médiatique qu'avait suscitée Y2K. Il faut rappeler que l'an 2000 possédait une force symbolique particulière dans les sociétés occidentales : changement de millénaire, fascination pour l'avenir, et même prédictions de fin du monde. Le bug informatique était venu nourrir ces inquiétudes, bien au-delà des milieux techniques.

Rien de comparable avec le 19 janvier 2038, date sans signification particulière pour le grand public. Cette différence contribue peut-être à expliquer la discrétion actuelle du sujet, sans préjuger de la gravité des problèmes qu'il pourrait provoquer.

Une machine peut survivre à son logiciel

Revenons de ces voyages temporels à l'origine du problème. Une automobile, un appareil de mesure, un contrôleur industriel ou une installation technique peuvent rester en service bien plus longtemps que le logiciel qui les anime. Ils peuvent même survivre à leur fabricant. Or un programme ne s'use pas comme un roulement : il peut fonctionner pendant des années, puis buter sur une date, un protocole devenu incompatible ou un service Internet qui n'existe plus.

Que fera-t-on alors d'un appareil matériellement sain, mais incapable de passer correctement une échéance informatique ? Le remplacera-t-on tout entier pour corriger quelques lignes de code ? Une solution pourtant simple sur le papier serait parfois coûteuse en pratique, tant financièrement qu'écologiquement.

Il serait injuste, toutefois, d'attribuer toute la responsabilité au constructeur. Un fabricant peut avoir prévu une mise à jour, sans que l'exploitant l'installe. L'utilisateur ignore parfois son importance, ou ne veut tout simplement pas en assumer le coût si le matériel fonctionne correctement ; ailleurs, la maintenance peut nécessiter un arrêt de production, de nouveaux tests ou l'intervention d'un spécialiste. Entre l'information donnée, la possibilité d'agir et la décision de le faire, les responsabilités ne se répartissent pas toujours facilement.

Se pose donc une question très concrète : que se passe-t-il lorsqu'une panne informatique potentielle coûte davantage à prévenir, pour celui qui pourrait la corriger, qu'à la laisser survenir ? Le risque, qui pourrait être jugé acceptable par un fabricant ou un exploitant, ne l'est pas nécessairement pour les utilisateurs finaux.

Des pièces détachées… pour les logiciels ?

Quand une poignée de réfrigérateur casse, on peut parfois en trouver une compatible, même si la pièce d'origine n'est plus commercialisée. Un joint peut être refabriqué à partir de ses caractéristiques. Pourquoi la logique serait-elle radicalement différente pour le logiciel embarqué ?

La prise de conscience progresse également. En France, l'indice de réparabilité, puis, plus récemment, l'indice de durabilité pour certaines catégories d'appareils, permettent au consommateur d'évaluer leur aptitude à être réparés et conservés plus longtemps.

Ces indicateurs constituent une avancée, mais restent largement centrés sur les caractéristiques matérielles des produits. Certains critères prennent déjà en compte des aspects logiciels, mais ne garantissent pas leur maintenance durable.

À quoi bon pouvoir remplacer facilement une pièce défectueuse si, quelques années plus tard, un logiciel impossible à mettre à jour condamne l'appareil entier ?

Un réparateur indépendant devrait pouvoir disposer des informations et des outils nécessaires pour diagnostiquer, corriger et installer une mise à jour. Cela suppose parfois l'accès au code source (des licences open source pourraient le faciliter), mais aussi aux spécifications du matériel et à une procédure d'installation autorisée et sûre, sans compromettre la sécurité de l'équipement.

Cela dit, les constructeurs ont des intérêts économiques légitimes, tandis que la maintenance d'un équipement industriel ou médical impose des exigences particulières de sûreté. Il ne s'agit donc pas là d'ouvrir sans précaution tous les systèmes, mais d'envisager dès leur conception les conditions d'une maintenance indépendante, lorsque le fabricant ne peut ou ne veut plus l'assurer.

La fin d'une garantie ne signifie pas la fin de la réparabilité. Pourquoi l'arrêt du support logiciel devrait-il condamner une machine encore parfaitement fonctionnelle ?

Préparer 2038, et ce qui viendra après

Le bug de 2038 sera peut-être, pour l'essentiel des équipements concernés et encore maintenus, corrigé avant son échéance. C'est évidemment ce qu'il faut espérer. Il restera toujours difficile de savoir combien de pannes auront été évitées par un travail de prévention largement invisible.

Mais 2038 ne sera pas la dernière limite découverte dans un logiciel, ni la dernière fois qu'un appareil fonctionnera plus longtemps que son environnement numérique. Le problème dépasse donc une date ou un langage de programmation.

Nous savons fabriquer des machines réparables avec des pièces compatibles. Nous savons organiser la maintenance par des tiers, parfois pendant des décennies. Ne devrions-nous pas prévoir la même continuité pour leurs logiciels ?

Au fond, le compte à rebours de 2038 pose une question toute simple : lorsqu'on achète une machine conçue pour durer, pourquoi n'achète-t-on pas aussi toutes les possibilités de la faire durer ?

Patrick Varlet

Mis en ligne le .

Sources et références

  1. nemOweb, « Chaîne du froid dans les supermarchés : quand le contrôle à distance devient perte de contrôle », 16 octobre 2026.
  2. The Open Group, spécifications POSIX, interfaces temporelles.
  3. Linux man-pages, time(2).
  4. GNU C Library, documentation.
  5. IETF, juin 2010, RFC 5905 — Network Time Protocol Version 4.
  6. Axis Communications, « AXIS OS — Year 2038 problem », documentation technique.
  7. A. Eberle, « Year 2038 Problem: Assessing Industrial Systems Early ».
  8. Debian, « Debian 13 — Notes de publication », § 2.2.6, transition vers time_t sur 64 bits.
  9. U.S. Government Accountability Office (GAO), « High-Risk Series: Key Practices to Successfully Address High-Risk Areas and Remove Them from the List », bilan rétrospectif du passage à l'an 2000 et du taux de conformité de 99,9 %.
  10. Time, 18 janvier 1999, « A Wired and Weird Millennium ».
  11. Ministère de la Transition écologique, « Prendre en compte les indices de réparabilité et de durabilité », mis à jour le 8 janvier 2026.

Lectures complémentaires