Passage informatique à l'an 2000

Le passage informatique à l'an 2000, fréquemment nommé bug de l'an 2000 ou bogue de l'an 2000, a suscité de sérieuses inquiétudes à cause de problèmes de conception...


Catégories :

Culture informatique - Normalisation - Bug - 2000 - Calendrier - Mesure du temps - Mesure physique - Métrologie - Temps - Chronologie de l'informatique

Recherche sur Google Images :


Source image : fr.wikipedia.org
Cette image est un résultat de recherche de Google Image. Elle est peut-être réduite par rapport à l'originale et/ou protégée par des droits d'auteur.

Page(s) en rapport avec ce sujet :

  • Pour ce qui concerne les dispositifs de l'État, la mission " passage informatique à l'an 2000 " est chargée d'assurer la coordination des différentes actions... (source : dsi.cnrs)

Le passage informatique à l'an 2000, fréquemment nommé bug de l'an 2000 ou bogue de l'an 2000, a suscité de sérieuses inquiétudes à cause de problèmes de conception et par conséquent de programmation portant sur le format de la date dans les mémoires des ordinateurs et , donc dans les matériels informatiques, mais aussi dans les logiciels. Dans de nombreux programmes et énormément de bases de données, il manquait les deux chiffres 19 correspondant au siècle, de sorte qu'au passage de 99 à 100, en réalité 00, de nombreux dysfonctionnements devaient se produire dans ces traitements informatiques, 00 correspondant à l'année 1900 au lieu de 2000.

Au contraire de ce que laisse entendre l'appellation commune de «bug de l'an 2000», le problème de l'an 2000 n'était pas à proprement parler un bug, comme l'ont bien souligné plusieurs experts aux États-Unis, mais une erreur de conception systémique[réf.  nécessaire]. Cette erreur a obligation dans bien des cas de revoir en profondeur l'architecture des dispositifs d'information selon une approche systémique, surtout quand certains composants critiques du dispositif d'information ne pouvaient pas être réparés parce qu'ils étaient trop anciens et n'étaient plus maintenus. Il a par conséquent fréquemment fallu remplacer totalement des dispositifs d'information, le plus souvent spécifiques, par des progiciels du marché compatibles an 2000. Les dispositifs plus récents ont pu être réparés par conversion.

Finalement, aucun problème critique ne s'est produit. Cependant des sommes énormes ont dû être dépensées pour prévenir tout incident à propos de ce passage. [réf.  nécessaire]

Y2K

Y2K (Y pour year, 2K pour 2000) fut le sigle américain le plus fréquemment utilisé pour désigner le problème[réf.  nécessaire].

Par extension, Y2K a désigné le projet mondial de conversion des dispositifs informatiques occasionné par le passage à l'an 2000.

Le terme millennium bug («bogue du millénaire») a aussi été utilisé aux États-Unis, même si stricto sensu, le nouveau millénaire commençait le 1er janvier 2001. Les Américains ont aussi parlé de Y2K bug et de Y2K time bomb.

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 majorité des traitements étaient faits sur des cartes perforées représentant le texte sur des lignes de 80 colonnes uniquement. 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 quelquefois un bit supplémentaire nommé «zone de perforation» pour garder un caractère pour les nombres négatifs, ou compressaient quelquefois deux chiffres en un sous une forme nommé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 uniquement. Les évolutions spectaculaires des moyens de traitement et de stockage n'ont pas vraiment remis en cause ces pratiques. [réf.  nécessaire]

Les technologies du Web, Internet / extranet / intranet, plus récentes que les applications informatiques de gestion classiques, étaient particulièrement peu affectées par les erreurs de format de date. [réf.  nécessaire]

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

Il s'agissait par conséquent principalement d'un problème de normalisation et de conception. [réf.  nécessaire]

Pilotage

Le pilotage de cette opération s'est mis en place progressivement entre 1995, date à laquelle IBM a reconnu le problème, et 1998.

En France, le CIGREF (Club Informatique des Grandes Entreprises Françaises) s'est saisi du problème en 1995. Il a mis en place un premier groupe de travail constitué d'une dizaine de grandes entreprises.

