Les défaillances de l’informatique : une nouvelle menace ? l’exemple du bug de l’an 2000

À l’ap­proche de l’an 2000 a ressur­gi un mil­lé­nar­isme qui con­traire­ment à celui de l’an 1000 n’an­nonce point les splen­deurs du Roy­aume de Dieu. Bien au con­traire nos peurs sont aujour­d’hui bien réelles, bien con­crètes : le spec­tre de la pol­lu­tion, les risques nucléaires…, pla­nent au-dessus de nos têtes comme autant d’oiseaux de proie ; qui n’a pas trem­blé à la vue de ces sous-marins nucléaires de l’ex-marine sovié­tique en train de pour­rir dans les ports de la presqu’île de Kola ?

La sci­ence nous a appris au cours des siè­cles passés que le pre­mier jan­vi­er de l’an 2000 serait un jour comme les autres dans l’his­toire de l’u­nivers. Mal­gré cela, ce jour pour­rait rester inscrit dans l’his­toire de l’hu­man­ité comme celui d’un désas­tre arti­fi­ciel, aux con­séquences a pri­ori dif­fi­ciles à imaginer.

Les phénomènes non linéaires naturels

Pour bien com­pren­dre, il est bon de rap­pel­er qu’il existe dans la nature des phénomènes car­ac­térisés par le fait que leurs caus­es, générale­ment infimes, peu­vent par­fois s’am­pli­fi­er démesuré­ment et avoir alors des con­séquences sans com­mune mesure avec ce qui leur a don­né naissance.

La suite est immé­di­ate : il est impos­si­ble théorique­ment et pra­tique­ment de faire à leur sujet des prévi­sions à long terme.

Les exem­ples de tels phénomènes sont nom­breux, mais celui qui vient spon­tané­ment à l’e­sprit est celui qui a don­né nais­sance à l’ex­pres­sion faire boule de neige : l’avalanche.

Les phénomènes non linéaires artificiels

Au cours des décen­nies passées, la sci­ence et la tech­nolo­gie nous ont offert des phénomènes non linéaires arti­fi­ciels, par exem­ple, celui de l’échec du vol Ari­ane 501, le 4 juin 1996. Une petite anom­alie dans un logi­ciel issu d’Ar­i­ane 4 et qui ne s’é­tait jamais man­i­festée a con­traint à l’au­tode­struc­tion de la fusée après quelques dizaines de sec­on­des de vol.

Ain­si, une infime anom­alie s’est ampli­fiée jusqu’à avoir des con­séquences ayant coûté un nom­bre appré­cia­ble de mil­liards de francs. Il con­vient, pour en ter­min­er avec cet inci­dent “exem­plaire”, de pré­cis­er que la com­pé­tence des ingénieurs con­cernés ne peut être mise en doute : c’est l’ex­trême com­plex­ité de ces sys­tèmes qui rend impos­si­ble (à jamais ?) leur fia­bil­ité absolue.

La préhistoire de l’informatique

Né à la fin des années quar­ante, l’or­di­na­teur avait à sa nais­sance voca­tion de machine à cal­culer et ses pères imag­i­naient alors que seuls quelques exem­plaires de ces mon­stres nous seraient utiles. Pesant des dizaines de tonnes, occu­pant des cen­taines de mètres car­rés au sol, ils étaient entourés d’ar­mées de spé­cial­istes. Puis, dans les années cinquante, les pre­mières appli­ca­tions de ges­tion virent le jour. Au début des années soix­ante-dix, les per­for­mances et les capac­ités restaient encore très lim­itées : des mémoires cen­trales de quelques dizaines de kilo-octets et des dis­ques de moins d’un méga-octet étaient la norme.

En ces temps reculés, point d’écran couleur et de souris ser­vant à l’in­ter­ac­tion avec les machines, mais unique­ment les 80 colonnes des cartes per­forées. Tout cela con­traig­nait les pro­gram­meurs à beau­coup d’ha­bileté et à cer­taines pra­tiques dont quelques-unes se sont per­pé­tuées jusqu’à aujour­d’hui. L’une d’en­tre elles fut la trans­po­si­tion d’une habi­tude bien antérieure à l’in­for­ma­tique, con­sis­tant à omet­tre les deux pre­miers chiffres des années.

Mais si l’homme peut par­ler sans ambiguïté de Mai 68 et de la guerre de 70, il en va mal­heureuse­ment dif­férem­ment pour nos chers ordinateurs…

L’informatique aujourd’hui

En l’e­space de quelques années, le paysage infor­ma­tique a bien changé. Cela est dû prin­ci­pale­ment à l’in­té­gra­tion à très grande échelle (VLSI), tech­nique qui per­met de réalis­er de façon fiable, automa­tique et économique, sur une sur­face de l’or­dre du cen­timètre car­ré, des sys­tèmes qui hier demandaient des dizaines de mètres cubes. Aujour­d’hui, à côté des machines qui por­tent le nom d’or­di­na­teur, rares sont les dis­posi­tifs, même par­mi les plus quo­ti­di­ens, qui n’in­tè­grent pas l’une de ces ” puces ” (micro­processeurs, mémoires…). À cela s’a­joute la facil­ité avec laque­lle tous ces dis­posi­tifs peu­vent com­mu­ni­quer entre eux et échang­er de l’in­for­ma­tion. Ain­si l’in­for­ma­tique actuelle est omniprésente et communicante.

