AVERTISSEMENT :

• INTRODUCTION
• 1-LES PHENOMENES NON LINEAIRES NATURELS
• 2-LES PHENOMENES NON LINEAIRES ARTIFICIELS
• 3-LA PREHISTOIRE DE L'INFORMATIQUE
• 4-L'INFORMATIQUE AUJOURD'HUI
• 5-QUELQUES REMARQUES CONCERNANT LES DEVELOPPEMENTS INFORMATIQUES
• 5.1-De la durée de vie des applications informatiques
• 5.2-De l'absence de méthode
• 5.3-De la non prévisibilité
• 5.4-De la compatibilité ascendante
• 5.5-Des risques encourus
• 5.6-De la capacité limitée des ordinateurs
• 6-LE BUG DIT DE L'AN 2000
• 6.1-Le pseudo-numéro de siècle maltraité
• 6.2-Les dates inaccessibles
• 6.3-L'arithmétique sur les dates
• 6.4-La capacité limitée
• 6.5-Les années bissextiles
• 7-LES RESPONSABLES (LES COUPABLES ?)
• 8-LES SOLUTIONS
• 8.1-Le cauchemar
• 8.2-Le mythe de la solution miracle
• 8.3-L'inventaire
• 8.4-Le rafistolage
• 8.5-L'année pivot
• 8.6-Les tests
• 8.7-Les coûts
• 8.8-Les dead lines
• 8.9-L'effet domino
• CONCLUSION

INTRODUCTION :

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é. Nous connaissons déjà les faiblesses de ces réseaux en face d'attaques "terroristes" tant physiques que logiques, mais il existe aussi des risques internes, voire intrinsèques. 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é à résister à des perturbations ? Ne seraient-elles pas que de gigantesques châteaux de cartes prets à s'écrouler à la moindre occasion ? Nous allons montrer sur un exemple précis et d'apparence anodine, celui de la gestion des dates dans les ordinateurs, qu'il en est malheureusement ainsi, et qu'un malheureux grain de sable dans le silicium de nos microprocesseurs pourrait être à l'origine d'importantes défaillances, tout ceci sans faire preuve d'un catastrophisme excessif et en conservant présent à l'esprit qu'il vaut mieux prévenir que guérir.

A l'approche de l'an 2000 ressurgit un millénarisme qui contrairement à celui de l'an 1000 n'annonce pas les splendeurs du Royaume de Dieu. Bien au contraire nos peurs sont aujourd'hui bien réelles, bien concrètes : le spectre de la pollution, les risques nucléaires,... plannent au-dessus de nos têtes comme autant d'oiseaux de proie prêts à fondre sur nous ; qui n'a pas tremblé à la vue de ces sous-marins nucléaires de l'ex-marine soviétique en train de pourrir dans les ports de la presqu'île de Kola ?

