Il suffit de creuser un peu pour s'apercevoir que ce “bug 2038” est connu depuis plus de vingt ans dans le monde des codeurs. Son origine est simple : un grand nombre de nos systèmes informatiques fonctionnent avec une date paramétrée qui permet de repérer des actions dans le temps (prêt bancaire, maintenance…). Et pour que tout soit harmonisé, une norme dite “heure Unix” ou “heure Posix” impose que cette date soit calculée en égrenant les secondes à partir du 1er janvier 1970 (juste après l'invention du système d'exploitation Unix, en 1969). Par exemple, le 25 février 2026, date de sortie de ce numéro d'Epsiloon, il se sera écoulé 1 772 020 678 secondes. Sauf que cette date, exprimée en bits (0 ou 1), est souvent codée sur un nombre de bits limité, en l'occurrence 32 : 31 pour égrener les secondes qui s'écoulent et le 32e pour préciser si on est avant ou après 1970. Le problème, avec ce système, c'est que le nombre le plus élevé s'écrit 01111111 11111111 11111111 11111111. Ce qui correspond au 19 janvier 2038, 3 h 14 min et 7 s donc. Et que la seconde suivante, le codage va afficher 10000000 00000000 00000000 00000000 : le 13 décembre 1901, la date la plus reculée possible dans le passé… “Nos systèmes informatiques comparent les chiffre, et une date future qui se retrouve d'un seul coup plus ancienne que la précédente induit des erreurs”, conclut Thierry Roger, directeur de recherche chez Alten, à Rennes.