Passage informatique à l'an 2000

Un tableau d'affichage électronique de l'École centrale de Nantes qui indique janvier 1900 au lieu de janvier 2000.

Le passage informatique à l'an 2000, connu sous le terme de bug de l'an 2000, est un défi sans précédent en matière de conception et de programmation informatique ayant lieu lors du passage à l'an 2000. Ce problème est attribuable à la manière dont les dates étaient formatées dans les systèmes informatiques, souvent réduites à deux chiffres pour l'année. Ainsi, en passant de 1999 à 2000, ces systèmes risquaient d'interpréter cette transition comme un retour à l'année 1900, entraînant des conséquences potentiellement graves sur le fonctionnement des programmes et des équipements.

Contrairement à la perception courante que ce problème était un simple bug, il s'agissait en fait d'une question d'obsolescence systémique qui exigeait une refonte profonde de l'architecture des systèmes d'information. Cette mise à jour était d'autant plus complexe que certains composants anciens n'étaient plus maintenus, nécessitant parfois le remplacement complet des systèmes.

L'ampleur des efforts déployés pour résoudre ce problème a été considérable, mobilisant des ressources financières estimées à plusieurs centaines de milliards de dollars à l'échelle mondiale. Malgré les coûts et les défis, ces initiatives ont réussi à prévenir tout incident majeur lors du passage au nouveau millénaire.

Origines

Dans les années 1960–1970 et avant la 4^e génération d'ordinateurs, la mémoire en informatique était coûteuse, la plupart des traitements étaient faits sur la base de la carte perforée stockant les données (système d'information utilisé avant-guerre). Ces cartes représentent un texte sur des lignes de 80 caractères. IBM est resté seul fabricant de l'époque de machines mécanographiques. Les cartes perforées sont destinées à un traitement de masse d'informations. Les langages de programmation d'alors, comme le Fortran, le Cobol et le RPG traitent les nombres à partir de leur représentation EBCDIC et apparut à partir de 1975 la norme ASCII non utilisée par IBM.

Le coût de la mémoire dynamique et le coût des données stockées sur des supports externes en forme de fiches ont fait coder les années sur deux chiffres seulement. Les évolutions spectaculaires des moyens de traitement et de stockage n'ont pas vraiment remis en cause ces pratiques^[1].

Les systèmes du web, tels qu'Internet, Extranet et intranet, plus récents que les applications informatiques de gestion classiques, étaient très peu affectés par les erreurs de format de date, en raison du nombre d'applications utilisant comme base de stockage pour les dates l'heure Unix. Les systèmes UNIX en général n'étaient donc pas touchés par ce bug, mais ils sont en revanche sujets au bug de l'an 2038.

En réalité, « Y2K » n'était pas à proprement parler un bug, mais un choix de conception des matériels informatiques, des logiciels et de leur génération et des données^[2].

Il s'agissait donc essentiellement d'un problème de normalisation et de conception^[1] très problématique aux États-Unis.

Y2K

Logo de Y2K.

Y2K (Y pour year et 2K pour 2000) est le sigle américain le plus couramment employé pour désigner le problème. Par extension, Y2K désigne le projet mondial de conversion des systèmes informatiques occasionné par le passage à l'an 2000. Les termes Year 2000 problem, Y2K problem, millennium bug (« bug du millénaire »), Y2K bug et Y2K glitch sont aussi utilisés aux États-Unis, même si stricto sensu, le nouveau millénaire commençait le 1^er janvier 2001. Les Américains ont aussi parlé de Y2K bug et de Y2K time bomb.

Sensibilisation et mobilisation

Aux États-Unis

Peter de Jager, ingénieur canadien entré chez IBM en 1980, ne cesse d'alerter sur le problème. En 1995, il quitte son entreprise pour fonder un centre d'information sur le passage à l'an 2000 (year 2000 information center). Son site web year2000.com est à l'époque le plus interconnecté au monde avec 25 000 liens^{[réf. nécessaire]}. Aux États-Unis, dans les années 1996–1999, il existe plusieurs sites internet du même type qui informent sur le problème. Le problème suscite un véritable phénomène de société, de nombreux « Y2K speakers » prenant la parole ou s'exprimant sur des sites internet pour alerter le grand public, comme Donald S. McAlvany^[3],[4].