La plu­part des ordi­na­teurs de la planète, qu’ils soient vis­i­bles (un PC sur un bureau) ou invis­i­bles (un dis­posi­tif de con­trôle de proces­sus indus­triel) com­mu­niquent donc entre eux. Il est alors pos­si­ble d’af­firmer qu’ils for­ment un sys­tème non linéaire dont la com­plex­ité dépasse l’en­ten­de­ment et qui peut, dans cer­taines cir­con­stances, devenir imprévis­i­ble et chaotique.

Quelques remarques concernant les développements informatiques

Avant de présen­ter le bug de l’an 2000, il sem­ble utile de faire quelques remar­ques très générales per­me­t­tant de mieux appréhen­der celui-ci, tout à la fois dans sa mag­nifique sim­plic­ité et son effroy­able complexité…

L’ex­péri­ence mon­tre que la durée de vie des appli­ca­tions infor­ma­tiques dépasse en général large­ment celle qui est envis­agée par leurs con­cep­teurs : il n’est pas rare de voir aujour­d’hui des chaînes de traite­ment conçues il y a plus de vingt ans et encore opéra­tionnelles. Mal­heureuse­ment, leurs développe­ments eurent lieu bien sou­vent sans que des méth­odes strictes et bien doc­u­men­tées ne soient util­isées. Et cela n’a fait ensuite que s’ag­graver au cours de leurs années d’ex­ploita­tion car elles ont dû évoluer pour inté­gr­er de nou­velles fonc­tion­nal­ités et pour cor­riger les inévita­bles anom­alies (bugs ou bogues en français) intro­duites par les con­cep­teurs et les programmeurs.

Le tra­vail de celui qui doit s’in­tro­duire dans de tels logi­ciels est sem­blable à celui du paléon­to­logue qui cherche à déchiffr­er le passé à par­tir des quelques traces qu’il a lais­sées. Ain­si, un pro­gramme peut être vu bien sou­vent comme un empile­ment insta­ble d’un cer­tain nom­bre de couch­es déposées de façon plus ou moins anar­chique et pré­caire au cours des années. Les infor­mati­ciens préfèrent l’a­jout à la sup­pres­sion parce que cela est plus sim­ple et moins risqué. La com­plex­ité et l’in­sta­bil­ité chronique qui en résul­tent ne peu­vent qu’aller en s’am­pli­fi­ant : l’in­for­ma­tique au quo­ti­di­en n’est ni un art, ni une sci­ence, ce n’est que du bricolage…

Lorsqu’en 1876 à Boston Gra­ham Bell inven­ta le télé­phone, il n’imag­i­nait absol­u­ment pas la portée de son inven­tion. Cette absence de prévis­i­bil­ité à long terme (voire à moyen ou à court terme), de même que l’inévitable exis­tence d’anom­alies et de risques, se retrou­ve tout naturelle­ment lors de tout développe­ment et de toute inno­va­tion infor­ma­tiques. Ain­si, l’écran et le clavier facili­tent l’in­ter­ac­tion avec l’or­di­na­teur, intro­duisent une nou­velle forme d’er­gonomie et de con­fort ; mais inverse­ment, nos vertèbres cer­vi­cales et lom­baires ne vont-elles pas en souf­frir, et ce temps réel qu’ils per­me­t­tent ne va-t-il pas nous pouss­er à agir avec plus de pré­cip­i­ta­tion, moins de réflex­ion et de dis­cerne­ment qu’en ces temps reculés où la réponse de la machine nous arrivait après de nom­breuses heures d’at­tente fébrile ?

Lors de développe­ments infor­ma­tiques, les con­cep­teurs sont amenés à faire des choix bien sou­vent arbi­traires et cer­tains d’en­tre eux s’avèrent être par la suite irréversibles. Ils créent ain­si de fortes rela­tions de dépen­dance qu’il faut ensuite absol­u­ment respecter : c’est la notion de com­pat­i­bil­ité. C’est le cas des codes util­isés pour représen­ter les car­ac­tères d’im­primerie ou encore les 80 colonnes des cartes per­forées encore gravées dans de nom­breux logi­ciels d’au­jour­d’hui… Dans tous les cas, l’ensem­ble des spé­cial­istes recon­nais­sent unanime­ment qu’il serait plus que souhaitable de faire quelque chose : oui, mais quoi et surtout comment ?

Les sys­tèmes infor­ma­tiques sont générale­ment d’une com­plex­ité qui dépasse nos capac­ités de maîtrise. L’at­ti­tude la plus répan­due con­siste donc à éviter de touch­er à ce qui sem­ble fonc­tion­ner cor­recte­ment, sauf cas de force majeure (cas du bug de l’an 2000). En effet, l’ex­péri­ence mon­tre que toute mod­i­fi­ca­tion, même mineure, dans un logi­ciel fait courir des risques graves à celui-ci, ain­si qu’à l’in­tégrité de la mis­sion qu’il remplit.

Enfin, con­traire­ment à une idée très répan­due, les ordi­na­teurs pos­sè­dent des lim­ites qui peu­vent être soit intrin­sèques (la con­ti­nu­ité — au sens math­é­ma­tique du terme — n’ex­iste pas dans un ordi­na­teur), soit imposées par les con­cep­teurs et les pro­gram­meurs, sou­vent de façon tout à fait arbi­traire. Celles-ci peu­vent être atteintes avec plus ou moins de facil­ité, mais cette sit­u­a­tion entraîne un grand dan­ger car générale­ment elle est ignorée et donc non prévue…

