Bug de l’an 2038 : comment protéger vos équipements industriels avant l’échéance ?
Le bug de l’an 2038 est souvent comparé au bug de l’an 2000, parfois à tort. Si ce dernier avait déclenché une mobilisation mondiale, le problème de 2038 reste encore largement sous le radar des équipes terrain. Pourtant, il touche directement les systèmes industriels, les automates programmables industriels, les équipements embarqués et les infrastructures SCADA, dont beaucoup ont été déployés dans les années 2000 et fonctionnent toujours sans mise à jour majeure.
La date critique : le 19 janvier 2038 à 03:14:07 UTC. Ce jour-là, un compteur présent dans des millions de systèmes informatiques atteindra sa valeur maximale. La seconde suivante, il basculera dans une valeur négative ou reviendra à zéro, selon l’implémentation. Pour les systèmes concernés, la date sera subitement interprétée comme le 13 décembre 1901.
La racine technique du problème
Tout repose sur le timestamp Unix, une convention qui mesure le temps écoulé depuis le 1er janvier 1970 en secondes. Sur les systèmes utilisant un entier signé 32 bits pour stocker cette valeur, le maximum atteignable est 2 147 483 647. Ce plafond correspond précisément au 19 janvier 2038.
| Unix Epoch | Date et heure (GMT) |
|---|---|
| 123 456 789 | Jeu. 29 nov. 1973 21:33:09 +0000 |
| 500 000 000 | Lun. 05 nov. 1985 00:53:20 +0000 |
| 946 684 800 | Sam. 01 jan. 2000 00:00:00 +0000 |
| 1 000 000 000 | Dim. 09 sep. 2001 01:46:40 +0000 |
| 1 234 567 890 | Ven. 13 fév. 2009 23:31:30 +0000 |
| 1 555 555 555 | Jeu. 18 avr. 2019 02:45:55 +0000 |
| 1 666 666 666 | Mar. 25 oct. 2022 02:57:46 +0000 |
| 1 700 000 000 | Mer. 15 nov. 2023 06:13:20 +0000 |
| 1 777 777 777 | Dim. 03 mai 2026 03:09:37 +0000 |
| 1 888 888 888 | Ven. 09 nov. 2029 03:21:28 +0000 |
| 2 000 000 000 | Mer. 18 mai 2033 03:33:20 +0000 |
| 2 111 111 111 | Lun. 24 nov. 2036 03:45:11 +0000 |
| 2 147 483 647 | La Fin — Mar. 19 jan. 2038 03:14:07 +0000 |
| -2 147 483 648 | Ven. 13 déc. 1901 20:45:52 +0000 |
Les systèmes 64 bits n’ont pas ce problème : leur compteur peut gérer des dates jusqu’en l’an 292 milliards environ. Le problème concerne exclusivement les architectures 32 bits ou les applications développées en C/C++ sans adaptation, qui encodent encore le temps sur 32 bits même sur des matériels plus récents.
Dans l’industrie, ce cas est fréquent. Des systèmes embarqués conçus dans les années 1990 ou 2000, des IHM (interfaces homme-machine) sous systèmes d’exploitation vieillissants, ou des bibliothèques de gestion du temps non mises à jour sont autant de points de vulnérabilité potentiels.
Quels équipements industriels sont exposés ?
- Automates programmables industriels (API) : certains modèles anciens de Siemens, Allen-Bradley, Schneider Electric ou Mitsubishi embarquent des horloges temps réel avec des registres 32 bits non migrés
- Systèmes SCADA et DCS : les logiciels de supervision comme les versions anciennes de WinCC, InTouch ou iFIX peuvent inclure des modules de gestion du temps hérités
- Routeurs industriels : équipements réseau déployés en usine depuis les années 2000, rarement mis à jour
- Systèmes de traçabilité et horodatage : dans les lignes de production soumises à des exigences réglementaires (agroalimentaire, pharmacie), un mauvais horodatage peut invalider des lots entiers
- Systèmes de maintenance prédictive : les outils s’appuyant sur des séries temporelles peuvent générer des erreurs de calcul ou des fausses alertes si l’horloge système déraille
Il faut aussi considérer les équipements avec une longue durée de vie. Un automate installé aujourd’hui peut encore être en service en 2038. La question de la compatibilité doit donc se poser dès la phase de spécification.
Les conséquences en production
Un débordement du compteur 32 bits ne produit pas nécessairement un arrêt immédiat. Les effets peuvent être plus sournois :
- Des erreurs d’horodatage dans les journaux de bord et les archives de production
- Des défaillances dans les systèmes de planification et d’ordonnancement (MES, ERP connectés) qui calculent des délais ou des durées
- Des dysfonctionnements dans les algorithmes de contrôle qui utilisent le temps comme variable (recettes, cycles temporisés)
- Des problèmes de certificats numériques dans les communications sécurisées entre équipements (OPC-UA, MQTT), dont la validité est liée à des dates système
- Des vulnérabilités exploitables : des chercheurs en sécurité ont confirmé que le déclenchement du bug peut être utilisé pour contourner des mécanismes de sécurité, provoquer des crashs ou couvrir des intrusions
Contactez nos experts pour planifier le rétrofit de vos équipements exposés.
Dans les secteurs à forte contrainte réglementaire (traitement des eaux, énergie, pharmacie), un horodatage incorrect peut déclencher des non-conformités et des arrêts de ligne.
Comment anticiper et se préparer
La bonne nouvelle : douze ans, c’est suffisant pour agir, à condition de commencer l’inventaire maintenant.
Cartographier les équipements exposés est la première étape. Il s’agit de recenser tous les systèmes embarquant un timestamp Unix 32 bits : automates, IHM, passerelles, serveurs SCADA, équipements réseau. Les fournisseurs majeurs publient des bulletins de compatibilité à ce sujet.
Vérifier les systèmes d’exploitation : Linux Kernel 5.6 (sorti en 2020) intègre la correction pour les systèmes 32 bits. Les OS industriels basés sur des versions antérieures de Linux ou sur des noyaux temps réel propriétaires doivent être évalués individuellement.
Anticiper lors des renouvellements : tout projet de migration ou de remplacement d’équipement doit intégrer une clause de conformité post-2038 dans les cahiers des charges. Les constructeurs doivent être en mesure de fournir une garantie explicite sur la gestion du timestamp.
Tester en environnement de simulation : il est possible de décaler artificiellement l’horloge d’un banc de test pour observer le comportement des équipements au-delà du 19 janvier 2038. Cette démarche s’inscrit naturellement dans une politique de gestion des risques industriels.
Conclusion
Le bug de 2038 n’est pas une apocalypse annoncée, mais un risque technique réel et planifiable. Contrairement au bug de l’an 2000, la fenêtre de préparation est large et le diagnostic technique est bien compris. Pour les équipes d’automatisme, l’enjeu est de traiter ce sujet avec la même rigueur qu’une mise à jour de firmware ou qu’un plan de maintenance préventive : avec méthode, sans urgence excessive, mais sans attendre non plus.
Les systèmes industriels ont la particularité d’avoir de longues durées de vie. Ce qui est installé aujourd’hui sera peut-être encore en service en 2038. Intégrer la compatibilité temporelle dans vos critères de choix dès maintenant, c’est éviter une contrainte coûteuse dans douze ans.
