Passage informatique à l'an 2000

Y2K (Y pour year, 2K pour 2000) fut le sigle américain le plus couramment employé pour désigner le problème. Par extension, Y2K a désigné 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 ont aussi été 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.

Peter de Jaeger, ingénieur canadien entré chez IBM en 1980, ne cessait d'alerter sur le problème. C'est en 1995 qu'il a quitté son entreprise pour fonder un centre d'information sur le passage à l'an 2000 (year 2000 information center). Son site internet, www.year2000.com, était à l'époque le plus interconnecté au monde avec 25 000 liens. Aux États-Unis, dans les années 1996-1999, il existait plusieurs sites internet du même type qui ont informé sur le problème. Le problème a suscité 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[4] - [5].

Internet a joué 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 a permis une mobilisation de la communauté mondiale. Pour le dixième anniversaire du passage à l'an 2000, Peter de Jaeger a été reconnu pour ses efforts de mobilisation mondiale[6].

Les principaux impacts se trouvaient en informatique de gestion, tant dans le matériel informatique (hardware) que dans le logiciel (software). Pour traiter ces non-conformités, il fallait 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 étaient 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[2]. Concernant l'informatique scientifique, les impacts étaient 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.

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

Très souvent dans l'industrie des progiciels de gestion intégrés (PGI) étaient présents — ex. : SAP en Europe —, sous Unix ou « Type Unix » suivant le fabricant de matériel.

En Europe, cela a présenté l'avantage de coupler le passage à l'an 2000 et à l'euro, donc de réduire globalement les coûts.

En effet, le passage à l'euro consistait 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 ont adopté ce type de stratégie selon un expert du CIGREF.

Cela a concerné les entreprises « moins prévoyantes », ou dont la complexité des systèmes ne permettait pas de mieux anticiper le problème (langages informatiques utilisés) ou encore structurées en « départements » (production quelle que soit la nature du produit, recherche, etc.). En Europe, il comportait 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 sont restées avec d'anciennes architectures d'applications informatiques dites propriétaires. Environ 40 % des grandes entreprises françaises ont opté pour cette nécessité à court-terme selon le même expert du CIGREF.

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.

Un point essentiel des programmes « An 2000 » était leur couverture sur le territoire. Il s'agissait 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) avaient un programme « An 2000 » avec un responsable. Par ailleurs, les organisations ont établi, à partir du début de 1999, des plans de secours. En Europe, ces plans ont en fait été utiles pour remédier aux conséquences de la tempête de fin décembre 1999.

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 Group, qui a estimé 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 fut 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 a créé un marché temporaire de l'emploi informatique, d'autant plus qu'en Europe cette échéance était quasi simultanée avec le passage à l'euro. Même si les systèmes internet étaient peu concernés, la bulle internet a aussi encore accru cet appel d'air. Les sociétés d'informatique (constructeurs informatiques et sociétés de services en informatique) ont alors pour l'année augmenté leurs effectifs. La surcharge de travail autour de l'an 2000, aggravée encore par le passage à l'euro, a aussi entraîné une dépression sur le marché informatique à partir de 2002.

Le bogue de l'an 2000 posait 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 étaient rendus complexes par le nombre important de fournisseurs engagés dans les grands contrats d'intégration, notamment :

• Constructeurs de matériels informatiques et leurs services de maintenance ;
• Fournisseurs de logiciels spécifiques ;
• Éditeurs de solutions progicielles (ERP) ;
• Intégrateurs ;
• Entreprises d'infogérance ;
• Opérateurs de télécommunications.

Les sociétés de conseil en management ont aussi joué un grand rôle, pour la planification des projets de mise en conformité à partir des estimations des analystes (Gartner Group…).

Lorsque le problème a commencé à être sérieusement identifié en dehors des entreprises de crédit bancaire, c'est-à-dire vers 1995 (en France, constitution d'un premier groupe de travail au CIGREF), le Club informatique des grandes entreprises françaises (CIGREF) s'est appuyé sur la directive européenne sur la responsabilité des produits défectueux de 1985, non encore 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 était concerné.

Ces questions se sont posées à partir de 1996 en France[Note 2]. Le SYNTEC, qui représente les SSII, n'a pas été d'accord avec cette position, et a adopté une position plus favorable aux fournisseurs, prenant comme référence la date du 1^er janvier 1995. Un grand fournisseur de logiciel a retenu la date du 1^er janvier 1994. Les juristes ont commencé à s'exprimer sur le sujet en 1996.

En France, le ministère de l'Économie et des Finances a donné 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'a été transposée en droit français que le 19 mai 1998. Certains fournisseurs se sont donc appuyés sur cette date.

Les enjeux incluent les responsabilités respectives des utilisateurs et des fournisseurs, la façon dont les fournisseurs ont exercé leur devoir d'information et la façon dont les fournisseurs ont exercé leur devoir de conseil. À travers la date de référence (1990, 1995…), 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. Un délai de 13 ans a été 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 an 2000 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 ont estimé que la non-conformité d’anciennes programmations à l'an 2000 ne relevait pas d'un vice caché, mais résultait en fait de l’absence d’une spécification par suite d’un choix délibéré. C'est ainsi que, en France, la garantie légale contre les vices cachés n'a généralement pas pu être invoquée par les clients[9].