Le bug de l’an 2000

L’ex­em­ple bien trop réel que nous allons main­tenant décrire va nous per­me­t­tre d’il­lus­tr­er con­crète­ment ces dif­férents points. Avant toute chose, pré­cisons que, pour sim­pli­fi­er, nous sup­poserons les années écrites à l’aide de qua­tre chiffres déci­maux et nous appellerons pseu­do-numéro de siè­cle les deux pre­miers chiffres de cette représen­ta­tion (par exem­ple 19 pour 1999). Pré­cisons que ce pseu­do-numéro de siè­cle ne cor­re­spond au véri­ta­ble numéro de siè­cle que pour les années dont l’écri­t­ure se ter­mine par 00 ; ceci implique en par­ti­c­uli­er que l’en­trée dans le vingt et unième siè­cle et dans le troisième mil­lé­naire n’au­ra lieu que le pre­mier jan­vi­er de l’an 2001 (l’an 2000 est la dernière année du vingtième siècle).

Le pseu­do-numéro de siè­cle mal­traité : déjà évo­qué, ce pre­mier prob­lème est de loin le plus con­séquent. La pra­tique anci­enne de n’u­tilis­er que les deux derniers chiffres des années, comme cela se retrou­ve dans le numéro INSEE des Français, fut donc trans­posée dans le monde de l’in­for­ma­tique. En effet, les dates, et donc les années, con­stituent des don­nées omniprésentes dans les ordi­na­teurs et en par­ti­c­uli­er dans les sys­tèmes de ges­tion. Cela con­sti­tua donc un arti­fice capa­ble de faire économiser 50 % des octets néces­saires à la mémori­sa­tion des années, tout en per­me­t­tant de faire cor­recte­ment les opéra­tions arith­mé­tiques utiles et en par­ti­c­uli­er les cal­culs de durées ; par exem­ple, un enfant né en [19]90 aura [19]99 — [19]90 = 9 ans en 1999.

Mal­heureuse­ment, cette pro­priété ne se con­servera pas au pas­sage de la Saint-Sylvestre 1999 ; ce même enfant aura [20]00 — [19]90 = ‑90 ans en 2000. Il nous est évi­dent qu’une telle valeur est incor­recte, puisqu’un âge ne peut être négatif, mais com­ment se com­portera un pro­gramme en sa présence ? Il est impos­si­ble de répon­dre en toute général­ité à cette ques­tion, mais il est cer­tain que ces cir­con­stances n’ayant en général pas été prévues, le résul­tat sera a pri­ori imprévisible…

Ce choix n’é­tait en fait qu’un moyen pro­vi­soire des­tiné à com­penser la faible capac­ité des machines préhis­toriques. Les pro­gram­meurs d’alors n’imag­i­naient pas que cette façon de représen­ter les années se per­pétuerait au cours des décen­nies suiv­antes ; il est donc logique qu’ils n’en aient pas prévu les funestes conséquences.

Cette pra­tique est extrême­ment répan­due, même sur des sys­tèmes infor­ma­tiques don­nant l’il­lu­sion d’une ges­tion des années sur qua­tre chiffres ; l’édi­tion de ” 1998 ” sur un relevé ban­caire ne prou­ve rien : les deux car­ac­tères ” 19 ” peu­vant avoir été ajoutés a pos­te­ri­ori lors de l’im­pres­sion. De plus, les for­mats de la date vari­ent d’un pays à l’autre ; par­mi trois valeurs don­nant cha­cune sur deux chiffres le jour, le mois et l’an­née, pour retrou­ver cette dernière, l’al­go­rithme fréquem­ment util­isé con­siste à rechercher la valeur stricte­ment supérieure à 31. Il est évi­dent qu’à par­tir du pre­mier jan­vi­er [20]00 cette pra­tique sera défail­lante, tout au moins jusqu’en [20]32. Ain­si, ces deux exem­ples mon­trent que la représen­ta­tion et la manip­u­la­tion des dates dans les ordi­na­teurs ne sont ni aus­si sim­ples, ni aus­si logiques que le bon sens le lais­serait supposer…

Ain­si, une ges­tion des années sur deux chiffres pour­ra con­duire à des cal­culs de durée erronés, à des rela­tions d’or­dre tem­porel inver­sées ou encore à des actions automa­tiques déclenchées au mau­vais moment ou pas du tout. Mal­heureuse­ment, le prob­lème du codage des années sur deux chiffres n’est pas le seul : qua­tre autres l’accompagnent…

Les dates inac­ces­si­bles : pour représen­ter dans les pro­grammes cer­taines con­di­tions par­ti­c­ulières telle une erreur ou la fin d’une liste d’ob­jets con­tenant des dates, une pra­tique très répan­due a con­sisté à utilis­er une date (9/9/99…) ou une année (99…) par­ti­c­ulières, les ren­dant par là même inac­ces­si­bles. Ces valeurs furent choisies parce que d’une part elles demandaient la frappe d’une touche unique sur un clavier et que d’autre part elles sem­blaient appartenir à un futur bien loin­tain. Cette anom­alie n’a provo­qué que quelques dys­fonc­tion­nements mineurs : par exem­ple, elle a ren­du impos­si­ble la délivrance de passe­ports pro­vi­soires en Suède dans les pre­miers jours de 1999.

