Passage informatique à l'an 2000 - Définition

Source: Wikipédia sous licence CC-BY-SA 3.0.
La liste des auteurs de cet article est disponible ici.

Les origines du problème

Le problème de programmation qui faisait craindre le bug de l'an 2000 était avéré. Dans les années 1960, la mémoire et l'entreposage des données en informatique étaient coûteux et rares, la plupart des traitements étaient faits sur des cartes perforées représentant le texte sur des lignes de 80 colonnes seulement. Les langages de programmation de cette époque, comme le COBOL et le RPG, traitaient les nombres à partir de leur représentation ASCII ou EBCDIC. Ils utilisaient parfois un bit supplémentaire appelé « zone de perforation » pour garder un caractère pour les nombres négatifs, ou compressaient parfois deux chiffres en un sous une forme appelée décimal codé binaire, mais sinon, ils traitaient les nombres comme du texte ordinaire.

Cette pénurie de place en mémoire et dans les fichiers a incité les programmeurs à 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.

Les technologies du Web, Internet / extranet / intranet, plus récentes que les applications informatiques de gestion classiques, étaient très peu affectées par les erreurs de format de date.

En réalité, Y2K n'était pas à proprement parler un bug, mais un choix de conception des matériels informatiques, des logiciels et des bases de données.

Il s'agissait donc essentiellement d'un problème de normalisation et de conception.

Quelques aspects du problème

Aspects économiques

De nombreuses estimations ont été avancées sur le coût de la correction du bug, surtout aux États-Unis. Les plus sérieuses sont 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 $ dans le monde, sur la base de 300 à 600 milliards de lignes de programme existant dans le monde, et 1 $ par ligne de programme à convertir.

Le coût est extrêmement variable selon qu'on le restreint aux conversions de code proprement dites, ou bien si l'on y inclut 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.

On a estimé que ce coût s'est réparti à peu près à parts égales en Amérique, en Europe, et en Asie.

Le projet a donc coûté entre 100 et 200 milliards de $ en Europe.

Le traitement du passage informatique à l'an 2000 a créé un important appel d'air sur le marché 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 fortement 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.

Aspects juridiques

Le bug 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. Ces questions se sont posées à partir de 1996 en France.

Ces aspects étaient rendus complexes par le nombre important de fournisseurs engagés dans les grands contrats d'intégration :

  • constructeurs de matériels informatiques et leurs services de maintenance ;
  • Fournisseurs de logiciels spécifiques ;
  • Éditeurs de solutions progicielles (ERP) ;
  • Intégrateurs ;
  • Entreprises de facilities management ;
  • Opérateurs de télécommunications ;
  • etc.

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é, c'est-à-dire vers 1995 (en France, constitution d'un premier groupe de travail au CIGREF), le CIGREF (Club Informatique des Grandes Entreprises Françaises) 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 1er janvier 1990 était concerné.

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 1er janvier 1995.

Un grand fournisseur de logiciel a retenu la date du 1er janvier 1994.[réf. souhaitée]

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 !

Sur le fond, ce qui est en jeu, c'est :

  • les responsabilités respectives des utilisateurs et des fournisseurs ;
  • la façon dont les fournisseurs ont exercé leur devoir d'information ;
  • 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.

On voit qu'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.

Aux États-Unis, le projet Y2K a été l'une des raisons qui a 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.

Aspects communication

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.

L'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 20 000 liens.

En France, la communication institutionnelle par Internet n'est apparue qu'à partir de mars 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.

Aspects relations clients / fournisseurs

Un aspect important du problème é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 d'approvisionnement 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é à la sensibilisation au problème, et que le problème a été finalement résolu.

On retrouve actuellement des pratiques semblables avec le développement durable. La durabilité des activités d'une entreprise dépend en grande partie de la durabilité de ses fournisseurs. c'est pourquoi on parle d'achats durables.

Page générée en 0.312 seconde(s) - site hébergé chez Contabo
Ce site fait l'objet d'une déclaration à la CNIL sous le numéro de dossier 1037632
A propos - Informations légales
Version anglaise | Version allemande | Version espagnole | Version portugaise