Bug de l’an 2000

L’histoire du bug de l’an 2000 commence bien avant les années de panique qui précédèrent le passage au nouveau millénaire. Dans les années 1960, quand les programmeurs travaillaient avec des cartes perforées limitées à 80 colonnes et que chaque octet de mémoire coûtait une fortune, coder les dates sur deux chiffres semblait une décision parfaitement raisonnable. Qui aurait imaginé que ces programmes tourneraient encore quarante ans plus tard ? Cette économie d’espace, anodine sur le moment, allait se transformer en l’un des plus grands casse-têtes techniques de la fin du XX^e siècle.

Le mécanisme du problème était d’une simplicité désarmante. Les systèmes ne stockant que les deux derniers chiffres de l’année ne pouvaient distinguer 1900 de 2000. Un calcul de durée entre deux dates, un tri chronologique, une vérification de validité : autant d’opérations qui risquaient de produire des résultats aberrants. Les premiers signes apparurent dès les années 1980, bien avant que l’expression « bug de l’an 2000 » ne fasse la une des journaux. En 1988, la chaîne britannique Marks & Spencer refusa une livraison de conserves dont le système avait interprété la date de péremption en 2000 comme 1900, considérant les produits périmés depuis près de quatre-vingt-dix ans. L’anecdote fit sourire, mais elle annonçait des ennuis autrement plus sérieux.

La prise de conscience s’amorça vraiment courant 1990. Les experts commencèrent à multiplier les alertes : dysfonctionnements bancaires, réseaux électriques à l’arrêt, contrôle aérien paralysé, équipements médicaux défaillants. En 1992, Mary Bandar, une dame de 104 ans, reçut une invitation à rejoindre une classe de maternelle — son année de naissance « 88 » ayant été lue comme 1988 plutôt que 1888. L’incident aurait pu prêter à rire s’il n’avait révélé l’ampleur du problème qui se profilait.

Les gouvernements finirent par réagir. Le Royaume-Uni créa la « Taskforce 2000 » en 1996, suivie l’année suivante par « Action 2000 », dotée d’un budget initial d’un million de livres sterling qui grimpa à 17 millions. Les Nations Unies établirent en février 1999 le Centre international de coopération Y2K, financé par la Banque mondiale. Les entreprises lancèrent des programmes de mise en conformité massifs. La Bourse de New York y consacra 30 millions de dollars sur sept ans.

Mais le problème ne se cantonnait pas aux grands systèmes centraux. Les contrôleurs logiques programmables, omniprésents dans l’industrie pour commander machines et processus, utilisaient souvent des dates à deux chiffres. Les PC présentaient leurs propres complications, liées à leur horloge temps réel et à leur BIOS. Certaines versions, comme l’Award v4.50 de 1994-1995, ne géraient tout simplement pas les dates au-delà de 1999, tout comme Windows 95 n’était pas compatible non plus avec le passage à l’an 2000.

Face à cette situation, quelques stratégies techniques émergèrent. L’expansion des années à quatre chiffres représentait la solution la plus solide, mais elle exigeait de revoir en profondeur les programmes et les bases de données. La technique dite du « windowing » conservait le format à deux chiffres tout en ajoutant une logique d’interprétation : « 00 » à « 19 » correspondait à 2000-2019, « 20 » à « 99 » à 1920-1999. Cette méthode, moins coûteuse, avait le défaut de simplement reporter le problème à une date ultérieure.

Les audits se multiplièrent à partir de 1997. Les cabinets commencèrent à exiger de leurs clients qu’ils certifient la conformité de leurs systèmes critiques pour garantir la continuité de leur activité. Des sociétés spécialisées développèrent des outils automatisés pour détecter et corriger les problèmes dans le code source. Des programmeurs COBOL sortirent de leur retraite, réclamant des salaires confortables pour intervenir sur les systèmes qu’ils avaient bâtis des décennies plus tôt.

Les tests révélèrent des failles inquiétantes. Le système antimissile Rapier britannique se révéla inopérable après 2000. Une centrale nucléaire suédoise s’arrêta automatiquement lors d’un test de passage au nouveau millénaire. Chez Chrysler, un essai en 1997 paralysa le système de sécurité d’une usine, bloquant les accès et empêchant la gestion de la paie.

Le coût global des corrections oscilla entre 300 et 500 milliards de dollars. Les États-Unis dépensèrent 34 milliards, l’Italie 2,5 milliards, le Venezuela 100 millions. Les pays industrialisés, dont l’économie reposait davantage sur les systèmes numériques, investirent proportionnellement plus que les autres.

Finalement, le passage à l’an 2000 provoqua moins de chaos que redouté. Des incidents survinrent : quinze réacteurs nucléaires s’arrêtèrent, des systèmes de paiement par carte dysfonctionnèrent, des pannes de courant touchèrent Hawaï. Mais la catastrophe annoncée n’eut pas lieu, résultat direct des efforts déployés pendant la décennie précédente.

Cette expérience laissa des traces. Elle démontra que les principes d’ingénierie logicielle comme l’abstraction et l’encapsulation n’étaient pas que des concepts théoriques. Elle souligna les dangers des points de défaillance uniques et l’intérêt d’un couplage faible entre systèmes. Elle prouva qu’une mobilisation internationale face à une menace informatique identifiée restait possible.

Paradoxalement, le succès de la gestion du « Y2K » freina l’adoption de certaines leçons. L’industrie continua de privilégier la rapidité de mise sur le marché au détriment de la robustesse. Les chaînes d’approvisionnement se resserrèrent, réduisant leur capacité à absorber les chocs. La crise actuelle de la cybersécurité témoigne de cette difficulté persistante à concevoir des systèmes informatiques à la fois robustes et sécurisés. Le bug de l’an 2000 aura été, au fond, une occasion manquée d’apprendre vraiment de nos erreurs.

Ceci illustre bien deux principes d’architecture à garder en tête dans tout travail de conception, informatique ou pas : « Les problèmes d’aujourd’hui viennent des solutions d’hier » et « La cause et l’effet peuvent intervenir à des temps et des lieux lointains ».