L’arith­mé­tique sur les dates : dans les sys­tèmes infor­ma­tiques de ges­tion, cer­taines don­nées numériques, comme les dates, sont préféren­tielle­ment codées sous forme de chaînes de car­ac­tères. Ain­si, l’an­née ” 1998 ” sera représen­tée par la suite {“ 1 “, ” 9 “, ” 9 “, ” 8 ”}. Lorsque des cal­culs doivent être effec­tués sur ces représen­ta­tions, le pro­gram­meur doit faire accom­plir explicite­ment à la machine tout ce qui est fait lors d’un cal­cul manuel et en par­ti­c­uli­er la prop­a­ga­tion des retenues. Oubli­er cela lors de la déter­mi­na­tion de l’an­née suiv­ante peut don­ner fréquem­ment des résul­tats cor­rects (“ 1998 ” suiv­ie de ” 1999 ”) et de temps en temps des sur­pris­es (“ 1999 ” suiv­ie de ” 199 : ”). De telles anom­alies ont déjà été ren­con­trées en Ital­ie, lors d’opéra­tions por­tant sur des cartes ban­caires, à la fin des années quatre-vingt.

La capac­ité lim­itée : il ne suf­fit pas à un ordi­na­teur d’archiv­er des dates ” sta­tiques “. Pour accom­plir ses mis­sions, il doit aus­si être capa­ble de déter­min­er en per­ma­nence la date et l’heure courantes. Cela est réal­isé à l’aide d’un instant de référence arbi­traire et d’un comp­teur incré­men­té péri­odique­ment d’une unité. Que se passe-t-il si ce dernier est sous-dimen­sion­né par rap­port à l’usage prévu ?

Le sys­tème GPS (Glob­al Posi­tion­ing Sys­tem) donne un exem­ple d’une telle anom­alie. Celui-ci utilise une con­stel­la­tion de satel­lites et néces­site, au niveau des mobiles qui l’u­tilisent, des récep­teurs. Ces derniers ont besoin de la date et ils la déter­mi­nent, en par­ti­c­uli­er, à l’aide d’un comp­teur de semaines qui ne peut compter que de 0 à 1 023. Ain­si, tous les récep­teurs GPS sont repassés à 0 le 21 août 1999 à 23 : 59 : 47 UTC en ne provo­quant aucune cat­a­stro­phe, mais seule­ment quelques anom­alies dans des sys­tèmes grand pub­lic de nav­i­ga­tion (mar­itime et auto­mo­bile). Mal­gré cela, le choix d’une telle lim­ite (de l’or­dre de vingt ans) dans un dis­posi­tif d’o­rig­ine mil­i­taire sem­ble tout à fait arbi­traire et mystérieux !

De telles anom­alies se retrou­vent poten­tielle­ment dans la plu­part des ordi­na­teurs. Remar­quons enfin que cette non-exten­si­bil­ité des ordi­na­teurs con­cerne aus­si de nom­breuses autres infor­ma­tions : par exem­ple le stock­age des numéros de sécu­rité sociale ou encore de téléphone.

Les années bis­sex­tiles : les unités de mesure du temps reposent his­torique­ment sur des con­sid­éra­tions astronomiques. C’est ain­si que l’an­née cor­re­spond à la durée de la révo­lu­tion de la Terre autour du Soleil, soit env­i­ron 365,2422 jours, ce qui n’est pas un nom­bre entier. Afin que l’an­née astronomique reste en phase avec le cal­en­dri­er, la seule solu­tion est de don­ner à cette dernière une longueur vari­able de 365 ou de 366 jours. Ain­si, péri­odique­ment, des années dites bis­sex­tiles sont introduites.

Jusqu’à la réforme imposée par Gré­goire XIII en 1582, les années bis­sex­tiles reve­naient tous les qua­tre ans, ce qui don­nait une année moyenne de 365,25 jours donc légère­ment trop longue. Le cal­en­dri­er, dit gré­gorien, fut donc des­tiné à com­penser cette anom­alie au prix d’une déf­i­ni­tion plus com­plexe de la bis­sex­til­ité. Une année sera bis­sex­tile si elle est divis­i­ble par 4 sauf si elle est sécu­laire (c’est-à-dire divis­i­ble par 100) et non divis­i­ble par 400. Ain­si, 2000 et 1996 sont bis­sex­tiles, alors que 1900 et 1999 ne le sont pas.

L’ensem­ble de ces critères est générale­ment mécon­nu du pub­lic, même cul­tivé, et aus­si, bien sou­vent, absent des ouvrages de référence. C’est ain­si que Le Petit Robert, dans son édi­tion de 1976, donne à la page 179 la déf­i­ni­tion Bis­sex­tile : se dit de l’an­née qui revient tous les qua­tre ans et dont le mois de févri­er com­porte 29 jours ! Cela a don­né nais­sance à quelques logi­ciels et matériels présen­tant des anom­alies graves leur faisant con­sid­ér­er que l’an 2000 n’é­tait pas bissextile.

Ain­si, ce qui est appelé com­muné­ment le bug de l’an 2000 est en fait l’u­nion d’un cer­tain nom­bre d’anom­alies de ges­tion des dates dans la plu­part de nos ordi­na­teurs, tant au niveau des matériels que des logi­ciels. Ces anom­alies, qui sont plus le résul­tat de choix anciens que d’er­reurs, sont par­ti­c­ulière­ment élé­men­taires à spé­ci­fi­er. Cette con­stata­tion a deux con­séquences immé­di­ates : la pre­mière con­cerne l’in­cré­dulité de ceux qui décou­vrent ces prob­lèmes, alors que la sec­onde fait croire à ces derniers que la solu­tion est, elle aus­si, élé­men­taire. De par la nature non linéaire de ces ” phénomènes “, il n’en est rien, tout au contraire.

