Quand le bug de l'an 2000 faisait trembler le monde entier

Pannes d’électricité à grande échelle, avions cloués au sol, hôpitaux paralysés, téléphones momentanément inutilisables… Non, ce n’est pas le décor d’un nouveau film post-apocalyptique mais bien quelques-uns des scénarios catastrophes évoqués à l’époque du passage à l’an 2000. Le responsable de tous ces maux? Vous vous en rappelez sûrement... Le fameux “bug de l’an 2000” !

Certains n’y ont vu qu’un pétard mouillé, d’autres une vraie apocalypse. Dans le doute, le Royaume-Uni s’est même préparé à envoyer des militaires dans les rues pour “empêcher les pillages et les vols” qui auraient pu avoir lieu à la suite des dysfonctionnements informatiques.

Entre fantasmes et réalité, retour sur l’un des événements les plus célèbres de l’histoire de l’informatique.

L'origine d'un bug qui n'en est pas un

L'Apple II (1977), l'un des premiers ordinateurs personnels fabriqué à grande échelle.

L'Apple II (1977), l'un des premiers ordinateurs personnels fabriqué à grande échelle.

Le Cobol était le langage de programmation le plus utilisé dans les années 60-80.

Le Cobol était le langage de programmation le plus utilisé dans les années 60-80.

C’est au milieu des années 90 qu’une poignée d’informaticiens tirent pour la première fois la sonnette d’alarme. Selon eux, de nombreux systèmes informatiques à travers le monde subiront de graves perturbations lors du passage à l’an 2000. La cause? Le fameux "bug de l’an 2000" (aussi appelé Y2K en anglais), dont l’origine remonte au temps où les premiers ordinateurs personnels ont été conçus. Revenons quelques années en arrière.

Dans les années 70 et jusqu’au début des années 80, la mémoire des machines était microscopique. Elle ne se comptait pas encore en gigas mais en… kilo-octets. Stocker des données était très coûteux. Par conséquent, toutes les astuces permettant de gagner de la place étaient bonnes à prendre. L’une d’entre elles consistait à encoder la date sur 2 chiffres au lieu de 4. 1975 est donc devenu 75, et 1989, 89. Un choix a priori anodin qui allait pourtant causer quelques soucis au moment du passage à l’an 2000. Lorsque les chiffres de la décennie passeraient de “99” à “00”, l’ordinateur serait tout bonnement incapable de comprendre qu’il était en 2000. Au lieu de ça, il se penserait tout naturellement revenu en 1900. Et on ne peut pas lui en vouloir: il ne pouvait pas deviner ce qu’on ne lui avait jamais dit. Les occasions de le mettre au courant n’avaient pourtant pas manqué... Encoder la date sur 2 chiffres n’était d’ailleurs plus vraiment nécessaire puisqu'au fil du temps la taille des mémoires avait fini par augmenter. Malheureusement, en codage comme dans tout, les (mauvaises) habitudes sont tenaces. 

À l’époque, les informaticiens pensaient que d’ici le 21e siècle, leurs réalisations n’existeraient plus. Ils pensaient que leurs programmes ne seraient utilisés que quelques années. Mais ils ont duré bien plus longtemps que ça”, souligne Axel Legay, professeur de cybersécurité à l’UCLouvain. Pour la simple et bonne raison que “dans les entreprises, on ne change pas comme ça un programme qui marche. Ça coûte de l’argent, ça demande d’arrêter le système... Si elles n’y sont pas obligées, elles ne voient pas de raisons de le faire.” 

Ce "bug", ou plutôt ce problème de conception informatique, est donc celui de la négligence et du manque d’anticipation. “C’est le bug de la bêtise”, renchérit Axel Legay.

Des conséquences redoutées

Concrètement, quel était le problème qu’un ordinateur se pense en 1900 et pas en 2000? Recevoir un e-mail de “bonne année” erronément daté du 1er janvier 1900 n’était pas dramatique. Mais de nombreux logiciels, principalement de gestion et de planification, ont besoin de dates précises pour fonctionner correctement. Elles sont nécessaires pour effectuer des calculs entre deux dates, lancer des procédures automatiques qui ont lieu un certain jour de la semaine ou encore connaître la durée de vie de fichiers.

Jean-François Colonna, chercheur à l’école polytechnique (France), détaillait à l’époque quelques problèmes possibles. “Une sauvegarde datant du 1er janvier 2000 pourra être considérée comme antérieure à celle du 31 décembre 1999 (00 < 99) et sera donc détruite. Une facture émise en 1999 et toujours impayée en 2000 échappera au système de relance automatique.

En résumé, le traitement de résultats erronés pouvait perturber voire carrément faire planter les ordinateurs centraux des entreprises ainsi que les microprocesseurs présents dans de plus en plus d'appareils (instruments médicaux, robots). Avec des conséquences potentiellement désastreuses pour certains secteurs comme l'électricité, les banques, les aéroports ou les hôpitaux. 