Rôle d'internet

Internet joue un rôle clé dans la prise de conscience de l'ampleur du problème de l'an 2000 et dans sa résolution. Il permet une mobilisation de la communauté mondiale. Pour le dixième anniversaire du passage à l'an 2000, Peter de Jager est reconnu pour ses efforts de mobilisation mondiale^[5].

Aspects sociaux et pilotage

Le pilotage de l'opération du passage à l'an 2000 se met progressivement en place entre 1995, date à laquelle IBM reconnaît le problème, et 1998.

Les services de renseignement américains s'intéressent à la question dès 1996. D'après le département de la Défense des États-Unis, c'est le cabinet Mitre qui effectue les adaptations des systèmes. Le gouvernement américain met en place une cellule sous la responsabilité du vice-président Al Gore et installe une salle de commandement qui fournit une visibilité mondiale sur l'avancement du projet. Les Américains sont alors en mesure de connaître l'avancement de chaque pays dans la résolution du problème^{[réf. nécessaire]}.

En France, le pilotage gouvernemental est mis en place en 1998. Il porte sur cinq secteurs de services essentiels, dont l'électricité et l'eau. Le Cigref se saisit du problème en 1995. Il met en place un premier groupe de travail constitué d'une dizaine de grandes entreprises. En Europe, la charge de travail pour les informaticiens est telle que, dans la plupart des cas, il est nécessaire de repousser au-delà du 1^er janvier 2000 les conversions à l'euro qui ne concernent pas directement les marchés financiers.

La période transitoire de passage à l'euro se déroule donc en deux phases : une première phase en 1999 pour les systèmes financiers, puis une seconde phase en 2000–2001 pour les autres systèmes. Les bascules à l'euro, c'est-à-dire les conversions de la devise dans les systèmes comptables de la monnaie locale à l'euro, sont effectuées la plupart du temps lors de cette deuxième phase. Peu d'entreprises réussissent à faire la bascule à l'euro dès 1999.

Le gouvernement français lance une politique d'intelligence économique vers 1995. Elle est arrêtée peu de temps plus tard.

Différents impacts selon les types d'informatique

Les principaux impacts se trouvent en informatique de gestion, tant dans le matériel informatique (hardware) que dans le logiciel (software). Pour traiter ces non-conformités, il faut soit migrer vers de nouvelles plateformes matérielles et applications logicielles, soit réparer les anciennes plateformes et applications.

En informatique technique (temps réel), les impacts sont moindres, en raison du plus faible nombre de systèmes de pilotage industriels employant l'année. La plupart des systèmes embarqués ou de pilotage dans l'aéronautique, le spatial, l'armement, les transports, le nucléaire, n'utilisent que le jour, l'heure, la minute ou la seconde. La nécessité de garantir le bon fonctionnement des systèmes électroniques déjà embarqués fait rapatrier pour le changement de siècle les cartes électroniques et les reprogrammer^[1]. Concernant l'informatique scientifique, les impacts sont quasi nuls, le temps n'étant qu'un paramètre d'intégration des calculs scientifiques, pour la résolution des équations différentielles discrétisées.

Migration ou conversion

Deux tactiques sont utilisées par les grandes entreprises dans la décennie 1990.

Migration

Très souvent dans l'industrie des progiciels de gestion intégrés (PGI) sont présents (par exemple SAP en Europe), sous Unix ou « Type Unix » suivant le fabricant de matériel. En Europe, cela présente l'avantage de coupler le passage à l'an 2000 à celui de l'euro, et donc de réduire globalement les coûts. En effet, le passage à l'euro consiste alors en une mise à jour vers une version euro, puis en une bascule à l'euro selon les spécifications du fournisseur de PGI. L'autre avantage réside dans le passage à des systèmes complètement rénovés, avec des architectures informatiques mieux normées. Environ 60 % des grandes entreprises françaises adoptent ce type de stratégie, selon un expert du Cigref^{[réf. souhaitée]}.

