Les plus jeunes qui lisent ces lignes n’auront peut-être pas connu le bug de l’an 2000. Et même si vous l’avez connu, vous l’avez sans doute entièrement oublié, et pour cause : l’apocalypse informatique annoncée n’a pas eu lieu. C’était une peur importante tout au long des années 1990, on imaginait alors que tous les ordinateurs allaient planter le 1er janvier 2000 à minuit. L’année 1999 s’est finalement terminée sans incident majeur1.
Ce devrait être en gros ce qui se passera aussi en 2038. Car oui, c’est le 19 janvier 2038 à trois heures, quatorze minutes et sept secondes UTC, soit 5h14 du matin en France, que le prochain bug du même genre pourrait avoir lieu. À cette date précise, les ordinateurs, qui mesurent le temps en nombre de secondes qui se sont écoulées depuis 1970 par convention, auront atteint la limite de ce qu’un nombre encodé sur 32 bits peut stocker.
Pour résumer la situation rapidement, les dates sont enregistrées en informatique avec un « timestamp » (horodatage en français), une série de chiffres qui représentent le temps. Le plus commun est le timestamp UNIX qui est constitué du nombre de secondes qui se sont écoulées depuis le premier janvier 1970 à minuit. Par exemple, le timestamp UNIX correspondant à la publication de cet article est 1603271700, soit environ 1,6 milliards de secondes après cette date choisie, ce qui correspond au 21 octobre 2020 à 09h15 en France.
Ce choix est pratique : en utilisant une valeur unique, tous les ordinateurs peuvent échanger entre eux, quel que soit leur fuseau horaire et surtout quelle que soit la manière d’encoder la date. Vous savez peut-être que les Américains commencent par le mois, si bien que la date du jour est 10/21/2020 aux États-Unis, alors que nous commençons par le jour, 21/10/2020. Mais dans les deux cas, le timestamp UNIX est identique, ce qui est indispensable notamment pour communiquer via internet.
Cette technique est née dans les années 1970 en même temps que les systèmes UNIX et c’est pourquoi cette date symbolique a été choisie. Cette méthode de notation n’a aucune limite en soi, mais il y en a une qui surviendra en 2038 : si le timestamp est encodé en 32 bits, alors on aura atteint le nombre maximal de chiffres qui peut être exprimé. Quand le timestamp atteindra 2147483647, il ne pourra plus être incrémenté. À partir de là, soit la date du système reviendra à 0, soit le système plantera et on obtient le bug de 2038.
C’est inquiétant, mais le bug de l’an 2000 a servi de leçon et on est prêt à gérer ce cas de figure. Pour commencer, tous les systèmes d’exploitations 64 bits utilisent un timestamp UNIX encodé lui aussi sur 64 bits. On estime que le nombre de secondes qu’il peut contenir est environ vingt fois plus important que la durée de l’univers, autant dire qu’on sera tranquille pour un moment. Apple utilise cet encodage depuis Snow Leopard (macOS 10.6), même si c’est El Capitan qui corrige entièrement le problème.
Les bugs pourraient persister pour les anciens systèmes restés en 32 bits, comme les anciens Mac bloqués à une version antérieure du système. On peut déjà savoir ce qui va se passer : sur un Mac équipé de Tiger (10.4), le système ne peut pas dépasser le 31 décembre 2037 par sécurité, il revient à cette date si on essaie de le configurer au-delà. Sur d’autres modèles, on sait que le bug se manifestera par un retour à une date antérieure2.
Pour les ordinateurs 32 bits sous Linux, les créateurs du noyau ont prévu un correctif qui permettra de gérer les dates jusqu’en 2486. Le plus gros problème potentiel devrait toutefois venir des multiples ordinateurs embarqués, par exemple dans les voitures, qui pourraient encore fonctionner. On ne parle pas des ordinateurs de bord, mais bien des systèmes informatiques qui gèrent des fonctions essentielles comme l’ABS, l’ESP et autre.
Ces ordinateurs sont en général limités par des processeurs 32 bits, mais leur utilisation de la date est restreinte. Il s’agit souvent de déterminer des durées, ce qui veut dire qu’ils devraient pouvoir passer de 2038 à une date antérieure sans créer de problèmes majeurs. Dans quelques cas précis, il faudra peut-être mettre à jour des composants anciens de machines ou véhicules avant l’année 2038.
Quoi qu’il en soit, vous pourrez vous endormir tranquilles ce soir, ce nouveau bug devrait bien être aussi mineur que le précédent…
-
Ce qui ne veut pas dire qu’il n’a pas fallu travailler en amont. Comme vous le rappelez fort justement dans les commentaires, de nombreux programmes ont été mis à jour pour éviter les bugs qui auraient eu lieu avec le passage à l’an 2000. ↩︎
-
Un nombre encodé en 32 bits peut évoluer entre 2147483647 et -2147483647. Si l’ordinateur atteint la valeur supérieure, il ne revient pas à 0, mais à la valeur minimale, soit -2147483647. Et comme le timestamp UNIX fixe le 0 au premier janvier 1970, cet horodatage correspond au 13 décembre 1901 à 20h45 et 52 secondes. ↩︎
-
Pour optimiser le stockage, denrée extrêmement rare et précieuse les premières années de l’informatique, on encodait parfois les dates sur deux caractères : « 75 » pour 1975, « 91 » pour 1991, etc. Une bonne idée sur le papier, mais les développeurs n’avaient pas anticipé qu’à partir de 2000, le programme considérerait qu’on était revenu en 1900 plutôt qu’en approche du XXIe siècle. C’est très certainement ce qui s’est passé pour ce tableau d’affichage. ↩︎