La Science nous a appris au cours des siècles et des décennies passées que le premier janvier de l'an 2000 serait un jour comme les autres dans l'histoire de l'Univers ; la probabilité pour qu'une catastrophe naturelle (tremblement de terre, éruption volcanique, collision d'un corps céleste avec notre Terre,...) ait lieu de jour-là est égale à celle qu'elle ait lieu à n'importe qu'elle autre date. Malgré cela, ce jour particulier (et d'autres peut-être, ainsi que nous le verrons par la suite) pourrait rester inscrit dans l'histoire de l'Humanité comme celui d'un cataclysme artificiel aux conséquences aujourd'hui encore inimaginables.






1-LES PHENOMENES NON LINEAIRES NATURELS :

Pour bien comprendre cela, il est bon d'évoquer brièvement les phénomènes que l'on dit non linéaires et que la science étudie depuis relativement peu de temps (de par leur complexité mathématique). Ils sont caractérisés par le fait que des causes infimes peuvent s'amplifier démesurement et avoir des conséquences sans commune mesure avec ce qui leur a donné naissance. Cela a une conséquence immédiate : l'impossibilité, tant théorique que pratique (par le calcul, par exemple), de faire à leur sujet des prévisions à long terme. Les exemples naturels de tels phénomènes sont légions, mais celui qui vient spontanément à l'esprit est celui qui a donné naissance à l'expression faire boule de neige : les avalanches. Dans ce cas particulier, quelques grammes de neige mis en mouvement sur une pente par un animal, ou encore par le vent, deviennent parfois en quelques minutes plusieurs dizaines de milliers de tonnes ravageant tout sur leur passage, semant alors la terreur et la mort.






2-LES PHENOMENES NON LINEAIRES ARTIFICIELS :

Dans le langage scientifique, il est fréquent de parler de l'effet papillon, expression imagée, imaginée par Edward Lorenz dans les années soixante, alors qu'il travaillait au MIT sur le problème de la turbulence. Grâce à son ordinateur, il découvrit le phénomène dit de la sensibilité aux conditions initiales qui caractérise mathématiquement les phénomènes non linéaires (au cours de ces dernières années, l'auteur de cet article a attiré l'attention de la communauté scientifique sur une conséquence très importante de cela : l'impossibilité de faire du calcul numérique précis, voire utile, sur ces systèmes). Au cours des années passées, la Science et la Technologie nous ont fourni des exemples de phénomènes non linéaires artificiels.

Décrivons l'un d'entre-eux : celui de l'échec du vol Ariane 501, le 4 juin 1996. Un lanceur moderne est un système d'une effroyable complexité dont les objectifs de réalisation sont la performance, la compétitivité et la fiabilité. Pour construire Ariane 5, certains modules logiciels furent importés d'Ariane 4 ; en particulier des programmes de la centrale inertielle qui exploitent des mesures faites afin de déterminer les paramêtres de vols réels de la fusée et de les comparer aux paramêtres théoriques et nécessaires au bon accomplissement de la mission. Certaines de ces mesures donnent des valeurs exprimées à l'aide de nombres dits flottants 64 bits qui sont ensuite convertis à l'intérieur de ces programmes en nombres dits entiers 16 bits. Ces conversions avaient toujours été réalisables dans Ariane 4 et cette possibilité constituait en fait une regrettable hypothèse implicite en ce qui concernait l'amplitude de ces résultats. Malheureusement, dans Ariane 5, dès le premier vol, des mesures de vitesse violèrent cela et provoquèrent des défauts reproduits presqu'immédiatement sur le calcul de secours qui était conçu et réalisé de façon strictement identique au calculateur primaire. Il fut alors considéré que les paramêtres réels de vol étaient effectivement incorrects, ce qui provoqua la décision de détruire le lanceur. Il convient d'ajouter, qu'apparemment, la séquence de programme en cause était en fait inutile sur Ariane 5, mais avait été conservée parce que, ainsi que cela sera répété ultérieurement, il est toujours risque d'intervenir (par suppression ou par adjonction) sur un programme qui fonctionne correctement. Ainsi, dans cet exemple réel, une anomalie infime s'est amplifiée jusqu'a avoir des conséquences ayant coûte un nombre appréciable de milliards de francs. Il convient pour en terminer avec cet incident "exemplaire", d'ajouter que les commentaires précédents ne sont en aucune façon destinés à critiquer les méthodes des ingénieurs concernés ; leurs compétences ne peuvent être mises en doute. C'est malheureusement la complexité extrême de ces systèmes qui rend impossible (a jamais ?) la prévision absolue en ce qui les concerne ; nous aurons l'occasion de revenir ultérieurement sur ce point.






3-LA PREHISTOIRE DE L'INFORMATIQUE :

L'informatique a récemment fêté son jubilé. Né à la fin des années quarante, l'ordinateur avait à sa naissance vocation de machine à calculer et ses pères imaginaient que seuls quelques exemplaires de ces monstres nous seraient utiles. Pesant des dizaines de tonnes, occupant des centaines de mêtres carrés au sol, ils demandaient des armées de spécialistes (les grands prêtres de cette nouvelle religion) pour s'occuper d'eux. Puis, dans les années soixante, les applications de gestion virent le jour, mais leurs performances et les capacités de leurs mémoires restaient très limitées. Au debut des années soixante-dix des mémoires centrales de 32 kilo-octets et des disques de moins d'un méga-octet étaient considérés comme standards. Ces mémoires semblent aujourd'hui dérisoires et pour ceux qui ont utilisé ces machines et pratiquent celles d'aujourd'hui, il y a là un certain mystère : comment faisait-on pour travailler et produire des résultats pertinents avec de telles configurations ?

En ces temps reculés, point d'écran couleur servant à l'interaction avec ces machines, mais des rubans de papier perforés de petits trous ronds codant les valeurs 0 et 1 de l'algèbre binaire et surtout les cartes perforées et leurs 80 colonnes. Elles furent inventées par Hermann Hollerith à l'occasion du recensement américain de 1890 et donc en un temps ou l'électronique et a fortiori l'ordinateur, n'existaient pas. A l'avénement de l'informatique, elles devinrent rapidement le support roi des données et des programmes. Leur capacité réduite et fixe, associée à celle mentionnée ci-dessus des ordinateurs d'alors, contraignaient les programmeurs à beaucoup d'habileté. A celle-ci étaient bien sur associées un certain nombre de méthodes pragmatiques (des recettes de cuisine) et extremêment dangereuses : par exemple, utiliser une même zone de mémoire à des fins différentes, mais non simultanément, dans un certain programme. L'une de celles-ci fut empruntée à une pratique bien antérieure à l'apparition de ces machines (notons des à présent que dans la suite de ce texte, il sera systématiquement supposé, pour des raisons de simplicité, que les années sont représentées de façon assez naturelle par un nombre de quatre chiffres décimaux) : lorsqu'une lettre est rédigée ou un formulaire rempli et qu'une ou plusieurs dates y figurent, il est une pratique courante consistant à omettre les deux premiers chiffres des années ; c'est ainsi que l'on parle sans ambiguïté de mai 68 et personne ne comprend alors qu'il s'agit de l'an 68 après Jesus Christ... Cette pratique fut donc transposée dans l'univers numérique, devint même une norme et ne point la respecter pouvait parfois même apparaître comme une faute professionnelle ! Ainsi, elle permettait de réduire de 4 a 2 le nombre de caractères nécessaires à coder les années comprises entre 1900 et 1999 (rappelons au passage que l'année 1900 appartient au dix-neuvieme siècle...). Mais nous reviendrons sur tout ceci par la suite...






4-L'INFORMATIQUE AUJOURD'HUI :

En l'espace de quelques années, le paysage informatique a bien changé. Cela est très certainement dû à ce que l'on appelle l'intégration à (très) grande échelle (VLSI) qui permet aujourd'hui de réaliser, sur une surface de l'ordre du centimêtre carré, des systèmes qui hier demandaient des dizaines de mêtres cubes et ceci de façon entièrement automatisée, rapide et fiable ! Ces réalisations s'appellent microprocesseurs, mémoires RAM, contrôleurs, DSP,... Aujourd'hui, à côté des machines qui portent le nom d'ordinateur, rares sont les dispositifs, mêmes les plus quotidiens (machines à laver ou à coudre, par exemple), qui n'intègrent pas l'une de ces "puces". Ainsi l'informatique est partout ; c'est là sa première caractéristique : l'omniprésence. Mais à cela s'ajoute la facilité avec laquelle tous ces dispositifs peuvent communiquer entre-eux et échanger de l'information. Internet est l'exemple le plus typique de la deuxième caractéristique de l'informatique : la connectivité.

La plupart des ordinateurs de la planète, qu'ils soient visibles (par exemple, un PC sur un bureau) ou invisibles (par exemple, un dispositif de contrôle de processus industriel) sont donc connectés entre-eux. Il est donc logique de dire qu'ils forment ainsi un système dont la complexité dépasse l'entendement. Il est des lors possible de soutenir, par l'exemple qui va suivre, la thèse suivante : ce système global est non linéaire et par conséquent, son comportement, dans certaines circonstances, peut devenir imprévisible et chaotique.






5-QUELQUES REMARQUES CONCERNANT LES DEVELOPPEMENTS INFORMATIQUES :

Avant de présenter le problème dit de l'an 2000, il semble utile de faire quelques remarques très générales permettant de mieux appréhender celui-ci, tout à la fois dans sa magnifique simplicité et son effroyable complexité...



5.1-De la durée de vie des applications informatiques :

il est assez rare de faire de la programmation pour le plaisir de pratiquer cet art (mais en est-ce un d'ailleurs ? Quelques éléments de réponse seront donnés par la suite). En général, cette activité est accomplie dans le but de remplir une certaine mission dans un contexte donné (par exemple, gérer les comptes clients dans une banque). L'expérience montre que la durée de vie des développements alors réalisés dépasse en général largement celle qui était initialement prévue ; cela se vérifie en particulier pour beaucoup d'applications mises en place dans les années soixante et soixante-dix. Il n'est pas rare de voir encore aujurd'hui opérationnelles des chaînes de traitement conçues il y a plus de vingt ans.





5.2-De l'absence de méthode :

beaucoup de ces développements eurent lieu sans que des méthodes strictes soient utilisées et bien souvent sans laisser de traces documentaires dans lesquelles seraient consignés les algorithmes, mais aussi les justifications des choix faits. Cela n'a fait ensuite que s'aggraver au cours des années d'exploitation de ces applications car, elles ont dû évoluer d'une part pour intégrer de nouvelles fonctionnalités et d'autre part pour corriger les inévitables anomalies introduites par les programmeurs (les bugs ou bogues en français). Le travail de celui qui penêtre un tel logiciel est semblable à celui du géologue ou du paléontologue qui cherche à déchiffrer le passé à partir des traces qu'il a laissé. Ainsi, un logiciel peut être vu bien souvent comme un empilement instable d'un certain nombre de couches ajoutées de façon plus ou moins anarchique et précaire au cours des mois et des années (plus il est âgé, et plus cela est vrai...). Les informaticiens préfèrent l'ajout à la suppression et à la simplification (rappelons-nous l'exemple du vol Ariane 501 évoqué précédemment) parce que cela est plus simple ; la complexité et l'instabilité chronique qui en résultent ne peuvent qu'aller en s'amplifiant ! Malheureusement, l'informatique au quotidien n'est ni un Art ni une Science, ce n'est que du bricolage...





5.3-De la non previsibilité :

lorsqu'en 1875 Graham Bell inventa le téléphone à l'Université de Boston, il n'imaginait absolument pas la portée de son invention et cette sorte d'ubiquité qu'elle nous offrirait. Un siècle plus tard, il est devenu l'un des objets les plus indispensables à la vie courante et aux activités professionnelles. Mais aurait-il pu concevoir aussi, que sous sa forme portable, il allait devenir rapidement une nouvelle forme de nuisance dans les lieux publics. Les inventeurs de l'automobile doivent-ils être tenus pour responsables de la pollution atmosphérique ou encore des accidents de la route ? Enfin, pourrait-il exister des médailles sans revers ? Cette absence de previsibilité à long terme (voire à moyen ou à court terme), l'inévitable existence d'anomalies et de risques se retrouvent tout naturellement lors de tout développement et de toute innovation informatiques. Ainsi, l'écran et le clavier facilitent l'interaction avec l'ordinateur, introduisent une nouvelle forme d'ergonomie et de confort ; mais inversement, nos vertèbres cervicales et lombaires ne vont-elles pas en souffrir, et ce temps réel qu'ils permettent ne va-t-il pas nous pousser à agir avec plus de précipitation, moins de réflexion et de discernement qu'en ces temps reculés ou la réponse de la machine nous arrivait après de nombreuses heures d'attente fébrile ?





5.4-De la compatibilité ascendante :

à l'exception de la Grande-Bretagne et des pays du Commonwealth, la circulation automobile a lieu à droite. Ce choix historique semble aujourd'hui arbitraire ; mais quelque découverte pourrait nous amener à reconsidérer celui-ci (à titre d'exemple, notre cerveau est latéralisé et ses deux hémisphères, spécialisés). Mais cela est-il possible ? Examinons cela sur un exemple limité : celui de Paris intra-muros. La première étape, incontournable, de ce processus consisterait à faire un inventaire de tout ce qui dépend de la circulation à droite : signalisation verticale, signalisation horizontale, entrées et sorties des parkings, péages divers et variés, accès à l'intérieur des autobus, topologie des voies à sens unique, structures des voies rapides, entrées et sorties de Paris,... mais aussi position optimisée des panneaux publicitaires... Ce "simple" inventaire, en soi une opération fort complexe, de longue haleine et dont l'exhaustivité semble illusoire, pourrait faire renoncer rapidement à ce projet. Les systèmes informatiques sont eux aussi peuples de telles dépendances, pour la plupart irréversibles : par exemple les codes (ASCII ou EBCDIC) utilisés pour coder les caractères (alphabétiques, numériques, ponctuation,...) ou encore les 80 caractères des cartes perforées qui se retrouvent encore "graves" dans de nombreux logiciels d'aujourd'hui... Pour tous ces exemples, l'ensemble des spécialistes reconnaissent unanimêment qu'il serait plus que souhaitable de faire quelque chose ; oui, mais quoi et surtout comment ?





5.5-Des risques encourus :

cela a déjà été mentionné, mais il est essentiel de revenir à plusieurs reprises sur le fait que les systèmes informatiques sont généralement d'une complexité excessive, qui dépasse largement nos capacités de maîtrise. L'attitude la plus répandue consiste donc à éviter de toucher à ce qui fonctionne correctement (ou presque...), sauf cas de force majeure (et nous sommes aujourd'hui dans une telle situation, ainsi que nous le verrons par la suite). En effet, l'expèrience montre que toute modification, même mineure, dans un logiciel (afin d'adjoindre une nouvelle fonctionnalitè ou bien encore de corriger une anomalie) fait courir des risques graves à celui-ci ainsi qu'à l'intégrité de la mission qu'il remplit. L'univers des télécommunications nord-américaines est là pour en témoigner : de nombreuses indisponibilités complètes et de longues durées (plusieurs heures) ont déjà été constatées sur des réseaux de transmission de données à la suite de corrections infimes apportées à certains logiciels dans quelques uns des routeurs assurant l'acheminement des messages.





5.6-De la capacité limitée des ordinateurs :

c'est peut-être là le danger tout à la fois le plus important et le plus méconnu. Contrairement à une idée plus ou moins explicitée et très répandue (y compris dans le milieu scientifique), ces machines ont des limites. Ces limites peuvent être soit intrinsèques (une information continue -au sens mathématique du terme- doit être échantillonnée et quantifiée pour être manipulable ; l'une des consèquences de ceci est que les nombres dits réels, chers aux mathématiciens et aux physiciens, n'existent pas en toute généralité dans un ordinateur, alors que toutes les applications scientifiques reposent implicitement sur l'hypothèse inverse !), soit imposées, en général de façon tout à fait arbitraire et implicite, par les concepteurs et les programmeurs. Quelqu'en soit l'origine, suivant les cas applicatifs, celles-ci peuvent être atteintes avec plus ou moins de facilité ; mais systématiquement, les atteindre constitue une situation de grand danger car, en général, ignorée et donc non prévue... Un exemple de cela a déjà été fourni lors de la relation de l'échec de la mission Ariane 501 ; la manipulation des composantes de la vitesse à l'aide de nombres dits entiers 16 bits limitaient implicitement cette même vitesse, le franchissement de cette limite a eu des conséquences brutales, puisqu'il a rendu impossible l'accomplissement de la mission !







6-LE BUG DIT DE L'AN 2000 :

L'exemple (malheureusement bien trop réel !) que nous allons maintenant décrire va nous permettre d'illustrer concrètement les différents points précédents. Avant toute chose, précisons que, pour simplifier l'exposé, nous supposerons les années écrites à l'aide de quatre chiffres décimaux et, dans ces conditions, nous appelerons pseudo-numéro de siècle les deux premiers chiffres de cette représentation (par exemple 19 pour 1998). Rappelons enfin que ce pseudo-numéro de siècle ne correspond au véritable numéro de siècle que pour les années dites séculaires (celles dont l'écriture décimale se termine par 00) ce qui implique en particulier que l'entrée dans le vingt-et-unieme siècle et dans le troisième millénaire n'aura lieu que le premier janvier de l'an 2001... Nous sommes maintenant prêts à définir le bug dit de l'an 2000 et montrer qu'il résulte de l'union et de la conjonction d'un certain nombre de problèmes indépendants mais possédant comme dénominateur commun la gestion incorrecte des dates dans les ordinateurs.



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

ce premier problème, très certainement le plus conséquent, a déjà été mentionné lorsque nous avons rappeél précédemment que les ordinateurs n'ont pas toujours possèdé des mémoires centrales de plusieurs dizaines méga-octets et des disques de plusieurs giga-octets. Dans les années soixante et soixante-dix, la pratique antérieure de n'utiliser que les deux derniers chiffres des années fut transposée dans le monde de l'informatique et fut même érigée en norme. Il est essentiel de bien comprendre que les dates, et donc les années, sont des données ominiprésentes dans les ordinateurs, en particulier évidemment dans ceux qui sont intégrés dans des systèmes de gestion. Cela constitua donc une véritable idée de génie, capable de faire économiser 50% des octets nécessaires à mémoriser les années tout en permettant de faire correctement les opérations arithmétiques utiles, en particulier, aux calculs des durées ; par exemple, un enfant né en [19]90 aura [19]98-[19]90=8 ans en 1998. Malheureusement, cette propriété ne se conserve pas après la Saint Sylvestre 1999 ; ce même enfant aura [20]00-[19]90=-90 ans en 2000. Il est évident à tout un chacun que cette dernière valeur est incorrecte, puisqu'un âge ne peut être négatif ; mais nous possédons bien souvent des connaissances plus ou moins implicites que nous ne communiquons pas à nos machines. Comment se comportera donc un programme aboutissant à un âge négatif ? Il est impossible de répondre en toute généralité à cette question, mais il est certain que ces circonstances n'ayant en général pas été prévues le résultat est a priori imprévisible...

Rappelons au passage que ce choix fut aussi celui de ceux qui définirent le numéro de sécurite sociale (aussi bien en France qu'aux Etats-Unis). Dans le cas particulier du numéro INSEE, il est nécessaire de s'interroger sur ce choix qui, dès l'origine, était a priori inconsistant puisque destiné à suivre les français durant la vie entière de nombreuses générations et donc au long de plusieurs centaines d'années, alors qu'en ce qui concerne le problème ici défini, ce choix n'était en fait considéré qu'en tant que moyen provisoire destiné à compenser la faible capacité de ces machines préhistoriques. Les programmeurs d'alors n'imaginaient pas que cette façon de représenter les années se perpétuerait au cours des décennies suivantes et il est donc logique qu'il n'en aient pas prévu les funestes conséquences.

Certains systèmes informatiques donnent parfois l'illusion d'une gestion des années sur quatre chiffres, mais, par exemple, l'édition d'un 1998 sur un relevé bancaire ne prouve rien : les deux caractères 19 peuvent être ajoutés a posteriori lors de l'impression, mais ne pas être en fait memorisé. D'autres encore gèrent effectivement les quatre chiffres, mais sous la forme de deux groupes indépendants de deux chiffres ; c'est ainsi qu'une grande banque française a récemment découvert que l'opération 2000-1 (destinée à calculer l'année précédant 2000) donnait comme résultat 2099. Ces quelques exemples montrent que la représentation et la manipulation des dates dans les ordinateurs n'est ni aussi simple, ni aussi logique que le bons sens le laisserait supposer...

En toute généralité, les formats de date varient d'un pays à l'autre : par exemple, un français écrira 24/10/98 pour le 24 octobre 1988, quant un americain utilisera 10/24/98. Comment dans de telles écritures identifions-nous l'année ? L'algorithme utilisé de façon implicite par chacun d'entre nous consiste à rechercher parmi les trois nombres de deux chiffres celui qui est strictement supérieur à 31. Cette méthode est largement implémentée dans de nombreux logiciels pour identifier automatiquement les formats de date. Il est évident qu'à partir du premier janvier 2000 cette pratique sera défaillante, tout au moins jusqu'en 2032...

Ainsi, une gestion des années sur deux chiffres seulement aménera à des calculs de durée erronés, à des relations d'ordre temporel inversées (considérant, par exemple, que 1999 est dans le futur de 2000 parce que 99 est supérieur a 00) ou encore à des actions automatiques déclenchées au mauvais moment ou pas du tout. A titre d'exemple, nombreux sont les ordinateurs qui contrôlent l'accès sécurisé à des bâtiments. Or le premier janvier de l'an 2000 sera un samedi, jour ou en général les accès sont plus restreints, voire interdits (agences bancaires,...). Dans le cas ou cette surveillance serait effectuée par un système informatique ne manipulant les années que sur deux chiffres, celui-ci pourra interpréter l'an 00 comme étant 1900 ; le premier janvier 1900 était un lundi, jour ouvrable...





6.2-Les dates inaccessibles :

une autre difficulté surgit, indépendamment du nombre de chiffres utilisés pour coder les années. Elle est liée à la nécessité de codifier dans les programmes certaines conditions particulières. Par exemple, comment spécifier la fin d'une liste d'objets (des bons de commande,...) contenant des dates ? Une pratique très répandue consiste à placer en queue, un objet contenant une date ou une année particulières qui tiendra lieu d'indicateur de fin. C'est ainsi que l'année 99 ou la date 9/9/99 sont largement utilisées, les rendant par la-même inaccessibles.





6.3-L'arithmétique sur les dates :

dans le monde de la gestion, à la représentation binaire des nombres est préférée l'écriture utilisant des chaînes de caractères. Ainsi, l'année 1998, alors qu'elle peut s'écrire sous la forme d'une somme de puissances de 2 :

                            10    9    8    7    6    3    2    1
                    1998 = 2   + 2  + 2  + 2  + 2  + 2  + 2  + 2

s'écrira préférentiellement sous la forme d'une chaîne de quatre caractères (notées ici entre guillemets afin de faire la différence avec la valeur numérique correspondante) :

                    "1998"

soit en binaire quatre octets successifs contenant les valeurs décimales :

                    {49,57,57,56}

codant respectivement les caractères "1", "9", "9" et "8", lorsque le code ASCII est utilisé. Or les opérateurs arithmétiques des ordinateurs sont faits pour effectuer les opérations élémentaires (addition, soustraction, multiplication et division) sur la représentation en puissance de deux des nombres et non point sur leur écriture sous la forme de chaînes de caractères, même si rien ne l'empèche. Certains programmes contiennent donc, malheureusement, de telles opérations, qui par chance donnent parfois de bons résultats mais qui sont fausses en toute généralité. Ainsi, pour connaître l'année suivant "1998", l'opération :

                    {49,57,57,56+1} = {49,57,57,57}

fournit correctement l'année "1999". Mais ce procédé, itèré une fois de plus, donnera :

                    {49,57,57,57+1} = {49,57,57,58}

ce qui ne représente pas l'année "2000" mais "199:", la valeur décimale 58 définissant le caractere ":". De telles anomalies ont déjà été rencontrées lors d'opérations portant sur des cartes bancaires, à la fin des années quatre-vingt en Italie.





6.4-La capacité limitée :

ainsi que cela fut déjà dit, tout système informatique possède, à différents niveaux, des limites. Cela est vrai, en particulier, au niveau de la gestion des dates. Ainsi, un ordinateur détermine en permanence la date et l'heure courantes à l'aide d'un instant de référence arbitraire et d'un compteur incrémente en permanence d'une unité avec une certaine fréquence. Que se passe-t-il si ce dernier est sous-dimensionné par rapport à l'usage prévu ? Le système GPS donne un exemple d'une telle anomalie. Celui-ci utilise une base terrestre de référence, une constellation de satellites et nécessite, au niveau des mobiles qui l'utilisent, des récepteurs. Ces derniers ont besoin de la date pour des raisons d'éphémérides, mais aussi pour la communiquer éventuellement à des dispositifs auxquels ils sont connectés. La connaissance de la date se fait en particulier à l'aide d'un compteur de semaines sur 10 bits ; cela lui permet donc de compter de 0 à 1023 semaines. Les compteurs de tous les récepteurs GPS repasseront à 0 dans la nuit du 21 au 22 août 1999. Rappelons que le système GPS, même s'il trouve aujourd'hui des applications civiles de plus en plus en plus nombreuses (par exemple dans les autobus de la RATP) est à l'origine un système militaire conçu par le Pentagone. Comment alors comprendre qu'une telle limitation temporelle (de l'ordre de 20 ans) ait été choisie ? Définir un compteur de semaines sur 16 bits, par exemple, multipliait la durée de vie par 64 donnant ainsi plus de 1000 ans sans en faire un système ni plus complexe, ni plus onéreux (même en se replacant dans le contexte de l'électronique d'il y a vingt ans...). De telles limites se retrouvent dans la plupart des ordinateurs (PC, système UNIX,...). Que se passera-t-il si les corrections ne sont pas apportées en temps voulu ? Remarquons enfin que cela concerne aussi le stockage, par exemple, des numéros de sécurité sociale ou des numéros de téléphone qui, l'un comme l'autre devront voir leurs capacités augmentées dans un avenir très proche.





6.5-Les années bissextiles :

les unités de mesure du temps reposent historiquement sur des considérations astronomiques. C'est ainsi, que l'année correspond à la durée de la révolution de la Terre autour du Soleil et le jour à la durée de la rotation de notre planète d'un tour sur elle-même. Malheureusement, l'année astronomique dure environ 365.2422 jours, ce qui n'est pas un nombre entier. Afin que l'année astronomique reste en phase avec l'année civile, la seule solution est de donner à cette dernière une longueur variable de 365 ou de 366 jours. Ainsi, périodiquement, des années spéciales de 366 jours, dites bissextiles, sont introduites dans le calendrier. Jusqu'à la réforme imposée par Grégoire XIII en 1582, les années bissextiles revenaient tous les quatre ans, ce qui donnait une année moyenne de 365.25 jours donc légèrement trop longue. Le nouveau calendrier, dit grégorien, est donc destiné à compenser cette anomalie aux prix d'une définition plus complexe de la bissextilité. Une année sera bissextile si elle est divisible par 4 sauf si elle est séculaire (c'est-à-dire divisible par 100) et non divisible par 400. Cela peut s'écrire sous la forme d'un pseudo-programme permettant de déterminer si une année A est bissextile ou pas :

                    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)
                                                  }
                                        }
                              }

où A est supposée supérieure à une certaine valeur (1582, 1752,... suivant les pays). Donnons quelques exemples dans l'ordre des tests ci-dessus :


• 2000 est bissextile,
• 1900 n'est pas bissextile,
• 1996 est bissextile,
• 1998 n'est pas bissextile.

Le calendrier grégorien a été mis en place en octobre 1582 a Rome, en décembre de la même année en France et en septembre 1752 en Angleterre (pour la petite histoire, cela implique que l'année 1700 fut bissextile à Londres mais pas à Paris...) ; a cette occasion, dix ou onze jours (suivant les pays donc) disparurent du calendrier pour annuler l'avance de l'année civile sur l'année astronomique.

L'ensemble des critères de bissextilite est assez méconnu du public, même cultivé, et aussi, bien souvent, absent des ouvrages de référence. C'est ainsi que le Petit Robet, dans son édition de 1976, donne à la page 179 la définition "bissextile : se dit de l'année qui revient tous les quatre ans et dont le mois de février comporte 29 jours". Ici ne se trouve donc que le critère de périodicité de quatre ans mais sans année de référence, permettant de considérer que, par exemple, les années {...,1997,2001,2005,...} seraient bissextiles. Dans l'édition 1979 du Dictionnaire Encyclopédique Larousse L1 la définition est plus complète, mais aussi beaucoup plus complexe et fausse en toute généralité ! Ainsi, la notion de calendrier en général, et celle d'année bissextile en particulier, ne sont pas aussi simples qu'il y parait au premier abord ; cela peut donc donner naissance à des logiciels ou des matériels présentant des anomalies graves et qui considèrent, par exemple, que l'an 2000 n'est pas bissextile ou encore que 1998 l'est (exemple vecu récemment par l'auteur).

Ainsi, ce qui est appelé communément le bug de l'an 2000 est en fait l'union d'un certain nombre d'anomalies de gestion des dates dans la plupart de nos ordinateurs, tant au niveau des matériels que des logiciels ; ainsi que cela vient d'être présenté, ces anomalies sont particulièrement élémentaires à spécifier. Cette constatation à deux conséquences immédiates : la première concerne l'incrédulité de ceux qui découvrent ces problèmes, alors que la seconde fait croire à ces derniers que la solution est, elle-aussi, élémentaire ; nous verrons par la suite qu'il n'en est rien, tout au contraire, de par la nature non linéaire de ces "phénomènes".







7-LES RESPONSABLES (LES COUPABLES ?) :

Mais avant de décrire concrètement les difficultés qui nous attendent, il est bon de rechercher les responsabilités et d'essayer de comprendre comment il est possible que, ces problèmes étant connus depuis plus de vingt ans (c'est le cas en ce qui concerne la maltraitance du pseudo-numéro de siècle dans le milieu bancaire), la plupart des acteurs concernés aient attendu la dernière minute pour agir (et encore...).

Les informaticiens semblent bien évidemment être des coupables tout désignés. En effet, ils n'ont pas su voir à long terme les conséquences des choix effectués et ils n'ont pas été capables d'écrire des programmes sans erreurs. Ils n'ont pas eu ensuite la franchise d'avouer leurs fautes, le courage d'expliquer les conséquences néfastes de ces dernières et la force de demander les moyens indispensables pour effectuer les réparations utiles... Rien ne sert de courir, il faut partir à point, regrettons donc que le nécessaire ne fut point fait lorsqu'il en était encore temps ; fait donc posément, correctement et non point dans la précipitation, elle-même source évidente de nouvelles anomalies. Mais arrêtons-là de les accabler ; en effet, nous avons déjà montré que l'absence de prévisibilité était une constante dans toutes nos activités.

Malgré cela, pourquoi les grandes associations professionnelles que sont l'ACM [The Association for Computing Machinery] ou encore l'IEEE [The Institute of Electrical & Electronics Engineers] n'ont-elles pas tiré le signal d'alarme plus tôt ? Pourquoi a-t-il fallu attendre ces derniers mois pour voir publier des articles (brefs le plus souvent) sur ces sujets ? Est-ce parce que la maintenance (c'est bien de cela qu'il s'agit ici) n'est pas une activité digne d'intérêt ou pire parce que qu'elle ne fait pas partie de l'univers de l'informatique ? Les ordinateurs ne sont pas des objets abstraits et simples ; ce sont des machines complexes, composées de nombreuses couches coopérantes présentant toutes, de façon plus ou moins chroniques, des anomalies qu'il faut corriger ou contourner suivant les cas. La maintenance fait donc partie de la vie de l'informaticien et doit donc être traitée avec tout le respect dû a ce qui finalement conditionne le bon fonctionnement quotidien de nos machines ! Enfin, l'ampleur des difficultés auxquelles nous sommes aujourd'hui confrontées aurait pu susciter des vocations, par exemple, dans le monde de l'Intelligence Artificielle (IA) de façon a fournir des concepts nouveaux de manipulation de la complexité ou encore des outils d'extraction d'informations d'ensembles non structurés (certains programmes), mais, malheureusement, il est trop tard !

Ainsi, les informaticiens ont des circonstances atténuantes. Mais qu'en est-il des utilisateurs eux-mêmes ? En effet, ils sont nombreux ceux qui connaissaient ces problèmes depuis longtemps ; les banquiers, par exemple, ne font-ils pas des prêts à vingt ou trente ans ? Ils savaient donc des les années soixante-dix que l'absence du pseudo-numéro de siècle était nuisible. Il est certain qu'alors seul le strict nécessaire a été fait ; n'aurait-ce pas été faire preuve de clairvoyance que d'extrapoler vers les domaines non encore en crise (notons au passage, que plus nous remontons dans le temps, moins ces problèmes étaient difficiles à résoudre, puisque l'informatique y est moins omniprésente...) ? Pourquoi, de plus, n'ont-ils pas fortement fait pression sur les grands constructeurs dont ils sont parmi les plus gros clients ? Cela aurait d'une part accéléré l'arrivée sur le marche de systèmes "compatibles" et d'autre part sensibilisé d'autres classes d'utilisateurs (tous ?) ! Là aussi, il est malheureusement trop tard !

Que dire maintenant de la responsabilite des média ? Elle semble considérable puisqu'un événement n'existe que s'il est relaté ; son importance est alors proportionnelle au nombre de lignes et de minutes qui lui est consacré. A titre d'exemple, la maladie de la vache folle, tant au niveau des média grand public que professionnels a été plus longuement décrite que les problèmes liés à la mauvaise gestion informatique des dates. Est-ce à dire que leurs importances relatives sont dans le même ordre ? Rien n'est moins sûr puisqu'aujourd'hui toute nos activités reposent sur les épaules de nos ordinateurs et que le temps presse. Or les média ont montré récemment, avec certaines affaires de la Maison Blanche, qu'ils savaient mobiliser efficacement l'intégralité de leurs ressources ! N'est-il donc pas dramatique de constater, par exemple, que la presse informatique (française et internationale) n'a abordé tout cela que fort récemment, alors que nombreux sont ceux qui ne sont pas encore sensibilisés (30% des PME françaises se disent non concernées...).

Enfin, le monde politique a lui aussi fait preuve d'une absence coupable. Plus le temps avance et plus ses silences sont angoissants. Au niveau français, en particulier, alors que le 9 septembre 1998, Catherine Trautmann annoncait un budget exceptionnel de 180 MFF accordé par le Premier Ministre pour les festivités de l'an 2000, n'est-il pas dramatique qu'il ait fallu attendre le 20 février de cette même année pour qu'une mission présidée par Gérard Théry soit constituée et cela sans pratiquement lui accorder de moyens. N'est-ce pas préparer les fêtes de la Victoire avant d'avoir proclamé la Mobilisation Générale. Car, en effet, c'est bien de cela qu'il devrait s'agir. Serait-il acceptable, alors qu'un ennemi menaçant serait à nos frontières, qu'un site Internet officiel soit mis en place pour inviter mollement nos concitoyens à l'auto-défense ? Or, si l'ennemi dont il s'agit est bien malheureusement virtuel, les destructions qu'il pourrait causer, pourraient être bien réelles ! L'urgence est telle aujourd'hui, qu'elle demande d'une part une coordination nationale (et internationale) aux plus hauts niveaux des états et d'autre part que des informations soient communiquées aux citoyens afin qu'ils sachent l'état réel dans lequel se trouvent les administrations, les services publics et de santé, la distribution des énergies, les systèmes de transport (l'aviation civile tout particulièrement), la défense nationale,... Des plans de secours sont-ils établis et fonctionneront-ils (le malheureux accident survenu dans la nuit du 25 au 26 septembre 1998 à l'Hôpital Edouard-Herriot de Lyon est particulièrement instructif) ? En cas d'incidents, le retour à la normale sera-t-il garanti rapidement (au mois de février 1998, la ville d'Auckland en Nouvelle-Zelande a été complètement privée d'électricité pendant plusieurs semaines à la suite de la mise hors-service successive des quatre câbles électriques 110 KV qui l'alimentaient) ? Est-on prêts et capables de revenir provisoirement au papier et au crayon ? Autant de questions que nous nous posons tout naturellement et l'absence de réponses ne peut qu'engendrer plus d'inquiétude...

A cela, il convient d'ajouter la relative insouciance avec laquelle le calendrier de la mise en place de l'Euro a été défini, sans apparemment prendre en compte le fait évident qu'il est difficile, pour ne pas dire impossible, de mener à bien et correctement deux projets informatiques d'une telle ampleur simultanément. Enfin, sachant le déficit en ressources humaines dans le milieu de l'informatique, au niveau mondial et en France en particulier (ou plusieurs dizaines de milliers de postes sont actuellement inoccupés), dans notre pays, la loi sur les 35 heures n'est-elle pas incompatible, provisoirement, avec l'urgence de la situation (notons au passage qu'il ne s'agit pas ici de critiques envers l'Euro et les mesures pour l'emploi, domaines dans lequel l'auteur n'a aucune compétence, mais simplement de remarques de bon sens : serait-il raisonnable de demander à des pompiers qui éteignent un incendie, d'abandonner leur tâche, sous prétexte qu'il est dix-sept heures trente ?).

Finalement, ne serions-nous tous pas à la fois responsables et coupables ? En tout cas, quelle que soit la réponse qui sera donnée à cette interrogation, il parait évident que nous devons tous nous sentir concernés, tant au niveau de nos fonctions professionnelles (les entreprises et les organismes auxquels nous appartenons ont besoin de nous) qu'en tant que citoyen. De notre attitude responsable dépend en grande partie la victoire...






8-LES SOLUTIONS :




8.1-Le cauchemar :

encore une fois, tous les problèmes que nous venons de décrire sont élémentaires et ne demandent aucune compétence particuliere pour être compris. Alors où est la difficulté ? Pour la saisir, il peut être utile de s'appuyer sur un problème concret. En effet, les systèmes informatiques sont en quelque sorte une nouvelle forme d'iceberg : 10% de réel émergé (le matériel) et 90% de virtuel immergé (le logiciel) ; or autant il est facile d'apprécier la complexité matérielle d'un lanceur tel Ariane 5 (parce qu'elle est visible, par exemple dans sa "plomberie"), autant cela est difficile pour la complexité logicielle associée. Ce problème concret proposé est donc le suivant : compter les grains de sable sur une plage. Il est bien posé (ou enfin presque, car il suppose que la notion de plage est définie sans ambiguïté), élémentaire, sans aucune difficulté théorique. Comptons donc : un grain de sable, deux grains de sable,... mille grains de sable. Ici, déjà la fatigue se fait sentir, mais aussi le découragement car, en effet, que sont mille grains de sable par rapport à une plage ?





8.2-Le mythe de la solution miracle :

en ce qui concerne la gestion des dates dans nos ordinateurs, la situation est identique : les opérations individuelles de correction sont élémentaires ; la difficulté réside uniquement dans leur nombre purement astronomique ! Il y aurait actuellement, de par le monde, environ cent milliards de lignes de programmes concernées (majoritairement écrites en Cobol, langage pour lequel il n'y a plus guère de spécialistes...). Environ 4% d'entre-elles auraient d'ailleurs disparues et d'autres ne correspondraient plus aux programmes réellement utilisés dans les chaînes de traitement... Un mythe répandu consiste à affirmer l'existence d'une solution miracle. Malheureusement, celle-ci n'existe pas en toute généralité ; en effet, pour qu'un outil universel de mise à jour puisse exister, il faudrait qu'au cours de ces décennies de développement, des méthodes strictes aient été utilisées. Il n'en est rien malheureusement et par exemple, le nombre de façons de représenter une date dans un ordinateur est compris entre beaucoup et l'infini... Il convient d'ajouter que même si cette solution existait, elle ne dispenserait pas de la première étape incontournable : l'inventaire.





8.3-L'inventaire :

en effet, avant de corriger les matériels et les logiciels, il est nécessaire de disposer de leur liste exhaustive. Or, aussi paradoxal que cela puisse paraître, ces inventaires, en général, n'existent pas ; il faut donc commencer par les établir, et c'est là que les première difficultés surgissent. L'expérience montre que pour une banque, le nombre de logiciels utilisés est de l'ordre de plusieurs dizaines de milliers, ce dénombrement demandant parfois plus d'une année pour être fait proprement ! Et malheureusement, l'informatique concernée par le problème de l'an 2000 n'est pas faite, loin s'en faut, d'ordinateurs posés sur nos bureaux et contenant quelques logiciels bien rangés... Non, elle est partout : aussi bien dans les ascenseurs, les climatiseurs, les photocopieurs,... Et c'est certainement là que le risque est le plus grand : dans l'informatique que l'on qualifie d'enfouïe, qui assure en permanence le bon fonctionnement de tout notre environnement et dont nous ignorons presque tout !





8.4-Le rafistolage :

ainsi, même si la solution miracle existait, de toute façon, sa mise en œuvre demanderait de nombreux mois pour les préparatifs. Mais de toute façon elle n'existe pas : il n'y a donc pas d'autre solution que de retrousser les manches et de passer au peigne fin ces milliards et ces milliards de lignes de programmes en général non documentées, ces centaines de millions de systèmes spécialisés, à la recherche de toutes les occurences (logiques et physiques) des dates ; ainsi nous cherchons des aiguilles aux formes et en nombre inconnus dans une meule de foin planétaire ! Si la prise de conscience avait eu lieu en temps utile, plus que des corrections ponctuelles, il aurait été envisageable de remplacer l'ancien par du nouveau. Mais un point de non retour a été en quelque sorte atteint et seules donc les corrections restent envisageables. En réalité, la situation est en général plus précaire que cela : lorsque sont pris en compte les ressources humaines disponibles, le temps restant et la quantité de travail à accomplir, il apparait que pour beaucoup, même ce "rafistolage" exhaustif est impossible ! Il convient donc pour ceux-la de procéder à un tri permettant de mettre en évidence les priorités : quels sont les logiciels et les matériels qui sont vitaux (tant pour l'homme que pour l'entreprise) ? Quels sont ceux qui le sont moins ? Tout ceci étant évidemment associé à une analyse des risques encourus, ainsi qu'à la mise en place de plans de secours...





8.5-L'année pivot :

mais en quoi consiste donc ces "rafistolages" ? Intéressons-nous donc au codage des années sur deux chiffres ; la solution à ce problème particulier consisterait à étendre les zones de mémoire destinées à stocker et à manipuler des années. Combien de chiffres sont donc nécessaires ? Quatre paraissent raisonnables mais ce problème ne se reposera-t-il pas en 9999 ? Evidemment nous ne serons plus là pour le voir et nos petits enfants, si toute trace de civilisation n'a pas disparu à la surface de la Terre, utiliseront évidemment une technologie qui nous serait aussi étrangère que la nôtre à nos lointains ancêtres dans leurs cavernes. Mais cette remarque en forme de plaisanterie est destinée à nous rappeler l'un des points les plus essentiels : celui des limites arbitraires imposées par les programmeurs. Quatre chiffres sont donc suffisants ; malheureusement, la complexité des opérations correspondantes est rédhibitoire. D'autres solutions doivent donc être mise en œuvre. L'une d'entre-elle, la plus répandue, consiste à utiliser une année dite pivot et effectivement codée sur quatre chiffres : par exemple, dans un certain contexte, 1960 ; ensuite toute année AA, codée sur deux chiffres, sera étendue sur quatre chiffres là où elle est utile et uniquement là (ainsi, en particulier, les innombrables et volumineuses bases de données contenant des années sur deux chiffres resteront inchangées). Cette extension se fera à l'aide d'un test simple : par exemple, si AA est supérieur à [19]60, il lui est substitue 19AA et dans le cas contraire, 20AA. Cette solution, présente un certain nombre de dangers. Le premier est immédiat et concerne la cohérence ; en effet, il est important que la même date pivot soit utilisée par tous les éléments qui sont en inter-relation : aussi bien a l'intérieur qu'a l'extérieur d'une entreprise, mais la chose est-elle possible ? Certainement pas en toute généralité, car cela signifierait à la limite que l'ensemble de la planète utilise la même, or il est évident qu'à la sécurité sociale l'utilisation des dates n'est pas la même que dans une centrale nucléaire. Le deuxième danger est plus lointain et donc plus grand ; en effet, que se passera-t-il lorsque tous les obstacles qui s'annoncent devant nous auront été franchis avec plus ou moins de succès ? La réponse est simple : nous commettrons les mêmes erreurs que par le passé et nous oublierons nos rafistolages. Or la notion même d'année pivot contient sa propre limite de validité temporelle : de l'ordre de cent ans. Nous sommes donc en train de mettre en place des bombes à retardement qui donneront bien de la peine a nos successeurs !





8.6-Les tests :

dans tout projet informatique, toute modification doit être testée. Ces tests essentiels, qui permettent de vérifier si le cahier des charges est satisfait, occupe environ 50% du temps total ! Face à des échéances si proches, tout peut-il être testé ? Or malheureusement deux types de tests doivent être accomplis ; d'une part des tests de non régression qui permettent de vérifier que les corrections apportées ont maintenu l'intégralité des fonctionnalités antérieures (notons au passage, que parfois certaines sont implicites et donc non documentées...). Au niveau d'une banque, par exemple, cela se fait en mettant en place des sites de test indépendants des sites de production, mais identiques en tout ; ayant choisi un état de référence des systèmes de production (états des comptes clients à une date donnée,...), l'intégralité des transactions sur une longue période (afin d'être représentatives) sont archivées, puis "rejouées" sur le système de test à partir de l'état initial fixé. Ensuite, l'état final obtenu est comparé à ce qu'il fut en réalité dans le système de production. Il convient de noter que cette approche est plus statistique qu'exhaustive, mais il n' y a pas mieux à faire ! D'autre part, des tests de compatibilité doivent être conduits ; ils sont destinés à vérifier que tous les problèmes de date sont résolus. A cette occasion, certaines dates particulièrement critiques devront être examinées à la loupe (le jeudi 09/09/1999, le lundi 03/01/2000, le mardi 29/02/2000, le mercredi 01/03/2000, le mardi 10/10/2000,...). Cette série de tests est particulièrement délicate pour au moins deux raisons : d'une part personne ne sait en toute généralité ce qu'il faut réellement tester ; d'autre part, il est nécessaire de procéder sur des cas réels mais malheureusement situés dans le futur. Pour reprendre l'exemple bancaire précédent, il convient donc de faire vieillir artificiellement l'état initial du système, ainsi que l'intégralité des transactions. Mais se faisant, en vieillissant, par exemple de cinq ou dix années toutes les dates, la plus grande partie des clients mineurs vont disparaître et donc les tests perdront le peu d'exhaustivité qu'ils possédaient encore...





8.7-Les coûts :

évidemment tout cela a un coût. Evalué très grossièrement, les corrections, à elles seules demanderaient au niveau de la planète mille milliards de dollars ! Mais il y a deux raisons poussant à augmenter cette évaluation : d'une part y a-t-il des exemples de (grands) projets informatiques pour lesquels les budgets initiaux ont été respectés. D'autre part, il ne faut pas oublier les dédommagements suite aux inévitables dégats et catastrophes : ils sont actuellement évalués à deux mille milliards de dollars ! Les assureurs ont triplement à s'inquiéter : ils sont tout à la fois parmi les plus gros utilisateurs de l'informatique, les plus sensibles à ces problèmes de gestion de dates et les plus concernés de par leur fonction. Mais 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 ? Y a-t-il de l'aléatoire dans nos problèmes de date ? Si certains informaticiens peuvent craindre le chômage, les avocats et autres juristes n'ont, quant à eux, aucun soucis à se faire...





8.8-Les dead lines :

pour la première fois dans l'histoire de l'informatique, des projets ont des dates d'achévement immuables. Il est évidemment impossible de retarder le premier janvier de l'an 2000... Or rares, pour ne pas dire inexistants, sont les projets qui se sont achevés à temps, tout en respectant les budgets et les fonctionnalités.





8.9-L'effet domino :

il est essentiel de noter enfin que de par l'interconnectivité généralisée, il ne suffit pas, par exemple, qu'une entreprise soit prête ; il importe que l'intégralité de ses clients, de ses fournisseurs avec lesquels elle entretient en permanence des relations informatiques, soient eux-aussi prêts sous peine de risques graves de pollution. Ainsi, la Royal Bank of Canada, qui a inventorié dix-huit millions de lignes de programme, possède vingt-cinq mille clients avec lesquels elle est en relation ; en plus du travail de mise à niveau interne, il a donc fallu qu'elle procède à un colossal travail de sensibilisation... Le monde de la banque et de la finance est particulièrement sensible à ce phénomène de domino ; un scénario catastrophe, des plus réalistes malheureusement, consisterait à imaginer sur une place boursière, n'importe où dans le monde, un ordinateur défaillant qui provoquerait une anomalie qui se propagerait ensuite, de façon quasiment irréversible, à la vitesse de la lumière et qui provoquerait des ventes massives, un krach, une récession...







CONCLUSION :

Les problèmes de gestion des dates dans les ordinateurs, même s'ils paraissent élémentaires (au moins à spécifier...) constituent une réelle menace pour l'intégrité de nos économies et même pour la sécurité de nos états. Il n'y a a priori aucune activité (ni personne) qui soit réellement à l'abri, ne serait-ce qu'à cause des interdépendances. Malheureusement il ne s'agit là que d'un exemple concret d'une catastrophe annoncée parmi d'autres, qui gisent potentiellement, prêtes à éclater à tout moment. Nos réalisations reposent aujourd'hui toutes sans exception sur l'informatique ; pratiquée au quotidien, celle-ci est à des années lumière de la pureté des 0s et des 1s de l'algèbre de Boole et de ses règles absolues. En toute généralité, elle n'est ni Art, ni Science, mais du bricolage. Bricolage parfois de génie, les réussites sont là pour le prouver ; l'ordinateur est en particulier un outil fantastique pour amplifier nos facultés intellectuelles (ne devrions nous pas créer le concept d'Imagination Assistée par Ordinateur ?) et nous permettre des progrès sans précédents dans le domaine de la Connaissance. Mais bricolage approximatif le plus souvent, qui pourra nous conduire vers d'autres catastrophes aux conséquences incalculables dans un avenir plus ou moins proche. Le temps n'est-il donc pas venu de s'interroger sur cette complexité dont nous sommes à l'origine, que nous ne maîtrisons plus et qui nous échappe ? Quelle pourrait être cette nouvelle informatique qui nous permettrait de vaincre ces difficultés ? Peut-être une informatique beaucoup plus redondante, plus tolérante aux anomalies en s'inspirant de grands principes naturels.

Soyons en tout cas tous conscients de notre responsabilité aujourd'hui et œuvrons chacun à notre niveau pour faire de la Saint Sylvestre 1999 une Saint Sylvestre comme les autres...