Les responsables

Mais avant de décrire les dif­fi­cultés cor­re­spon­dantes, il est bon de rechercher les respon­s­abil­ités et d’es­say­er de com­pren­dre com­ment il est pos­si­ble que la plu­part des acteurs con­cernés aient atten­du la dernière minute pour agir, alors que ces prob­lèmes sont con­nus depuis plus de vingt ans, dans le milieu ban­caire en particulier.

Les infor­mati­ciens sem­blent bien évidem­ment être les coupables tout désignés. En effet, ils n’ont pas su voir à long terme les con­séquences de leurs choix et ils n’ont pas été capa­bles d’écrire des pro­grammes sans erreurs. Ils n’ont pas eu ensuite la fran­chise d’avouer leurs fautes, le courage d’ex­pli­quer les con­séquences néfastes de ces dernières et la force de deman­der les énormes moyens indis­pens­ables pour effectuer les répa­ra­tions utiles…

Rien ne sert de courir, il faut par­tir à point, regret­tons donc que le néces­saire ne fût point fait lorsqu’il en était encore temps ; fait donc posé­ment, cor­recte­ment et non point dans la pré­cip­i­ta­tion, elle-même source évi­dente de nou­velles anom­alies. Mais arrê­tons là de les acca­bler : en effet, l’ab­sence de prévis­i­bil­ité et de fia­bil­ité est une con­stante dans toutes les activ­ités humaines.

Mal­gré cela, pourquoi les grandes asso­ci­a­tions pro­fes­sion­nelles que sont l’ACM (The Asso­ci­a­tion for Com­put­ing Machin­ery) ou encore l’IEEE (The Insti­tute of Elec­tri­cal & Elec­tron­ics Engi­neers) n’ont-elles pas tiré le sig­nal d’alarme plus tôt ? Pourquoi a‑t-il fal­lu atten­dre ces derniers mois pour voir pub­li­er de trop brefs arti­cles sur ce sujet ? Est-ce parce que la main­te­nance n’est pas une activ­ité digne d’in­térêt ou pire parce que qu’elle ne fait pas par­tie de l’u­nivers de l’informatique ?

Mais les ordi­na­teurs ne sont pas des objets abstraits et sim­ples ; ce sont des machines com­plex­es, com­posées de nom­breuses entités coopérantes présen­tant toutes, de façon plus ou moins chronique, des anom­alies. La main­te­nance fait donc par­tie de la vie de l’in­for­mati­cien et doit donc être traitée avec tout le respect dû à ce qui finale­ment con­di­tionne le bon fonc­tion­nement quo­ti­di­en de nos machines. Enfin, l’am­pleur des dif­fi­cultés aux­quelles nous sommes aujour­d’hui con­fron­tés aurait pu sus­citer des voca­tions, par exem­ple dans le monde de l’in­tel­li­gence arti­fi­cielle. Mal­heureuse­ment, il est trop tard !

Ain­si, les infor­mati­ciens (des temps héroïques…) ont des cir­con­stances atténu­antes. Mais qu’en est-il des util­isa­teurs eux-mêmes ? En effet, nom­breux sont ceux qui con­nais­saient ces prob­lèmes depuis longtemps : les ban­quiers, par exem­ple, ne font-ils pas des prêts à vingt ou trente ans ? Ils savaient donc dès les années soix­ante-dix que l’ab­sence du pseu­do-numéro de siè­cle était nuisible.

Il est cer­tain qu’alors seul le strict néces­saire a été fait ; n’au­rait-ce pas été faire preuve de clair­voy­ance que d’ex­trapol­er vers les domaines non encore cri­tiques ? Notons de plus qu’alors l’in­for­ma­tique était beau­coup moins omniprésente, ce qui rendait ces prob­lèmes plus faciles à résoudre. Pourquoi enfin n’ont-ils pas forte­ment fait pres­sion sur les grands con­struc­teurs dont ils sont par­mi les plus gros clients ? Cela aurait cer­taine­ment accéléré l’ar­rivée sur le marché de sys­tèmes ” com­pat­i­bles ” et peut-être étouf­fé l’in­cendie avant qu’il ne se propage ! Là aus­si, il est mal­heureuse­ment trop tard !

Que dire main­tenant de la respon­s­abil­ité des médias ? Elle sem­ble con­sid­érable puisqu’un événe­ment n’ex­iste que s’il est relaté ; son impor­tance est alors pro­por­tion­nelle au nom­bre de lignes et de min­utes qui lui est con­sacré. Il est donc regret­table de con­stater le trop long silence de la presse, en par­ti­c­uli­er infor­ma­tique, tant nationale qu’internationale.

Enfin, le monde poli­tique a lui aus­si fait preuve d’une absence, mais encore faut-il que l’in­for­ma­tion remonte au som­met de la pyra­mide… En France, il a fal­lu atten­dre le 20 févri­er 1998 pour qu’une mis­sion présidée par Gérard Théry soit con­sti­tuée. L’am­pleur du prob­lème est telle, qu’elle aurait demandé d’une part une coor­di­na­tion inter­na­tionale au plus haut niveau des États et d’autre part que des infor­ma­tions soient com­mu­niquées aux citoyens afin qu’ils sachent l’é­tat réel dans lequel se trou­vent les admin­is­tra­tions, les ser­vices publics et de san­té, la dis­tri­b­u­tion des éner­gies, les sys­tèmes de trans­port, la défense nationale…