Le projet Y2K a été l'une des raisons qui ont poussé le gouvernement fédéral à définir une loi (Clinger-Cohen Act) 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 a été défini pour se conformer à cette loi.

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

La grande majorité des mises en conformité a été 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 ont été identifiés en définissant des profils d'application dans le Global Information Locator Service(en) (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 était informé depuis le début de 1996), et confrontée à un problème de plus en plus urgent, l'administration américaine a 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 limitait la responsabilité des fournisseurs en cas d'erreur ou d'imprécision dans les informations échangées.

Un aspect important du problème du millénaire était le fait que les entreprises dépendaient à la fois de leurs fournisseurs et de leurs clients. Le problème pouvait affecter l'ensemble des chaînes logistiques par effet domino. Les programmes an 2000 comportaient donc systématiquement des actions d'information et de questionnement sur les programmes an 2000 de leurs partenaires. C'est sans doute une des raisons pour lesquelles pratiquement aucune entreprise n'a échappé 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 était 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 3].

La presse américaine a été 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 avait qualifié ce problème de la façon suivante : « Y2K is a œcumenical problem », dans la mesure où ce problème était universel.

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

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

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

Quelques fabricants du circuit faisant fonction d'horloge électronique dans les ordinateurs avaient fabriqué des composants incapables de stocker ou d'exploiter les deux chiffres du siècle. Ceux-ci valaient 19 par défaut, comme pour les programmes extrapolés. Évidemment, de tels circuits, et par conséquent les ordinateurs et leurs logiciels, pouvaient difficilement passer avec succès le 01/01/2000 sans commettre une erreur d'interprétation de date.

Ceux-ci se retrouvaient dans nombre d'ordinateurs vétustes, mais pas seulement ceux-là. Certains constructeurs peu scrupuleux ou ignorants avaient continué à utiliser des composants connus comme bugués mais beaucoup moins chers. Des patches furent distribués à l'envoi pour être mis en place avant le jour fatidique.

Au fil du temps, les cartes à perforer furent 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 changeait habituellement pas beaucoup. Des logiciels populaires ont continué la pratique de stocker les dates comme du texte. Rares étaient les logiciels utilisant les bases de données qui stockaient ou même prenaient en compte les deux chiffres du siècle, ceux-ci étaient presque systématiquement extrapolés.

Économiser deux caractères pour chaque champ de date était jusqu'au milieu des années 1970 une économie vitale pour certains systèmes. Cette logique a persisté dans les années 1980 en raison d'un coût élevé de l'octet. La plupart des programmes informatiques était présumé 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'attendaient pas à ce que leurs travaux demeurent en utilisation durant plusieurs décennies.

Le problème a été reconnu pour la première fois en 1958 par Bob Bemer par le résultat d'un travail sur un logiciel de généalogie. Il passa les vingt années suivantes à essayer de sensibiliser les programmeurs, IBM, le gouvernement des États-Unis et l'ISO au problème, avec peu de résultats. Ceci incluait la recommandation d'utiliser quatre chiffres dans les clauses PICTURE du COBOL pour les années. Cela aurait pu être fait 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 ont seulement commencé à reconnaître l'année 2000 comme un problème dans les années 1990, mais même alors, il a été 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 vers 1975 à émerger (par ex. Merise) et structurent tout 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.

L'une des raisons pour lesquelles les informaticiens ont tant tardé à s'attaquer au problème venait de ce que les dates n'étaient 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 français, américain ou anglais adopté. Les systèmes Unix de leur côté décomptent les secondes pour calculer les dates.

Selon certains experts américains[Note 4], le problème de l'an 2000 ne s'apparentait pas exactement à un bug, mais plutôt à un choix de conception. En effet, dans les spécifications fonctionnelles détaillées et les études techniques, on prévoyait un format de date inadéquat excluant le siècle. Ce défaut était systémique, puisqu'il était quasi général dans les systèmes d'information.

Le problème informatique de l'an 2000 a été 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'était 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é en 1974 sur les machines de gestion fut 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 fut 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. Une décompilation était nécessaire, — interdite par la loi lorsqu'il n'y a pas extrême nécessité[Note 5] —.

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 du stockage des dates en cette norme.

Le problème de stockage provient plutôt maintenant d'une gestion anarchique des hyperdonnées.

• Court-termisme#L'informatique
• Professionnalisme et gestion de crise
• Responsabilité du fait des produits défectueux
• Obsolescence programmée
• Date (métadonnée)
• ITSEC ; TCSEC
• MITRE ; Profil de protection
• Bug de l'an 2038

• (fr) Une page sur les conséquences du bug de l'an 2000, ainsi que sur les autres bugs du même genre passés ou à venir.
• (fr) Quand l’An 2000 a fait trembler l’informatique, sur le site du Cigref