Réparation (ou conversion)

La réparation concerne les entreprises « moins prévoyantes » ou dont la complexité des systèmes ne permet pas de mieux anticiper le problème (langages informatiques utilisés) ou encore structurées en « départements »^[6] (production quelle que soit la nature du produit, recherche, etc.). En Europe, il comporte l'inconvénient de nécessiter une double conversion pour le passage à l'an 2000 et à l'euro, donc d'augmenter les coûts. D'autre part, ces entreprises restent avec d'anciennes architectures d'applications informatiques dites propriétaires. Environ 40 % des grandes entreprises françaises optent pour cette nécessité à court-terme selon le même expert du Cigref^{[réf. souhaitée]}.

Les « plus petites entreprises » avaient des problèmes beaucoup plus légers, dans la mesure où elles étaient déjà équipées de progiciels, qu'il suffisait de mettre à jour vers des versions conformes an 2000 et euro.

Couverture des programmes An 2000 et plans de secours

Un point essentiel des programmes « An 2000 » est leur couverture sur le territoire. Il s'agit en effet de s'assurer que toutes les organisations (administrations, entreprises, collectivités locales) ainsi que toutes les filiales (dans le cas des grands groupes) ont un programme « An 2000 » avec un responsable. Par ailleurs, les organisations établissent, à partir du début de 1999, des plans de secours. En Europe, ces plans sont utiles pour remédier aux conséquences de la tempête de fin décembre 1999.

Aspects économiques

De nombreuses estimations ont été avancées sur le coût de la correction du « bogue », surtout aux États-Unis. « Les plus sérieuses » seraient celles du cabinet d'analyse stratégique Gartner, qui estime en 1995 que le projet Y2K coûterait environ 300 à 600 milliards de dollars dans le monde^[7], sur la base de 300 à 600 milliards de lignes de programme existant dans le monde, et un dollar par ligne de programme à convertir.

Le coût estimé est extrêmement variable si on se limite aux conversions de code proprement dites, ou bien si le coût de mise en œuvre de tous les progiciels qu'il a fallu déployer au cours de la décennie 1990 pour remplacer d'anciennes applications devenues obsolètes est inclus.

Il est estimé en 1998 depuis les États-Unis que ce coût allait se répartir à peu près à parts égales en Amérique, en Europe, et en Asie. Le projet aurait donc coûté entre 100 et 200 milliards de dollars en Europe.

Le traitement du passage informatique à l'an 2000 créer un marché temporaire de l'emploi informatique, d'autant plus qu'en Europe cette échéance est quasi simultanée avec le passage à l'euro. Même si les systèmes Internet sont peu concernés, la bulle Internet accroît cet appel d'air. Les sociétés d'informatique (constructeurs et services) augmentent alors leurs effectifs pour l'année. La surcharge de travail autour de l'an 2000, aggravée encore par le passage à l'euro, entraîne aussi une dépression sur le marché informatique à partir de 2002.

Aspects juridiques

Le bogue de l'an 2000 pose des questions juridiques sur les responsabilités respectives des utilisateurs d'informatique, et des fournisseurs de matériels informatiques et de logiciels^[8]. Ces aspects sont rendus complexes par le nombre important de fournisseurs engagés dans les grands contrats d'intégration, notamment chez les constructeurs de matériels informatiques et leurs services de maintenance, les fournisseurs de logiciels spécifiques, les éditeurs de solutions progicielles (ERP), les intégrateurs, les entreprises d'infogérance et les opérateurs de télécommunications. Les sociétés de conseil en management jouent aussi un grand important pour la planification des projets de mise en conformité à partir des estimations des analystes Gartner.