Les plans de sec­ours mis en place fonc­tion­neront-ils (le mal­heureux acci­dent sur­venu dans la nuit du 25 au 26 sep­tem­bre 1998 à l’hôpi­tal Édouard-Her­riot de Lyon est par­ti­c­ulière­ment instruc­tif) ? En cas d’in­ci­dents, le retour à la nor­male sera-t-il garan­ti rapi­de­ment ? Est-on capa­ble de revenir pro­vi­soire­ment au papi­er et au cray­on ? Autant de ques­tions que tous se posent naturelle­ment ; l’ab­sence de répons­es ne peut qu’en­gen­dr­er plus d’in­quié­tude et déclencher des mou­ve­ments de panique dont les con­séquences pour­raient être bien plus graves que celles des inci­dents réels, peut-être inex­is­tants d’ailleurs…

Ces réac­tions pos­si­bles pour­raient être déclenchées par des pénuries arti­fi­cielles por­tant, par exem­ple, sur l’ar­gent liq­uide ou encore les biens de pre­mière néces­sité (dans les pre­miers jours de jan­vi­er 1999, quelques bureaux de poste français ont été pris d’as­saut à la suite de l’indisponi­bil­ité du sys­tème infor­ma­tique gérant les comptes d’épargne).

À cela, il con­vient d’a­jouter le cal­en­dri­er de la mise en place de l’eu­ro qui a été défi­ni, sans apparem­ment pren­dre en compte le fait évi­dent qu’il est dif­fi­cile, pour ne pas dire impos­si­ble, de men­er à bien et cor­recte­ment deux pro­jets infor­ma­tiques d’une telle ampleur simultanément.

Enfin, sachant le déficit général­isé en infor­mati­ciens, la loi française sur les 35 heures n’est-elle pas incom­pat­i­ble, pro­vi­soire­ment, avec l’ur­gence de la sit­u­a­tion (notons au pas­sage qu’il ne s’ag­it pas ici de cri­tiques envers l’eu­ro et les mesures pour l’emploi, mais sim­ple­ment de remar­ques de bon sens : serait-il raisonnable de deman­der à des pom­piers qui éteignent un incendie, d’a­ban­don­ner leur tâche, sous pré­texte qu’il est dix-sept heures trente ?).

Finale­ment, ne seri­ons-nous tous pas à la fois respon­s­ables et coupables ? En tout cas, quelle que soit la réponse don­née à cette inter­ro­ga­tion, il paraît évi­dent que nous devons tous nous sen­tir con­cernés, tant à l’in­térieur des struc­tures pro­fes­sion­nelles aux­quelles nous appartenons, qu’en tant que citoyen.

Les solutions

Tous les prob­lèmes que nous venons de décrire sont élé­men­taires et ne deman­dent aucune com­pé­tence par­ti­c­ulière pour être com­pris. Alors où est la dif­fi­culté ? Les sys­tèmes infor­ma­tiques sont sem­blables aux ice­bergs : 10 % de réel émergé (le matériel) et 90 % de virtuel immergé (le logi­ciel) ; or autant il est facile d’ap­préhen­der la com­plex­ité matérielle car vis­i­ble, autant cela est dif­fi­cile pour la com­plex­ité logi­cielle puisque intan­gi­ble. En fait, les infor­mati­ciens sont en face d’un prob­lème assez sim­i­laire à celui qui con­sis­terait à leur deman­der de compter les grains de sable sur une plage.

En ce qui con­cerne la ges­tion des dates dans nos ordi­na­teurs, la sit­u­a­tion est iden­tique : les opéra­tions indi­vidu­elles de cor­rec­tion sont élé­men­taires ; la dif­fi­culté réside unique­ment dans leur nom­bre. Il y aurait actuelle­ment, de par le monde, env­i­ron cent mil­liards de lignes de pro­grammes con­cernées. Un mythe répan­du con­siste à affirmer l’ex­is­tence d’une solu­tion miracle.

Mal­heureuse­ment, celle-ci n’ex­iste pas ; en effet, pour qu’un out­il uni­versel de mise à jour puisse être conçu, il aurait fal­lu qu’au cours des décen­nies passées, des méth­odes strictes de développe­ment aient été util­isées. Il n’en est rien et par exem­ple, le nom­bre de façons de représen­ter une date dans un ordi­na­teur est élevé… Il con­vient d’a­jouter que même si cette solu­tion exis­tait elle ne dis­penserait pas de la pre­mière étape incon­tourn­able : l’inventaire.

En effet, avant de cor­riger les matériels et les logi­ciels, il est néces­saire de dis­pos­er de leur liste exhaus­tive. Or, aus­si para­dox­al que cela puisse paraître, ces inven­taires, en général, n’ex­is­tent pas ; il faut donc com­mencer par les établir. L’ex­péri­ence mon­tre que, pour une banque, plusieurs dizaines de mil­liers de logi­ciels sont util­isés et ce dénom­bre­ment demande par­fois plus d’une année pour être réal­isé proprement !