C'est aussi en 1995 que Peter de Jæger, ingénieur entré chez IBM en 1980 qui ne cessait d'alerter sur le problème, a quitté son entreprise pour fonder un centre d'information sur le passage à l'an 2000 (year 2000 information center) . Son site web était le plus interconnecté au monde avec 25 000 liens. [réf.  nécessaire]

Les services de renseignement américains se sont penchés sur la question dès 1996. Pour le DoD (Department of Defense) , c'est le cabinet Mitre qui a effectué les adaptations des dispositifs. Le gouvernement américain a mis en place une cellule sous la responsabilité du vice-président Al Gore, et a installé une salle de commandement qui fournissait une visibilité mondiale sur l'avancement du projet. Les Américains étaient en mesure de connaître l'avancement de chaque pays dans la résolution du problème.

En France, le pilotage gouvernemental s'est mis en place en 1998. Il a porté sur cinq secteurs de services essentiels, dont l'électricité et l'eau.

En Europe, la charge de travail pour les informaticiens était telle que, dans la majorité des cas, il a été indispensable de repousser au-delà du 1er janvier 2000 les conversions à l'euro qui ne concernaient pas directement les marchés financiers.

La période transitoire de passage à l'euro a par conséquent dû se dérouler en deux phases :

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

Stratégies adoptées

Impacts selon les différents types d'informatique

Pour comprendre les stratégies des grandes entreprises, il est important de garder en tête les différents types d'informatique :

L'informatique de gestion

Les principaux impacts se trouvaient dans ce type de dispositifs, 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.

L'informatique technique (temps réel)

Les impacts sur ce type de dispositifs étaient moindres, en raison du plus faible nombre de dispositifs de pilotage industriels employant l'année. La majorité des dispositifs embarqués ou de pilotage dans l'aéronautique, le spatial, l'armement, les transports, le nucléaire, n'utilisent en effet que le jour, l'heure, la minute ou la seconde.

L'informatique scientifique

Pour ces dispositifs, 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.

Migration vs conversion

Revenons aux deux types de stratégies adoptées par les grandes entreprises dans la décennie 1990, pour en analyser les forces et les faiblesses :

La migration des anciennes applications vers de nouvelles applications,

fréquemment des progiciels de gestion intégrés (PGI), sous Unix (dans l'industrie essentiellement). En Europe, ce type de stratégie a présenté l'avantage de coupler le passage à l'an 2000 ainsi qu'à l'euro, par conséquent de diminuer 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 dispositifs totalement rénovés, avec des architectures informatiques mieux normées. À peu près 60% des grandes entreprises françaises ont adopté ce type de stratégie selon un expert du CIGREF.

La réparation (ou conversion).

Ce deuxième type de stratégie a concerné les entreprises moins prévoyantes, ou dont la complexité des dispositifs ne permettait pas de mieux anticiper le problème. En Europe, il comportait l'inconvénient de nécessiter une double conversion pour le passage à l'an 2000 ainsi qu'à l'euro, par conséquent d'augmenter les coûts. D'autre part, ces entreprises sont restées avec d'anciennes architectures d'applications informatiques moins normées. À peu près 40% des grandes entreprises françaises ont opté pour cette stratégie selon le même expert du CIGREF.

Les plus petites entreprises avaient des problèmes bien plus légers, étant donné qu'elles étaient déjà équipées de progiciels, qu'il suffisait de mettre à jour vers des versions conformes an 2000 et euro.

Quelques aspects du problème

Aspects économiques

De nombreuses estimations ont été avancées sur le coût de la correction du bug, en particulier 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 à peu près 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 elles-mêmes, ou bien si on y inclut le coût de mise en œuvre de l'ensemble des 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 environ à parts identiques en Amérique, en Europe, et en Asie.

Le projet a par conséquent 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 dispositifs internet étaient peu concernés, la bulle internet a aussi toujours 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 toujours 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. [1] Ces questions se sont posées à partir de 1996 en France. [Note 1]

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

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…).

Quand 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 toujours 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.

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 par conséquent appuyés sur cette date !

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