En France et en Europe

Lorsque le problème commence à être sérieusement identifié en dehors des entreprises de crédit bancaire, c'est-à-dire vers 1995, le Cigref s'appuie sur la directive de l'Union européenne sur la responsabilité des produits défectueux de 1985, encore non transposée. Selon cette directive, le fournisseur d'un produit est responsable des défauts d'un produit pendant une période de dix ans après sa mise en service ou sa commercialisation. Ainsi, tout matériel ou logiciel commercialisé à partir du 1^er janvier 1990 est concerné.

Ces questions se posent à partir de 1996 en France. La Syntec, qui représente les SSII, en désaccord avec cette position, adopte une position plus favorable aux fournisseurs, prenant comme référence la date du 1^er janvier 1995. Un grand fournisseur de logiciel^[Lequel ?] retient la date du 1^er janvier 1994^{[réf. souhaitée]}. Les juristes commencent à s'exprimer sur le sujet en 1996.

En France, le ministère de l'Économie et des Finances donne une première position sur le sujet en janvier 1997, en réponse à une lettre envoyée par un cabinet de juristes spécialisés en droit de l'informatique. La directive sur les produits défectueux n'est transposée en droit français que le 19 mai 1998. Certains fournisseurs s'appuient donc sur cette date.

Les enjeux incluent les responsabilités respectives des utilisateurs et des fournisseurs, la façon dont les fournisseurs exercent leur devoir d'information et la façon dont les fournisseurs exercent leur devoir de conseil. À travers la date de référence, la transposition de la directive sur les produits défectueux de 1985 et l'applicabilité effective en droit national de cette directive non transposée^{[incompréhensible]}. Un délai de 13 ans est nécessaire pour transposer la directive de 1985. En moyenne, une directive européenne est transposée en droit national en deux ans.

Du fait que de nombreux logiciels non conformes ont été conçus à une époque où toute l'industrie informatique utilisait la programmation à deux chiffres pour économiser la mémoire des ordinateurs, c'est-à-dire pour un motif à la fois technique et économique, certains juristes estiment que la non-conformité d’anciennes programmations à l'an 2000 ne relève pas d'un vice caché mais résulte de l’absence d’une spécification par suite d’un choix délibéré. C'est ainsi que, en France, la garantie des vices cachés n'a généralement pas pu être invoquée par les clients.

Aux États-Unis

Le projet Y2K est l'une des raisons qui pousse le gouvernement fédéral des États-Unis à définir une loi Clinger-Cohen Act (en) de mise en conformité des systèmes d'information par rapport aux directives gouvernementales. Le cadre d'architecture DoDAF du département de la défense est défini pour se conformer à cette loi.

Le cabinet MITRE assiste les armées des États-Unis et les agences dépendant du département de la Défense (NSA, DISA, etc.) pour la résolution de ce problème, dès 1993 pour l'US Air Force.

La grande majorité des mises en conformité est faite grâce au remplacement des applications spécifiques par des progiciels de gestion intégrés ou bien par des conversions des lignes de code, à 80 % en utilisant la technique du fenêtrage.

Les systèmes critiques du gouvernement fédéral des États-Unis sont identifiés en définissant des profils d'application dans le Global Information Locator Service (GILS), en employant des jeux de données signifiantes (Dublin Core).

Cependant, aux États-Unis, certaines données spécifiques (legacy data) ont dû être traitées par du langage XML.

En 1998, à l'approche de l'échéance (le président Bill Clinton est informé depuis le début de 1996), et confrontée à un problème de plus en plus urgent, l'administration américaine fait voter une loi permettant un échange de bonnes pratiques entre les fournisseurs d'équipements informatiques et de logiciels : Year 2000 Information and Readiness Act (18 octobre 1998), également surnommée Good Samaritan Law en référence à la parabole du Bon Samaritain dans la Bible. Cette loi limite la responsabilité des fournisseurs en cas d'erreur ou d'imprécision dans les informations échangées.