Mais à ce moment-là, toutes les entreprises ne comprennent pas tout de suite les risques qu’elles courent. L’enjeu est donc de les informer au mieux.

Mieux vaut prévenir que guérir

Dès 1995, Peter de Jaeger, un ingénieur canadien, décide de quitter son poste chez IBM pour fonder son propre centre d’informations dédié au “bug de l’an 2000”. Il est l’un des premiers à développer un site internet (year2000.com), en anglais, documentant de façon précise le problème. 

Durant des années, il ne cesse de marteler qu’il est essentiel d’agir avant pour éviter les ennuis après.

Si les Etats-Unis prennent rapidement la balle au bond, l’Europe, elle, traîne les pieds. “On a été plus lent à réagir car, en plus du bug de l’an 2000, l’informatique de gestion devait faire face à un autre problème : le passage à l’euro. Les entreprises avaient très peur de devoir payer deux fois. Elles ont donc reporté la mise en place de solutions pendant longtemps.” Or, faire une mise à jour ou installer un nouveau programme ne se fait pas en un claquement de doigts. “Il faut le faire sur chaque poste de travail, ce qui impacte forcément le fonctionnement de l'entreprise”, explique Axel Legay. 

Quelques mois avant la date fatidique, le retentissement est tellement énorme que les entreprises ne peuvent plus ignorer ce problème plus longtemps. D'autant plus qu'elles sont également menacées par... leurs assureurs qui refusent de les couvrir pour certains incidents en lien avec le bug de l'an 2000. S'ils acceptent d'intervenir dans quelques rares cas, c'est à la condition expresse que les firmes fournissent la preuve qu'elles n'ont pas pris le problème à la légère. Elles finissent donc toutes par agir, parfois à contrecœur.  

Le jour J

Dans la nuit du 31 décembre au 1er janvier, de nombreuses sociétés à travers le monde sont sur le qui-vive. Pour éviter tout désagrément, certaines d’entre elles demandent même à leurs informaticiens de se tenir prêts à intervenir en cas de panne. 

En Belgique, les grandes entreprises ne se font toutefois pas trop de mouron. Grâce à leurs multiples audits et leur "plan an 2000", elles sont prêtes à affronter le bug. La Sabena, Electrabel (Engie) et Belgacom (Proximus) se veulent donc très rassurantes. Souvent interrogée au sujet des potentielles coupures d'électricité, Electrabel n'a jamais cessé de confirmer que tout irait bien. Belgacom, de son côté, craignait davantage la surcharge de ses réseaux à cause de l’afflux de bons vœux envoyés par SMS que le bug lui-même. Seule la SNCB a choisi d’agir par excès de précaution en arrêtant tous ses trains entre 22h et 6h du matin.

Et finalement que s’est-il passé dans le monde après le passage à l'an 2000? Rien… Ou plus exactement quelques problèmes sans conséquence qui n’ont duré qu’une poignée d’heures. 

Comme il fallait s’y attendre, le soulagement a donc rapidement fait place aux critiques...

Le bug de l'an 2000, une belle arnaque?

Entre ceux qui ont raillé les sommes investies par les entreprises pour réparer un “bug inexistant” et ceux qui s’en sont pris aux médias et experts qui ont “dramatisé” le bug, il y en avait pour tous les goûts. 20 ans plus tard, que penser de tout cela? 

Un coût mais surtout un vide juridique qui pose question

Gartner Group, une entreprise américaine de conseils dans le domaine technique, a estimé que ce “bug” avait coûté entre 300 et 600 milliards de dollars à l'échelle mondiale. “Ils ont calculé qu’il a fallu modifier 300 à 600 milliards de lignes de code. En estimant chaque ligne à un dollar, ils sont arrivés à cette somme. Mais, en pratique, quand on corrige un bug, on copie-colle des lignes de code à plusieurs endroits. Cette estimation a donc été surévaluée, même si tout cela a évidemment coûté très cher”, poursuit Axel Legay. 

Est-ce que, comme le dénonçaient les Guignols de l’info dans la vidéo ci-dessus, certaines sociétés informatiques ont profité de la panique d’entreprises qui venaient juste de s’informatiser pour se faire de l’argent facile? Il serait naïf de penser le contraire… Mais, à l'époque, le débat n’a pas vraiment tourné autour de cette question-là. "Personne n'a intenté de procès aux entreprises informatiques pour avoir facturé trop cher leur intervention", souligne Axel Legay. “A l’époque, les discussions ont plutôt porté sur la responsabilité juridique des éditeurs de logiciels. Imaginons qu’une entreprise achète un logiciel où la date est codée sur 2 chiffres à cause d'une économie de mémoire qui n’avait plus lieu d’être. Quelques années plus tard, elle est forcée de le changer à cause d’une erreur de conception qui ne dépend pas d’elle. Qui doit payer? Combien de temps un éditeur de logiciels est-il responsable du contenu qu’il fournit? Ces questions étaient posées pour la première fois. Et il a fallu y répondre”, se souvient le professeur. 