On voit qu'un délai de 13 ans a été indispensable 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 ont poussé le gouvernement fédéral à définir une loi (Clinger-Cohen Act) de mise en conformité des dispositifs d'information comparé 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[2].

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[3].

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 donnant la possibilité d'un échange de bonnes pratiques entre les fournisseurs d'équipements informatiques et de logiciels : Year 2000 Information and Readiness Act (18 octobre 1998), aussi 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é bien 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», étant donné que ce problème était universel.

L'Internet a joué un grand rôle dans la communication sur le problème de l'an 2000, en particulier 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 Jæger, 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 indispensable de faire une veille pour se tenir informé de l'avancement des méthodes de résolution du problème auprès des fournisseurs surtout. 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 la totalité des chaînes d'approvisionnement par effet domino. Les programmes an 2000 comportaient par conséquent toujours des actions d'information et de questionnement sur les programmes an 2000 de leurs partenaires. C'est probablement une des raisons pour lesquelles quasiment aucune entreprise n'a échappé à la sensibilisation au problème, et que le problème a été finalement résolu.

On retrouve aujourd'hui des pratiques identiques 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.

On pensait à raison que les programmes informatiques utilisés pour la gestion risquaient de s'arrêter de fonctionner ou produiraient des résultats erronés. Cela parce que la date dispositif du matériel informatique (hardware) ne comportait que deux chiffres pour l'année, sans le siècle, et que les logiciels et bases de données présentaient le même problème, avec uniquement les deux derniers chiffres pour l'année. Ainsi, l'année 2000 serait représentée par 00 et ne suivrait pas 1999 (99) dans une séquence numérique. Ceci risquait de créer des calculs et des comparaisons de données avec des résultats incorrects.

On pensait que les systèmes embarqués, étant donné qu'ils obéissaient à une logique identique, risquaient de ne plus fonctionner, entraînant le dysfonctionnement d'outils et d'autres infrastructures principales dans les dispositifs industriels.

Dans les années précédant 2000, quelques entreprises et gouvernements, quand ils ont fait des tests pour déterminer les impacts potentiels, ont rapporté que des dispositifs critiques auraient besoin de grandes réparations ou risqueraient des problèmes sérieux. De 1997 à 1998, des estimations incertaines et alarmistes rapportaient à propos d'entreprises et d'industries une faible préparation de l'évènement. L'imprécision de ces rapports et l'incertitude des possibilités que le bug de l'an 2000 se produise ainsi --que des centaines de milliards de dollars soient dépensés dans la correction du problème, -- furent une raison majeure de la peur du public. Des comités spéciaux furent établis par les gouvernements pour analyser les travaux nécessaires pour éviter le bug, en particulier pour les infrastructures principales comme les télécommunications, afin d'assurer que la majorité des services critiques soient prêts au 1er janvier. À partir de 1999, même si les mêmes organisations et gouvernements prétendaient être bien préparées, la confiance du public n'y était plus. [réf.  nécessaire]

Aux États-Unis en particulier, la presse a énormément communiqué dès 1996, surtout sous l'influence de Peter de Jæger, avec comme corolaire des craintes millénaristes.

Certains estiment que cette psychose aurait été volontairement alimentée par des entreprises informatiques dans l'objectif de pousser les consommateurs et les professionnels à s'équiper de matériel informatique plus récent. Dans la majorité des cas, les modifications étaient en réalité justifiées. Il faut dire que si le problème avait été anticipé plus tôt, il aurait coûté nettement moins cher ![réf.  nécessaire]

Un label «compatible an 2000» fut créé et attribué aux matériels informatiques censés ne pas souffrir du passage à l'an 2000.

Ce n'est que le passage sans problèmes à l'année 2000 qui a totalement écarté les craintes du public.

Pour approfondir

Le matériel informatique

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. Bien entendu, de tels circuits, et donc 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 uniquement ceux-là. Certains constructeurs peu scrupuleux ou ignorants avaient continué à utiliser des composants connus comme bugués mais nettement moins chers.

Des patches furent distribuées à l'envi pour être mises en place avant le jour fatidique.

Le logiciel

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 généralement pas énormément. 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 toujours extrapolés.