Mal­heureuse­ment, l’in­for­ma­tique con­cernée par le bug n’est pas faite, loin s’en faut, d’or­di­na­teurs posés sur nos bureaux et con­tenant quelques logi­ciels bien rangés… Non, elle est partout : aus­si bien dans les ascenseurs, les cli­ma­tiseurs, les robots de fab­ri­ca­tion… Et c’est cer­taine­ment là que le risque est le plus grand : dans cette infor­ma­tique qual­i­fiée d’enfouie qui assure en per­ma­nence le bon fonc­tion­nement de tout notre envi­ron­nement et dont nous ignorons presque tout !

Il n’y a donc pas d’autre solu­tion que de pass­er au peigne fin ces mil­liards de lignes de pro­grammes et ces mil­lions de sys­tèmes spé­cial­isés : nous sommes à la recherche d’aigu­illes (les dates) aux formes et en nom­bre incon­nus dans une meule de foin. Si la prise de con­science avait eu lieu en temps utile, il aurait été envis­age­able de rem­plac­er l’an­cien par du nouveau.

Mais un point de non-retour a été franchi et donc seules les cor­rec­tions restent envis­age­ables. En réal­ité, la sit­u­a­tion est en général plus pré­caire que cela : lorsque sont pris en compte les ressources humaines disponibles, le temps restant et la quan­tité de tra­vail à accom­plir, il appa­raît que, bien sou­vent, même ce “rafis­to­lage” exhaus­tif est impos­si­ble ! S’im­pose alors un tri per­me­t­tant de fix­er les pri­or­ités : quels sont les logi­ciels et les matériels qui sont vitaux tant pour l’homme que pour l’en­tre­prise et quels sont ceux qui le sont moins ? Tout ceci doit être évidem­ment asso­cié à une analyse des risques encou­rus, ain­si qu’à la mise en place de plans de secours.

Mais en quoi con­sis­tent donc ces “rafis­to­lages” ? La bonne solu­tion au prob­lème du codage des années sur deux chiffres con­sis­terait à éten­dre les zones de mémoire des­tinées à stock­er et à manip­uler des années. Com­bi­en de chiffres seraient néces­saires ? Qua­tre parais­sent a pri­ori raisonnables, mais ce prob­lème ne se reposera-t-il pas alors en 9999 ? Cette remar­que en forme de boutade est des­tinée à nous rap­pel­er deux points essen­tiels : les lim­ites arbi­traires (et sou­vent irréversibles) imposées par les pro­gram­meurs et le manque de vis­i­bil­ité à long terme. Qua­tre chiffres sont évidem­ment suff­isants ; mal­heureuse­ment, la com­plex­ité des opéra­tions cor­re­spon­dantes est rédhibitoire.

‘autres solu­tions doivent donc être mis­es en œuvre. L’une des plus répan­dues con­siste à choisir, dans un cer­tain con­texte, une année dite piv­ot codée sur qua­tre chiffres, par exem­ple 1960 ; ensuite toute année AA sera éten­due sur qua­tre chiffres unique­ment là où cela est utile. Cette exten­sion se fera à l’aide d’un test sim­ple : si AA est supérieure à [19]60, il lui est sub­sti­tué 19AA et 20AA dans le cas con­traire. Cette solu­tion présente un cer­tain nom­bre de dan­gers. Le pre­mier con­cerne la cohérence ; en effet, il est impor­tant que la même date piv­ot soit util­isée par tous les sys­tèmes en rela­tion : mais est-ce pos­si­ble ? Non en toute général­ité, car cela sig­ni­fierait à la lim­ite que l’ensem­ble de la planète utilise la même.

Le sec­ond dan­ger est plus loin­tain ; en effet, que se passera-t-il lorsque tous les obsta­cles qui s’an­non­cent devant nous auront été fran­chis avec plus ou moins de suc­cès ? La réponse est déjà con­nue : nous com­met­trons les mêmes erreurs que par le passé et nous oublierons nos rafis­to­lages. Or la notion même d’an­née piv­ot con­tient sa pro­pre lim­ite, de l’or­dre de quelques dizaines d’an­nées. Ain­si, sans résoudre les vrais prob­lèmes, nous sommes en train de met­tre en place des bombes à retarde­ment qui don­neront bien des soucis à nos successeurs !

Dans tout pro­jet infor­ma­tique, il est essen­tiel de véri­fi­er la con­for­mité de la réal­i­sa­tion par rap­port au cahi­er des charges et ces tests occu­pent env­i­ron 50 % du temps glob­al de développe­ment. Pour le bug, deux types de tests doivent être accom­plis ; d’abord des tests de non-régres­sion qui per­me­t­tent de véri­fi­er que les cor­rec­tions apportées ont main­tenu l’in­té­gral­ité des fonc­tion­nal­ités antérieures. Au niveau d’une banque, par exem­ple, cela se fait en met­tant en place un site indépen­dant du site opéra­tionnel, puis en com­para­nt leurs résul­tats ; cette approche est mal­heureuse­ment plus sta­tis­tique qu’ex­haus­tive. Ensuite, des tests de com­pat­i­bil­ité doivent être con­duits afin de véri­fi­er que les prob­lèmes de date ont été réso­lus. Cer­taines dates par­ti­c­ulière­ment cri­tiques doivent être exam­inées à la loupe (le jeu­di 09/09/1999, le lun­di 03/01/2000, le mar­di 29/02/2000, le mer­cre­di 01/03/2000, le mar­di 10/10/2000…). Cette série de tests est par­ti­c­ulière­ment déli­cate, per­son­ne ne sachant en toute général­ité ni ce qu’il faut tester, ni com­ment vieil­lir les jeux de tests sans intro­duire de biais pervers.