Une dramatisation bénéfique

Après coup, beaucoup se sont demandé si on en n'avait pas fait des tonnes en exagérant les conséquences de ce bug. Alors fallait-il vraiment le réparer ou l'a-t-on trop dramatisé? “Cela a tellement été pris à temps qu’il est impossible de dire ce qui aurait pu se passer si on ne l'avait pas fait. Mais je pense qu'il aurait pu y avoir des problèmes. D'une certaine façon, on a eu raison de dramatiser ce bug. Il était temps de prendre conscience de certaines choses.” En plus du vide juridique sur la responsabilité des éditeurs évoqué ci-dessus, le professeur se souvient qu’avant le bug il y avait “une absence de politique de mises à jour”. “Même si les entreprises freineront toujours des quatre fers pour mettre à jour leurs logiciels, c’était la première fois que l’on expliquait vraiment l’importance de le faire.

Peter Praet, ancien directeur de la Banque nationale de Belgique, va même plus loin. Il estimait en 2002 dans nos colonnes que sans ce “bug”, les conséquences financières de l’attentat du 11 septembre auraient pu être beaucoup plus graves. Selon lui, les mesures prises à la veille du passage à l’an 2000 ont permis “d’améliorer l’efficacité et la sécurité des systèmes”. “Tout le management des banques et des télécoms avait comme priorité le problème de sécurité. Il était prêt à réagir à des situations graves.” Il faut dire qu’au-delà du bug de l’an 2000, c’était aussi l’époque où Internet était en plein boom et où l’on commençait à se rendre compte que les attaques pouvaient venir de l’extérieur.  

Faut-il craindre d'autres "bugs" du même genre à l'avenir?

Étant donné que le temps est par nature indéfini mais que les variables utilisées pour le stocker ont un espace limité, une flopée d’autres bugs sont à prévoir. Le plus récent remonte d’ailleurs au 6 avril dernier, date à laquelle certains GPS risquaient de tomber en panne. 

Pour fonctionner, un système GPS a besoin d’être synchronisé avec les horloges des satellites”, rappelle Alain Buys, chef de travaux au département informatique de l’UMons. “Au moment où les premiers GPS ont été créés, les concepteurs ont alloué un espace précis à la variable stockant le temps. Mais cette variable avait une durée de vie de 20 ans.” Après avoir été réinitialisée une première fois, elle a atteint sa limite une deuxième fois. “Le risque était que le GPS n’indique plus l’heure prévue d’arrivée étant donné qu’il ne connaissait pas l’heure de départ ou, plus embêtant, qu’il ne fonctionne plus du tout.” Au final, l’ampleur a été assez anecdotique puisque la plupart des vieux GPS n’existaient plus ou avaient été mis à jour.

Le bug de 2038, un nouveau bug de l’an 2000?

Souvenez-vous, le bug de l’an 2000 n’avait touché que les systèmes informatiques qui codaient la date sur 2 chiffres. Celui de 2038 ne concernera, lui, que les systèmes utilisant la représentation POSIX du temps. Un peu de technique… 

Quand ils codent la date et l’heure, les programmeurs doivent tenir compte du fait que tous les pays ne les représentent pas de la même manière. Le format de la date peut tantôt être jj-mm-aaaa (Europe) tantôt aaaa-mm-jj (Etats-Unis), les heures peuvent se compter sur 12 (anglo-saxons) ou 24 heures. Pour éviter de jongler avec ces différences, certains ont choisi de coder le temps de façon “universelle”, sous la forme d’un nombre de secondes écoulées depuis une date de référence. “L’heure POSIX se base sur ce principe et stocke le nombre de secondes écoulées depuis le 1er janvier 1970 à 0h00min00s dans une variable de 32 bits”, peut-on lire sur le site de Supinfo, l’école supérieure d’informatique de Paris

Sans rentrer dans les détails, précisons seulement que cette variable atteindra sa capacité maximale le 19 janvier 2038 à 3h 14min et 7s. Si bien que lorsque l’ordinateur devra représenter la seconde suivante, il reviendra 68 ans en arrière. 

Contrairement au bug de l’an 2000 qui portait sur la représentation lisible du temps, celui de 2038 concerne sa représentation interne dans les systèmes d’exploitation de la famille UNIX (Linux, MacOS, iOS et BSD). Alain Buys ne voit donc pas de raison de s’alarmer. “Les architectures des ordinateurs ont beaucoup évolué. On est passé de systèmes qui fonctionnent avec des mots de 32 bits à des systèmes 64 bits. Normalement, aucun ordinateur concerné par ce problème ne sera encore en fonctionnement en 2038.” 


Texte : Jessica Flament
Photos : Pexels, Reporters et Shutterstock