Relations clients-fournisseurs

Un aspect important du problème du millénaire est le fait que les entreprises dépendent à la fois de leurs fournisseurs et de leurs clients. Le problème peut affecter l'ensemble des chaînes logistiques par effet domino. Les programmes an 2000 comportent donc systématiquement des actions d'information et de questionnement sur les programmes de leurs partenaires. C'est sans doute une des raisons pour lesquelles pratiquement aucune entreprise n'échappe au problème.

Pratiqué depuis la décennie 1970 sur la croissance industrielle établie après la Deuxième Guerre mondiale, le système de la production après acte d'achat est la « production tirée ».

Cependant, la production des produits industriels commence à être pensée « pour pousser à l'achat » et assurer la rentabilité pour l'entreprise par la vente des pièces de rechange (après 2010 selon ce qui sera le marketing management)^{[Note 1]}.

Communication

La presse américaine est beaucoup plus communicative que la presse française, et de façon plus générale que la presse européenne, sur le problème de passage informatique à l'an 2000.

Un journaliste américain^[Qui ?] qualifie ce problème de la façon suivante^[Quand ?] : « Y2K is a œcumenical problem », dans la mesure où ce problème est universel.

Internet joue un grand rôle dans la communication sur le problème, surtout aux États-Unis. Plusieurs sites spécialisés sont créés pour communiquer sur le problème (systèmes impactés, informations sur les fournisseurs, outils et méthodes, bonnes pratiques, etc.). Pour donner une idée de l'importance de la communication sur le sujet, le site year2000.com du consultant canadien Peter de Jager, créé en 1995, est à l'époque le site le plus interconnecté au monde avec 25 000 liens.

En France, la communication institutionnelle par Internet n'apparaît qu'à partir de mai 1998, avec la création du site gouvernemental urgence2000.fr.

Il est nécessaire de faire une veille pour se tenir informé de l'avancement des méthodes de résolution du problème, et ce auprès notamment des fournisseurs. Ainsi, le passage informatique à l'an 2000 comporte certains aspects d'intelligence économique.

Nature détaillée du problème

Les programmes informatiques utilisés pour la gestion risquent de s'arrêter de fonctionner ou de produire des résultats erronés en raison du fait que la date système du matériel informatique (hardware) ne comporte que deux chiffres pour l'année, sans le siècle, et que les logiciels et bases de données présentent le même problème, avec seulement les deux derniers chiffres pour l'année. Ainsi, l'année 2000 est représenté par 00 et ne suit pas 1999 (99) dans une séquence numérique. Ceci risque de créer des calculs et des comparaisons de données avec des résultats incorrects.

Les systèmes embarqués, dans la mesure où ils obéissent à une logique similaire, risquent de ne plus fonctionner, entraînant le dysfonctionnement d'outils et d'autres infrastructures cruciales dans les systèmes industriels.

Dans les années précédant 2000, quelques entreprises et gouvernements, lorsqu'ils font des tests pour déterminer les impacts potentiels, rapportent que des systèmes critiques auraient besoin de grandes réparations ou risquent des problèmes sérieux. De 1997 à 1998, des estimations incertaines et alarmistes sont rapportées sur des entreprises dans l'industrie et le service.

L'imprécision de ces rapports, l'incertitude des possibilités que le bug de l'an 2000 se produise ainsi que des centaines de milliards de dollars dépensés dans la correction du problème sont les raisons majeures de la peur du public. Des comités spéciaux sont établis par les gouvernements pour analyser les travaux nécessaires pour éviter le bug, particulièrement pour les infrastructures cruciales comme les télécommunications, afin d'assurer que la plupart des services critiques soient prêts au 1^er janvier. À partir de 1999, même si les mêmes organisations et gouvernements prétendent être bien préparées, la confiance du public n'y était plus^[9].

Aux États-Unis particulièrement, la presse communique beaucoup dès 1996, notamment sous l'influence de Peter de Jager, avec comme corollaire des craintes millénaristes.

