• 1.1-Les phénomènes non linéaires naturels :
• 1.2-Les phénomènes non linéaires artificiels :
• 1.3-L'informatique dans les années soixante :
• 1.3.1-La mémoire des ordinateurs :
• 1.3.2-Les cartes perforées :
• 1.3.3-Economiser :
• 1.4-L'informatisation généralisée :

• 2.1-Les causes générales :
• 2.1.1-La durée de vie des réalisations informatiques :
• 2.1.2-Le développement des projets informatiques :
• 2.1.3-L'absence de prévisibilité :
• 2.1.4-La nécessité de la compatibilité :
• 2.1.5-Tout marche bien :
• 2.1.6-Les ordinateurs ont une capacité limitée :
• 2.2-Les causes spécifiques :
• 2.2.1-Le pseudo-numéro de siècle maltraité :
• 2.2.1.1-Le pseudo-numéro de siècle perdu :
• 2.2.1.2-Le pseudo-numéro de siècle figé :
• 2.2.1.3-Le pseudo-numéro de siècle "fourre-tout" :
• 2.2.1.4-Le format des dates :
• 2.2.2-Les dates et les années inaccessibles :
• 2.2.3-La capacité limitée :
• 2.2.4-Les chaînes de caractères numériques ne sont pas des nombres :
• 2.2.5-Les années bissextiles (l'an 2000 est une année bissextile) :
• 2.3-Les responsables (les coupables ?) :
• 2.3.1-Les informaticiens :
• 2.3.2-Les utilisateurs :
• 2.3.3-Les média :
• 2.3.4-Le monde politique :

• 3.1-Le retour dans le passé :
• 3.2-Les calculs de durée :
• 3.3-Les actions périodiques :
• 3.4-Les relations d'ordre temporels :
• 3.5-La durée de vie :
• 3.6-L'arithmétique :
• 3.7-La génération de noms d'objets :
• 3.8-Les conséquences économiques et sociales :

• 4.1-Arréter d'utiliser deux chiffres pour l'année !
• 4.2-Le pseudo-numéro de siècle :
• 4.3-Les fonctions de calcul de date :
• 4.4-Les dates inaccessibles :
• 4.5-Tout est facile, mais où est le problème ?

• 5.1-L'ampleur du travail :
• 5.1.1-Le cauchemar :
• 5.1.2-Les programmes :
• 5.1.3-L'omniprèsence :
• 5.1.4-L'effet domino :
• 5.2-Il n'y a pas de solution miracle !
• 5.3-De la maintenance :
• 5.4-La methode :
• 5.4.1-Inventorier et èvaluer les risques :
• 5.4.2-Examiner :
• 5.4.2.1-L'automatisation est difficile :
• 5.4.2.2-La documentation :
• 5.4.2.3-A propos des sources des programmes :
• 5.4.3-Corriger :
• 5.4.3.1-La compatibilitè :
• 5.4.3.2-Gerer les risques :
• 5.4.3.3-Les compètences Cobol :
• 5.4.3.4-Comment et quoi tester ?
• 5.4.3.5-Les consèquences :
• 5.4.3.6-Ne pas oublier :
• 5.5-Les problèmes juridiques et autres :
• 5.5.1-Le ralentissement des applications :
• 5.5.2-Qui va payer ?
• 5.5.3-Qui sera responsable des inèvitables degats ?
• 5.5.4-L'Europe :
• 5.5.5-La France :
• 5.6-Quelques exemples :
• 5.6.1-La Royal Bank of Canada :
• 5.6.2-L'Union Pacific :

• 6.1-La prise de conscience :
• 6.2-La sensibilisation :
• 6.3-Vérifier et maintenir notre environnement :
• 6.4-Interroger :
• 6.5-Les contrats :
• 6.6-Etre plus vigilant :
• 6.7-Suggerer :

• 8.1-Le problème :
• 8.2-Profiter de l'occasion :
• 8.3-"Mieux vaut prévenir que guérir", "Rien ne sert de courir, il faut partir à point" et "Un homme averti en vaut deux".

1.1-Les phénomènes non linéaires naturels :

Il est dans la nature de nombreux phénomènes pour lesquels des causes infimes peuvent avoir des conséquences énormes et pour lesquels la prévisibilité à long terme est impossible. L'un des meilleurs exemples est celui des avalanches ("petites causes et grands effets", ne dit-on pas d'ailleurs faire boule de neige) ou encore l'effet "papillon" d'Edward Lorenz.




1.2-Les phénomènes non linéaires artificiels :

Notre Science et notre Technologie nous offrent des "objets" artificiels ou manufactures possédant les mêmes propriétés. L'attracteur de Lorenz est l'un des plus fameux exemples de système non linéaire ; il permet en particulier de montrer le phénomène de la sensibilité aux conditions initiales.

