Passer au contenu

Le bug de l’an 2000 fait son come-back, 20 ans plus tard

Une solution bancale pour éviter les bugs liés au passage à l’an 2000 cause du tort en 2020. À New York, les parcmètres ont cessé de fonctionner, tout comme de nombreuses caisses enregistreuses chez des commerçants et même le jeu de catch WWE 2K20.

Rappelez-vous, en 1999, lorsque le bug de l’an 2000 menaçait de faire s’effondrer le réseau informatique mondial. 20 ans plus tard, il semblerait que la menace soit définitivement écartée. Pourtant, un peu comme dans le dernier Star Wars, la terrible menace de la fin des années 1990 fait un come-back inattendu en 2020. Comme le note New Scientist, il faut s’attendre à une série de bugs cette année, comme ceux ayant déjà affecté les parcmètres new-yorkais et le jeu vidéo WWE 2K20. Dans ces deux cas de figure, le passage à l’an 2020 a créé un certain nombre de problèmes, empêchant les New-yorkais de payer avec leurs cartes bancaires sur les parcmètres, quand WWE 2K20 s’est bloqué passé minuit lorsque les premiers États américains sont passés dans la nouvelle année.

https://twitter.com/scully1888/status/1212400419038810113

Y a-t-il un bug de l’an 2020 ? En réalité, le problème serait directement lié au bug de l’an 2000. Craignant de voir leurs infrastructures s’effondrer au passage du nouveau millénaire, de nombreuses entreprises avaient tenté de minimiser les problèmes à venir en réécrivant partiellement la façon dans les ordinateurs stockent les dates, évitant ainsi que le passage à l’an 2000 ne les ramène en 1900. Pour éviter le bug de l’an 2000, une solution efficace et rapide à mettre en place avait été trouvée, et baptisé le « windowing », ou fenêtrage. Cette solution consistait alors à traiter les dates de 00 à 20, et cela à partir de l’an 2000, afin d’éviter de voir les systèmes retourner en 1900. Comme l’indique New Scientist, 80% des ordinateurs avaient été modifiés afin de procéder de la sorte en 1999 pour contourner le bug de l’an 2000. Le problème, c’est que cette solution ne corrige pas le bug, mais le décale simplement à plus tard, et notamment en l’an 2020, puisque les codeurs auraient choisi 1920-2020 comme fenêtre standard, afin d’inclure le point médian de l’heure Unix, qui démarre le 01/01/1970.

« La correction des bugs dans les anciens systèmes est un cauchemar : cela ressemble à des spaghettis et les personnes qui l’ont écrit ne sont plus là », explique à New Scientist Paul Lomax, qui a géré le bug de l’an 2000 pour l’opérateur américain Vodafone, tout en précisant « ils ont supposé que leurs systèmes seraient depuis longtemps hors d’usage d’ici 2020. Tout comme ceux des années 1960 ne pensaient pas que leur code serait encore là en l’an 2000. » Concrètement, si le passage à l’an 2020 a causé des problèmes informatiques, c’est notamment car les systèmes qui avaient utilisé ce « pansement » se sont subitement retrouvés… en 1920. Ce problème de date expliquerait pourquoi les payements ont été refusés, aussi bien sur les parcmètres new-yorkais que sur des caisses enregistreuses de nombreux commerçants.

Le prochain bug est prévu pour le 19 janvier 2038 à 3 heures 14 minutes et 7 secondes. C’est en effet à cette date que les ordinateurs 32 bits arriveront à court de capacité de stockage de date, et qu’ils risquent de se retrouver en… 1901. L’avantage, c’est que, grâce à l’informatique, pas besoin de machine à voyager dans le temps pour se retrouver au siècle dernier.

🟣 Pour ne manquer aucune news sur le Journal du Geek, abonnez-vous sur Google Actualités. Et si vous nous adorez, on a une newsletter tous les matins.

8 commentaires
  1. Nawak total les chiffres sur les évolution disant que 80% des ordis avaient étés corrigé de la sorte. Y’a que les neuneux qui avaient déjà un système de ***** et qui ont corrigé avec une verrue toute autant dégueu.

    Le bug de l’an 2000 c’est pour tout ceux qui utilisait des formats de dates tout pourris pour stocker en format numérique et faire des opérations plus simples. Les les formats habituels genre date time, timestamp qu’utilisent la plupart des devs ne souffre pas de ce problème. Dans la plupart des boites les devs rigolaient complètement à l’idée du passage à l’an 2000. Y’avait juste un effet de panique créé par la presse etc.

    le seul point réaliste c’est effectivement le bug de 2038 qui vas bien gêner toutes les archis 32 bits

    1. C’est bien beau de critiquer mais les langages de programmation et compilateur évolue énormément chaque années.

      Exemple con, le PHP d’aujourd’hui n’est plus le PHP d’il y a 20 ans. Si tu regardes une page web de l’an 2000 avec plein de balise div, c’est choquant pour un programmeur aujourd’hui.

      Perso je n’ai pas connu la syntaxe timestamp en C/C++ il y a 20 ans mais d’autres syntaxes pour gérer le temps. Ça existait peu t’être à cette époque en rajoutant une librairie spécifique.

  2. Avec certains vieux langages comme le COBOL ou le PL1 il n’y a pas de format date. Et à une époque un octet coûtait cher, alors on a effectivement stocké des dates sur 6. Le bug était réel, pas juste un effet de presse. Après sa portée restera indéterminée puisque le chaos n’a pas eu lieu. En tout cas, l’appli sur laquelle j’ai travaillé en 1999 aurait planté déconné si rien n’avait été fait, mais personne n’en aurait parlé car le “grand public” n’aurait pas été concerné.
    N’enpêche que nous on utilisait 1950 comme date pivot, ça laisse plus de marge que 1920….

  3. il y aura aussi le bug de l’an 2027/28, pour les programmes avec une année codé sur un “short int” et où le bug de l’an 2000 a juste consisté a faire +1900 a l’affichage

Les commentaires sont fermés.

Mode