Certains estiment que cette psychose aurait été volontairement alimentée par des entreprises informatiques dans le but de pousser les consommateurs et les professionnels à s'équiper de matériel informatique plus récent. Dans la plupart des cas, les modifications sont en réalité justifiées.

Un label « compatible an 2000 » est créé^[Quand ?] et est attribué aux matériels informatiques censés ne pas souffrir du passage à l'an 2000.

Matériel informatique

Quelques fabricants du circuit faisant fonction d'horloge électronique dans les ordinateurs fabriquent des composants incapables de stocker ou d'exploiter les deux chiffres du siècle. Ceux-ci valent 19 par défaut, comme pour les programmes extrapolés. De tels circuits, et par conséquent les ordinateurs et leurs logiciels, peuvent difficilement passer avec succès l'an 2000 sans commettre une erreur d'interprétation de date.

Ceux-ci se retrouvent dans nombre d'ordinateurs vétustes, mais pas seulement : certains constructeurs peu scrupuleux ou ignorants continuent d'utiliser des composants connus comme bugués mais beaucoup moins chers. Des patches sont distribués à l'envoi pour être mis en place avant en temps voulu.

Logiciel

Au fil du temps, les cartes à perforer sont remplacées par des rubans magnétiques, des fichiers sur disque, puis des bases de données simples comme ISAM, mais la structure des programmes ne change habituellement pas beaucoup. Des logiciels populaires continuent de stocker les dates comme du texte. Rares sont les logiciels utilisant les bases de données qui stockent ou même prennent en compte les deux chiffres du siècle, ceux-ci sont presque systématiquement extrapolés.

Économiser deux caractères pour chaque champ de date est, jusqu'au milieu des années 1970, une économie vitale pour certains systèmes. Cette logique persiste dans les années 1980 en raison d'un coût élevé de l'octet. La plupart des programmes informatiques sont présumés d'une durée de vie d'environ 10 ans, calqués sur la vie de l'entreprise type société-à-capital et ses opérations de fusion-absorption ; la majorité des programmeurs de l'époque ne s'attendent pas à ce que leurs travaux demeurent en utilisation durant plusieurs décennies.

Le problème est reconnu pour la première fois en 1958 par Robert Bemer grâce au résultat d'un travail sur un logiciel de généalogie. Il passe les vingt années suivantes à essayer de sensibiliser les programmeurs, IBM, le gouvernement fédéral des États-Unis et l'ISO au problème, avec peu de résultats. Ceci inclut la recommandation d'utiliser quatre chiffres dans les clauses PICTURE du Cobol. Cela aurait pu être réalisé par les programmeurs à n'importe quel moment à partir de la version initiale du premier compilateur Cobol en 1961. Toutefois, pour certains « une indifférence et un manque de vision à long terme » ont fait que cette préconisation ne fut pas suivie.

Malgré des articles de magazines sur le sujet à partir de 1970, la majorité des programmeurs commencent seulement à reconnaître l'année 2000 comme un problème dans les années 1990, mais même alors, il est grandement ignoré jusqu'aux toutes dernières années de la décennie.

C'est parce que les méthodes informatiques d'analyse fonctionnelle et de programmation commencent seulement à émerger vers 1975 (par exemple Merise) et structurent le "métier" d'informaticien et son marché de l'emploi.

En pratique, le codage des dates sur deux chiffres est toujours utilisé sans grand problème en 2003, dans de nombreux systèmes, les programmeurs (quel que soit le langage) utilisent des techniques de fenêtrage (ceci rend le système très légèrement plus lent) pour déduire le siècle, souvent par un système de date pivot (>=50 est traduit 19xx, <50 est traduit 20xx). Cette logique ne fait que repousser le problème à 2050, sans le résoudre.

Normalisation