L'échec du vol Ariane 501 le 04/06/1996, même s'il n'a rien à voir avec des problèmes de date, est un excellent (et malheureux) exemple des conséquences dramatiques que peut avoir un petit grain de sable (de silicium ?) dans les "rouages", même bien huilés, d'un système informatique conçu par des ingénieurs dont la compétence et les méthodes ne peuvent être mises en doute (j'espère qu'ils pardonneront donc la publicité qui est faite ici à cet incident...). Pour eux, la fiabilité est l'un des objectifs annoncés -à côté de la performance et de la compétitivité en particulier- ; il est ainsi possible de lire dans le dossier de presse du vol Ariane 501 : ce sont les choix des technologies et de l'architecture du lanceur et des moyens au sol qui contribuent à la simplicité et à la fiabilité (...) le système électrique et logiciel bord est complètement redondé (malheureusement, depuis le début du quatrième trimestre 1998, le rapport relatif à cet incident n'est plus disponible sur le site du CNES ; en voici malgré tout un résumé).

Enfin, un troisième exemple de phénomènes non linéaires artificiels qui très certainement marquera moins l'histoire de l'humanité que les deux précédents, mais qui est lui aussi très lié à des anomalies logicielles souvent inexplicables. Il s'agit d'un (véritable) bulletin de salaire du mois de juillet 1992 ; celui-ci devait faire apparaître rétroactivement une augmentation accordée au mois de janvier de la même année. Malheureusement, il indique un montant imposable du mois de -104526.88 francs qui est donc négatif (un comble après une augmentation !) et démesuré en valeur absolue ; la logique du calcul des déductions échappent à toute analyse, même si elle est de toute évidence programmée dans un ordinateur ! Il est évident qu'un cas non prévu est apparu lors de l'établissement de ce bulletin, et que cela a alors engendré une avalanche de valeurs fausses...




1.3-L'informatique dans les années soixante :




1.3.1-La mémoire des ordinateurs :

Elle était une denrée rare et coûteuse (une mémoire de 32 kilo-octets et des disques de moins d'un méga-octet étaient alors considérés comme standards). Certaines de ces machines ne possédaient comme "mémoires externes" que des bandes magnétiques, voire des rubans perforés...




1.3.2-Les cartes perforées :

Inventées par Hermann Hollerith, elles furent utilisées à l'occasion du recensement américain de 1890. Elles étaient, avec leurs 80 colonnes permettant d'enregistrer 80 octets (ou un peu plus, en stockant 12 bits par colonne au lieu de 8), le support universel d'interaction avec l'ordinateur. Une simple cassette DAT de 120 mêtres est aujourd'hui l'équivalent d'une centaine de tonnes de ces cartes...




1.3.3-Economiser :

Notons au préalable, que par abus de langage, nous appelerons par la suite pseudo-numéro de siècle les deux premiers chiffres d'une année alors qu'en toute généralité, ceux-ci ne désignent véritablement le siècle que pour les années séculaires (c'est-à-dire divisibles par 100) dont la représentation décimale contient exactement quatre chiffres : ainsi, l'année 1900 appartient encore au dix-neuvième siècle, alors que 1901 est la première année du vingtième siècle ; de même, l'année 2000 appartiendra encore au vingtième siècle, alors que 2001 sera la première année du vingt-et-unième siècle et du troisième millénaire !

Tout invitait donc à économiser l'usage qui était fait des octets, tant en mémoire centrale que sur les disques. Or, quoi de plus naturel, lorsque l'on rédige une lettre ou remplit un chèque, que de rendre implicite le pseudo-numéro du siècle (par exemple, 20/03/97 pour 20/03/1997) ?

Alors pourquoi ne pas étendre et systématiser cette méthode ?

Il est important de bien noter que cette pratique est bien antérieure à l'apparition de l'informatique. A titre d'illustration de ceci, l'exposition Mallarmé, un destin d'écriture consacrée à Stéphane Mallarmé au Musée d'Orsay de Paris (09/1998-01/1999) présentait, en particulier, des enveloppes (datant donc du dix-neuvième siècle) sur lesquelles les cachets postaux donnaient uniquement les deux derniers chiffres des années. Ainsi, même si la capacité des ordinateurs avait été suffisante, les années auraient peut-être été codées, malgré tout, sur deux chiffres !





1.4-L'informatisation généralisée :

Si l'informatique est un outil aujourd'hui indispensable dans toutes nos activités, elle a malgré tout créé de fortes dépendances et fragilisé dans un certain sens nos économies (déjà des problèmes boursiers ont été provoqués par des activités automatisées et donc éventuellement incontrôlables) ainsi que notre confort quotidien. Les fortes interconnexions des systèmes informatiques donnent naissance à un système global fortement non linéaire dont le comportement peut devenir chaotique et donc imprévisible.

2.1-Les causes générales :




2.1.1-La durée de vie des réalisations informatiques :

Les logiciels (et les bases de données) ont en général des durées de vie très supérieures à celles qui sont prévues lors de leurs développements ; ceci se vérifie, en particulier, pour celles qui furent conçues dans les années soixante et soixante-dix.

Et de plus, qui imaginait dans les années cinquante et soixante que l'ordinateur prendrait tant d'importance ? Certains avaient même annonce au tout debut de l'informatique que seuls quelques uns de ces "monstres" suffiraient a nos besoins...

Il est important de bien comprendre que les systèmes informatiques qui gèrent nos banques, nos entreprises, nos administrations,... sont d'une incroyable complexité. Une conséquence de cela est qu'en général ils évoluent plus par des remplacements restreints et limités, plutôt que par des bouleversements de très grande ampleur. Ils sont assez similaires à nos grandes villes : il y a dans Paris des bâtiments millénaires, des rues où les voitures ne peuvent passer,... Lorsqu'une nouvelle ligne de métro est construite, elle doit s'intégrer à l'existant et respecter les contraintes induites : le futur d'une ville se construit sur son passé. Dans les systèmes informatiques, il en est de même : les nouveaux programmes, les nouveaux ordinateurs,... viennent s'intégrer à d'autres plus anciens, dont ils doivent respecter les protocoles. C'est ainsi donc, que de proche en proche (de nouveaux programmes en nouveaux programmes, de nouveaux ordinateurs en nouveaux ordinateurs), des choix anciens peuvent se propager, franchir les décennies et arriver jusqu'à nous, et ce indépendamment de la volonté de ceux qui les avaient faits !




2.1.2-Le développement des projets informatiques :

Trop fréquemment des logiciels furent (et sont encore : quelquefois ? souvent ?) développés en l'absence de toute méthode, sans commentaires et en faisant appel à de nombreuses hypothèses implicites ; la documentation fait trop souvent défaut.




2.1.3-L'absence de prévisibilité :

Bien souvent, malheureusement, l'ensemble des conséquences à long terme d'un choix est impossible à prévoir, et ce, quelle que soit la (bonne) volonté (et les compétences).

Ceci n'est pas propre à la corporation des informaticiens : à titre d'exemple, les inventeurs de l'automobile pouvaient-ils prévoir la pollution et les accidents mortels de la circulation ? Et si oui, devaient-ils pour cela renoncer à cette invention ? De même, Graham Bell, lorsqu'il inventa le téléphone en 1875 à l'Universite de Boston, imaginait-il qu'un siècle plus tard son invention serait devenue l'une des plus indispensables à la vie courante ? Et aurait-il pu concevoir que sous sa forme portable, ce même téléphone deviendrait une nouvelle forme de pollution dans les lieux publics ?

Au passage, existe-t-il, et même peut-il exister, des médailles sans revers ?




2.1.4-La nécessité de la compatibilité :

Il est très souvent nécessaire d'assurer la compatibilité (dite ascendante) des nouveaux programmes avec les anciens. Ainsi se créent des relations de dépendance forte vis à vis de choix antérieurs.

Ici de même, l'informatique n'est pas la seule à nous enchainer irréversiblement à des choix (parfois arbitraires) faits dans le passé. A titre d'exemple, imaginons que nous décidions de rouler à gauche, même dans un espace limité comme celui de Paris intra-muros ; le simple inventaire de tout ce qui dépend du choix ancien de rouler à droite (signalisation, points d'accès -portes des autobus, entrées et sorties des parkings et autoroutes,...-, péages, topologie des voies en sens unique, mais aussi disposition des panneaux publicitaires,...) conduirait à renoncer rapidement à ce projet. Notons enfin l'importance de la phase initiale, dite d'inventaire, que nous retrouverons naturellement un peu plus loin, dans le problème qui nous intéresse ici...




2.1.5-Tout marche bien :

Il est souvent très sage d'éviter de toucher à un échafaudage informatique qui fonctionne correctement. En effet, il est plus que fréquent qu'une modification mineure (en vue de corriger un défaut antérieur ou bien d'ajouter une fonctionnalité) introduise un défaut a priori imprévu et majeur. Le problème de l'An 2000 est connu depuis longtemps, mais tout marche si bien (enfin presque...).




2.1.6-Les ordinateurs ont une capacité limitée :

Lors de le réalisation d'applications informatiques (y compris dans le milieu scientifique), les programmeurs ont tendance à considérer que les ordinateurs ont une capacité illimitée et savent manipuler l'infini. Cela est faux bien évidemment, et l'ignorer peut conduire à d'énormes difficultés. Il convient de bien noter que les limites que possèdent les ordinateurs peuvent être soit intrinsèques et inhérentes à leurs principes fondamentaux (cas, par exemple, des erreurs d'arrondi), soit imposées arbitrairement par les programmeurs comme nous allons le voir dans les paragraphes suivants...

Ceci est l'une des raisons pour lesquelles les tests concernant les problèmes de date sont si difficiles à conduire exhaustivement et en toute généralité. En effet, quelque chose fonctionnant correctement à une certaine date, peut très bien ne plus fonctionner le lendemain, sans qu'aucune action ne soit venue modifier le système (changement de version -release-, modification de programmes,...). Un incident survenu le 26/09/1999 en donne un magnifique exemple...





2.2-Les causes spécifiques :

(liste non exhaustive)

(rappelons au préalable, que par abus de langage, nous appelons pseudo-numéro de siècle les deux premiers caractères du numéro d'une année à quatre chiffres)





2.2.1-Le pseudo-numéro de siècle maltraité :




2.2.1.1-Le pseudo-numéro de siècle perdu :

Il a été assez systématiquement ignoré (ainsi l'année 1997, par exemple, sera connu comme étant 97). C'est le cas du numéro de Sécurite Sociale en France ; en ce qui concerne ce dernier, alors qu'il est destiné à identifier de façon biunivoque tous les français au long de leur vie, le choix qui a été fait de coder l'année sur deux chiffres constitue un manque de vue à long terme (il est difficile d'imaginer que ses concepteurs ne croyaient pas que ce format serait destiné à durer très longtemps ; mais il faut se replacer, comme pour les programmeurs des temps "heroïques", dans le contexte technologique de l'année 1941, lorsque René Carmille mis en place ce numéro, alors que la mécanographie était utilisée et imposait des contraintes extremêment sévères...).


2.2.1.2-Le pseudo-numéro de siècle figé :

De façon à ce qu'il puisse malgré tout apparaître lorsque cela est nécessaire, il est souvent ajouté a posteriori et de façon statique (ainsi un "19" sera edité devant les 2 chiffres de l'année).


2.2.1.3-Le pseudo-numéro de siècle "fourre-tout" :

Un emplacement peut lui être réservé, mais malheureusement il peut ne pas être systématiquement exploité (cas vécu dans une grande banque française pour laquelle 2000-1=2099) ou encore être utilisé à d'autres fins.


2.2.1.4-Le format des dates :

Suivant certains critères (géographiques, économiques,...), les différentes composantes d'une date peuvent apparaître dans des ordres différents. Ainsi "XX/YY/ZZ" pourra être interprété comme étant "AA/MM/JJ" ou "JJ/MM/AA" suivant les cas ("AA" désigne l'année sur 2 chiffres, "MM" le mois et "JJ" le jour). De nombreux logiciels sont amenés à déterminer automatiquement l'ordre à utiliser en comparant "XX" à "31" : si "XX" est strictement supérieur à 31, c'est le format "AA/MM/JJ" qui est choisi et dans le cas contraire, c'est le format "JJ/MM/AA" qui l'est ; ainsi "20/03/97" sera interprètè comme signifiant "20/03/??97" (notons au passage que cela ne résoud pas le problème de l'ambiguïté sur le pseudo-numéro de siècle, "20/03/97" signifiant peut-être "20/03/1897"). Mais que signifie alors "10/03/05" : "10/03/??05", "05/03/??10", ou encore autre chose ?




2.2.2-Les dates et les années inaccessibles :

De nombreux logiciels, lorsqu'ils rencontrent dans un fichier certaines années (par exemple "00" ou "99") ou certaines dates particulières (par exemple "9/9/99") considèrent qu'elles ne font pas partie d'une date et sont en fait des indicateurs spécifiques (de fin de fichier, d'espace libre ou à libérer, d'erreur,...). Les dates ou les années correspondantes sont donc inaccessibles. Ainsi, des 1999, des anomalies liées à ceci pourraient apparaître...

Effectivement, au cours des premiers jours de 1999, la police des frontières suédoise a été dans l'incapacité de délivrer des passeports dits provisoires dans les trois aéroports internationaux du pays : le système informatique correspondant ne reconnaissait pas l'année [19]99 !

Malgré tout, ce problème ne concerne que des systèmes anciens, voire obsolètes ; il ne devrait donc avoir aucunes conséquences visibles...




2.2.3-La capacité limitée :

La date courante (ainsi que l'heure...) est déterminée à l'aide d'un compteur incrémenté automatiquement et de façon périodique. Bien souvent ce compteur a une capacité très limité ; lorsqu'il déborde, c'est un retour vers le passé. Un tel exemple est rencontré avec les récepteurs 'GPS' qui utilisent un compteur de semaines sur 10 bits qui (repassera) est repassé a 0 dans la nuit du 21/08/1999 au 22/08/1999 -Electronic Design 04/11/1996 page 18, Datamation 06/1997 page 31- !

Pour bien comprendre de quoi il s'agit, rappelons que le système 'GPS' [Navstar Global Positionning System] a été développé il y a une vingtaine d'années à l'initiative du Pentagone. Il permet de connaître de façon précise la position d'un point quelconque par rapport à la Terre (notons au passage que cette précision dépend de plusieurs facteurs, et en particulier de la nature civile ou militaire des applications). Pour ce faire, elle utilise (à la fin des années mille neuf cent quatre-vingt dix) :


• Une constellation de 31 (24 en l'an 2000) satellites en orbite à 10900 miles nautiques dans six plans inclinés à 55 degrés sur l'équateur ; leur période orbitale est de douze heures.
• Cinq stations au sol :
  
  
  • Iles Hawaii,
  • Ile de l'Ascension,
  • Diego Garcia,
  • Kwajalein et
  • Colorado Springs
  
  les surveillent en permamence afin de connaître, en particulier, les infimes déviations par rapport aux "plans de vol" théoriques.
• Pour connaître sa position, un mobile quelconque doit disposer d'un récepteur 'GPS' qui reçoit en permamence, de tous les satellites "en vue", des séquences de code "pseudo-aléatoires" différentes pour chaque satellite (ce qui permet de les identifier) et indiquant les dérives de chacun d'eux par rapport à leur position théorique. Chaque récepteur est capable de déterminer le retard à la réception de ces messages ; ce retard dépend de la distance parcourue, des perturbations inhérentes à la propagation du signal et de brouillages volontaires destinés à réduire la qualité (ceux-ci, destinés à garantir aux militaires américains une meilleure précision qu'aux autres utilisateurs, ont été supprimés par le gouvernement des Etats-Unis le 01/05/2000). Ce retard est ensuite converti "simplement" en une distance (celle qui sépare le récepteur du satellite correspondant). Connaissant les distances à 3 (et de préférence à 4) satellites, il est "aisé" géométriquement de calculer la position du récepteur par rapport à ces satellites (notons au passage que, comme bien souvent, le diable est dans les détails ; ce calcul géométrique n'est donc pas aussi simple que cela, loin s'en faut : en effet, d'une part les Relativités Restreinte et Générale -qui par rapport à un observateur terrestre ralentissent et accélèrent respectivement les horloges embarquées de très haute précision, "filles" de la Mécanique Quantique- ne peuvent être ignorées et d'autre part le milieu de propagation des ondes électromagnétiques est inhomogène et turbulent...). Pour connaître ensuite la position par rapport à la Terre, il suffit de déterminer la position des satellites par rapport à la Terre. C'est là que la date et l'heure interviennent. Chaque récepteur contient donc un almanach programmé qui utilise, en particulier, un compteur de semaines dont la capacité est limitée à 1024 (de 0 à 1023) ; cette limite est des plus "mystérieuses" et semble bien difficile à justifier de façon rationnelle.

Le passage de 1023 à 0 (appele GPS week roll over) aura lieu le 21/08/1999 à 23:59:47 UTC. Il convient de noter que ceci est parfaitement documenté dans les spécifications initiales du 'GPS' (ICD-GPS-200, paragraphe 3.3.4b). C'est donc à chaque fabricant de récepteur qu'il revient de gérer ce problème. Il semblerait que cela soit réalisé correctement dans les récepteurs "haut de gamme", mais que la situation soit beaucoup plus floue en ce qui concerne les produits "grands publics". Les conséquences seraient alors de deux types : d'une part des erreurs grossières de localisation et d'autre part des transmissions de dates erronées à d'éventuels équipements périphériques connectés aux récepteurs 'GPS' (voir l'actualité du 23/08/1999).

Le bug de l'An 2038 : Notons au passage que les systèmes UNIX seront eux aussi, a priori, victime d'un tel problème le 19/01/2038 à 03:14:07 UTC (la date de référence d'UNIX étant le 01/01/1970 à 00:00:00), lors du débordement du compteur du nombre de secondes écoulées depuis le 01/01/1970. Ce compteur est actuellement, dans la plupart des systèmes UNIX, un entier signé sur 32 bits (time_t). En 2038, tous les systèmes UNIX seront-ils 64 bits ? Evidemment, il s'agit ici d'un problème logiciel ; mais à celui-ci peuvent venir se greffer (éventuellement plus tôt : le 31/12/1999 par exemple) d'autres problèmes, de nature matérielle : ce pourrait ainsi être le cas de PCs sous UNIX disposant d'une horloge temps réel "non compatible". Pour la petite histoire, l'un de mes ordinateurs (une Origin 200 Silicon Graphics, dont les qualités, les performances, la fiabilité,... ne sont pas ici mises en cause), après une mise hors-tension le 13/03/1998, s'est retrouvé, lors du redémarrage, à la date du 12/03/1998, considérant qu'il y avait eu en 1998 un 29 février ! La date dans un ordinateur, ce n'est pas quelque chose d'aussi simple que la logique et l'intuition le laisseraient supposer...

Enfin, remarquons que ce problème se retrouve aussi dans le format des zones de mémoire destinées à stocker des données dont la taille peut être amenée à changer au cours du temps. Or de telles données sont omniprésentes : c'est ainsi le cas des numéros de téléphone (il est évident que le système actuel est très insuffisant par rapport aux évolutions prévisibles) ou encore celui des identifiants d'individu (le numéro INSEE en France)...




2.2.4-Les chaînes de caractères numériques ne sont pas des nombres :

Il n'est pas possible de faire, sans précautions, des opérations arithmétiques sur des chaînes de caractères. Par exemple, en utilisant le code ASCII,

                    "1998"+1 = "1999"

car, "par chance" :

                    "8"+1 = "9"

(le code du caractère "9" suit celui du caractère "8") mais, en itérant cette opération :

                    "1999"+1 = "199:"

et non pas "2000", car :

                    "9"+1 = ":"

(le code du caractère ":" suit celui du caractère "9" et la notion de "retenue" n'existe pas). Ce problème a déjà été rencontré avec des systèmes de cartes bancaires en Italie, à la fin des années mille neuf cent quatre-vingt.




2.2.5-Les années bissextiles (l'an 2000 est une année bissextile) :

La durée d'une révolution de la Terre autour du Soleil n'étant pas un nombre exact de jours (365.2422), il est nécessaire d'introduire de temps en temps des années exceptionnelles (dites bissextiles), d'une durée de 366 jours, afin de maintenir en synchronisme notre calendrier avec les événements astronomiques. Le calendrier grégorien actuellement en vigueur a été défini en 1582 par le Pape Grégoire XIII. Afin de compenser les anomalies du calendrier Julien qui le précéda (lui-même établi en 46 avant notre ère, sous le règne de Jules César), il fallu supprimer un certain nombre de jours ; c'est ainsi que lors de son entrée en vigueur à Rome, au jeudi 4 octobre 1582 succéda le vendredi 15 du même mois. Mais tous les pays ne réalisèrent pas cette opération simultanément : par exemple, en France, au dimanche 9 décembre 1582 succéda le lundi 20, alors qu'en Angleterre, cette opération eu lieu beaucoup plus tard et au 2 septembre 1752 succéda le 14 septembre.

Au passage, cela explique aux utilisateurs des systèmes UNIX (et Linux évidemment...) pourquoi la commande :

                    cal 9 1752

donne un mois de septembre "raccourci" :

                       September 1752
                     S  M Tu  W Th  F  S
                           1  2 14 15 16
                    17 18 19 20 21 22 23
                    24 25 26 27 28 29 30

et que :

                    cal 2 1700

donne un mois de février de 29 jours :

                       February 1700
                     S  M Tu  W Th  F  S
                                 1  2  3
                     4  5  6  7  8  9 10
                    11 12 13 14 15 16 17
                    18 19 20 21 22 23 24
                    25 26 27 28 29

alors que suivant le calendrier grégorien, l'année 1700 n'est pas bissextile (et ne le fut pas en France).

C'est pour la même raison que si l'on s'intéresse aux dates de naissance et de mort d'Isaac Newton on trouve soit 25/12/1642-20/03/1727 (calendrier julien), soit 04/01/1643-31/03/1727 (calendrier grégorien)...

Dans le calendrier grégorien, sont bissextiles les années divisibles par 4, sauf si elles sont divisibles par 100 ; elles sont alors malgré tout bissextiles si elles sont de plus divisibles par 400. Ce dernier critère est bien souvent ignoré, faisant croire ainsi que l'an 2000 n'est pas une année bissextile ; indiquons donc de nouveau et sans ambiguïté que l'an 2000 est une année bissextile. Certaines anciennes versions d'Excel présenteraient ce défaut.

Le pseudo-programme suivant permet de déterminer la nature d'une année A :

                    si        (A est divisible par 400) alors
                              {
                              A est bissextile;                                                     (Exemple : 2000)
                              }
                    sinon
                              {
                              si        (A est divisible par 100) alors
                                        {
                                        A n'est pas bissextile;                                     (Exemple : 1900)
                                        }
                              sinon
                                        {
                                        si        (A est divisible par 4) alors
                                                  {
                                                  A est bissextile;                                 (Exemple : 1996)
                                                  }
                                        sinon
                                                  {
                                                  A n'est pas bissextile;                           (Exemple : 1998)
                                                  }
                                        }
                              }

en supposant l'année A supérieure à une certaine valeur (1582, 1752,...) suivant le contexte. On notera que les trois valeurs numériques {4,100,400} proviennent évidemment de l'approximation suivante :

                                                        1      1       1
                    365.2422 - 365 = 0.2422 ~ 0.2425 = --- - ----- + -----
                                                        4     100     400

ou 0.2422 est l'excès de l'année astronomique sur l'année calendaire.

Etant donné que l'approximation suivante :

                                                         1      1       1       1
                    365.2422 - 365 = 0.2422 ~ 0.24225 = --- - ----- + ----- - ------
                                                         4     100     400     4000

est encore meilleure, certaines éditions de l'Encyclopedia Britannica ont indiqué, par erreur semble-t-il, que les années divisibles par 4000 (l'an 4000, par exemple) devraient être bissextiles (alors que le signe "-" qui précède 1/4000 implique le contraire). S'il en était ainsi, un quatrième test devrait être placé avant les trois précédents ; mais il faut bien avouer que ses effets seraient bien lointains...

Il convient de noter que sur les systèmes n'utilisant que deux chiffres pour l'année, il est évident que seul le test de divisibilité par 4 peut être utilisé ; il est alors correct si '00' signifie '2000', mais ne l'est plus si cette valeur signifie '1900' (puisque '1900' est divisible par 100 sans l'être par 400). Les solutions apportées à l'absence du pseudo-numéro de siècle (ajouter ce pseudo-numéro, utiliser une année dite pivot,...) devront donc prendre ce phénomène en compte...

Ceux qui ignorent la définition complète de ce qu'est une année bissextile sont pardonnables s'ils ont utilisé la définition donnée par le dictionnaire Le Petit Robert dans son édition de 1976 ; en effet, il est possible d'y lire à la page 169 :


• BISSEXTILE : Se dit de l'année qui revient tous les quatre ans et dont le mois de février comporte 29 jours.

Ainsi, seul le premier des trois critères y apparait (la périodicité de quatre ans) mais, malheureusement de façon incomplète (en omettant d'évoquer la divisibilité par 4) permettant ainsi d'imaginer, par exemple, que la suite {1997, 2001, 2005,...} est faite d'années bissextiles ! Puis dans l'édition de 1989 du Petit Robert 1, à la page 189, la phrase les années dont l'expression numérale est divisible par 4 ou 400 (années séculaires) sont bissextiles a été ajoutée. Malheureusement, les critères énoncés sont incomplets et font, par exemple, de l'année 1900 une année bissextile (puisque divisible par 4) ; enfin, ce sont les années divisibles par 100 (et non point par 400) qui sont dites années séculaires. Enfin, dans l'édition de 1994 du Petit Robert, il est possible d'y lire à la page 227 :


• ANNEE BISSEXTILE : année de 366 jours, le 366ieme jour étant le 29 février, qui revient généralement tous les quatre ans.

Ainsi, des définitions très approximatives se sont succédées au cours des années, sans jamais donner la bonne...

Montrons maintenant l'aide plus complète que nous apporte le Dictionnaire Encyclopédique Larousse L1 (edition de 1979) en reproduisant in extenso les définitions nécessaires à la comprehension de cette notion :


• BISSEXTILE : Se dit de l'année de 366 jours (Toute année dont l'expression numérale est divisible par 4 est bissextile : 1960, 1964, 1968, 1972, 1976, 1980, etc... Toutefois les années séculaires ne sont sont pas bissextiles, sauf celles dont les deux premiers chiffres sont divisibles par 4, comme 1600, 2000, 2400, etc...)
• SECULAIRE : Qui a lieu tous les cent ans. Année séculaire, année qui termine le siècle.
• SIECLE : Période de cent années numérotées de 1 a 100, de 101 a 200, de 201 a 300, etc...

Cette définition, plus proche de la vérité est d'une part inutilement compliquée (mais pourquoi faire simple quand il est possible de faire compliqué ?) et d'autre part fausse en toute généralité ; faisons donc quelques remarques :


• Elle fait appel simultanément aux notions de divisibilité et de sécularité, alors que la première de celle-ci suffit pour définir les trois critères.
• Elle référence explicitement la base de numération décimale en faisant reposer le troisième critère sur une décomposition de la date en ses premiers et ses derniers chiffres.
• Enfin, cette définition est fausse en toute généralité puisqu'elle fait reposer le troisième critère sur les deux premiers chiffres de la représentation décimale de l'année et ainsi limite sa portée à des années de quatre chiffres. Par exemple, cette définition fait de l'année 20100 (un futur bien lointain...) une année bissextile (le nombre 20, forme par les deux premiers chiffres est divisible par 4) alors qu'elle ne doit pas l'être (suivant les critères actuels qui en toute logique devraient être remis en cause, puisqu'actuellement les années sont en moyenne trop longues de 0.0003 jours), 20100 n'ètant pas divisible par 400.

La notion de calendrier en général (et d'année bissextile bissextile en particulier) n'est donc pas aussi simple qu'il y parait au premier abord... Même si cela peut paraître hors du sujet, il est bon de signaler qu'au cours des siècles, celui que nous utilisons a subi des évolutions considérables. Ainsi, le commencement de l'année n'a pas toujours eu lieu le premier janvier : à titre d'exemple au cours des douzième et treizième siècles, le jour de l'an coïncidait avec la fête de Pâques, qui étant une fête mobile, ne facilitait pas les choses (c'est à Charles IX que l'on doit en 1564 le choix du premier janvier -en France...- comme jour de l'an) ! La rèponse à la simple question combien de jours se sont-ils écoulés depuis le sacre de Charlemagne est donc loin d'être évidente...


Ainsi, ce qui est communément appelé le bug de l'An 2000 ne se limite pas au problème du passage du 31/12/1999 au 01/01/2000 et ne peut être qualifié de bug au sens strict ! Il est en grande partie le résultat de choix astucieux à une certaine époque et regrettables aujourd'hui. Il est donc la conjonction, en un court laps de temps, d'un certain nombre d'anomalies (et de quelques erreurs -ou bugs-) dans la gestion informatique des dates et il concerne a priori tous les systèmes, qu'ils soient "visibles" ou "invisibles"...





2.3-Les responsables (les coupables ?) :




2.3.1-Les informaticiens :

Les informaticiens (j'en fait partie et j'assume ma part de responsabilité, bien qu'œuvrant dans le monde de l'informatique scientifique où ces problèmes semblent moins préoccupants, bien que...) en premier lieu car ils n'ont pas su voir à long terme les conséquences de leur choix (mais nous sommes tous victimes, malheureusement, de cette déficience ; la pollution ou encore le trou dans la couche d'ozone sont là pour nous le rappeler...) et n'ont peut-être pas eu ensuite la franchise ou le courage d'exposer clairement ces difficultés et leurs conséquences à leurs directions générales. C'est dommage, car l'aspect positif du problème est qu'il implique nécessairement une meilleure connaissance de nos systèmes informatiques et une modernisation de nos infrastructures lorsque l'on se donne le temps d'agir, alors que la précipitation actuelle ne peut conduire qu'à du rafistolage hâtif, désoptimisé et forcément partiellement erroné ; de nouvelles difficultés sont donc à prévoir ultérieurement ! Au passage, que se passera-t-il une fois les obstacles franchis (avec plus ou moins de bonheur) ? Les rafistolages provisoires introduits bien souvent pour les vaincre seront-ils destinés à durer "éternellement" et alors que se passera-t-il, par exemple, dans quelques années avec la notion d'année pivot ? Quels sont ceux qui auront le courage (et les moyens...) de tout remettre à plat ?

Il semble donc juste de dire que les informaticiens des temps heroïques ont finalement (et paradoxalement) moins de responsabilité dans cette malheureuse affaire que ceux d'aujourd'hui, qui ont trop longtemps laissé se dégrader la situation, alors que le mal était bien connu.

Enfin, pourquoi les grandes associations professionnelles (ACM, IEEE,...) n'ont-elles pas donné l'alerte quand il en était temps ? Le problème n'était-il pas assez scientifique ? Est-il honteux de s'intéresser à la maintenance ? Il semble que l'ampleur du problème aurait pu susciter des vocations, par exemple dans le monde de l'Intelligence Artificielle, mais aujourd'hui, il est trop tard...




2.3.2-Les utilisateurs :

Les "gros" utilisateurs de l'informatique (les banques, par exemple) ont eux aussi leur part de responsabilité lorsqu'ils étaient conscients des difficultés à venir : d'une part, ils n'ont pas fait tout le nécessaire dans leurs propres systèmes et d'autre part, ils auraient dû exercer une pression suffisante sur leurs fournisseurs. Ainsi, des systèmes "compatibles" seraient peut-être apparus plus tôt ; ils auraient été alors utilisés par ceux qui étaient moins concernés par ces problèmes et le bug de l'An 2000 se serait peut-être résorbé...




2.3.3-Les média :

Que dire ensuite de la responsabilité des média ? Elle est très certainement considérable : en effet, un événement n'existe que s'il est relaté. Est-il alors concevable que la presse informatique spécialisée, en France particulièrement, n'est abordée en général ce problème qu'au cours des derniers mois, alors que pour beaucoup il est peut-être déjà trop tard ? De plus, l'importance d'un événement est certainement mesurable par le nombre de lignes ou de minutes qui lui est consacré. A titre d'exemple, la maladie de la vache folle a été plus fréquemment et plus longuement présentée que le problème de l'An 2000 au cours des derniers mois. Est-ce à dire que leurs importances relatives sont dans le même ordre ? Rien n'est moins sûr ; en effet, en ce qui concerne nos ordinateurs les conséquences de cette insouciance pourraient être dramatiques et le temps presse : il ne reste que quelques mois pour inventorier, faire les analyses de risque, corriger et tester les millions de systèmes pour lesquels rien n'a encore été fait.




2.3.4-Le monde politique :

Enfin, le monde politique (au niveau international), de par l'ampleur sans précédent du problème, n'est pas non plus lui-même innocent. Lors des précédentes élections législatives françaises, aucun des candidats n'a, à ma connaissance, évoqué ce problème. Or dans notre pays, où le chômage pèse lourdement sur l'économie et sur le moral de nos concitoyens, il est inutile d'ajouter de nouvelles difficultés car, en effet, pour les entreprises qui ne seraient pas prêtes à temps, des catastrophes économiques (et donc sociales) sont à prévoir.

En Europe, n'est-il pas risqué de lancer simultanément le chantier de la monnaie unique (l'Euro)?

En France, la loi sur les 35 heures (et les mesures associées) est-elle compatible avec l'ampleur du travail à réaliser ? Est-il enfin raisonnable d'avoir attendu le 11/02/1998 pour voir Gérard Théry nommé en tant que Monsieur An 2000 ?


Finalement, serions-nous tous responsables ?

3.1-Le retour dans le passé :

L'an [20]00 (par exemple) sera considéré comme étant 1900 (ou encore 1970, 1980,... suivant des choix spécifiques à chaque constructeur).




3.2-Les calculs de durée :

Ils pourront être faux s'il sont faits en ignorant le pseudo-numéro de siècle (par exemple, quelqu'un né en [19]80 aura 99-80=19 ans en [19]99 et, par exemple, 00-80=-80 ans en [20]00).




3.3-Les actions périodiques :

Des actions pourront être entreprises au mauvais moment ; en effet, le 01/01/1900 étant un lundi, 01/01/[20]00 pourra être considéré lui aussi comme un lundi alors qu'il sera en fait un samedi. Des traitements informatiques pourront ne pas avoir lieu, des systèmes de contrôle d'accès pourront faire le contraire de ce que l'on attend d'eux,...




3.4-Les relations d'ordre temporels :

Elles pourront être erronées et considérer que, par exemple, [19]99 > [20]00.




3.5-La durée de vie :

Des documents, des objets,... seront détruits ou recyclés par erreur (par exemple, une sauvegarde du 01/01/[20]00 pourra être considérée comme antérieure à celle du 31/12/[19]99 et sera donc détruite, ou encore, une facture émise en [19]99 et impayée en [20]00 pourra échapper à un système de relance automatique,...).




3.6-L'arithmétique :

Des traitements seront interrompus brutalement car, en effet, des méthodes dites de hash-coding divisent par l'année (pour définir des pointeurs d'accès rapide aux informations). C'est aussi le cas de certains générateurs de nombres aléatoires. Avec l'année [20]00, il y aura donc des divisions par 0 si le pseudo-numéro de siècle est ignoré...




3.7-La génération de noms d'objets :

Il est une pratique courante et utile consistant à donner à des objets (des fichiers en particulier) un nom obtenu par concaténation des différentes composantes de la date (et de l'heure si nécessaire). Ainsi, par exemple, un certain enregistrement créé le 11/07/1997 à 11:40:38 pourra être baptisé "19970711114037". Là encore, si les quatre chiffres de l'année sont utilisés, il n'y a pas de risque de "collisions" (c'est-à-dire des noms identiques créés à des dates différentes) ou de relations d'ordre erronées ; par contre si les deux derniers chiffres sont seuls utilisés, ces risques existent.




3.8-Les conséquences économiques et sociales :

Il est évident que certaines activités sont beaucoup plus sensibles (le commerce, l'assurance, la banque,...) que d'autres (la recherche scientifique, par exemple) aux perturbations liées aux dysfonctionnement de la date. Pour les plus sensibles qui n'auraient pas entrepris les corrections à temps, les conséquences économiques (et donc sociales) à attendre, pourraient être dramatiques.

4.1-Arrêter de n'utiliser que deux chiffres pour l'année !

Lors du développement de nouvelles applications, il est essentiel de coder correctement les années. En ce qui concerne les corrections apportées à d'anciens logiciels, il est clair que malheureusement nous ne disposons ni du temps, ni de la main d'œuvre nécessaire. D'autres solutions doivent donc être mises en œuvre consistant, par exemple, à continuer la manipulation des années sur deux chiffres et à se donner une année '19AA' définie sur quatre chiffres (elle est dite pivot et est en général une année du vingtième siècle) ; ensuite, toute année définie par les deux chiffres 'aa' sera considérée comme étant '20aa' si 'aa < AA' et '19aa' dans le cas contraire. Il est essentiel de bien comprendre que cette solution ne peut qu'être provisoire puisqu'elle ne permet pas d'aller au delà de l'année '20AA'...

Notons au passage, que les spécifications de certains projets très récents contiennent des références explicites au codage des années sur deux chiffres pour de malheureuses raisons de compatibilité !




4.2-Le pseudo-numéro de siècle :

Il convient donc de mémoriser et d'utiliser le pseudo-numéro de siècle, et donc d'étendre de 2 à N octets la mémoire nécessaire au stockage des années. Mais combien doit valoir N ? La valeur de 4 semble raisonnable ; mais alors le problème se reposera en 9999...




4.3-Les fonctions de calcul de date :

Elles doivent être corrigées afin de traiter correctement les années bissextiles, la détermination du nom d'un jour quelconque...




4.4-Les dates inaccessibles :

Il convient de rendre "accessibles" toutes les dates et donc de programmer différemment certaines circonstances particulières (mais n'ayant rien à voir avec la date, comme les fins de fichiers ou les espaces libres...).




4.5-Tout est facile, mais où est le problème ?

5.1-L'ampleur du travail :




5.1.1-Le cauchemar :

Le volume de travail est sans commune mesure avec tout ce que l'on a connu avant, sachant que les opérations correspondantes doivent être menées en parallèle avec les développements en cours (par exemple, l'introduction de l'Euro) et qu'elles possèdent une date d'achèvement immuable (31/12/1999 ou pire, 31/12/1998). Au passage, existe-t-il beaucoup de grands projets informatiques qui se soient terminés en respectant les delais, les budgets et les fonctionnalités ? Il ne reste que très peu de temps ; pour 60% des entreprises américaines concernées, il serait déjà trop tard.

Imaginez un peu que vous deviez compter les grains de sable d'une plage et vous aurez une bonne idée de l'ampleur de la tâche. L'opération de comptage est en soi élémentaire (il suffit de déplacer les grains un à un en faisant '+1' pour chacun d'eux), mais itérée de très nombreuses fois, elle devient vite fastidieuse, source d'erreur et finalement impossible... Mais au fait, comment délimite-t-on une plage ?




5.1.2-Les programmes :

Il y aurait 100.000.000.000 de lignes (de Cobol majoritairement) à examiner dont environ 4% des sources sont irrémédiablement perdus. La conséquence immédiate de l'énormité de ce nombre est l'impossibilité de tout réécrire, ainsi que certains pourraient le suggérer. Il convient donc de corriger et d'adapter ce qui existe...




5.1.3-L'omniprésence :

L'ordinateur est partout (depuis les magnétoscopes jusqu'aux sous-marins nucléaires, en passant par les satellites dont l'accessibilité est réduite...) et ce phénomène n'a fait que s'accentuer exponentiellement depuis l'apparition du micro-ordinateur. Ne pas oublier, donc, les systèmes dits embarqués et l'informatique enfouïe (oui, mais où est-elle ?).




5.1.4-L'effet domino :

Il n'y a pratiquement plus de systèmes isolés : tout communique avec tout. Ainsi, il ne suffit pas d'être soi-même prêt : les autres (fournisseurs, clients, collaborateurs,...) doivent l'être simultanément. D'ailleurs, cette remarque s'applique aussi à tous les systèmes informatiques (même isolés...) puisque, en effet, ils sont tous constitués d'un ensemble en général hiérachisé de sous-systèmes, tant au niveau matériel que logiciel ; il est donc essentiel que tous les niveaux soient prêts et compatibles...





5.2-Il n'y a pas de solution miracle !

Même si un programme capable de corriger toutes les anomalies relatives aux dates à l'intérieur d'un autre programme existait, la phase d'inventaire préliminaire ne pourrait être évitée...


5.3-De la maintenance :

Ce n'est qu'une "simple" opération de maintenance (l'investissement n'est donc pas productif) destinée à prolonger la durée de vie de programmes obsolètes ("acharnement thérapeutique") qu'il faudra de toute façon réécrire un jour ou l'autre !

La situation est similaire à celle d'un automobiliste dont la voiture serait une véritable épave et qui, malgré tout, devrait investir une somme colossale pour réaliser les réparations nécessaires uniquement à lui faire parcourir les quelques kilomêtres qui la sépare d'une casse...




5.4-La methode :




5.4.1-Inventorier et évaluer les risques :

Il convient de faire un inventaire préliminaire des logiciels (mais aussi des matériels divers et variés, la date étant partout : dispositif de sécurité, systèmes de communications,..., magnétoscopes,...) concernés. Malheureusement, bien souvent cet "état des lieux" n'existe pas, et réserve bien des surprises, en particulier au niveau du volume du patrimoine... Etant donnée l'urgence, cet inventaire doit s'accompagner d'une évaluation des risques associés à chacun des "objets" rencontrés, ainsi que des conséquences des non-corrections (par exemple au niveau de la survie d'une entreprise). Il est évident que tout ne pourra pas être prêt à temps : il faut donc se préparer à des anomalies et mettre en place des plans de secours...




5.4.2-Examiner :

Il convient ensuite d'examiner en détail chaque "objet" inventorié, mais malheureusement :




5.4.2.1-L'automatisation est difficile :

En effet, il y a fréquemment absence de structures et de vocabulaires communs, ainsi qu'existence de méthodes folkloriques et inacceptables (par exemple utiliser {pierre,paul,marie} à la place de {année,mois,jour}-).



5.4.2.2-La documentation :

Elle est souvent mauvaise, incomplète, fausse, voire inexistante...


5.4.2.3-A propos des sources des programmes :

Environ 4% de ceux-ci seraient perdus ; pour les 96% qui existent encore, il apparait que certains d'entre-eux ne sont pas à jour, les exécutables correspondants ayant été parfois corrigés directement en binaire !




5.4.3-Corriger :




5.4.3.1-La compatibilité :

Il est impossible de faire toutes les modifications simultanément : des interfaces (provisoires) assurant la compatibilité avec les versions antérieures devront donc être mises en place.

Mais des problèmes de compatibilité vont aussi se rencontrer lors de la compilation des versions corrigées avec les outils d'aujourd'hui, moins laxistes que ceux d'hier, d'ou de nouvelles corrections en perspective...



5.4.3.2-Gérer les risques :

Des priorités devront être fixées en déterminant quelles sont les applications réellement vitales (pour l'homme et/ou pour l'entreprise) et celles qui le sont moins. Mais, malheureusement ici, le risque 0 n'existe pas ; les conséquences des corrections impossibles à effectuer (dans le temps imparti) doivent être évaluées.

Il ne faudra pas oublier non plus qu'il certainement préférable d'avoir en face de soi un système qui ne fonctionne plus du tout, qu'un système qui semble fonctionner correctement, alors qu'il produit des résultats erronés ou provoque des actions incorrectes.



5.4.3.3-Les compétences Cobol :

Mais avons-nous suffisamment de compétences (des retraités du Cobol sont actuellement réembauchés) et comment ne pas se faire débaucher celles que l'on possède à l'approche de la date (des dates) fatidique(s) ?



5.4.3.4-Comment et quoi tester ?

Comment pouvoir tester exhaustivement la compatibilité "An 2000" tout en garantissant que l'ensemble des fonctionnalités est maintenue (tests dits de non régression) ? Mais d'ailleurs, a-t-on le temps de tester quand on sait que les tests représentent au moins 50% du temps nécessaire à un projet ? Il ne faudra pas oublier au passage que les jeux de tests doivent être eux-mêmes corrigés. Il conviendra donc de simuler et de mettre en place des environnements de tests complets et indépendants des systèmes opérationnels. Mais alors, comment intégrer les développements réalisés simultanément ? En plus des dates sensibles "évidentes" :


• Le 01/01/2000 (qui, rappelons-le au passage, ne correspond pas à l'entrée dans le troisième millénaire),
• Le 29/02/2000,

il conviendra de ne pas en oublier d'autres, et par exemple :


• Le 09/09/1999 dans le cas où la date "9/9/99" joue un rôle spécifique, en notant au passage que les systèmes à risque concernant cette date peuvent montrer des signes de dysfonctionnement aussi bien avant, qu'après...
• Le 26/09/1999 dans le cas où des nombres entiers du type 'AAAAMMJJhhmmss' (ou 'AAAA', 'MM' , 'JJ' , 'hh' , 'mm' et 'ss' reprèsentent respectivement l'année, le mois, le jour, l'heure, les minutes et les secondes) sont manipulès, par exemple, sous UNIX.
• Le 03/01/2000 qui sera le premier jour ouvrable de l'an 2000,
• Le 01/03/2000 qui sera un mercredi et non pas un mardi (puisque le 29/02/2000 existe),
• Le 10/10/2000 qui est le premier jour qui nècessite rèellement 8 caractères pour être mémorisé complètement -après la "discontinuité" de la Saint-Sylvestre 1999-,
• Le 31/12/2000 qui sera le trois-cent soixante-sixième jour de l'an 2000,
• etc...

Cet inventaire est malheureusement non exhaustif...

Il convient de faire une remarque très importante en ce qui concerne ces dates. Certaines correspondent effectivement à des jours où des risques plus ou moins importants existent : c'est principalement et évidemment le cas du 01/01/2000. D'autres, par contre, peuvent provoquer des anomalies n'importe quand (avant, comme après) et non pas uniquement ce jour-là : par exemple, le 09/09/1999 peut se manifester dès que cette date est introduite dans un système pour lequel ce défaut existerait encore.



5.4.3.5-Les conséquences :

Il est bien connu que des corrections (même mineures) d'un logiciel peuvent avoir des conséquences catastrophiques (des effondrements complets de réseaux de télécommunications ont déjà eu lieu pour ces raisons...). Cette opération n'est donc pas sans danger : environ 10% des corrections devraient introduire de nouveaux défauts.



5.4.3.6-Ne pas oublier :

L'informatique n'étant pas faite que de logiciel, du matériel devra être aussi mis a jour. Dans le cas de l'informatique enfouïe cela peut constituer un véritable casse-tête. En particulier, nombreux sont les systèmes qui utilisent des micro-processeurs anciens (INTEL 8051 8 bits,...) associés à des horloges temps réel ignorant le pseudo-numéro de siècle (DS1287,...), soudés directement sur des cartes de circuits imprimés et programmés en assembleur sans qu'aucune documentation ne soit disponible... Ces systèmes sont, par exemple, utilisés pour contrôler des processus industriels tout en vérifiant la bonne régularité des opérations de maintenance à l'aide de la date et agissant en conséquence...

Enfin, il ne faudra pas négliger les formulaires papier, le format des écrans de saisie, la sensibilisation et la formation des personnels concernés,...




5.5-Les problèmes juridiques et autres :




5.5.1-Le ralentissement des applications :

Ces corrections, devant être faites de façon hâtives, vont désoptimiser et ralentir les chaînes de traitement actuelles ; au moins 20% est à prévoir, mais les plus pessismistes n'hésitent pas à donner des estimation plus élevées. Ainsi, les capacités de traitement des centres de calcul devront être augmentées ; cela est vrai aussi de l'espace disque...




5.5.2-Qui va payer ?

L'addition serait de l'ordre de $1.000.000.000.000, sachant que les prévisions dans ce domaine sont toujours sous-estimées. Les assureurs ont donc de multiples raisons de s'inquiéter (en tant qu'utilisateurs de l'informatique, mais aussi de par la fonction qu'ils remplissent, les dédommagements étant actuellement évalués a $2.000.000.000.000...).




5.5.3-Qui sera responsable des inévitables dégats ?

Le Journal Officiel des Communautés Européennes a publié le 07/08/1985 dans son volume L210 (page 29) la directive numéro 85/374/CEE (au passage, il est "amusant" de noter que ce numéro contient "85" et non pas "1985"...) relative au rapprochement des dispositions législatives, réglementaires et administratives des Etats membres en matière de responsabilité du fait des produits défectueux. L'article 11 indique :

Les Etats membres prévoient dans leur législation que les droits conférés à la victime en application de la présente directive s'éteignent à l'expiration d'un délai de 10 ans à compter de la date à laquelle le producteur a mis en circulation le produit, même qui a causé le dommage, à moins que durant cette période la victime n'ait engagé une procédure judiciaire contre celui-ci.

Le CIGREF (Club Informatique des GRandes Entreprises Françaises) et le CLUSIF (CLUb de la Sécurité Informatique Français) préconisent de fixer comme date "charnière" entre responsabilité clent et responsabilité fournisseur le 01/01/1990. Ainsi, peut-être les fournisseurs sont-ils responsables en ce concerne les produits commercialisés après cette date. En tout cas, cela donnera du travail aux avocats et aux assureurs (au passage, l'objet de l'assurance n'est-il pas d'intervenir pour des sinistres de nature accidentelle et non lorsque leur réalisation ne comporte aucun caractère aléatoire ?)...

La France s'est alignée sur cette directive le 19/05/1998.

Et lorsque les mises à jour des logiciels d'une entreprise sont externalisées, cette dernière ne court-elle pas des risques par exemple au niveau de l'espionnage industriel, ou encore en ce qui concerne sa sécurité future (installation de chevaux de Troie,...) ?


5.5.4-L'Europe :

Le problème du passage à la monnaie unique ne vient pas simplifier le problème. Un récent rapport de la Computing Services and Software Association de Grande-Bretagne affirmait que les échéances d'introduction de l'Euro pourrait ne pas être respectées. A cause des problèmes informatiques, cinq années de retard sont prévisibles (voir IT Issues Could Threaten European Monetary Union dans IEEE Computer, 02/1997, page 19). Ceux qui ont défini le calendrier de la mise en place de l'Euro, connaissaient-ils les problèmes ici décrits. Si non, il y a négligence et si oui, il y a incompétence ; il semble en effet difficile -voire impossible- de mener à bien ces deux tâches simultanément... La précipitation et la surcharge ne peuvent que conduire à un travail bâclé et nous font donc courir des risques mal evalués. À quoi bon une monnaie unique mise en place précipitamment dans une Europe mise à mal par une informatique chaotique ? Il aurait peut-être été sage de sérier les problèmes...




5.5.5-La France :

Elle semble en retard (par rapport à la Grande-Bretagne et aux USA principalement). L'information "grand public" fait défaut ; qui avertit les PME et PMI ? La nommination de Monsieur An 2000 (Gérard Théry) le 11/02/1998 n'est-elle pas un peu tardive ? Ou en sont donc nos entreprises, notre administration, notre défense nationale,... ? Enfin, la loi sur les 35 heures ne va-t-elle pas réduire la capacité de travail des équipes et des sociétés en charge de ces problèmes (notons au passage que sa mise en œuvre dans les entreprises pose, de plus, des problèmes informatiques complexes, ce qui ne simplifie rien...) ? Des mesures d'assouplissement ne seraient-elles pas alors souhaitables dans ce contexte ?





5.6-Quelques exemples :




5.6.1-La Royal Bank of Canada :

• 18.000.000 de lignes de code,
• 25.000 clients avec lesquels des données sont échangées en permanence.





5.6.2-L'Union Pacific (après la fusion avec le Southern Pacific) :

• 36.000 miles de voies,
• 53.000 employés,
• 7.100 locomotives,
• 146.000 wagons,
• 2.000 trains par jour,
• 7000 programmes Cobol,
• 12.000.000 de lignes,
• 200.000 heures de conversion.

6.1-La prise de conscience :

Prendre connaissance de la réalité et de l'importance de ce problème.




6.2-La sensibilisation :

Sensibiliser et faire passer le message à ceux qui sont dans l'ignorance ou qui sous-estiment le problème. Nombreux sont encore ceux qui ne voient là qu'une "invention" des constructeurs ou des éditeurs de logiciels, voire une plaisanterie ; pour illustrer ce point, voici la copie in extenso et sans retouche, d'un courrier électronique anonyme (c'est-à-dire non signé et dont l'adresse n'est pas "explicite") recu le 24/11/1998 :

Il ne doit vraiment pas y avoir beaucoup à faire à l'école polytechnique pour que quelqu'un tartine autant de pages pour ça... Surtout que la plupart des circuit d'horloge des ordinateurs sont prévus pour fonctionner de 1980 jusqu'aux environs de 2020: les concepteurs de circuits intégrés sont tout de même pas tout à fait stupides.

Heureusement, ce type de message est exceptionnel...

Nous sommes tous concernes et personne n'est à l'abri !




6.3-Vérifier et maintenir notre environnement :

Vérifier nos outils informatiques (en particulier au niveau gestion, comptabilité, sauvegardes, activités automatiques et périodiques -sécurité, sauvegardes,...-, licenses de logiciels, programmes divers -commande make sous UNIX,...-), mais aussi nos instruments de mesure et en fait tout ce qui peut contenir de l'informatique (visible ou non...). Enfin, ne pas négliger l'aspect coopératif de nos activités (ne polluons pas et ne soyons pas pollués).

Attention, je ne dis pas ici que ces "outils" auront des problèmes ! Non, je dis simplement que nombreux sont ceux qui utilisent et manipulent des dates (parfois de façon fort complexe) et ce, même en dehors du monde de la gestion (par exemple dans le milieu scientifique).

A titre d'illustration de ce dernier point, voici une petite anecdote personnelle : l'environnement de travail que j'ai développé, pour supporter ma recherche, repose sur UNIX. La date dite de dernière modification d'un fichier est pour moi une information essentielle car, en effet, elle m'a permis de mettre en place un dispositif assurant la mise à jour automatique, à partir d'un ordinateur dit de référence, de toutes les autres machines dont j'ai besoin. La commande UNIX touch est, dans ces conditions, essentielle. Malheureusement en release 5.3 du système IRIX de Silicon Graphics que j'utilise, cette commande n'autorise la spécification des années que sur deux chiffres "AA", interprétés comme signifiant "19AA" ; au-delà du 31/12/1999, elle fera "remonter dans le passé" les fichiers qu'elle "touchera". Il n'y a aucune solution de contournement de cela, si ce n'est d'installer des patches ou de changer de release, ces deux solutions demandant un espace disque dont je ne dispose pas ! La solution que j'ai dû adopter a consisté à programmer entièrement une nouvelle commande touch acceptant les années sur quatre chiffres "AAAA".

Enfin, il ne faudra pas oublier que nos outils informatiques ne possèdent pas, loin s'en faut, une fiabilité absolue. Des sauvegardes (ou backup) doivent être effectuées très périodiquement (par exemple quotidiennement en cas de travail intensif). Cela est encore plus vrai à l'approche des dates fatidiques. Ces sauvegardes doivent être systématiquement vérifiées après leur génération ; en effet, il n'y a rien de pire que d'avoir besoin de restaurer un système et de découvrir alors que les sauvegardes sont vides ou illisibles. Ainsi, il faut les valider, mais aussi ne pas utiliser un seul support, mais plusieurs en permutation circulaire et les disperser géographiquement. Le bug de l'an 2000 créant des risques supplémentaires au niveau des dates et ces dernières faisant partie des sauvegardes en général, d'autres précautions peuvent être envisagées : par exemple, lors de la disponibilité de plusieurs machines, consacrer l'une d'elle (de préférence celle qui sera considérée comme la plus fiable et qui disposera de suffisamment d'espace sur ses disques) au support d'une sauvegarde par duplication des fichiers des autres machines. Ensuite, cette machine ne devra plus être utilisée et il sera peut être même utile de retarder son horloge interne d'un an (ou plus) afin qu'elle ne subisse les eventuels effets du bug de l'An 2000 que bien plus tard.




6.4-Interroger :

Il convient d'interroger nos fournisseurs sur l'état actuel de leurs produits et sur leurs projets dans ce domaine, sans se contenter d'affirmations hâtives (faire des tests).




6.5-Les contrats :

Il sera plus que souhaitable de prévoir dorénavant une clause "Conformité An 2000" dans les futurs contrats (informatiques et autres...). L'IEEE Computer Society prépare actuellement une définition standard des technologies compatibles An 2000 (voir Year 2000 compliance dans IEEE Micro, 09/1997, page 6). Dans le numéro de mars 1998 de la revue IEEE Computer, une proposition de standard définit la compatibilite An 2000 comme :

Une techonologie, incluant (mais sans être limitée à) les technologies de l'information, les systèmes embarqués, ou tout autre système électro-mécanique ou contenant des processeurs, lorsqu'elle est utilisée en accord avec sa documentation, capable de traiter, de fournir et/ou de recevoir, le tout avec précision, des données de type date du vingtième et du vingt-et-unième siècles, ainsi que des années 1999 et 2000, incluant le calcul des années bissextiles, à condition que tout autre technologie échange correctement des données de type date avec elle.

Rappelons au passage, puisqu'il est question ci-dessus d'une utilisation conforme aux documentations, que ces dernières doivent être fournies en français, pour les matériels, les logiciels,... vendus en France.

Remarquons que cette proposition néglige un point qui semble très important : celui de la "durée de vie de la compatibilité". Or, des solutions du type année pivot n'ont qu'une durée de vie limitée. D'autre part, au-delà de la définition de la compatibilité, les vraies difficultés ne situent-elles pas au niveau des tests nécessaires (et suffisants...) pour la garantir ?

Notons enfin, que cette cette proposition, comme son nom l'indique, n'essaye pas de voir plus loin que les problèmes actuels, alors qu'il est évident que d'autres difficultés sont à venir ; il est grand temps de proposer une mémorisation et une manipulation correctes des dates dans nos ordinateurs !




6.6-Etre plus vigilant :

À partir de maintenant, il conviendra d'être plus attentif. Par exemple, sans sombrer dans une paranoïa excessive, il est suggéré de surveiller plus attentivement les relevés divers que nous recevons (factures, relevés bancaires,...) et de conserver les documents imprimés correspondants.




6.7-Suggérer :

Il serait temps de normaliser au niveau international la représentation de la date et de profiter de l'occasion pour l'implémenter progressivement dans l'ensemble des applications anciennes et la rendre obligatoire dans tout nouveau développement. Notons au passage qu'il est finalement peu rationnel d'utiliser des "unités" de temps, telles l'année (365 ou 366 jours) et le mois (28, 29, 30 ou 31 jours), dont la définition soit variable (que dirait-on d'un mêtre qui changerait suivant le lieu où la mesure est faite ?).

Dans ces conditions, pourquoi ne pas mémoriser et manipuler la date sous la forme d'un simple compteur signé sur 32 bits (ce qui permet de compter de -2147483648 à +2147483647) par rapport à une date de référence ? Celle-ci pourrait être le 01/01/0001 UT ou encore le 20/12/1582,... ; son choix devrait être fait en tenant compte de nombreuses contraintes -religieuses, nationales,...- et par exemple en la choisissant aléatoirement dans un passé relativement récent : dans le dix-huitième ou le dix-neuvième siècle. Le nombre de jours écoulés depuis étant inférieur à 732000 (=366*2000) et donc largement compatible avec la capacité de ce compteur et les besoins futurs (il convient de remarquer que d'une part il pourrait inclure l'heure universelle et que d'autre part ce compteur serait indépendant de toute réforme possible du calendrier -inévitable, car l'actuel calendrier grégorien, malgré la définition des années bissextiles, définit des années trop longues, en moyenne, de 0.0003 jours-, et par exemple un retour au calendrier révolutionnaire, alors que cela est évidemment faux actuellement...) ! Ensuite, deux fonctions de conversion (compteur-->date et date-->compteur) devraient être normalisées à partir des spécifications strictes du calendrier actuellement utilisé, en refusant toute hypothèse simplificatrice ; la plupart des formats de date en service seraient proposés et un argument facultatif, présenté sous une forme voisine des formats de la fonction C 'printf()', permettrait toutes les conversions imaginables. Enfin, un jeu de tests, lui aussi normalisé, devrait être fourni simultanément...

7-L'AN 2000 AU JOUR LE JOUR (L'actualité, Mes principaux rendez-vous, Questions diverses, Quelques références utiles) :

• Le 08/01/1997, le Dominion, journal néo-zélandais, annonçait que la production d'aluminium avait été brutalement interrompue à minuit, le 31/12/1996. Le responsable en fut l'un des ordinateurs de contrôle qui "ignorait" que l'année 1996 était bissextile. Deux heures plus tard, à cause du décalage horaire, un incident identique eut lieu en Tasmanie. Dans les deux cas, le redémarrage des installations a couté plus d'un million de dollars.



• Le 19 février 1998, la ville d'Auckland en Nouvelle-Zélande a été complètement privée d'électricité à la suite de la mise hors-service successive de quatre cables d'alimentation haute-tension (110KV), celle-ci ayant été provoquée par la sur-consommation liée à un été particulièrement chaud. Le retour à la normale a demandé plusieurs semaines pendant lesquelles la situation a été particulièrement critique. Même si les causes de cet incident n'ont a priori rien à voir avec les problèmes informatiques qui viennent d'être exposés, celui-ci nous rappelle malgré tout que ce qui semble si bien fonctionner peut à tout moment se gripper et rendre notre avenir bien précaire. Enfin, n'oublions pas à ce propos la forte dépendance de la distribution d'énergie vis à vis de l'informatique (enfouïe principalement) et réciproquement...



• Le 20 février 1998, Gérard Théry (Directeur Général des Télécommunications dans les années soixante-dix) a été nommé Monsieur An2000. Sa mission consiste à mobiliser rapidement la communauté nationale, à inciter les administrations et les principaux organismes à prendre les dispositions nécessaires et enfin, à proposer les mesures destinées à traiter le problème de la vente des produits non compatibles.



• En mars 1998, la COB (Commission des Opérations de Bourse) a émis une recommandation demandant aux entreprises côtées de procéder sans délai à un état des lieux et à une évaluation de leurs risques opérationnels. Il est de plus suggérer de communiquer cet inventaire dans le rapport annuel relatif à l'exercice qui sera clos fin 1998.



• En mars 1998, la revue IEEE Computer annonce que l'Administration Fédérale de l'Aviation nord-américaine (FAA) n'aura pas résolu ses problèmes au 01/01/2000 et que cela pourrait conduire à une dégradation de la sécurité ainsi qu'à une augmentation des retards. Ceci a été publié dans un rapport du GAO (General Accounting Office, bureau d'investigation du Congrès américain). Les systèmes informatiques incriminés sont pour la plupart très anciens, correspondent à 18.000 sous-systèmes et 65.000.000 de lignes de code. La FAA a admis qu'elle était très en retard y compris en ce qui concernait l'inventaire de ses missions les plus critiques...



• Bill Clinton, Président des USA, et Tony Blair, Premier Ministre du Royaume-Uni, se sont mis d'accord pour mettre formellement au programme du prochain sommet du G7 (qui doit se tenir en Grande-Bretagne en mai 1998) le problème de l'An 2000.



• En avril 1998, Guy de Panafieu, PDG de BULL, a dit, à propos de l'Euro et de l'An 2000 : Entre un sentiment d'urgence à l'anglaise et l'attentisme à la française, ce sont les anglais qui ont raison.



• En mai 1998, Edward Yardeni, Economiste en Chef de la firme d'investissements Deutsche Morgan Grenfell, a dit, à propos de l'An 2000 : La récession pourrait être aussi sévère que celle de 1973-1974, causée par la crise du pétrole. Aujourd'hui, l'information est aussi vitale que le pétrole pour faire tourner nos économies.



• Le 3 mai 1998, le London Times a révélé que dans un hopital nord londonien, une opération avait du être reportée, parce que le système informatique avait annoncé une rupture de stock concernant les compresses. En fait, il y en avait en nombre suffisant, mais leur date limite d'utilisation etait située en 2001, ce que l'ordinateur, n'utilisant que les deux derniers chiffres des années, avait interprétée comme étant 1901 !



• Le 5 mai 1998, l'hebdomadaire 01 Informatique annonçait que la passage de l'indice Dow Jones au-delà des 9999 points (très certainement dans les mois à venir, sauf si des problèmes liés à l'An 2000 provoquaient un krach boursier...) pourrait causer de graves problèmes informatiques à Wall Street (et ailleurs donc...), les ordinateurs correspondants n'ayant pas été programmés, apparemment, pour gérer un indice à 5 chiffres ! Bien que ce phénomène n'ait rien à voir avec des problèmes de date, il illustre parfaitement ce qui a été dit au sujet de la capacité limitée des ordinateurs, intrinsèque et/ou imposée par les programmeurs.
  
  Cette anomalie a heureusement été corrigée depuis...



• Le 20 mai 1998, Christian Pierret présente l'état de la mission "Passage Informatique à l'An 2000". Après avoir rappelé qu'à défaut d'adaptations, des pannes pourraient affecter non seulement le fonctionnement de l'économie mais aussi la vie quotidienne et la sécurité de chacun, le secrétaire d'état à l'Industrie, a indiqué qu'il n'y avait pas lieu de dramatiser de manière excessive la situation, les adaptations liées à l'Euro ayant notamment favorisé la sensibilisation au passage informatique à l'an 2000. Gérard Théry a annoncé ensuite toute une série d'actions prévues qui seront mises en œuvre dans les prochains mois : création d'un site Internet, très large diffusion d'une plaquette d'information générale, promotion des initiatives des constructeurs qui identifieront leurs produits par un marquage produit compatible avec le passage informatique à l'an 2000, campagnes de sensibilisation dans les médias.
  
  Même s'il vaut mieux tard que jamais, ces mesures, par leur manque d'ambition, risquent d'avoir un effet démobilisateur. D'autre part, le public attendait certainement à cette occasion de l'information concernant les ministères et les administrations françaises, la sécurité sociale, la défense nationale,...



• En l'honneur de cette "Coupe du Monde de l'Informatique", pouquoi ne pas lancer l'idée d'une mascotte (Bugix) ?



• Le Journal Officiel de la République Française a publié le 21/05/1998 la Loi numéro 98-389 du 19 mai 1998 (comme pour la directive numéro 85/374/CEE, il est "amusant" de noter que ce numéro contient "98" et non pas "1998"...) relative à la responsabilité du fait des produits défectueux. L'article 18 indique :
  
  Sauf faute du producteur, la responsabilité de celui-ci, fondée sur les dispositions du présent titre, est éteinte dix ans après la mise en circulation du produit même qui a causé le dommage à moins que, durant cette période, la victime n'ait engagé une action en justice.
  
  Mais que signifie, dans le cas du problème de l'An 2000, la réserve sauf faute du producteur puisque les anomalies à venir sont connues, pour la plupart, depuis plus de dix ans ? Cela signifie-t-il que des recours seraient possibles concernant des matériels ou des logiciels acquis antérieurement a 1990 ?



• Le mardi 14/07/1998, Bill Clinton n'a pas hésité à déclarer devant la National Academy of Sciences que le problème de l'An 2000 constituait l'un des plus complexes défis de gestion de l'histoire.



• En juillet 1998, la revue americaine BYTE publie (enfin...) un dossier conséquent sur le sujet intitulé Year 2000 Survival Guide. Le problème de l'aviation y est abordé et à ce propos Bob Jorgensen de chez BOEING y fait une déclaration qui se veut rassurante : airplanes will not crash, if anything happens, they will not be able to leave the gate -les avions ne s'écraseront pas, si quelque chose arrive, ils ne pourront pas quitter la porte. Ceci conduit à faire les deux remarques suivantes : d'une part Bob Jorgensen ne dit pas il ne se passera rien mais si quelque chose arrive, ce qui est reconnaître implicitement que quelque chose peut arriver. D'autre part il semble oublier qu'a priori, à un instant donné, un bon nombre d'avions est en vol et non pas au sol. Notons de plus l'importance des fuseaux horaires qui font qu'en heure locale un avion puisse être encore en 1999, alors qu'à l'heure de ses ordinateurs de bord, il est déjà en 2000...



• Au mois de septembre 1998, une petite visite au site de la Mission An 2000 du Ministère de l'Industrie montre que certains confondent encore le premier janvier 2000 et l'entrèe dans le troisième millénaire (qui n'aura lieu, rappelons-le, que le premier janvier 2001) ; c'est ainsi qu'il est possible d'y lire : "Savez-vous que le changement de millénaire pourrait compromettre la poursuite de vos activités : Le prochain passage à l'an 2000...". Malheureusement, le seul problème qui est ensuite évoqué est celui du codage des années sur 2 chiffres ; cela veut-il dire qu'une Mission Années Bissextiles va être prochainement mise en place (sans oublier les autres problèmes...) ? Mais soyons malgré tout rassurés car, en effet, ce site reproduit un entretien accordé par Gérard Théry (notre Monsieur An 2000) au magazine Industries en juillet 1998 ; il y évoque les grosses applications comportant des centaines de lignes de codes et effectivement, si les grosses applications qui sont opérationnelles dans la banque ou dans l'industrie ne sont pas plus volumineuses, il n'y a aucune raison de dramatiser... Enfin, notons une initiative très importante : celle de la francisation du Y2K des anglo-saxons en A2M -An Deux Mille-.



• Le 9 septembre 1998, la Ministre de la Culture et de la Communication a presenté à la presse son budget pour 1999 (cité dans Le Technicien Film & Video du 15/10/1998). Pour conclure, Catherine Trautmann a donné le montant de l'enveloppe consacrée aux fêtes de l'an 2000 : 180MF (qui ne seront pas pris sur le budget du ministère, mais alloués spécialement par le Premier Ministre)... Est-il logique de préparer les fêtes de la Victoire avant d'avoir décrété la mobilisation générale ?



• Le 22 septembre 1998, s'est tenue à Montréal la trente-deuxième session de l'assemblée de l'ICAO (International Civil Aviation Organization). Au cours de cette réunion, Jane F. Garvey (administrateur de la FAA -Federal Aviation Administration-) a déclaré : we want to encourage states to do everything they can. But we are prepared to take the route of cutting off service to countries whose computer systems are suspect -nous souhaitons encourager les états à faire le maximum. Mais nous sommes prêts à prendre la décision d'interrompre le service vers des pays dans lesquels les systèmes informatiques ne seraient pas sûrs- (d'après Aviation Week & Space Technology du 05/101/998). Cela confirme qu'aux Etats-Unis ces problèmes sont pris très au sérieux...



• Le 25 septembre 1998, l'hebdomadaire 01 Informatique publie le coût du "passage à l'an 2000" pour quatre grandes entreprises françaises :
  
  
  • EDF : 800 MFF,
  • BNP : 600 MFF,
  • Peugeot : 300 MFF,
  • Essilor : 90 MFF.
  
  Ces sommes témoignent sans ambiguïté de la réalité du problème... Dans le même article, il est mentionné que 30% des PME se disent non concernés par l'an 2000. L'un des proches conseillers de Gérard Théry a déclaré à la lecture de ce score inquiétant (voire alarmant) qu'il était comparable à celui de la plupart des grands pays. Effectivement, dans ces conditions, pourquoi vouloir faire mieux qu'eux ou montrer l'exemple ? Pourquoi faire des efforts alors qu'il est si simple de se noyer tous ensemble...



• Dans la nuit du vendredi 25/09/1998 au samedi 26/09/1998 une panne d'électricite a eu lieu à l'Hôpital Edouard-Herriot de Lyon. Le basculement automatique du réseau sur les groupes électrogènes de secours n'ayant pas fonctionné, vingt-six malades en réanimation ont du être évacués vers d'autres établissements. Le 01/10/1998 une enquête préliminaire a été ouverte pour rechercher la cause de la mort de dix de ces patients. Même s'il est évident que la mauvaise gestion des dates dans les ordinateurs n'a absolument rien à voir avec ce problème-ci, malgré tout, il nous rappelle que les dispositifs de secours ne sont pas toujours prêts à remplir leur mission, en particulier dans les systèmes vitaux (santé, contrôle aérien,...).



• Au mois de septembre 1998, dans la revue SPECTRUM publiée par l'IEEE, Capers Jones, dans un article intitulé Bad days for software, annonce que le coût total pourrait atteindre $5.000.000.000.000...



• Le 09 octobre 1998, la revue Air & Cosmos annonce que les tests effectués par les deux principaux constructeurs d'avions civils (Airbus Industrie et Boeing) montrent qu'il y aurait peu de craintes à avoir en ce concerne l'informatique de bord des avions "numériques". Les problèmes recensés sembleraient se limiter à certains types de centrales inertielles au niveau de la navigation, ainsi qu'à quelques lecteurs de cartes de crédit utilisables par les passagers pour accéder à des services en vol (téléphone,...).



• Le 05 novembre 1998, le Premier Ministre français monte au créneau en adressant aux ministres, aux secrétaires d'Etat et aux Préfets une circulaire ou il déclare : Le rôle de l'Etat est double : il doit d'une part mobiliser la communauté nationale par des actions d'information et de sensibilisation, en direction notamment des entreprises. Il doit d'autre part veiller directement à l'adaptation des systèmes utilisés par les administrations, et inciter les entreprises publiques et les organismes sous tutelle à conduire les travaux nécessaires. La démarche du Gouvernement doit être à cet égard exemplaire.
  
  Le ton utilisé dans la note est cette fois-ci beaucoup moins rassurant que celui employé quelques mois plus tôt par Christian Pierret et Gérard Théry. Il y est question de la continuité des services essentiels, de la sécurité des établissement à risques (notamment des installations nucléaires), de l'activité économique et sociale,... Des plans ministériels dits de préparation et de sauvegarde devront être prêts respectivement avant la fin de 1998 et le 28/02/1999.
  
  Il faut donc se réjouir de cette action, qui malheureusement se limite, elle aussi, au codage des années sur deux chiffres, en oubliant les nombreux autres problèmes. Mais n'est-elle de plus pas un peu tardive ? En effet, les plans ministériels de préparation doivent rendre compte de manière exhaustive de l'inventaire des systèmes concernés et des actions de diagnostic et de correction, et ce en quelques mois seulement...



• Le 06 novembre 1998, l'hebdomadaire 01 Informatique annonce, dans le monde de la finance, la sortie du livre blanc sur le passage a l'an 2000. Dans la préface de celui-ci, Gérard Théry (notre Monsieur An 2000) y déclare : tout acteur doit se placer face à un risque maximal et donc déployer un programme d'action et de sauvegarde aussi exhaustif que possible.
  
  Cette déclaration ne peut que satisfaire (même si elle est un peu tardive...).



• Le 26 novembre 1998, Dominique Strauss-Kahn (Ministre de l'Economie, des Finances et de l'Industrie), Marylise Lebranchu (Secrétaire d'Etat aux PME, au Commerce et à l'Artisanat), et Christian Pierret (Secrétaire d'Etat à l'Industrie) ont rendu public, au cours d'une conférence de presse, le rapport de Gérard Théry. Il ressort de ce rapport que si les grandes entreprises françaises et nos grandes administrations semblent se préparer activement, il en va tout autrement d'autres acteurs économiques et des PME en particulier. Dominique Strauss-Kahn a donc été chargé par le Premier Ministre d'accroître la mobilisation de la communauté nationale sur cet enjeu et de présenter le programme d'action du gouvernement pour les mois à venir. Il a rappelé à cette occasion le contenu de la circulaire du 05/11/1998. Marylise Lebranchu a ensuite présenté une guide pratique intitulé Maîtrisons ensemble le passage à l'an 2000, et Christian Pierret a évoqué les efforts déjà engagés dans les domaines qui sont sous sa responsabilité, en particulier l'énergie et les télécommunications.
  
  Dominique Strauss-Kahn a enfin présenté le plan d'action du gouvernement pour les mois à venir. Il est articulé sur quatre objectifs : le renforcement de la mobilisation collective des acteurs privés et publics, le renforcement du dispositif d'action en régions, le renforcement de la coordination interministérielle et la mobilisation des organismes sous tutelle et entreprises publiques, et enfin, le renforcement des actions d'information.
  
  La facture, pour l'Etat français, serait de l'ordre de 12 milliards de francs étalés sur 2 ou 3 ans.



• Le quotidien Les Echos du 27/11/1998, annonçait que Martine Aubry allait proposer des dérogations à la législation du travail afin de permettre aux entreprises de terminer à temps leurs adaptations.



• Petite déception le 06 decembre 1998 lors de l'émission Public animé par Michel Field sur TF1. L'invité était Dominique Strauss-Kahn ; celui-ci n'a pas profité de cette occasion pour renforcer les actions d'information, comme il l'avait annoncé lors de la conférence de presse du 26 novembre 1998.



• Nous allons peut-être bénéficier d'un an de répit. En effet, dans son numéro du 23/12/1998, l'hebdomadaire Télérama annonce, dans sa critique des Entretiens sur la fin des temps, que l'an 2000 ne devrait commencer que le premier janvier 2001.



• Le 04/01/1999, les banques et les places boursières européennes s'éveillaient à l'Euro. Vingt-quatre heures plus tard, il apparait que le passage des monnaies antérieures à la monnaie unique s'est fait, au niveau informatique, en douceur. Cela est donc de bonne augure en ce qui concerne le bug de l'an 2000, tout du moins en ce qui concerne les établissements financiers et les grandes entreprises qui préparaient cela depuis de nombreux mois...



• L'Agence France Presse a annoncé que du 04/01/1999 au 06/01/1999 le système informatique, responsable à la Poste des transactions sur les 16 millions de comptes d'épargne, avait été victime d'une "surchauffe" qui s'est manifestée par de graves dysfonctionnements dans 14000 bureaux de Poste en France, en particulier à Paris, à Lyon, à Marseille et à Rouen. Les actualités télévisées du 06/01/1999 ont montré que dans certains bureaux, qui avaient été fermés à cette occasion, la situation avait été proche de l'émeute.
  
  Que se passerait-il alors, lors de dysfonctionnements de plus longue durée à la Poste ou dans les banques ? Que se passerait-il aussi à l'approche du 31/12/1999, si de nombreux clients de ces établissements demandaient la réalisation en espèces de tous leurs comptes ?



• La Télévision Suédoise annonçait que, le 01/01/1999, la police des frontières avait été incapable de délivrer, dans les trois aéroports internationaux du pays, des passeports provisoires, comme cela est possible habituellement. Le problème aurait duré plusieurs jours. Le système informatique était apparemment incapable de traiter l'année 99.



• L'agence Associated Press annonçait le 03/01/1999 que le système de tarification de 300 taxis de Singapour avait provoqué de mauvaises facturations le 01/01/1999 à partir de midi. Un problème similaire aurait été rencontré en Suede.



• Le 03/02/1999, le Premier Ministre a ouvert la première réunion du Comité National pour le passage à l'an 2000. Il a annoncé, en particulier, que le code des marchés publics serait allégé dans les prochaines semaines. Il a aussi declaré : la démarche des administrations doit être exemplaire et incitative pour les autres acteurs.



• Nous sommes au début de 1999, et les Elections Européennes approchent. Les candidats s'exprimeront-ils sur ces "difficultés" ? D'ailleurs ces problèmes ne demanderaient-ils pas une coordination internationale (et donc européenne) ?



• Le 09/03/1999, le BOI (Bulletin Officiel des Impôts) publie une instruction qui aligne la fiscalité des investissements an 2000 sur celle de l'Euro, en offrant la possibilité de provisionner les dépenses informatiques correspondantes (à savoir : le recours aux services d'une SSII, les tests informatiques, la mise en conformité des matériel et des logiciels, les études juridiques, la formation des personnels, l'embauche d'informaticiens, les dépenses de communication,...)



• Le 12/03/1999, l'hebdomadaire 01 Informatique rapporte les propos de Marylise Lebranchu, Secrétaire d'Etat aux PME, au Commerce et à l'Artisanat. Elle déclare en particulier que nous faisons face à des comportements inadmissibles : quand vous vendez un PC en 1998 avec une horloge à deux chiffres, vous méritez une paire de claques. Elle annonce de plus que la DGCCRF (Direction Générale de la Concurrence, de la Consommation et de la Répression des Fraudes) va publier son premier rapport sur la compatibilité an 2000. Enfin, elle confirme que la sensibilisation des PME se fait difficilement.



• Le 29/03/1999, l'OTAN reconnait la perte d'un avion furtif F177 de l'USAF lors d'une mission au-dessus de la Yougoslavie le 27/03/1999. Quel rapport avec le bug de l'an 2000 ? Aucun... Malgré tout, il s'agit d'un nouvel exemple d'un cuisant échec technologique. Le bombardier furtif F177 n'est-il pas, en effet, présenté systématiquement comme une "vitrine technologique", une arme "magique" même ? Quelle que soit la cause de cet incident, les objectifs d'invisibilité, de fiabilité, d'infaillibilité,... ne sont pas atteints. Notre technologie a ses faiblesses et ses limites ; il faut accepter ce fait.



• Le 09/04/1999, l'hebdomadaire 01 Informatique rapporte les propos de Michel Pagès, coordinateur an 2000, EDF-GDF, suite à la mise en place de la base de données an 2000 du Cigref. Il déclare en particulier j'espère que nous serons suivis dans cette démarche par d'autres entreprises, bien au-delà des membres du Cigref. Nous avons été les premiers à faire ce geste, en tant que service public. La publication de notre base de tests doit être comprise comme un geste de solidarité. L'intérêt général a, heureusement, prévalu sur les difficultés juridiques que posait la divulgation de ces informations.
  
  Un bel exemple à suivre et à méditer !



• Le 21/05/1999, l'hebdomadaire 01 Informatique annonce la sortie du livre Passage à l'an 2000, guide pour les maires de France.. Rappelons que depuis le 01/03/1994, le Code Pénal prévoit qu'un maire peut être reconnu responsable des accidents survenant dans sa commune, par exemple en cas de négligence. Or, ne pas s'enquérir de la compatibilité an 2000 d'une municipalité pourrait être vu ultérieurement comme une négligence...



• Le 01/06/1999, le mensuel Spectrum de l'IEEE publie le résultat d'une étude réalisée par le Gartner Group. Un tableau classe les différents pays du monde en 4 catégories (de 1 pour les moins à risques à 4 pour les plus en danger), et ce dans 6 domaines différents (l'énergie, le téléphone, les transports aériens, l'alimentation en eau potable, les services gouvernementaux et enfin les services bancaires). Deux mauvaises nouvelles : d'une part la France n'apparait que dans la deuxième catégorie (la première contenant : l'Australie, la Belgique, le Canada, le Danemark, la Grande-Bretagne, l'Irlande, Israël, les Pays-Bas, la Suède, la Suisse, les USA). D'autre part, pour les quatre catégories de pays, un risque majeur commun : celui des services gouvernementaux !



• Le 04/06/1999, l'hebdomadaire 01 Informatique rapporte que le premier test commun des principaux protagonsites de la place financière française s'est achevé le 02/06/1999 et semble s'être bien déroulé. Un test mondial à grande échelle est prévu pour le 12/06/1999. Tout le monde semble optimiste.
  
  Le test mondial, effectué le 12 et le 13/06/1999, portant sur 18000 transactions, aurait obtenu un taux de réussite de 99.92%. Cela pose deux questions : d'une part à quoi correspondent les échecs (0.08%) et d'autre part, les 18000 transactions sont-elles représentatives et en nombre suffisant ? Au passage, en temps normal, quel est le nombre de transactions par jour ?



• Le 09/07/1999, l'hebdomadaire 01 Informatique rapporte un certain pessimisme dans le quatrième rapport du Comité National pour le passage a l'an 2000. Il resterait encore 5% d'entreprises déclarant ne pas être prêtes d'ici la fin de 1999. Il est possible d'y lire de plus la phrase suivante : il est probable que les difficultés seront plus importantes que prévu, compte tenu d'un état de préparation réel des entreprises plus faible que ne laisse supposer les seules bases déclaratives. Les Très Petites Entreprises ('TPE') seraient toujours à la traîne et d'une façon générale, le sentiment d'être bien informé serait en léger recul (malgré le "petit bug vert" ?).



• Le 23/08/1999, au lendemain du GPS week roll over, il semblerait que tout se soit bien passé. Même si des incidents mineurs ont été rencontrés (ainsi, au Japon de nombreux automobilistes utilisant des systèmes de navigation dans leurs véhicules, ont vu leurs écrans afficher des informations "inhabituelles"), il n'y a pas eu, bien heureusement, de catastrophes.
  
  Cela est du très certainement d'une part à l'existence d'une spécification unique de ce système (ce qui n'est évidemment pas le cas en ce qui concerne le codage des dates dans les ordinateurs...) et d'autre part à la conformité à ces spécifications de très nombreux récepteurs 'GPS', en particulier dans les systèmes dont la sécurité en dépend.
  
  Malgré tout, ce succès n'enlève rien à la pertinence des remarques faites à ce sujet.



• Le 09/09/1999, rien à signaler, si ce n'est l'intérèt que les média ont porté à cette date, alors que peu était à craindre, contrairement aux possibles problèmes du 'GPS' le 21/08/1999 qui eux n'ont fait l'objet de pratiquement aucune actualité et pour lesquels, potentiellement, les risques étaient supérieurs. Donc beaucoup de bruit pour rien, ce qui pourrait avoir des conséquences négatives en ce qui concerne la mobilisation face aux véritables problèmes du 31 decembre prochain...



• A compter du 26/09/1999, un dispositif que j'ai mis en place sur les systèmes UNIX que j'utilise s'est mis brutalement à ne plus fonctionner. J'ai en effet l'habitude d'utiliser la date et l'heure pour baptiser certains fichiers (courriers électroniques émis et reçus, fichiers des transactions sur mon site Internet,...). Ainsi, à l'instant où j'écrit ces lignes, un tel document sera baptisé '19991004085716' puisque nous sommes le 04/10/1999 et qu'il est 08:57:16. Cette façon de procéder possède deux avantages : d'une part ne pas avoir à chercher des noms significatifs à tous les objets manipulés et d'autre part donner des noms dont les ordres alphabétique et chronologiques soient identiques. Sous le 'C-Shell' UNIX, il est ensuite possible d'écrire :

                      if        ($nom1 > $nom2) then
                                (...)
                      else
                                (...)
                      endif
  

  où 'nom1' et 'nom2' désignent deux noms de fichiers structurés comme cela vient d'être décrit. Le test précédent permet donc d'entreprendre telle ou telle action, suivant les âges respectifs de ces deux fichiers. Il apparait donc qu'à compter du 26/09/1999 ces tests d'inégalité (inférieur, supérieur,...) ne fonctionnent plus correctement. Ainsi, par exemple, la condition :

                      19990925235959 > 19990924083306
  

  est correctement interprétée comme étant vraie, alors que :

                      19990926000000 > 19990924083306
  

  est interprétée, par erreur, comme étant fausse... Au passage, l'analyse qui a suivi a montré que le problème venait du fait que le 'C-Shell' UNIX manipulait les nombres entiers modulo 2147483648, avec :

                      2147483648 = 21474836487+1 = 0x7fffffff
  

  (où la notation hexa-décimale '0x7fffffff' représente le plus grand entier positif sur 32 bits) sans jamais le signaler. Ainsi, les nombres 19990924083306 et 19990926000000 sont respectivement interprétés comme valant +2146287722 (positif) et -2146762880 (négatif), d'ou l'inversion observée dans la condition inférieur.
  
  Cela confirme donc qu'un programme manipulant des dates peut très bien ne plus fonctionner correctement de façon très brutale, sans qu'il ait été modifié et sans que son environnement ait changé !



• Le 01/10/1999, l'hebdomadaire 01 Informatique rapporte que la fédération des services CFDT de Lyon, suite à des difficultés dans les négociations sur la réduction du temps de travail, n'excluait pas un appel à la grève pendant la phase du passage à l'an 2000. Alors, inconscience ou irresponsabilité ?



• Le 17 décembre 1999, l'hebdomadaire 01 Informatique annonçait que le coût des opérations bug de l'an 2000, pour les entreprises françaises, serait de l'ordre de 140 milliards de francs. Ce même numéro rappelait que le bug était parfois utilisé lors des négociations relatives à la loi sur les 35 heures (dont la date d'application approche, elle aussi).



• Depuis le 26 décembre 1999, l'Europe de l'Ouest (et plus particulièrement la France), est victime de tempêtes d'une violence extrême. Le 28/12/1999, il y aurait dans notre pays environ deux millions de personnes privées d'électricité, le délai de rétablissement n'étant pas garanti par EDF. Un pourcentage important des lignes à très haute tension a été coupé : notre réseau électrique et donc notre pays ne sont donc pas au mieux de leur forme pour affronter le 31/12/1999. Ces événements dramatiques sont là pour nous rappeler aussi que les incidents divers et variés que nous rencontrerons dans les jours qui viennent ne seront pas tous du au bug...
  
  Ces événements incitent à faire un parallèle entre les catastrophes naturelles (comme celles que nous venons de connaître) et les éventuelles catastrophes liées au bug. Dans une catastrophe naturelle, les causes des dégats sont facilement identifiables (un pylône au sol, une ligne d'alimentation coupée,...) et "il suffit" ensuite de réparer. Dans le cas du bug, des dégats de même nature (une coupure de courant par exemple) auraient des causes de nature "virtuelle" qui seraient donc, en général, beaucoup plus difficiles à localiser.
  
  Enfin, nous semblons (re)découvrir dans ces circonstances que "tout dépend de tout" : il faut de l'électricité pour assurer l'alimentation en eau potable et pour permettre au téléphone de fonctionner, il faut de l'informatique pour produire l'électricité (les ordinateurs ayant évidemment besoin de cette source d'énergie !),...



• Entre le 01/01/2000 et le 03/01/2000, aucun incident notable lié au bug n'est venu perturber les fêtes de célébration de la nouvelle année. En particulier, les grands services publics (en France et ailleurs) fonctionnent normalement. Mon optimisme du 10/12/1999 était donc justifié. Malgré cela, il faut d'une part ne pas oublier que les possibles effets du bug peuvent être étalés dans le temps et que d'autre part toutes les remarques qui ont pu être faites à ce sujet (par exemple en ce qui concerne la faillabilité croissante de l'informatique) conservent toute leur pertinence.
  
  Il semblerait d'ailleurs qu'une polémique soit en train de naître sur ce "non-événement". Il serait incroyable, voire insultant, de critiquer ceux qui ont pris les mesures qui s'imposaient et ceux qui ont fait ce qui était nécessaire. Que se serait-il passé en l'absence de ces dépenses colossales et de ces actions accomplies par ces armées d'hommes et de femmes ? Nous n'aurons évidemment jamais la réponse à cette question, mais il me semble évident, pour faire une nouvelle analogie, que la propagation des épidémies est enrayée par les vaccinations ! Qui oserait prétendre à leur sujet qu'elles ne servent à rien puisqu'il y a beaucoup moins de victimes (voire plus du tout dans certains cas) ? Dans le même domaine (celui de la santé), l'inaction de certains n'est-elle pas aujourd'hui en cause dans l'affaire du sang contaminé, ou encore qui oserait raisonnablement critiquer les mesures prises (au nom du principe de précaution) par le gouvernement français et qui concernent l'embargo sur le bœuf britannique ? Enfin, si une telle polémique devait se poursuivre, il faudrait alors l'étendre, par exemple, à ceux qui dans le monde de l'automobile ou de l'aéronautique conçoivent des véhicules plus sûrs et donc plus chers !
  
  Dans l'état actuel, je ne crois pas que nous ayons surestimé le danger et comme je l'ai souvent répété, le bug de l'an 2000 ne consiste pas uniquement en la transition du 31/12/1999 au 01/01/2000, mais concerne, en toute généralité, la mauvaise gestion des dates dans les ordinateurs (d'ou le sous-titre de cette page). Ainsi, peut-être avons nous gagné une bataille, mais pour décider de l'issue de la guerre, il serait sage et prudent d'attendre encore quelques temps...
  
  En attendant, essayons de nouveau de voir le bon côté du bug : il a permis de mettre de l'ordre dans notre informatique, de renouveler des équipements obsolètes et surtour d'en avoir une meilleure connaissance car, j'insiste de nouveau sur ce point, nos systèmes informatiques sont d'une complexité telle que personne ne les maîtrise complètement, ceci étant d'ailleurs la raison pour laquelle je suggère, de nouveau, de ne pas "baisser la garde"...
  
  Je voudrai aussi rappeler que dans mon esprit, le bug de l'an 2000 n'était qu'un exemple destiné à montrer notre dépendance vis à vis de technologies finalement relativement fragiles. C'est ainsi qu'en introduction de certains de mes articles, bien avant la tempête, il était possible de lire :
  
  Dire que l'informatique, les télécommunications et l'énergie constituent les infrastructures vitales de notre économie, de notre défense et de notre confort quotidien est d'une extrême banalité. (...) S'interroge-t-on suffisamment sur les inter-dépendances de ces infrastructures de base que personne ne maîtrise complètement ainsi que sur leur robustesse et leur capacité à resister à des perturbations ? Ne seraient-elles pas que de gigantesques châteaux de cartes prêts à s'écrouler à la moindre occasion ?
  
  Ainsi, les tempêtes catastrophiques de la fin de l'année 1999 m'ont offert l'exemple que j'attendai du bug ! Je rappelle qu'aujourd'hui (le 06/01/2000) de nombreux foyers français sont encore privés d'électricité sans garantie quant aux délais de retour à la normale (au passage, ceci n'est absolument pas une critique de l'activité des techniciens de l'EDF qui font tout leur possible (et même plus) ; ils sont tout simplement dépassés par l'ampleur de la catastrophe). L'an 2000 commence donc bien mal avec ces arbres centenaires abattus et ces malheureux oiseaux mazoutés...



• Le 07 janvier 2000, l'hebdomadaire 01 Informatique annonce que 25% des entreprises françaises sont affectées, malgré le bon comportement des systèmes informatiques face au bug. 9% d'entre-elles ont dû réduire leur activité (1% aurait même du arrêter tout fonctionnement). Comme il était possible de s'y attendre, c'est l'informatique de gestion qui est le plus touchée (28%).






Mes principaux rendez-vous avec l'An 2000 :




• 24/07/1996 : Lettre adressée au rédacteur en chef du journal Pour La Science.
• 05/12/1996 : Lettre adressée au rédacteur en chef du journal l'Informatique Professionnelle.
• 06/12/1996 15:30 : Intervention dans l'émission Archipel-Science, France Culture.
• 25/05/1997 : Intervention dans l'émission E=M6, M6.
• 09/06/1997 : Intervention dans l'émission NetSurf, MCM.
• 20/03/1997 14:00 : Conférence à l'Ecole Polytechnique.
• 15/05/1997 10:30 : Conférence à l'IDRIS.
• 22/07/1997 : Lettre adressée au President de la République française.
• 02/09/1997 : Lettre adressée au Ministre de l'Education Nationale, de la Recherche et de la Technologie.
• 02/09/1997 : Lettre adressée au Secrétaire d'Etat à l'Industrie.
• 17/02/1998 20:00 : Intervention sur Radio FG.
• 06/03/1998 17:00 : Conférence à l'Ecole Supérieure de Commerce de Brest.
• 01/04/1998 : Publication de l'article "An 2000 : le Mégabug est programmé", La Recherche.
• 09/04/1998 09:00 : Conférence au Ministère de l'Equipement.
• 30/04/1998 09:00 : Intervention sur La Cinquième.
• 06/05/1998 : Intervention sur Radio France Internationale.
• 09/06/1998 09:00 : Conférence au Séminaire de Communication de l'Ecole Polytechnique.
• 11/06/1998 14:00 : Conférence à l'Ecole Polytechnique.
• 18/06/1998 10:00 : Conférence à la Caisse des Dépots et Consignations.
• 09/07/1998 17:00 : Conférence devant les directeurs de laboratoire de l'Ecole Polytechnique.
• 10/09/1998 : Publication de l'article "Alerte au bug de l'an 1999", Micro Hebdo.
• 22/09/1998 23:00 : Intervention dans l'émission Le Cercle, France 2.
• 01/10/1998 18:00 : Table-ronde à l'Ecole Européene des Affaires de Paris.
• 11/10/1998 15:00 : Table-ronde à la Cité des Sciences et de l'Industrie.
• 18/10/1998 : Intervention dans l'émission E=M6, M6.
• 20/10/1998 18:00 : Conférence à l'Institut des Hautes Etudes de la Défense Nationale de Paris.
• 22/10/1998 21:00 : Intervention dans l'émission Envoye Spécial, France 2.
• 13/11/1998 11:00 : Conférence au Cap Cyber de Nice.
• 17/11/1998 19:00 : Conférence au Forum des Sciences de Villeneuve d'Ascq.
• 18/11/1998 20:30 : Conférence à la MJC de Villebon-sur-Yvette.
• 07/12/1998 14:00 : Conférence au Centre de Recherche L'OREAL, Clichy.
• 01/01/1999 : Publication de l'article "Le Bug de l'An 2000 [ou les "Faiblesses" de l'Informatique par l'Exemple]", Revue ID du Conseil National des Ingénieurs et des Scientifiques de France.
• 28/01/1999 14:00 : Conférence devant les fournisseurs de Siemens Automotive, Toulouse.
• 30/01/1999 : Intervention dans l'émission Visa pour la Science, France 3.
• 01/02/1999 19:30 : Intervention dans l'émission Le Téléphone Sonne, France Inter.
• 04/02/1999 : Intervention dans l'émission Temps Présent, Télévision Suisse Romande 1.
• 09/02/1999 : Intervention sur Radio BFM.
• 09/02/1999 : Intervention dans l'émission Temps Présent, Télévision Suisse Romande 2.
• 09/02/1999 13:00 : Intervention dans l'émission Temps Présent, TV5.
• 10/02/1999 : Intervention dans l'émission Temps Présent, TV5.
• 11/02/1999 20:00 : Intervention dans le journal télévisé de la Télévision Suisse Romande 1.
• 14/02/1999 12:00 : Intervention dans l'émission Droit de Cité, Television Suisse Romande 1.
• 23/02/1999 09:00 : Intervention dans l'émission Archipel-Science, France Culture.
• 08/03/1999 : Sortie du livre "Le Bug de l'An 2000 - Comprendre l'informatique jusqu'à ses défaillances", en collaboration avec Bernard Aumont, publié chez Flammarion, Paris.
• 09/03/1999 09:00 : Conference devant X'Doc, Ile de Science Industrie, le District du Plateau de Saclay, et la Chambre de Commerce et d'Industrie de l'Essonne, Ecole Polytechnique.
• 15/03/1999 : Publication de l'article "Les défaillances de l'informatique : une nouvelle menace ? L'exemple du bug de l'an 2000", Athéna (Institut des Hautes Etudes de la Défense Nationale).
• 25/03/1999 19:00 : Conférence devant l'Association Nationale des Directeurs Financiers et des Controleurs de Gestion (DFCG), Paris.
• 31/03/1999 11:00 : Conférence au Lycée Jean Lurçat de Paris.
• 31/03/1999 23:30 : Présentation du livre "Le Bug de l'An 2000 - Comprendre l'informatique jusqu'à ses défaillances" dans l'émission de Daniel Schick sur Europe 1.
• 13/04/1999 : Interview dans Le Monde Interactif.
• 13/04/1999 : Interview dans Libération.
• 04/05/1999 09:30 : Présentation du livre "Le Bug de l'An 2000 - Comprendre l'informatique jusqu'à ses défaillances" sur Radio Notre-Dame.
• 04/06/1999 18:00 : Intervention dans l'émission Enjeux, Radio France International.
• 07/06/1999 : Mise en place du service "Jean-François COLONNA répond à vos questions" dont un miroir est donné ci-après, Le Monde Interactif.
• 17/06/1999 09:00 : Conférence à l'ESSEC, Cergy-Pontoise.
• 22/06/1999 14:00 : Conférence au Centre de Formation des Personnels de l'Education Nationale, Créteil.
• 25/06/1999 16:00 : Visio-Conférence pour la Chambre de Commerce & d'Industrie et l'Association des Moyennes et Petites Industries de la Martinique, Fort de France.
• 02/07/1999 09:30 : Intervention dans l'émission Magazine, Radio Bleue.
• 04/07/1999 11:30 : Intervention dans l'émission Droit de Cité, Television Suisse Romande 1.
• 05/07/1999 19:30 : Intervention dans l'émission Le Téléphone Sonne, France Inter.
• 06/07/1999 19:00 : Intervention dans l'émission Archimède (principalement sur le problème des erreurs d'arrondi), Arte.
• 06/07/1999 : Animation sur plusieurs jours du forum d'Archimède consacré au bug de l'An 2000, Arte.
• 08/09/1999 : Interview, malheureusement fort tronquée (le message enregistré il n'y aura pas de problèmes le 09/09/1999 n'est pas passé à l'antenne), sur LCI concernant le non-événement du bug du 9/9/99.
• 08/09/1999 : Interview sur BFM concernant le non-événement du bug du 9/9/99.
• 08/09/1999 : Interview sur France Inter concernant le non-événement du bug du 9/9/99.
• 23/09/1999 : Interview sur France Culture à l'occasion de J-100.
• 23/09/1999 09:00 : Conférence au G9+, Maison des Arts et Métiers, Paris.
• 28/09/1999 : Interview sur TSF.
• 01/10/1999 : Publication de l'article "Le Bug de l'An 2000 [ou les "Faiblesses" de l'Informatique par l'Exemple]", Sécurité Informatique du CNRS.
• 12/10/1999 : Lettre adressée au Président de la République française.
• 12/10/1999 : Lettre adressée au Premier Ministre.
• 23/10/1999 10:30 : Conférence dans le cadre de la Semaine de la Science, Fontenay-sous-Bois.
• 08/11/1999 : Interview sur Radio France.
• 15/11/1999 20:00 : Conférence à l'Ecole Normale Supérieure, Paris.
• 20/11/1999 18:00 : Conférence dans le cadre du Marché de l'Informatique, Souppes.
• 25/11/1999 21:00 : Intervention dans la rediffusion de l'émission Envoyé Spécial du 22/10/1998, France 2.
• 02/12/1999 16:00 : Conférence à l'Hôtel Crillon, Paris.
• 04/12/1999 14:00-19:00 : Dédicace du livre "Le Bug de l'An 2000 - Comprendre l'informatique jusqu'à ses défaillances" lors de La Journée du Livre d'Economie, Sénat.
• 08/12/1999 08:30 : Conférence à l'Ecole Nationale Supérieure des Télécommunications, Paris.
• 23/09/1999 12:30 : Interview sur Radio Champagne-Ardennes.
• 23/09/1999 : Interview sur Radio France International.
• 14/12/1999 20:30 : Conférence au Centre Culturel Saint-Exupéry, Reims.
• 24/12/1999 : Publication de l'article "Les défaillances de l'informatique : une nouvelle menace ?", Les Cahiers du Radicalisme.
• 26/12/1999 09:00 : Participation à l'émission C'est arrivé demain de Dominique Souchier sur Europe 1.
• 27/12/1999 18:30 : Interview sur LCI pour avoir mon pronostic (qui fut optimiste...).
• 28/12/1999 : Interview sur BFM concernant les incidences de la tempête sur le bug.
• 28/12/1999 19:30 (Annulé à cause de la tempête qui sévit sur la France) : Intervention dans l'émission Le Téléphone Sonne, France Inter.
• 30/12/1999 18:30 : Interview sur LCI à l'occasion de J-2.
• 03/01/2000 : Interview sur Radio France au cours de laquelle Nicolas Delourme, le journaliste, a rappelé que mes prévisions optimistes du 08/11/1999, sur cette même antenne, s'étaient réalisées.
• 26/01/2000 : Publication -un peu tardive- de l'article "Les défaillances de l'informatique : une nouvelle menace ?", La Jaune et la Rouge, revue mensuelle de la société amicale des anciens élèves de l'Ecole Polytechnique.

Sensibiliser, sensibiliser et encore sensibiliser...





Questions diverses :




• Le bug de l'An 2000 et les ordinateurs personnels (04/06/1999) : Il est essentiel de bien comprendre qu'un ordinateur (qu'il soit personnel ou super-calculateur...) ne se limite pas à une RTC ou à un BIOS. Il est en fait constitué d'un très grand nombre d'entités coopérantes (depuis les composants jusqu'aux applications utilisateurs) qui dialoguent entre-elles. Il ne suffit donc pas que l'une d'elles soit prête pour que l'ensemble le soit. A titre d'exemple, la RTC et le BIOS peuvent être "compatibles", alors que l'utilisateur a réalisé des feuilles de calcul où des années figurent explicitement sur deux chiffres. Il convient de noter aussi que deux entités peuvent être "compatibles" prises séparemment l'une de l'autre, et ne plus l'être lorsqu'elles sont réunies. Malgré cela, il faut remarquer qu'au niveau d'applications de type "traitement de texte", "navigation Internet" ou "jeu", les dysfonctionnements de la date n'ont en général que peu d'impact.
  
  Malgré cela, notons qu'il est impossible de répondre de façon catégorique et sure à une question du type "mon ordinateur va-t-il continuer à fonctionner ?". La trop grande complexité de ces systèmes ainsi que leur extrême diversité est la cause de cette incertitude...
  
  L'affirmation "les PCs ne sont pas compatibles alors que les Macs le sont" est fréquente. Elle est vraie et fausse à la fois. "Vraie", car, en effet, au niveau physique, il semble que les concepteurs du Mac aient vu "plus loin dans le temps". "Fausse", car, encore fois, un ordinateur, quelqu'il soit, est fait beaucoup plus de logiciel que de matériel. Dans ces conditions, il suffit d'avoir sur un Mac une application incompatible, ou d'avoir réalisé soi-même quelque chose d'incompatible (une feuille de calcul contenant des années sur deux chiffres, par exemple), pour perdre cet avantage. Rappelons au passage que la notion de compatibilité n'existe ni sur le plan formel ni sur le plan légal...
  
  N'oublions pas enfin, qu'un ordinateur n'est pas autonome et dépend, pour qu'il puisse fonctionner, d'un certain nombre de fournitures (l'électricite par exemple)...



• Le bug de l'An 2000 et les ordinateurs de poche (28/10/1999) : Deux remarques peuvent être faites à leur sujet : d'une part, beaucoup d'entre-eux assurent une fonction d'agenda et la date joue-là un rôle évident. D'autre part certains de leurs propriétaires les utilisent pour stocker temporairement des données (par exemple saisies "sur le terrain") qui sont ensuite transférées périodiquement sur un PC. Lors de ces opérations, il est vraisemblable que la date joue-là aussi un rôle important afin de ne transmettre que des mises à jour, par exemple.



• Le bug de l'An 2000 et le test des ordinateurs personnels (09/06/1999) : De même qu'il n'y a pas de "solution miracle" aux problèmes de date dans les ordinateurs, il n'y a pas de "test miracle" permettant de garantir la compatibilité (notion qui n'est d'ailleurs ni normalisée, ni formalisée). Malgré tout, un certain nombre d'éléments (le type de machine, ses dates de fabrication, son système d'exploitation et sa version,...) permettent de se faire une opinion "de bas niveau". Au-delà, il ne faudra pas oublier qu'au-dessus du matériel et des logiciels d'exploitation, il y a des applications et que celles-ci peuvent avoir été personnalisées. Par exemple, un utilisateur peut utiliser un tableur vendu comme "compatible" et placer malgré tout dans ses feuilles de calcul des années codées sur deux chiffres sur lesquelles, il fera des opérations. Ainsi, l'utilisateur peut avoir sa part de responsabilité dans la compatibilité.
  
  D'autre part, il ne faut pas négliger le fait que deux "entités" prises séparemment peuvent être déclarées "compatibles" et ne plus l'être lorsqu'elles coopèrent. Enfin, il ne faut pas oublier que l'on peut avoir mis à niveau son ordinateur, puis ensuite importer à l'interieur de nouveaux logiciels, ou de nouvelles données, non compatibles. donnera plus d'informations sur cette question.
  
  Il existe évidemment de nombreux logiciels permettant de tester la "conformité An 2000" d'un PC. Se souvenant, comme cela a déjà été répété à de nombreuses reprises, que la notion de conformité n'est pas parfaitement définie, cette dernière doit inclure au minimum le passage "en douceur" du 31/12/1999 au 01/01/2000, la mémorisation et la manipulation des années sur 4 chiffres, la programmation correcte du calendrier grégorien (et donc des années bissextiles). Notons que pour être en accord avec la définition complète du problème, il conviendrait, en toute généralité, d'ajouter quelques autres tests...
  
  Le CNRS, en association avec le Ministère de la Recherche, a sélectionné le logiciel "OnMark2000 Asses" de la société ViaSoft pour faire les tests concernant les PCs utilisés dans ses services et dans ses laboratoires. Ce logiciel assure le test du BIOS, l'inventaire des applications et l'édition des problèmes potentiels, l'analyse des données (de type ACCESS, FoxPro, Lotus 1-2-3, dBase3 et 4,...) et enfin l'analyse des feuilles de calcul.
  
  L'intérêt de ce type de logiciel est qu'il ne se contente pas de tester les couches basses de la machine (le BIOS), mais va jusqu'à examiner les fichiers créés par l'utilisateur. Rappelons à ce propos, qu'un PC, comme tout ordinateur, est un assemblage complexe de nombreux sous-ensembles...
  
  Si le PC à examiner supporte LINUX, ce programme pourra être utilisé pour tester le BIOS.



• Le bug de l'An 2000 et l'effet Crouch-Echlin (22/06/1999) : De l'avis même de Jace Crouch et de Mike Echlin, la cause (les causes...) de ce phénomène d'instabilité de temps et de date (ce qu'ils appellent aussi "dilatation") pourrait être liée à l'utilisation de RTCs [Real Time Clock] "non bufferisées" ; ceci n'est pas impossible car, en effet, le temps joue un rôle important dans les systèmes, en particulier dans les couches les plus basses. Il est donc possible d'imaginer des petites routines qui se synchroniseraient de façon "artisanale" sur des événements physiques et, par exemple, la présence dans un certain registre d'une date et d'un temps valide. En passant de [19]99 a [20]00, il est assez probable que le "timing" de cette disponibilité change (même de très peu : un cycle d'horloge par exemple), d'où le possible accès à ce registre à un instant où l'information est "instable" ou "invalide". Malgré cela, il semblerait que cet effet ait été aussi observé sur des systèmes possédant des RTCs "bufferisées" ; cela n'est peut-être pas en contradiction avec l'explication précédente si, par malheur, un registre "non bufferisé" est accessible à l'extérieur ou si encore la gestion de ce buffer possède lui-même le défaut évoqué précédemment...
  
  Enfin, là aussi, de l'avis de Jace Crouch et de Mike Echlin, il pourrait y avoir d'autres causes à ce phénomène, qui se cumuleraient, et en particulier des problèmes liés à des incompatibilités entre composants ; je n'en sais pas plus...
  
  En tout cas, cela montre que les ordinateurs sont des machines d'une complexité qui nous dépasse et que nous ne maîtrisons pas toujours. Cela montre aussi que la perfection des 0s et des 1s n'existe que dans un univers inaccessible et que la réalité quotidienne relève plutôt du bricolage...



• Le bug de l'An 2000 et Internet (20/08/1999) : Internet doit être considéré d'une part comme une infrastructure d'acheminement de messages et d'autre part comme un ensemble d'applications utilisant les services de transport. En ce qui concerne l'aspect réseau, il est évident qu'étant constitué de très nombreux ordinateurs et de très nombreux organes de routage dans lesquels la date existe et est utilisée, Internet est évidemment concerné par le bug de l'An 2000. Mais cela ne signifie pas qu'il va se "bloquer" ; en effet, il est constitué de matériels tellement divers que tous ne peuvent pas être victime de ses effets et de plus, il a, par conception, une structure fortement maillée permettant de contourner les zones à problème et de lui conserver longtemps sa connexité. Malgré tout, il ne faudra pas négliger, comme cela s'est déjà vu a plusieurs reprises récemment dans des réseaux nord-americains, de possibles phénomènes de type "avalanche" provoqués par la propagation d'anomalies qui peuvent alors conduire à des blocages complets de réseaux par saturation... Des tests ont été faits et sont en cours permettant d'assurer au mieux la "compatibilité". Bien entendu, il ne faut pas oublier que ces tests, là comme ailleurs, ne peuvent être exhaustifs ; de plus, il semblerait que dans certains cas, ces tests ne sont pas neutres et que ces "allers et retours" des horloges entre le présent, l'an 2000 et le présent laissent parfois des traces... Internet, c'est aussi des applications comme le courrier électronique ("mail") ou le "Web". La date y intervient nécessairement : par exemple, les courriers contiennent la date et l'heure ; une anomalie possible pourrait être, par exemple, des erreurs de tris chronologiques, ou l'élimination de certains messages considérés comme trop anciens. Au niveau du "Web", il en est de même ; à titre d'exemple, des pages sont générées dynamiquement et si elles présentent des informations datées, il peut y avoir anomalie. La moralité de ceci est qu'il convient, dans les mois qui viennent, d'être plus vigilant et plus suspicieux...
  
  En ce qui concerne les transactions "professionnelles" utilisant Internet, elles ne sont peut-être pas plus à risque que celles qui emprunteraient d'autres voies. Malgré tout deux conseils peuvent être donnés : d'une part d'être ici très vigilant lors des périodes critiques, et d'autre part dans ces moments, si cela est possible, d'interrompre temporairement les connexions, ou sinon de réduire au maximum le trafic. Ces conseils sont indépendants de la nature des voies utilisées (Internet ou pas)



• Le bug de l'An 2000 n'est-il qu'une opération commerciale (10/06/1999) ? On ne peut pas ne pas se poser la question de la réalité du bug de l'an 2000 : ne serait-il pas plutôt le fruit de la stratégie commerciale de certains constructeurs ou d'éditeurs de logiciels ? Quelques remarques s'imposent alors :
  
  L'informatique n'est pas faite que d'ordinateurs individuels exploitant des logiciels Microsoft. Dans les grandes entreprises (les banques par exemple), il y a de nombreux "mainframes" sur lesquels tournent des centaines de millions de lignes de programmes développées en interne au cours des décennies passées. Cette informatique est victime (la plus grande ?) du bug de l'An 2000, tous les responsables des entreprises concernées peuvent en témoigner.
  
  Les fournisseurs informatiques ne peuvent être rendus responsables du bug de l'An 2000 lui-même (rappelons que d'une part il n'est pas un bug au sens strict du terme, et que d'autre part il est fait d'au moins cinq problèmes différents, dont le plus important est le codage des années sur deux chiffres). Par contre il serait possible de les accuser d'une part de négligence (pour ne pas avoir fait assez tôt le nécessaire) et d'autre part d'exagérer l'importance du problème (pour des raisons commerciales évidentes). En ce qui concerne la négligence, je ne crois pas qu'elle puisse être volontaire (afin de créer un besoin important ultérieur) car, en effet, ce serait alors véritablement jouer avec le feu, même si l'Histoire nous révèle que certains n'hésitèrent pas à procéder ainsi au cours des siècles passés et encore aujourd'hui...
  
  Pourquoi certains systèmes possèdent une horloge temps réel à deux chiffres pour représenter les années ? Pourquoi d'autres, à ce niveau physique, ne poseront des problèmes qu'en 2035 ? Pourquoi encore le GPS (Global Positionning System) va-t-il revenir 20 ans en arrière au mois d'août 1999...? Il me semble que la réponse à toutes ces questions est la même : pour chacun de ces systèmes, des choix ont été faits, en général, au moment de leur conception. Ces choix furent souvent arbitraires, avec de temps en temps une composante technique, voire économique. Ces choix se sont ensuite propagés jusqu'à aujourd'hui, un peu involontairement, pour des raisons de compatibilité. Certains se retrouvent alors plus judicieux que d'autres (a posteriori !). Mais au passage, notons que beaucoup d'entre-eux n'ont finalement qu'une durée de vie très limitée ; mais en ce qui concerne les autres, ils sont, à cause de cette longévité, pratiquement irréversibles... Dans tous les cas, il convient de remarquer que nos réalisations ont la vie bien plus dure que ne l'imaginent leurs concepteurs. Mais, aussi que les systèmes informatiques se constituent un peu comme les terrains : par empilement de couches successives, sans jamais "nettoyer" les fondations.
  
  N'oublions pas enfin, que la connaissance complète de la date au niveau physique ne garantit pas que cette même date soit gérée correctement ni par le système, ni par les application, ni enfin par les développements spécifiques ét eventuels de l'utilisateur final !



• Le bug de l'An 2000 et les dispositifs intégrant une horloge électronique (20/08/1999) : Il est vrai que de très nombreux dispositifs intègrent des horloges électroniques : de la cafetière au sous-marin nucléaire. Les systèmes les plus simples (les adoucisseurs d'eau, les systèmes de programmation de chauffage,...), s'ils ont été conçus simplement et logiquement, ne devraient connaître que l'heure courante et le numéro de jour (ce qui est facile à faire, il suffit d'un compteur modulo 7 : {0,1,2,3,4,5,6}) par exemple, pour utiliser le tarif électrique "heures creuses". S'il en est ainsi, il semble évident que le bug de l'an 2000 ne peut pas provoquer ici de dysfonctionnement. Dans le cas, où la conception serait différente et utiliserait vraiment la date, par exemple, pour connaître le numéro de jour, il pourrait y avoir un risque d'anomalie. Il est possible de s'adresser au fournisseur, voire au constructeur ; mais il est loin d'être évident qu'il puisse fournir des informations relatives à ce problème (le ou les concepteurs ont pu quitter la société, sans avoir documenté ce qui à l'époque n'etait qu'un petit détail). Un conseil donc : dans les périodes critiques, il convient d'être plus vigilant en ce qui concerne les dispositifs intégrant une horloge électronique.



• Le bug de l'An 2000 et le milieu de la santé (02/12/1999) : Un organisme de soins est une entreprise comme une autre : il possède des clients (les patients) et des fournisseurs, mais aussi des salariés. Ainsi, le bug de l'an 2000 se pose à lui dans toute sa généralité. Il est essentiel que ce problème ait été examiné à tous les niveaux de gestion : par exemple celle des dossiers des clients et de leur historique, ou encore celle des stocks de médicaments et autres matières périssables (rappelons que des incidents se sont déjà produits et en particulier dans un hôpital londonien en mai 1998).
  
  En ces lieux, il n'est pas, de plus, envisageable de manquer de certaines fournitures extérieures essentielles (eau et électricite en particulier) ; une attention toute particulière doit donc être apportée à la vérification de la continuité de ces services et du bon fonctionnement des plans de secours (souvenons-nous à ce sujet de l'incident de l'Hôpital Edouard-Herriot de Lyon dans la nuit du vendredi 25/09/1998 au samedi 26/09/1998). Enfin, ces organismes font usage de dispositifs de haute technologie intégrant une forte composante informatique : ainsi le suivi en temps réel des paramêtres vitaux, l'assistance à la chirurgie ou encore l'imagerie médicale font appel à des ordinateurs complexes.
  
  Il ne m'est pas possible de donner une liste des appareils à risque étant donné l'immense variété de ces dispositifs. Il est donc de la responsabilité des personnels soignants d'enquêter sur les possibles dysfonctionnements des matériels qu'ils utilisent et ce auprès de leurs fournisseurs. De nombreuses applications informatiques ne sont pas sensibles a priori aux problèmes de temps et de date (par exemple l'imagerie médicale), mais d'une part ces applications reposent sur des systèmes qui la manipulent et d'autre part, même dans ce cas, le problème du suivi medical d'un patient nécessite une connaissance sans faille de la chronologie. D'autres applications y sont a priori sensibles : c'est le cas du suivi en temps réel d'un malade en soins intensifs ou encore dans l'utilisation de produits radioactifs à vie relativement courte ; dans ces deux exemples la date (au sens calendaire du terme) n'est pas essentielle, c'est plus l'écoulement du temps et la durée qui ont de l'importance. Malgré tout la gestion informatique de ces paramêtres physiques peut être réalisée d'une façon telle que la date intervienne...
  
  Il est malheureusement un peu tard pour s'occuper de ces enquêtes ; il faut donc donner aujourd'hui la priorité à la mise en place et à la validation des plans de secours ainsi qu'a l'information et à la responsabilisation des personnels concernés et du public. Enfin, il convient dans les semaines à venir de faire preuve d'une plus grande vigilance.



• Le bug de l'An 2000 et les appareils électroménagers (19/10/1999) : Nombreux sont les appareils électroménagers qui affichent la date et l'heure, et en font de plus usage : magnétoscope, lave-linge avec programmateur, système de chauffage central. Dans de nombreux cas, seule l'heure est utile (voire une durée est suffisante) ; c'est ainsi le cas des appareils devant être utilisé la nuit afin de profiter des tarifs "heure creuse" de l'EDF. Ces appareils ne devraient pas, a priori, souffrir du bug de l'An 2000. Dans d'autres cas, la date est utile ; elle peut l'être de façon "simpliste" en ne demandant que la connaissance du jour dans la semaine (cas des systèmes de gestion d'un chauffage central où il est surtout utile de faire la difference entre les jours de travail et le week-end). Enfin, pour d'autres appareils, la connaissance de la date "complète" est essentielle ; l'exemple qui vient naturellement à l'esprit est celui du magnétoscope. En fait les dysfonctionnements possibles sont alors minimes : si ce type d'appareil manipule les années sur 4 chiffres et si sa programmation relative au calendrier grégorien est incorrecte, il pourra considérer que l'an 2000 n'est pas bissextile et pourra alors refuser la programmation d'un enregistrement le 29/02/2000. Mais ainsi qu'on le voit, la gène sera mineure ; il suffira, le MERCREDI 01/03/2000 (il se croira être le MERCREDI 02/03/2000) de retarder son calendrier d'une journée. Il est vrai, malheureusement, que si de plus ce magnétoscope indique le nom du jour, ce même nom sera incorrect (MARDI 01/03/2000) et effectivement, s'il n'y a pas possibilité de le changer indépendamment du reste, il sera décalé définitivement. Mais cela n'empéchera pas d'utiliser cette machine puisque sa programmation se fera sans utiliser le nom du jour (sauf cas particulier...).
  
  Tous ces exemples montrent que les risques concernant les appareils électroménagers semblent a priori très faibles. Un conseil malgré tout : dans les semaines qui viennent soyons plus vigilants en surveillant plus attentivement notre environnement...



• Le bug de l'An 2000 et les consoles de jeu (04/06/1999) : A priori, les consoles de jeu et autres jeux vidéos, s'ils ont été conçus "proprement" ne devraient pas avoir à souffrir du bug de l'An 2000. Maintenant, d'une part il est bien connu que certains concepteurs font de "pourquoi faire simple lorsque l'on peut faire compliqué" leur devise et d'autre part, des utilisations en réseau, ou encore des jeux sous license, pourraient faire apparaitre des anomalies très certainement mineures.



• Le bug de l'An 2000 et les automobiles (03/09/1999) : Dans les automobiles les plus récentes, comme d'ailleurs dans les autres moyens de tranport (train, bateau, avion,...), l'informatique est omniprésente. Pour caricaturer la situation, il serait presque possible de définir aujourd'hui une voiture comme étant un réseau local sur lequel plusieurs ordinateurs sont raccordés, chacun ayant un certain nombre de "périphériques" : moteur, boîte de vitesses, système de freinage, climatisation, système de réglages, sonorisation, systèmes de sécurité, système de navigation,...
  
  Cette informatique est utilisée pour superviser le fonctionnement du moteur, assister le conducteur dans certaines opérations (changement de vitesse dans les modèles automatiques, freinage -systèmes de type 'ABS'-,...), vérifier la périodicité de certaines opérations (relatives à l'entretien, comme les vidanges), assurer le confort des passagers (sonorisation, réglages divers et variés,...), faciliter la navigation,...
  
  Les remarques qu'il est possible de faire relativement à cette informatique sont les mêmes que celles qu'il est possible de faire pour d'autres systèmes, en ce qui concerne le bug de l'an 2000 : sauf en ce qui concerne les vérifications de bon entretien et l'aide à la navigation, la date ne joue a priori aucun rôle dans une automobile ; si les systèmes correspondants ont été réalisés suivant ce principe, il est évident que le bug de l'an 2000 n'aura pas de conséquences sur l'allumage ou la gestion des airbags. Par contre en ce qui concerne les fonctions où la date est utile, il pourrait y avoir des dysfonctionnements dont les conséquences ne pourraient, a priori, pas être la cause d'accidents. Ainsi, par exemple et de façon peut-être caricaturale, un ordinateur embarqué pourrait considérer que la vidange n'a pas été effectuée depuis une centaine d'années et refuser alors la mise en route du moteur ; au passage, dans un tel hypothétique véhicule, ce contrôle est-il effectué uniquement au démarrage ou même en fonctionnement ?
  
  Citroën, Peugeot et Renault ont déjà conduit les tests utiles et il semblerait qu'il n'y ait rien à craindre avec les véhicules de ces marques. Il faut rappeler de plus que la sécurité est un soucis permament des constructeurs automobiles. Maintenant, il ne faudra pas oublier qu'une automobile circule dans un environnement complexe et sensible au bug de l'an 2000 : gestion du trafic, approvisionnement en carburants, péges,...



• Le bug de l'An 2000 et les ascenseurs (04/06/1999) : Certains type d'ascenseurs sont équipés de dispositifs de surveillance de la fréquence des opérations de maintenance. Ceux-ci peuvent utiliser la date. Une mauvaise gestion de cette dernière peut faire croire que la dernière opération de contrôle a été effectuée depuis beaucoup trop longtemps, alors qu'il n'en n'est rien. Dans ces conditions, l'action effectuée consiste généralement à amener les cabines à un niveau donné avec les portes ouvertes et sans possibilité de les utiliser davantage. Le bug de l'an 2000, "interne" aux ascenseurs, ne risque donc pas de mettre des personnes dans une situation inconfortable, voire dangereuse. Malgré tout, il ne faut pas oublier qu'un ascenseur demande de l'énergie électrique et peut utiliser, au niveau des urgences, le téléphone. Il semble donc que si des problèmes de type "an 2000" sont à craindre avec des ascenseurs, leurs causes en seront assez probablement "externes". Il ne faut pas oublier non plus qu'il y a en permanence des ascenseurs qui tombent en panne pour des raisons diverses et variées ; ainsi, un ascenseur hors service le 01/01/2000 ne sera pas nécessairement la victime du bug de l'An 2000. Un petit conseil donc, évitons de tenter le diable : ne sollicitons pas (trop) les systèmes sensibles aux instants critiques !



• Le bug de l'An 2000 et les vols aériens (04/06/1999) : Le transport aérien est sensible au problème de l'an 2000 à quatre niveaux au moins : d'abord, les compagnies aériennes sont des entreprises comme les autres, et comme les autres donc, elles sont victimes du bug de l'An 2000. Ensuite, dans la gestion des clients (les passagers) la date et l'heure interviennent d'une façon fondamentale. D'autre part, le contrôle aérien fait un usage intensif de l'informatique pour laquelle la chronologie est vitale. Enfin, les avions modernes sont avant tout des systèmes informatiques volants. Les grands constructeurs (Airbus, Boeing,...) ont poursuivi au cours des mois passés des investigations qui ont montré que l'informatique de bord n'était que très peu, voire pas du tout, concernée par le bug de l'An 2000 ; malgré cela, n'oublions pas que cette informatique embarquée est particulièrement complexe (rappelons au passage, l'échec du vol Ariane 501 dû a une petite anomalie logicielle). En fait, le plus grand risque se situe au niveau du contrôle aérien, tant au niveau des accès aux aéroports qu'au niveau des routes aériennes. Dans de nombreux cas, l'informatique est ancienne et donc difficilement maintenable ; d'autre part, sans elle, les contrôleurs sont relativement désarmés. Il n'est donc pas question qu'elle vienne à être indisponible, ne serait-ce que quelques minutes. Souvent, la possibilité de passer en manuel est évoquée. Il est vrai que des plans de secours sont prêts en cas d'anomalies ; mais ici, comme ailleurs, ces plans font généralement l'hypothèse de la bonne santé de tout l'environnement (en particulier les approvionnements énérgétiques, les moyens de télécommunications,...). Or, en ce qui concerne le bug de l'an 2000, personne n'est a priori à l'abri. Dans ces conditions, certains plans de secours pourraient ne pas fonctionner, et ici, la vie humaine est en jeu. La prudence s'impose donc : "mieux vaut prévenir que guérir". Il convient donc de limiter le nombre des vols au cours de ces quelques heures "périlleuses" (n'oubliant pas que la Terre possède 24 fuseaux horaires et qu'ainsi, le passage de 1999 à 2000 va durer 24 heures) et de bloquer peut-être certaines destinations à risques (à l'Est, en Afrique,...) ; c'est en tout cas l'une des propositions américaines à ce sujet.



• Le bug de l'An 2000 et les engins spatiaux (28/09/1999) : Un engin spatial est un système d'une haute complexité dans lequel l'informatique joue un rôle fondamental. En amont, l'ordinateur est utilisé lors de sa conception et de sa fabrication, puis évidemment lors de sa mise en orbite par un lanceur. Au cours des années passées des incidents assez fréquents, causant la perte d'engins ou une réduction de leurs fonctionnalités, ont montré que la fiabilité absolue relevait du domaine de l'utopie. Ces remarques s'appliquent naturellement aux phases d'exploitation des engins spatiaux. Certaines de leurs activités ne nécessitent pas la connaissance de la date ; d'autres, par contre, la réclame : ainsi, des satellites effectuant des mesures renvoient généralement celles-ci sur Terre accompagnées de la date et de l'heure de leur saisie. Ainsi donc, les engins spatiaux pourraient être, eux aussi, victime du bug de l'An 2000. Evidemment, cela ne veux pas dire pour autant qu'ils vont s'écraser sur terre ; par contre ils pourraient être éventuellement victime de dysfonctionnements dans le maintien correct de leur position et de leur orientation, ainsi que dans l'accomplissement de leurs missions. Enfin, il conviendra de ne pas oublier que d'une part, par définition leur accessibilité est excessivement réduite ; dans ces conditions, certaines corrections nécessaires pourraient ne pas être réalisables, depuis la Terre, en ce qui les concerne. D'autre part, ces systèmes demandent des développements de très longue durée et ainsi, ceux qui sont actuellement en exploitation (même récente) ont pu être conçu à une époque ou le bug de l'An 2000 n'était pas encore d'actualité...
  
  Pour ceux qui utilisent des satellites, en particulier les chaînes de télévision, il n'est pas déraisonnable de faire appel, dans les semaines qui viennent, à de la redondance afin de garantir la continuité des liaisons. En effet, malheureusement, quelles que soient les précautions méthodologiques prises, des anomalies peuvent échapper aux tests ; souvenons-nous par exemple de (vol 501) et plus récemment (le 23/09/1999) de la perte de la sonde américaine Mars Climate Orbiter de la NASA pour une "vulgaire" question d'unités de mesure (au passage, évidemment, tout cela n'a rien à voir avec la date, mais avec la non fiabilité de l'informatique en général). Il convient d'ajouter que la redondance doit faire appel ici, comme ailleurs, à plusieurs systèmes et fournisseurs différents (rappelons que sur Ariane 501, la redondance du système informatique de la centrale inertielle était réalisée avec 2 processeurs identiques supportant la même programmation...).



• Le bug de l'An 2000 et les municipalités françaises (04/06/1999) : Une municipalité est une entreprise comme les autres : elle a ses employés, ses clients et ses fournisseurs. Elle possède aussi des missions vitales : assurer par exemple, la sécurité et le bien-être des administrés. Comme toute entreprise, elle est donc victime a priori du bug de l'An 2000. S'il est vrai que les dirigeants des PME françaises y sont peu sensibilisés, c'est encore plus vrai de nos maires. Comme les entreprises, il y a des municipalités pour lesquelles le problème est d'une effroyable complexité (Paris par exemple), et d'autres, les plus petites en particulier, pour lesquelles la sensibilité est bien moindre. Mais dans tous les cas, il est important que les élus locaux se sentent concernés et responsables. Il est donc essentiel qu'ils s'inquiètent, par exemple auprès des compagnies fournissant l'eau potable, de la continuité et de la qualité (c'est peut-être un point plus important encore) du service. Il est aussi essentiel qu'ils mobilisent leurs troupes et principalement les services de secours (pompier et police), en les informant des problèmes et en mettant en place des procédures d'exception au niveau des communications. Face à l'urgence, il est essentiel que tout individu se sente concerné et responsable d'une part en agissant (même très localement) et d'autre part en comprenant que de la réaction de chacun d'entre-nous face aux difficultés (réelles ou potentielles) dépend une partie du succès (ou de l'échec)...
  
  A la fin du mois de mai 1999, le livre "Passage à l'an 2000, guide pour les maires de France" a été publié par l'Association des Maires de France. Il est disponible sur Internet à l'adresse. Rappelons à ce propos que depuis 1994, le Code Pénal prévoit qu'un maire peut être reconnu responsable des accidents survenant dans sa commune, par exemple en cas de négligence. Or, ne pas s'enquérir de la "compatibilité an 2000" d'une municipalité pourrait être vu ultérieurement comme une négligence...



• Le bug de l'An 2000 et les TPME (28/10/1999) : Il est évident qu'il vaut mieux prévenir que guérir. Cela signifie qu'il faut d'abord s'interroger sur l'utilisation que l'on fait de l'informatique : si un ordinateur est purement décoratif et inutilisé, il est évident que de ne rien faire, ne fait courir que peu de risques à l'entreprise. Si par contre, celui-ci assure la gestion des commandes, des comptes-client, la facturation, la comptabilité, les relances, voire supervise la production, alors il est préférable d'agir. Dans le cas du bug de l'an 2000, cette action ne conduit pas nécessairement à des investissements importants ; elle doit en fait commencer par des tests au niveau du matèriel, du BIOS, du système d'exploitation, des applications utilisées et enfin des éventuels développements spécifiques. En l'absence de compétences personnelles, il est important de s'assurer alors de l'aide de personnes qualifiées. Au cas où ces tests montreraient qu'il y a danger, deux attitudes sont alors possibles : la première qui consiste à assurer la compatibilité par des remplacements éventuellement coûteux ; la seconde qui consiste à evaluer les dangers et à mettre en place un plan de secours permettant de garantir la continuité en cas de défaillance. Cela pourra signifier un retour provisoire à des pratiques faisant appel au papier et au crayon, en ayant pris la précaution d'éditer un certain nombre de documents essentiels et actuellement informatisés. Ce plan de secours devra aussi planifier l'activité de l'entreprise au moment des dates critiques et prévoir, par exemple, d'interrompre pendant deux ou trois jours les activités.
  
  Il ne faudra pas négliger le fait qu'ici, comme ailleurs, une part de plus en plus importante du patrimoine des entreprises (qu'elles soient multi-nationales ou TMPE) est virtuelle (c'est-à-dire sous forme de fichiers informatiques), et que ce patrimoine d'un nouveau type n'est peut-être pas aussi pérenne qu'on le croit trop souvent...



• Le bug de l'An 2000 et une possible récession économique (08/06/1999) : L'informatique intervient à plusieurs niveaux dans nos entreprises : la gestion du personnel, la gestion des clients et de leurs commandes, le contrôle des processus et de la fabrication, le contrôle de la sécurité, une partie des échanges avec les fournisseurs et les clients. Généralement, chacun de ces niveaux utilise de façon intensive la date. Il est alors évident que toute anomalie dans la gestion et la manipulation de cette donnée peut avoir des conséquences graves quant au bon fonctionnement des entreprises, à leur image de marque et à leur santé. Bien entendu, il en est de plus sensibles que d'autres : les banques évidemment, mais, par exemple, une entreprise de vente par correspondance ne peut se permettre une discontinuité dans les opérations de son service informatique, même pendant quelques minutes et a fortiori pendant plusieurs jours.
  
  Un scénario possible pour une entreprise mal préparée est donc la faillite immédiate ou à moyen terme, puisque les statistiques montrent qu'une proportion non négligeable des entreprises qui sont victime d'un sinistre grave (incendie par exemple) font faillite dans les mois qui suivent. Alors, si de nombreuses entreprise faisaient faillite, cela pourrait entrainer une récession mondiale (puisqu'un tel scénario est possible dans tous les pays et quelles que soient les activités) avec donc les conséquences sociales que l'on imagine facilement.
  
  Une autre source possible de faillite (qualifiable de "externe" par opposition à la cause précédente qui était "interne"), même si des tests sont actuellement conduits par les banques et les places financières du monde entier (avec un certain succès semble-t-il, ce qui est de bonne augure) se situe au niveau de la bourse. En effet, l'expérience quotidienne montre que ce qui fait la valeur d'une entreprise n'est pas fait uniquement de ses actifs, de la qualité de ses produits, de la compétence de ses employés, mais aussi d'un certain nombre de paramêtres que peu de gens maîtrisent réellement et complètement. Ainsi, des anomalies informatiques (éventuellement minimes) dans quelques systèmes boursiers pourraient provoquer des fluctuations importantes (et donc s'amplifier) sur la valeur des actions de quelques grandes multi-nationales et ainsi provoquer artificiellement la faillite de certaines d'entre-elles.
  
  Malheureusement toutes les entreprises (que ce soit en France ou bien à l'étranger) ne sont pas au même niveau de sensibilisation et évidemment de préparation. Or, il est presque banal de dire que notre économie est mondialisée ; en caricaturant : tout dépend de tout... A titre d'exemple, un grand constructeur automobile possède plusieurs centaines de sous-traitants ; or, il est impensable de mettre sur le marché une automobile incomplète, même au niveau de ses accessoires décoratifs. Ainsi un sous-traitant mineur peut bloquer le processus entier de fabrication. C'est une illustration de l'effet domino.
  
  Enfin, un dernier problème ne doit pas être négligé : celui de réactions de panique du public, provoquant artificiellement des pénuries sur certains produits essentiels (eau potable, essence, mais aussi argent liquide...) éventuellement, même en l'absence de tout problème technique... C'est pourquoi il est essentiel d'informer, de sensibiliser et de responsabiliser le public.



• Le bug de l'An 2000 et les relations avec les fournisseurs informatiques (09/06/1999) : Il convient de noter en premier lieu que la notion de "conformité an 2000" n'est pas formalisée, d'autant plus que les problèmes à attendre ne se limitent pas, contrairement à ce que l'on croit trop souvent, a la Saint Sylvestre 1999, mais regroupent un certain nombre de dates critiques supplémentaires (21/08/1999, 09/09/1999, 03/01/2000, 29/02/2000, 01/03/2000,... cette liste n'étant malheureusement pas exhaustive).
  
  Il semblerait qu'en France la législation ne soit pas prête à traiter simplement les litiges qui résulteront de ces problèmes. Il n'y a actuellement pas de jurisprudence, même si deux jugements (Créteil 16/06/1998 et Dijon 04/02/1999) ont déjà été rendus. Les enseignements qu'il est possible de tirer de ces deux cas sont que d'une part le bug de l'An 2000 ne peut être considéré comme un vice caché et que d'autre part, l'on ne peut imposer à un fournisseur de garantir un usage perpétuel pour ses produits (en particulier dans un domaine qui évolue aussi rapidement que l'informatique). Il me semble que le fait que l'on ne puisse considérer le bug de l'An 2000 comme un vice caché soit contestable. En effet, un logiciel (ou un matériel) destiné à gérer des dates doit être capable de gérer toutes les dates, sans exception au cours d'une durée de vie prévisible et raisonnable. D'autre part, ces problèmes sont connus depuis bien longtemps et l'on peut dire que de ne pas avoir fait le nécessaire constitue certainement une négligence de la part des fournisseurs. Il ne faudrait pas, non plus, rejeter la faute sur le client sous pretexte qu'il n'aurait pas demandé explicitement, lors de la transaction d'acquisition, cette fameuse compatibilité. Cela me semble aussi ridicule que de demander à son garagiste que l'on exige que la voiture que l'on acquiert ne devra pas s'immobiliser en passant de 1999 a 2000 kilomêtres !
  
  Malheureusement, ceci est un avis personnel, et ce sont les tribunaux qui trancheront. Il apparait donc que ce qui est prèponderant alors est le le type et le contenu du contrat qui lie le fournisseur à l'acquéreur.
  
  Enfin, en ce qui concerne les dégats éventuels, là aussi la loi du 19/05/1998 en matière de produits défectueux ne sera que d'une aide restreinte car, en effet, elle semble ne s'appliquer qu'aux dommages matériels, excluant les dommages économiques et "virtuels" (la perte ou la pollution de données, par exemple), alors que les assureurs prennent actuellement leurs distances...



• Le bug de l'An 2000 et les réactions du public (29/06/1999) : Souvenons-nous des scènes d'émeute que les actualités télévisées nous ont montrées au cours des premiers jours de l'année 1999. Elles furent causées par l'indisponibilité, pendant quelques heures, du système informatique gérant les comptes d'épargne de la Poste.
  
  Des irresponsables conseillent actuellement de réaliser en liquide tous les avoirs bancaires en prévision des éventuelles difficultés à venir. Il est évident qu'il n'y pas assez de liquidité pour satisfaire tout le monde. Le problème est le même pour les produits de première nécessité : eau potable, sucre, huile, farine, essence,... Il est donc possible d'imaginer qu'aucun problème technique grave (causé par le bug de l'An 2000) ne soit rencontré au cours des mois à venir et que malgré cela, nous ayons à vivre des moments très difficiles à cause de quelques pénuries artificielles.
  
  C'est pourquoi il est fondamental d'expliquer simplement au public la nature des problèmes, de l'informer périodiquement et de façon parfaitement transparente de l'avancement des travaux en ce qui concerne, en particulier, les grands services publiques. Enfin, il est vital de responsabiliser ce même public, en lui montrant que de ses réactions dépendent en grande partie le succès de ces opérations. L'homme est un maillon faible de la chaîne informatique...



• l'an 2000 et le troisième millénaire (29/06/1999) : Même si cela peut paraître choquant, le 01/01/2000 ne sera pas l'entrée, ni dans le vingt-et-unième siècle, ni dans le troisième millénaire. Il faudra attendre pour cela 366 jours, soit le 01/01/2001. L'explication est simple : il n'y pas eu d'année 0 ; le premier siècle, qui compta évidemment 100 années, fut constitué des années {1,2,...,99,100}, et ainsi de suite. Le vingtième siècle est constitué, lui, des années {1901,1902,...,1999,2000}. Une dernière remarque : les deux premiers chiffres de l'année ("19" pour "1999", ou "20" pour "2000") ne donnent, malheureusement pas, le numéro de siècle ; s'il en était ainsi, en 1999, nous serions au dix-neuvième siècle...



• Le bug de l'An 2000 et le devenir des informaticiens en extra (29/06/1999) : De nombreux informaticiens ont du être embauchés pour traiter les problèmes urgents auxquels nous sommes confrontés, et en particulier le bug de l'An 2000. Deux raisons non exclusives l'une de l'autre ont conduit à cela : d'une part, de nombreux programmes encore opérationnels aujourd'hui sont rédigés dans des langages obsolètes (assembleurs divers et variés, mais surtout le Cobol) ; dans ces domaines les compétences manquent cruellement et c'est dans le vivier des retraités que se trouvent les forces utiles. D'autre part, l'ampleur du travail est telle, que la main d'œuvre manque tout simplement.
  
  La question se pose évidemment de savoir si ces emplois sont précaires ou pas. Il est à craindre que oui. Mais, il y a malgré tout une lueur d'espoir. En effet, les travaux actuellement accomplis sont en grande partie des bricolages hâtifs et dangereux (par exemple, de nombreux rafistolages utilisent la notion d'année pivot). Partant en retard, il était effectivement difficile de faire mieux (la situation est un peu similaire à celle qui consisterait à entreprendre les travaux de consolidation de la Tour de Pise alors qu'elle est déjà à terre...) ; il ne faudra donc pas oublier, dans les années à venir que d'une part le problème prépondérant (le codage des années sur deux chiffres) n'a pas été corrigé, et que d'autre part, les corrections ont introduit un dispositif, l'année pivot, d'une durée de vie limitée et fort dangereux.
  
  Ainsi, dans les années à venir, il faudra bien se décider à faire les choses proprement, car, sinon, les difficultés que nous connaissons aujourd'hui pourraient n'être rien à côté de celles qui s'amoncelleraient alors à l'horizon. Enfin, nous devons méditer tous ces incidents ; essayons à l'avenir de construire une informatique de meilleure qualité puisqu'elle est notre infrastructure essentielle. Il y a donc la un travail fantastique à accomplir...



• Le bug de l'An 2000 et les mesures extrêmes (29/06/1999) : Il est clair que certains pays sont mieux préparés que d'autres, même si personne ne peut vraiment donner de leçon en la matière.
  
  Il est vrai que les souvenirs de Tchernobyl ou ces images qui nous montrent les sous-marins de la marine de l'ex-URSS, pourrissant dans les ports de la presqu'île de Kola, nous font frémir. Que se passerait-il effectivement si quelques unes des centrales nucléaires de la Russie connaissaient des "difficultés" dans les mois à venir ? Il me semble que d'une part, il n'est pas nécessaire d'invoquer le bug de l'An 2000 pour craindre ces catastrophes (à titre d'exemple, il semblerait que le dispositif de confinement mis en place à Tchernobyl montre des signes de défaillance...) ; à tout moment donc, nous risquons quelque chose. D'autre part, préparer des mesures exceptionnelles en prévision de ces catastrophes hypothétiques pourrait avoir un effet dévastateur au niveau du public, peut-être bien pire que celui des catastrophes elles-mêmes, si elles se réalisaient.
  
  Dans de telles circonstances d'ailleurs, le choix politique à faire entre "informer" et "ne pas informer pour ne pas semer la panique" est bien difficile !



• Le bug de l'An 2000 n'est pas un bug et il est multiple (29/06/1999) : Un bug désigne en informatique une erreur en général involontaire (au passage, cette expression tirerait son origine d'un véritable insecte -bug en anglais- dont le corps aurait coincé l'un des relais de l'ordinateur Mark II, dont Mary Grâce Hopper, la mère du Cobol, était l'un des responsables). En fait, il est principalement le résultat de choix anciens judicieux à l'époque et regrettables aujourd'hui et est composé de cinq problèmes différents.



• A quelques jours du bug de l'An 2000 (10/12/1999) : Lorsque j'ai commencé en 1996 ma campagne bénévole d'information relative au bug de l'an 2000, j'ai cru bon de tenir un discours technique teinté très légèrement de catastrophisme afin de sensibiliser au plus vite l'ensemble des acteurs à la réalité, à la gravité et à l'universalité du problème (des problèmes...).
  
  Aujourd'hui, à quelques jours de l'obstacle majeur (la Saint Sylvestre 1999), il n'est pratiquement plus temps d'agir pour ceux qui n'auraient encore entrepris aucunes mesures correctives. Il convient de noter que, bien que tous soient partis trop tard, de gros efforts ont été malgré tout accomplis ; la France, en particulier, se retrouve actuellement sixième au classement des pays les mieux préparés. Mais, même si les grandes entreprises ont un bon niveau de préparation, il subsiste encore des ombres au tableau : les administrations ne sont pas en avance, un quart des petites entreprises n'agiront qu'a posteriori, de nombreux correctifs utilisés sont provisoires (ce point ne devra pas être oublié plus tard...) et certains pays (dont nous dépendons d'une façon ou d'une autre), tel la Russie, n'ont pratiquement rien entrepris (dans ce domaine..., alors qu'il semble y avoir là-bas de l'énergie et des budgets pour d'autres opérations moins honorables...). Il est, dans ces conditions, logique de s'attendre à des dysfonctionnements (très probablement limités en ce qui concerne nos pays) au cours des semaines, voire des mois, à venir, puisqu'ici, comme ailleurs, le risque 0 n'existe pas. Pour tous, le temps est donc maintenant aux plans de secours.
  
  Mais il reste encore, malgré tout, quelques jours pour responsabiliser l'ensemble des citoyens. En effet, que cela soit à titre professionnel ou privé, de l'attitude de chacun d'entre-nous peut dépendre, en partie, le succès ou bien l'échec... Agissons donc de façon responsable et solidaire, par exemple, en ne constituant pas des stocks (d'argent liquide, de produits de première nécessité ou encore d'essence) au risque de créer de graves pénuries artificielles (dans le sens ou aucun problème technique lié au bug ne les aurait provoquées). De même, aux instants les plus critiques (aux alentours de minuit le 31/12/1999) évitons de surcharger les systèmes vitaux que sont la distribution d'électricite et les moyens de télécommunications (il est de notoriété publique que tous les ans, aux douze coups de minuit annonçant la nouvelle année, le trafic téléphonique augmente considérablement).
  
  Mais il convient aussi de regarder le bug de l'an 2000 de façon positive, tel un avertissement. En effet, aujourd'hui notre vie dépend fondamentalement de nos technologies et de l'informatique en particulier. Les systèmes actuellement développés possède une complexité que personne ne maîtrise plus et pour lesquels les erreurs intrinsèques sont de plus en plus nombreuses. Ne sommes-nous point en train de construire sur du sable ? Un très gros effort doit donc être réalisé du côté de l'éducation et de la formation : l'informaticien pourrait peut-être alors passer de l'état de "bricoleur" (de génie parfois...) à celui d'"artiste". L'ordinateur électronique depuis sa naissance aux environs de la seconde guerre mondiale, de machine à calculer est rapidement devenu l'un des collaborateurs essentiels de l'homme, dans toutes ses activités. Faisons donc en sorte qu'il le reste pour le plus grand bien de l'humanité.
  
  Bonne année à tous et rendez-vous dans un an, le 01/01/2001, pour fêter (enfin) l'arrivée du vingt-et-unième siècle et du troisième millénaire...
  
  Depuis que ces quelques lignes ont été écrites (et que des propos identiques ont été tenus sur les ondes), deux courriers électroniques m'ont accusé d'une part d'avoir tout à la fois un discours lénifiant, désinformant et "télécommande" (je cite : sur l'ordre d'on ne sait quelle autorité), et d'autre part d'être devenu maître de la litote. Le 28/12/1999, quelques remarques s'imposent donc...
  
  
  • Le naufrage du pétrolier Erika le 12/12/1999, au large de Brest, a montré que même dans dans un domaine techniquement parfaitement délimité, avec un suivi en temps réel de l'évolution de la situation à l'aide de moyens très complets d'observation associés à des outils de prévision faisant appel aux techniques les plus avancées, il est plus qu'hasardeux de faire des prévisions (le premier contact de la nappe de pétrole avec les côtes n'a pas eu lieu là où elle était attendue, loin s'en faut). En ce qui concerne donc le bug de l'an 2000, de quelconques prévisions seraient irresponsables. L'individu doit alors faire un choix basé sur son expérience et sur son sentiment sur la question : une confiance relative et raisonnée est donc une possibilité...
  • Dire, par exemple, qu'en France les grandes entreprises ont un bon niveau de préparation (en précisant d'ailleurs immédiatement qu'il subsiste des ombres au tableau), ce n'est pas dire (et cela ne signifie pas) qu'elles ne connaîtront pas des difficultés plus ou moins graves ; cela veut dire que, malgré les "retards au démarrage" et les difficultés de sensibilisation initale, elles ont agi ("Mieux vaut tard que jamais") et se sont mieux préparés que dans beaucoup d'autres pays. Il n'y a pas, à mon avis, contradiction entre "avoir confiance" et "connaître les dangers". Par analogie : lorsque je monte dans mon automobile, je fais confiance (par expérience) à ceux qui l'ont construite et à ceux qui l'entretiennent, mais je n'ignore pas d'une part qu'elle peut "me trahir" et que d'autre part il y a sur nos routes plusieurs milliers de morts par an (pour des raisons diverses et variées...).
  
  Je me permets donc de résumer tout ceci en :
  
  
  • Soyons responsables,
  • Soyons plus vigilants dans les jours (mais aussi dans les semaines et les mois) qui viennent,
  • Souvenons-nous que toute prévision est vaine et
  • Que le risque 0 n'existe pas,
  • Enfin, n'oublions pas demain que les solutions mises en place hier ne sont pour la plupart qu'incomplètes et provisoires.
  
  Plus que quelques heures pour avoir les premiers élements de réponse...






Quelques références utiles :




• Les défaillances de l'informatique : une nouvelle menace ? L'exemple du bug de l'an 2000,
• Le Bug de l'An 2000 [ou les "Faiblesses" de l'Informatique par l'Exemple],
• Le Bug de l'An 2000 - Comprendre l'informatique jusqu'à ses défaillances,

8.1-Le problème :

Il est réel, d'une ampleur sans précédent et possède des contraintes drastiques. Il est à considérer comme une véritable épidemie demandant une mobilisation (inter-)nationale ; nous sommes tous concernés et personne n'est à l'abri ! Nous devons, dans ces circonstances sans précédent, partager les informations que nous possédons et réapprendre donc la solidarité...

Ce problème peut aller jusqu'à menacer la sécurité -voire l'existence- des états.




8.2-Profiter de l'occasion :

C'est peut-être le moment de mettre de l'ordre dans notre informatique, d'avoir une meilleure connaissance de nos systèmes et d'introduire systématiquement une stricte méthodologie du développement (c'est peut-être là le seul bon côté du problème...). D'une façon générale, en ce qui concerne les systèmes de toute nature que nous spécifions et concevons, il serait peut-être bon de comprendre que leur complexité toujours plus importante est, bien souvent, loin d'être maîtrisée, cela pouvant conduire à des échecs retentissants mais aussi à des catastrophes allant jusqu'à menacer la survie de l'Humanité...

Au passage, n'oublions surtout pas que les solutions actuellement mises en place sont bien souvent provisoires et qu'il faudra donc appliquer tôt ou tard les solutions définitives, sous peine de voir ressurgir les mêmes difficultés, mais aggravées, dans les années à venir !

Mais tirerons-nous enfin les leçons de l'Histoire ? Enfin, n'oublions pas que toute médaille à son revers et que malgré ce que nous venons d'évoquer, l'ordinateur, levier de l'esprit, est l'outil indispensable qui nous permet de progresser sur la voie de la Connaissance : en conséquence, pas d'autodafé de ces machines mais une meilleure compréhension de leurs limites.

Les victoires déjà rencontrées lors du passage à la Monnaie Unique le 01/01/1999 ou lors du GPS week roll over le 23/08/1999 sont de bonne augure pour la suite ; mais ne baissons pas la garde...

Alors, Fin du Monde ou fin d'un monde ? A nous de choisir...




8.3-"Mieux vaut prévenir que guérir", "Rien ne sert de courir, il faut partir à point" et "Un homme averti en vaut deux".