C’est à la suite d’un échange sur Messenger avec Fred Gagné, de l’émission Midi Pile à KYK, que je me suis replongé dans le bogue de 2038. On discutait d’un texte d’Alain McKenna dans La Presse, qui explique bien le phénomène, notamment le moment où certains systèmes pourraient passer de 2038 à 1901 . L’explication est bonne, mais elle simplifie une réalité qui, sur le terrain, est beaucoup plus nuancée.
Une limite mathématique, pas un bogue classique
Un entier 32 bits signé peut stocker au maximum 2 147 483 647. C’est le nombre de secondes qu’un système peut compter depuis le 1er janvier 1970. Rendu là, on arrive exactement au 19 janvier 2038 à 3 h 14 min 07 s UTC. Une seconde plus tard, ça déborde. La valeur passe à -2 147 483 648. Le système ne plante pas, il ne signale rien, il continue avec une valeur valide, mais interprétée comme une date en 1901. Et c’est là le vrai problème. Pour un développeur, la dernière seconde valide et la première seconde brisée se ressemblent. Même type, même variable, la seule différence, c’est le signe. Aujourd’hui, on est déjà à plus de 1,7 milliard de secondes depuis 1970, le compteur avance en continu et il ne s’arrêtera pas.
Le problème est dans le code, pas dans la machine
Une des idées les plus répandues, c’est que les vieux systèmes 32 bits sont vulnérables. C’est faux. Un système est à risque seulement s’il utilise une représentation du temps sur 32 bits. Les environnements modernes en 64 bits, notamment sous Linux, sont déjà à l’abri. Windows utilise aussi une autre représentation du temps sur 64 bits. Par contre, une application compilée avec des outils plus anciens peut encore embarquer un time_t 32 bits. Donc le bogue peut exister sur une machine récente. Ce n’est pas une question d’âge, c’est une question de choix technique.
MySQL et les problèmes déjà visibles
Le cas des bases de données est parlant. Dans MySQL, le type TIMESTAMP est limité à 2038, alors que le type DATETIME permet d’aller beaucoup plus loin. MySQL n’est donc pas le problème. Le problème, c’est d’avoir choisi TIMESTAMP pour stocker une date qui dépasse cette limite. Ce genre de décision existe déjà dans des systèmes en production, ce qui signifie que certaines applications ont aujourd’hui des contraintes invisibles, sans que personne ne s’en rende compte.
Les systèmes qu’on ne regarde plus
Le vrai angle mort, ce sont les systèmes qu’on ne touche plus. Applications internes, logiciels développés il y a 15 ou 20 ans, outils compilés avec des bibliothèques anciennes, ces systèmes continuent de fonctionner sans être réévalués. Et c’est souvent là que le bogue se cache. Même sur une infrastructure moderne, un vieux binaire reste vulnérable.
Les systèmes invisibles, mais critiques
Il y a aussi toute une catégorie de systèmes qu’on oublie complètement, les systèmes embarqués. Automates industriels, systèmes SCADA, équipements médicaux, contrôles d’accès, ces systèmes n’ont souvent ni écran, ni interface visible. Ils fonctionnent avec des contrôleurs intégrés et du micrologiciel. Dans plusieurs cas, ils sont en place depuis des décennies. Le fabricant n’existe plus, le logiciel ne peut pas être mis à jour, et personne ne sait exactement comment le temps est géré à l’intérieur. Lors d’une panne électrique, certains de ces systèmes perdent leur notion du temps et redémarrent avec une date par défaut, parfois proche de 1970. D’autres conservent l’heure avec une batterie ou se resynchronisent automatiquement. Mais dans tous les cas, le bogue de 2038 ne dépend pas d’un redémarrage. Un système peut fonctionner pendant des années, puis commencer à produire des résultats incohérents simplement parce que la date dépasse une limite interne, ce qui est beaucoup plus difficile à diagnostiquer qu’un plantage.
Les systèmes publics et la complexité accumulée
Comme le souligne La Presse, plusieurs systèmes publics reposent encore sur des technologies anciennes . On parle souvent de COBOL, mais le problème est plus large. Ce sont des systèmes qui ont évolué par couches, avec des intégrations, des correctifs et des ajouts faits au fil du temps, parfois sans vision globale. Avec les années, la compréhension diminue. Et quand personne ne sait exactement comment le temps est géré, le risque augmente.
2038, ce n’est pas une date
Le bogue de 2038 ne va pas provoquer une panne globale. Il va surtout exposer les systèmes qu’on n’a jamais revus, ceux où le temps est encore géré comme il l’était il y a 20 ou 30 ans, sans validation depuis.
Sur papier, 2038 est encore loin. Mais en pratique, si on ne sait pas déjà comment nos systèmes gèrent le temps, le problème est déjà là. Parce que ce n’est pas un bogue qui va apparaître, c’est un bogue qui attend.