Éval­ué très grossière­ment, le coût des cor­rec­tions est au niveau de la planète de l’or­dre de mille mil­liards de dol­lars ! Mais il y a deux raisons pous­sant à aug­menter cette éval­u­a­tion : d’une part l’ab­sence d’ex­em­ple de grands pro­jets infor­ma­tiques pour lesquels les bud­gets ini­ti­aux ont été respec­tés et d’autre part les dédom­mage­ments dus aux inévita­bles dégâts et cat­a­stro­phes : ils sont actuelle­ment éval­ués à deux mille mil­liards de dollars !

Les assureurs ont triple­ment à s’in­quiéter : ils sont tout à la fois par­mi les plus gros util­isa­teurs de l’in­for­ma­tique, les plus sen­si­bles à ces prob­lèmes de ges­tion de dates et les plus con­cernés de par leur fonc­tion ; ils n’ont d’ailleurs pas man­qué de rap­pel­er (fort juste­ment d’ailleurs !) que le bug ne com­por­tait aucun car­ac­tère aléa­toire, l’ar­rivée du 01/01/2000 étant con­nue depuis quelques siècles…

Pour la pre­mière fois dans l’his­toire de l’in­for­ma­tique, des pro­jets ont des dates d’achève­ment immuables. Or rares sont les pro­jets qui se sont achevés à temps, tout en respec­tant les bud­gets et les fonctionnalités.

Enfin, nous sommes en présence d’un mag­nifique exem­ple d’effet domi­no : de par l’in­ter­con­nec­tiv­ité général­isée, il ne suf­fit pas qu’une entre­prise soit prête ; il importe que l’in­té­gral­ité de ses clients et de ses four­nisseurs avec lesquels elle entre­tient en per­ma­nence des rela­tions infor­ma­tiques soient eux aus­si prêts, sous peine de risques graves de “pol­lu­tion”. Ain­si, en plus du déli­cat tra­vail de mise à niveau interne, cha­cun doit procéder à un colos­sal tra­vail externe de sensibilisation…

Le monde de la banque et de la finance est par­ti­c­ulière­ment sen­si­ble à ce phénomène ; un scé­nario cat­a­stro­phe, indépen­dant du bug et des plus réal­istes mal­heureuse­ment, con­siste à imag­in­er sur une place bour­sière, n’im­porte où dans le monde, un ordi­na­teur défail­lant qui provo­querait une anom­alie qui se propagerait ensuite, de façon qua­si­ment irréversible, à une vitesse proche de celle de la lumière, cau­sant des ventes mas­sives, un krach, une récession…

Conclusion

Les prob­lèmes de ges­tion des dates dans les ordi­na­teurs, même s’ils sont élé­men­taires à spé­ci­fi­er, con­stituent une réelle men­ace pour l’in­tégrité de nos économies, voire même pour la sécu­rité de nos États. Il n’y a a pri­ori aucune activ­ité, ni per­son­ne qui en soit réelle­ment à l’abri, ne serait-ce qu’à cause des interdépendances.

Mal­heureuse­ment il ne s’ag­it là que d’un exem­ple con­cret d’une cat­a­stro­phe pos­si­ble par­mi d’autres, qui gisent poten­tielle­ment dans nos tech­nolo­gies, prêtes à éclater à tout moment.

Nos réal­i­sa­tions reposent aujour­d’hui toutes sans excep­tion sur l’in­for­ma­tique. Pra­tiquée au quo­ti­di­en, celle-ci est à des années-lumière de la pureté des 0 et des 1 de l’al­gèbre de Boole et de ses règles absolues : elle n’est ni Art, ni Sci­ence, mais bricolage.

Brico­lage de génie par­fois, ses réus­sites sont là pour en témoign­er : l’or­di­na­teur est en par­ti­c­uli­er un out­il fan­tas­tique pour ampli­fi­er nos fac­ultés intel­lectuelles et nous per­me­t­tre des pro­grès sans précé­dent dans le domaine de la con­nais­sance. Mais brico­lage approx­i­matif le plus sou­vent, qui pour­ra nous con­duire vers d’autres cat­a­stro­phes aux con­séquences incal­cu­la­bles dans un avenir plus ou moins proche.

Le bug est une donc une oppor­tu­nité à saisir : le temps n’est-il pas venu de s’in­ter­roger sur cette com­plex­ité dont nous sommes à l’o­rig­ine, que par­fois nous ne maîtrisons plus et qui nous échappe alors ? Soyons en tout cas con­scients de notre respon­s­abil­ité aujour­d’hui et œuvrons cha­cun à notre niveau.

Bib­li­ogra­phie :
Le Bug de l’an 2000 — Com­pren­dre l’in­for­ma­tique jusqu’à ses dys­fonc­tion­nements, Bernard Aumont et Jean-François Colon­na, Flam­mar­i­on, Paris, mars 1999.

---

Articles similaires :

Com­po­si­tion d’informatique — A — (XULCR) Com­po­si­tion d’informatique — B — (XELCR) Com­po­si­tion d’informatique (XCR) L’hyperpuissance de l’informatique Du Set pack­ing au taxi aérien autonome, ren­con­tre avec une jeune chercheuse en recherche opérationnelle Align­er la gou­ver­nance des sys­tèmes d’information sur la stratégie de l’entreprise