Connaissez-vous le bug de l'an 2038 ? Il n'est pas (encore) aussi médiatisé que celui de l'an 2000, mais il risque de poser quelques problèmes. Pour faire simple, dans la majorité des logiciels, le temps démarre le 1er janvier 1970, une convention issue d'UNIX. Dans beaucoup de cas, le nombre de secondes depuis cette date est stocké dans une valeur signée sur 32 bits (soit 231 valeurs possibles), ce qui implique que la date limite enregistrable est le 19 janvier 2038 vers 03:14:07. C'est un problème connu, qui devrait normalement être corrigé d'ici là d'une façon ou d'une autre. Mais à la RATP (la régie des transports parisiens), il a fallu aller au tribunal.
La RATP, qui achète ses rames à Alstom, a découvert le bug dès 2017. Ils se sont rendu compte que choisir une date au-delà de la limite empêchait les appareils de fonctionner. La RATP a donc demandé à Alstom de corriger le problème1, qui a refusé, en arguant ne pas être capable de régler le souci. Une analyse a ensuite permis de révéler que tous les appareils vendus par Alstom entre 1989 et 2014 étaient touchés, et que le problème allait affecter environ un tiers du réseau, selon L'informé. Devant les refus d'Alstom, la RATP a donc dû passer par la case du tribunal.
Le tribunal administratif a pris le parti de la RATP et ordonne donc à Alstom de trouver une solution rapidement (un an), avec des astreintes élevées au-delà (100 000 € par mois de retard). Elle devra ensuite être mise en place avant 2030 dans les véhicules (avec des astreintes de 1 million d'euros par mois au-delà)
Si les rames de la RATP devaient donc rouler correctement dans la nuit du 19 janvier 2038, nous pouvons prendre les paris sur un point : ce n'est probablement pas la dernière fois que vous entendrez parler du bug de l'an 2038.
-
Les deux solutions sont de passer sur une valeur 64 bits ou sur une valeur 32 bits non signées (soit 2^32 valeurs). Dans les deux cas, le problème est reporté assez loin (2106 dans le cas du 32 bits, dans 292 millions d'années en 64 bits). ↩︎