Économiser deux caractères pour chaque champ de date était jusqu'au milieu des années 1970 une économie vitale pour certains dispositifs. La majorité des programmeurs de l'époque ne s'attendaient pas à ce que leurs travaux demeurent en utilisation durant plusieurs décennies, et ne considéraient par conséquent pas cela comme un problème important. 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 20 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 de COBOL pour les années. Cela aurait pu être fait par les programmeurs à n'importe quel moment à partir de la version d'origine du premier compilateur COBOL en 1961. Cependant, l'indifférence et le manque de vision à long terme ont empêché ce conseil d'être suivi. Malgré des articles de magazines sur le sujet à partir de 1970, la majorité des programmeurs ont uniquement commencé à reconnaître l'année 2000 comme un problème dans les années 1990, mais même alors, il a été largement ignoré jusqu'aux toutes dernières années de la décennie.

En pratique, le codage des dates sur deux chiffres est toujours utilisé sans grand problèmes en 2003, dans de nombreux dispositifs, les programmeurs utilisant des techniques de fenêtrage pour déduire le siècle.

Nature du problème

Un problème de normalisation

L'une des raisons pour lesquelles on a 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 qu'on adopte le format de date français, américain ou anglais.

Les dispositifs Unix de leur côté décomptent les secondes pour calculer les dates.

Un défaut de conception systémique

Selon certains experts américains[Note 2], le problème de l'an 2000 ne s'apparentait pas précisément à un bug, mais plutôt à un défaut de conception. En effet, dans les spécifications fonctionnelles détaillées et les études techniques, on prévoyait un format de date incorrect. Ce défaut était systémique, dans la mesure où il était quasi-général dans les dispositifs d'information.

Une négligence

D'un point de vue moral, le problème de l'an 2000 a constitué une négligence lors de la conception (voir aussi dans ce sens l'étymologie du mot acédie). Il était en effet particulièrement simple de transformer les sous-programmes de gestion de dates et de concevoir des bases de données conformes au passage à l'an 2000. Il suffisait en effet d'introduire deux caractères pour le siècle dans les sous-programmes de gestion de date, et de déclarer les segments de base de données avec 8 caractères numériques pour le champ date.

Et l'avenir ?

Article détaillé : bug de l'an 2038.

Le bug de l'an 2038 devrait affecter les dispositifs Unix en 2038. En effet ces dispositifs utilisent le nombre de secondes écoulées depuis le 1er janvier 1970 (cette date «0» est nommée Epoch) pour exprimer les dates. Or en 2038, 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 habituel), le problème se posera en 2106 (le 7 février 2106 à 6 h 28 min et 15 sec 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 dispositifs 64 bits, il sera envisageable de stocker des dates à plus de 250 milliards d'années dans le futur. Cependant bon nombre de logiciels continuent à utiliser des représentations sources de malentendus (mm/jj/aa, jj/mm/aa, aa. mm. jj, etc. ).

Notes et références

Notes

  1. Pour approfondir, consulter les articles 1996 en informatique, 1997 en informatique, 1998 en informatique, 1999 en informatique
  2. Lane Core Junior surtout

Références

  1. Voir surtout ce site, où il est question de la position du CLUSIF vis-à-vis des fournisseurs informatiques
  2. Source :
  3. Source : http ://news. com. com/2110-1091-227567. html

Voir aussi

Liens externes

Recherche sur Amazone (livres) :



Principaux mots-clés de cette page : problèmes - informatique - 2000 - dispositifs - date - entreprises - fournisseur - passage - bug - logiciels - information - euro - données - nombres - programmes - nécessaire - conséquent - matériels - états - unis - réf - grandes - bases - chiffres - selon - conversion - y2k - américain - majorité - partir -

Ce texte est issu de l'encyclopédie Wikipedia. Vous pouvez consulter sa version originale dans cette encyclopédie à l'adresse http://fr.wikipedia.org/wiki/Passage_informatique_%C3%A0_l%27an_2000.
Voir la liste des contributeurs.
La version présentée ici à été extraite depuis cette source le 11/11/2010.
Ce texte est disponible sous les termes de la licence de documentation libre GNU (GFDL).
La liste des définitions proposées en tête de page est une sélection parmi les résultats obtenus à l'aide de la commande "define:" de Google.
Cette page fait partie du projet Wikibis.
Accueil Recherche Aller au contenuDébut page
ContactContact ImprimerImprimer liens d'évitement et raccourcis clavierAccessibilité
Aller au menu