L'une des raisons pour lesquelles les informaticiens ont tant tardé à s'attaquer au problème vient du fait que les dates ne sont pas normalisées. Différentes formes de stockage des dates existent dans les mémoires, les programmes et les bases de données des systèmes d'information selon le format de date adopté. De leur côté, les systèmes Unix décomptent les secondes pour calculer les dates.

Défaut de conception systémique

Selon certains experts américains comme Lane Core Junior notamment, le problème de l'an 2000 ne s'apparente pas exactement à un bug, mais plutôt à un choix de conception. En effet, dans les spécifications fonctionnelles et les études techniques, on prévoit un format de date inadéquat excluant le siècle. Ce défaut est systémique, puisqu'il est quasi général dans les systèmes d'information.

Négligence

Le problème informatique de l'an 2000 est jugé comme une négligence lors de la conception de produit.

Exploités dans les environnements « Mainframe » (IBM Bull NEC et autres), les millions d'« objets » dans le monde (programmes, clause copy, bases de données, etc.) auraient pu être corrigés plutôt que laissés en l'état au fil des nouveaux projets ou des Tierces Maintenances Applicatives, dans les années 1990. Cependant pour ces processeurs, la programmation structurée (type Unix) avec des spécifications générales, dans les années 1970 et 1980 n'est pas de mise. La notion de sous programmes exclusivement dédiés est celle du Système de gestion d'exceptions pour sa relation partie-tout dans le système d'exploitation de la machine. La traduction du binaire (assembleur) fait partie de ce qui est nécessaire à la mise en marche de tout ordinateur.

La programmation procédurale par « PERFORM » en Cobol massivement utilisée en 1974 sur les machines de gestion est calquée sur les enchainements de sources écrits en assembleur, abondance de « GO TO », structure pérennisée dans le Cobol 85. Par conséquent, les changements à effectuer sur l'ajout des deux chiffres du siècle est d'une très grande complexité, de plus sur les calculs effectués sur ces dates (échéanciers ou majorations de retard).

Ultime difficulté, dans de rares cas, certains load modules (exécutables constitués par compilation des sources écrits en Cobol, langage informatique le plus fréquent (voir IBM 1130) n'avaient plus leur source pour y porter les modifications^{[incompréhensible]}. Une décompilation était nécessaire, interdite par la loi^[10] lorsqu'il n'y a pas extrême nécessité^{[Note 2]}.

Conséquences

Le passage informatique à l'an 2000 n'entraîne aucun dommage sur l'économie, contrairement à ce qui était craint.

En revanche, le passage à l'an 2000 ainsi que, en Europe, le passage à l'euro, entraînent des investissements très lourds dans les années 1990. Les entreprises doivent amortir ces investissements au début des années 2000. Il y a donc une baisse d'activité significative entre 2002 et 2005. Les plus grandes entreprises du secteur ont dû licencier du personnel^{[réf. nécessaire]} pour s'adapter au changement de conjoncture.

Avenir

Le bug de l'an 2038 devrait affecter les systèmes Unix en 2038. En effet, ces systèmes utilisent le nombre de secondes écoulées depuis le 1^er janvier 1970 (cette date « 0 » est appelée Epoch) pour exprimer les dates. Or, le 19 janvier 2038 à 3 h 14 min 7 s, le nombre de secondes écoulées devrait dépasser les capacités de stockage des nombres signés sur quatre octets. Sur les variantes d'Unix représentant ce nombre de secondes avec des entiers non signés (ce qui, pour des raisons techniques, est peu fréquent), le problème se posera en 2106 (le 7 février 2106 à 6 h 28 min 15 s en temps universel). Pour éviter ce problème, il faut stocker la date sur un plus grand nombre de bits. Avec l'arrivée de systèmes 64 bits, il sera possible de stocker des dates à plus de 250 milliards d'années dans le futur. Or, d'après les scientifiques, notre planète disparaîtra dans environ 4,5 milliards d'années, en même temps que le Soleil, ce qui résout donc largement le problème.

Le problème de stockage provient désormais d'une gestion anarchique des hyperdonnées^{[En quoi ?]}.

Dans la culture populaire

• Les passages informatiques de l'an 2000 ont été parodiés dans le dixième Horror Show de la série Les Simpson.
• Dans le jeu vidéo Metal Gear Solid 2, les correctifs informatiques du bug de l'an 2000 sont présentés comme un virus déguisé permettant le contrôle du flot d'information mondial par internet.
• Le catcheur Chris Jericho utilise le surnom Y2J en référence au sigle Y2K.
• Il a été moqué dans Les Guignols de l'info à travers la World Company^[Quoi ?], montrant le passage informatique comme une arnaque digne d'une blague de maternelles.
• Selon le mythe, c'est l'approche du bug de l'an 2000 qui aurait transformé les Daft Punk en robot^[11].
• Le film américain Y2K (2024) évoque le sujet de manière parodique et uchronique.

Notes et références

Notes

1. Au XXI^e siècle, il est question de consommation responsable selon le secteur.
2. Il n'est possible de faire de la décompilation et de la correction que s'il s'agit d'un système hérité et que le fabricant ne peut pas corriger le code dans les temps s'imposant à l'utilisateur final.

Références

1. Nicolas Sanders, « Il y a 20 ans, le bug de l'an 2000 et la fin du monde qui n'ont pas eu lieu » , RFI, 31 décembre 2019 (consulté le 1^er octobre 2021)
2. En anglais, design flaw : (en) Silicon Valley Law Firm Weighs In On Y2K Bug & Legislation (SJ Merc News).
3. (en) Donald S. McAlvany, Y2K Crisis : Preparing for the Coming Computer Crash!, A. N. Incorporated International, 1998, 168 p. (ISBN 0-9647861-9-2, lire en ligne).
4. (en) Donald S. Mcalvany, The Y2k Tidal Wave : Year 2000 Economic Survival, Toronto, Frontier Research Publications, 1^er janvier 1999, 300 p. (ISBN 0-921714-54-8, lire en ligne).
5. (en) « 2009 Guardian Award : Peter de Jager Named Lifeboat Foundation 2009 Guardian Award Winner » , sur lifeboat.com, Lifeboat Foundation (consulté le 22 juillet 2024).
6. « Les architectures N-tiers » [PDF], sur cedric.cnam.fr, Cédric (consulté le 22 juillet 2024).
7. (en) Stephanie Schmitt-Grohé (en) et Martín Uribe (en), « Y2K », Review of Economic Dynamics (en), Academic Press, vol. 2, n^o 4,‎ octobre 1999, p. 850–856 (DOI 10.1006/redy.1999.0065, lire en ligne [PDF], consulté le 3 octobre 2021).
8. Laurent Pelé, « Le Clusif tente d'imposer aux fournisseurs les frais du passage à l'an 2000 » , sur pele.org (consulté le 22 juillet 2024)
9. Christophe Agnus, « Le grand bug de l'an 2000 » , L'Express, 4 avril 1996 (consulté le 1^er octobre 2021)
10. « Accès aux codes source : quels droits pour les utilisateurs ? » , sur Féral, 1^er mars 2002 (consulté le 22 juillet 2024).
11. Yohann Ruelle, « "Daft Punk Unchained" : L'histoire secrète du duo casqué racontée dans un documentaire », sur Charts in France, 24 juin 2015 (consulté le 22 septembre 2024).

Voir aussi

Articles connexes

• Court-termisme informatique
• Professionnalisme et gestion de crise
• Responsabilité du fait des produits défectueux en France
• Obsolescence programmée
• Date (métadonnée)
• ITSEC
• TCSEC
• Profil de protection
• Bug de l'an 2038
• Panne informatique mondiale de juillet 2024

Liens externes

• Notices dans des dictionnaires ou encyclopédies généralistes :

  • Britannica
  • Enciclopedia De Agostini
  • Nationalencyklopedin
• Notices d'autorité :

  • BnF (données)
  • LCCN
  • Israël