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 res­sur­gi un mil­lé­na­risme qui contrai­re­ment à celui de l’an 1000 n’an­nonce point les splen­deurs du Royaume de Dieu. Bien au contraire nos peurs sont aujourd’­hui bien réelles, bien concrètes : le spectre de la pol­lu­tion, les risques nucléaires…, planent au-des­sus de nos têtes comme autant d’oi­seaux 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 pres­qu’île de Kola ?

La science nous a appris au cours des siècles pas­sés que le pre­mier jan­vier de l’an 2000 serait un jour comme les autres dans l’his­toire de l’u­ni­vers. Mal­gré cela, ce jour pour­rait res­ter ins­crit dans l’his­toire de l’hu­ma­ni­té comme celui d’un désastre arti­fi­ciel, aux consé­quences a prio­ri dif­fi­ciles à imaginer.

Les phénomènes non linéaires naturels

Pour bien com­prendre, il est bon de rap­pe­ler qu’il existe dans la nature des phé­no­mènes carac­té­ri­sés par le fait que leurs causes, géné­ra­le­ment infimes, peuvent par­fois s’am­pli­fier déme­su­ré­ment et avoir alors des consé­quences sans com­mune mesure avec ce qui leur a don­né naissance.

La suite est immé­diate : il est impos­sible théo­ri­que­ment et pra­ti­que­ment de faire à leur sujet des pré­vi­sions à long terme.

Les exemples de tels phé­no­mènes sont nom­breux, mais celui qui vient spon­ta­né­ment à l’es­prit 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 pas­sées, la science et la tech­no­lo­gie nous ont offert des phé­no­mènes non linéaires arti­fi­ciels, par exemple, celui de l’é­chec du vol Ariane 501, le 4 juin 1996. Une petite ano­ma­lie dans un logi­ciel issu d’A­riane 4 et qui ne s’é­tait jamais mani­fes­tée a contraint à l’au­to­des­truc­tion de la fusée après quelques dizaines de secondes de vol.

Ain­si, une infime ano­ma­lie s’est ampli­fiée jus­qu’à avoir des consé­quences ayant coû­té un nombre appré­ciable de mil­liards de francs. Il convient, pour en ter­mi­ner avec cet inci­dent « exem­plaire », de pré­ci­ser que la com­pé­tence des ingé­nieurs concer­nés ne peut être mise en doute : c’est l’ex­trême com­plexi­té de ces sys­tèmes qui rend impos­sible (à jamais ?) leur fia­bi­li­té absolue.

La préhistoire de l’informatique

Né à la fin des années qua­rante, l’or­di­na­teur avait à sa nais­sance voca­tion de machine à cal­cu­ler et ses pères ima­gi­naient alors que seuls quelques exem­plaires de ces monstres nous seraient utiles. Pesant des dizaines de tonnes, occu­pant des cen­taines de mètres car­rés au sol, ils étaient entou­rés d’ar­mées de spé­cia­listes. Puis, dans les années cin­quante, les pre­mières appli­ca­tions de ges­tion virent le jour. Au début des années soixante-dix, les per­for­mances et les capa­ci­tés res­taient encore très limi­tées : des mémoires cen­trales de quelques dizaines de kilo-octets et des disques de moins d’un méga-octet étaient la norme.

En ces temps recu­lés, point d’é­cran cou­leur et de sou­ris ser­vant à l’in­te­rac­tion avec les machines, mais uni­que­ment les 80 colonnes des cartes per­fo­rées. Tout cela contrai­gnait les pro­gram­meurs à beau­coup d’ha­bi­le­té et à cer­taines pra­tiques dont quelques-unes se sont per­pé­tuées jus­qu’à aujourd’­hui. L’une d’entre elles fut la trans­po­si­tion d’une habi­tude bien anté­rieure à l’in­for­ma­tique, consis­tant à omettre les deux pre­miers chiffres des années.

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

L’informatique aujourd’hui

En l’es­pace de quelques années, le pay­sage infor­ma­tique a bien chan­gé. Cela est dû prin­ci­pa­le­ment à l’in­té­gra­tion à très grande échelle (VLSI), tech­nique qui per­met de réa­li­ser de façon fiable, auto­ma­tique et éco­no­mique, sur une sur­face de l’ordre du cen­ti­mètre car­ré, des sys­tèmes qui hier deman­daient des dizaines de mètres cubes. Aujourd’­hui, à côté des machines qui portent le nom d’or­di­na­teur, rares sont les dis­po­si­tifs, même par­mi les plus quo­ti­diens, qui n’in­tègrent pas l’une de ces » puces » (micro­pro­ces­seurs, mémoires…). À cela s’a­joute la faci­li­té avec laquelle tous ces dis­po­si­tifs peuvent com­mu­ni­quer entre eux et échan­ger de l’in­for­ma­tion. Ain­si l’in­for­ma­tique actuelle est omni­pré­sente et communicante.

La plu­part des ordi­na­teurs de la pla­nète, qu’ils soient visibles (un PC sur un bureau) ou invi­sibles (un dis­po­si­tif de contrôle de pro­ces­sus indus­triel) com­mu­niquent donc entre eux. Il est alors pos­sible d’af­fir­mer qu’ils forment un sys­tème non linéaire dont la com­plexi­té dépasse l’en­ten­de­ment et qui peut, dans cer­taines cir­cons­tances, deve­nir impré­vi­sible et chaotique.

Quelques remarques concernant les développements informatiques

Avant de pré­sen­ter le bug de l’an 2000, il semble utile de faire quelques remarques très géné­rales per­met­tant de mieux appré­hen­der celui-ci, tout à la fois dans sa magni­fique sim­pli­ci­té et son effroyable complexité…

L’ex­pé­rience montre que la durée de vie des appli­ca­tions infor­ma­tiques dépasse en géné­ral lar­ge­ment celle qui est envi­sa­gée par leurs concep­teurs : il n’est pas rare de voir aujourd’­hui des chaînes de trai­te­ment conçues il y a plus de vingt ans et encore opé­ra­tion­nelles. Mal­heu­reu­se­ment, leurs déve­lop­pe­ments eurent lieu bien sou­vent sans que des méthodes strictes et bien docu­men­tées ne soient uti­li­sées. Et cela n’a fait ensuite que s’ag­gra­ver au cours de leurs années d’ex­ploi­ta­tion car elles ont dû évo­luer pour inté­grer de nou­velles fonc­tion­na­li­tés et pour cor­ri­ger les inévi­tables ano­ma­lies (bugs ou bogues en fran­çais) intro­duites par les concep­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échif­frer le pas­sé à par­tir des quelques traces qu’il a lais­sées. Ain­si, un pro­gramme peut être vu bien sou­vent comme un empi­le­ment instable d’un cer­tain nombre de couches dépo­sées de façon plus ou moins anar­chique et pré­caire au cours des années. Les infor­ma­ti­ciens pré­fèrent l’a­jout à la sup­pres­sion parce que cela est plus simple et moins ris­qué. La com­plexi­té et l’ins­ta­bi­li­té chro­nique qui en résultent ne peuvent qu’al­ler en s’am­pli­fiant : l’in­for­ma­tique au quo­ti­dien n’est ni un art, ni une science, ce n’est que du bricolage…

Lors­qu’en 1876 à Bos­ton Gra­ham Bell inven­ta le télé­phone, il n’i­ma­gi­nait abso­lu­ment pas la por­tée de son inven­tion. Cette absence de pré­vi­si­bi­li­té à long terme (voire à moyen ou à court terme), de même que l’i­né­vi­table exis­tence d’a­no­ma­lies et de risques, se retrouve tout natu­rel­le­ment lors de tout déve­lop­pe­ment et de toute inno­va­tion infor­ma­tiques. Ain­si, l’é­cran et le cla­vier faci­litent l’in­te­rac­tion avec l’or­di­na­teur, intro­duisent une nou­velle forme d’er­go­no­mie et de confort ; mais inver­se­ment, nos ver­tèbres cer­vi­cales et lom­baires ne vont-elles pas en souf­frir, et ce temps réel qu’ils per­mettent ne va-t-il pas nous pous­ser à agir avec plus de pré­ci­pi­ta­tion, moins de réflexion et de dis­cer­ne­ment qu’en ces temps recu­lés où la réponse de la machine nous arri­vait après de nom­breuses heures d’at­tente fébrile ?

Lors de déve­lop­pe­ments infor­ma­tiques, les concep­teurs sont ame­nés à faire des choix bien sou­vent arbi­traires et cer­tains d’entre eux s’a­vèrent être par la suite irré­ver­sibles. Ils créent ain­si de fortes rela­tions de dépen­dance qu’il faut ensuite abso­lu­ment res­pec­ter : c’est la notion de com­pa­ti­bi­li­té. C’est le cas des codes uti­li­sés pour repré­sen­ter les carac­tères d’im­pri­me­rie ou encore les 80 colonnes des cartes per­fo­rées encore gra­vées dans de nom­breux logi­ciels d’au­jourd’­hui… Dans tous les cas, l’en­semble des spé­cia­listes recon­naissent una­ni­me­ment qu’il serait plus que sou­hai­table de faire quelque chose : oui, mais quoi et sur­tout comment ?

Les sys­tèmes infor­ma­tiques sont géné­ra­le­ment d’une com­plexi­té qui dépasse nos capa­ci­tés de maî­trise. L’at­ti­tude la plus répan­due consiste donc à évi­ter de tou­cher à ce qui semble fonc­tion­ner cor­rec­te­ment, sauf cas de force majeure (cas du bug de l’an 2000). En effet, l’ex­pé­rience montre que toute modi­fi­ca­tion, même mineure, dans un logi­ciel fait cou­rir des risques graves à celui-ci, ain­si qu’à l’in­té­gri­té de la mis­sion qu’il remplit.

Enfin, contrai­re­ment à une idée très répan­due, les ordi­na­teurs pos­sèdent des limites qui peuvent être soit intrin­sèques (la conti­nui­té – au sens mathé­ma­tique du terme – n’existe pas dans un ordi­na­teur), soit impo­sées par les concep­teurs et les pro­gram­meurs, sou­vent de façon tout à fait arbi­traire. Celles-ci peuvent être atteintes avec plus ou moins de faci­li­té, mais cette situa­tion entraîne un grand dan­ger car géné­ra­le­ment elle est igno­rée et donc non prévue…

Le bug de l’an 2000

L’exemple bien trop réel que nous allons main­te­nant décrire va nous per­mettre d’illus­trer concrè­te­ment ces dif­fé­rents points. Avant toute chose, pré­ci­sons que, pour sim­pli­fier, nous sup­po­se­rons les années écrites à l’aide de quatre chiffres déci­maux et nous appel­le­rons pseu­do-numé­ro de siècle les deux pre­miers chiffres de cette repré­sen­ta­tion (par exemple 19 pour 1999). Pré­ci­sons que ce pseu­do-numé­ro de siècle ne cor­res­pond au véri­table numé­ro de siècle que pour les années dont l’é­cri­ture se ter­mine par 00 ; ceci implique en par­ti­cu­lier que l’en­trée dans le vingt et unième siècle et dans le troi­sième mil­lé­naire n’au­ra lieu que le pre­mier jan­vier de l’an 2001 (l’an 2000 est la der­nière année du ving­tième siècle).

Le pseu­do-numé­ro de siècle mal­trai­té : déjà évo­qué, ce pre­mier pro­blème est de loin le plus consé­quent. La pra­tique ancienne de n’u­ti­li­ser que les deux der­niers chiffres des années, comme cela se retrouve dans le numé­ro INSEE des Fran­çais, fut donc trans­po­sée dans le monde de l’in­for­ma­tique. En effet, les dates, et donc les années, consti­tuent des don­nées omni­pré­sentes dans les ordi­na­teurs et en par­ti­cu­lier dans les sys­tèmes de ges­tion. Cela consti­tua donc un arti­fice capable de faire éco­no­mi­ser 50 % des octets néces­saires à la mémo­ri­sa­tion des années, tout en per­met­tant de faire cor­rec­te­ment les opé­ra­tions arith­mé­tiques utiles et en par­ti­cu­lier les cal­culs de durées ; par exemple, un enfant né en [19]90 aura [19]99 – [19]90 = 9 ans en 1999.

Mal­heu­reu­se­ment, cette pro­prié­té ne se conser­ve­ra pas au pas­sage de la Saint-Syl­vestre 1999 ; ce même enfant aura [20]00 – [19]90 = ‑90 ans en 2000. Il nous est évident qu’une telle valeur est incor­recte, puis­qu’un âge ne peut être néga­tif, mais com­ment se com­por­te­ra un pro­gramme en sa pré­sence ? Il est impos­sible de répondre en toute géné­ra­li­té à cette ques­tion, mais il est cer­tain que ces cir­cons­tances n’ayant en géné­ral pas été pré­vues, le résul­tat sera a prio­ri imprévisible…

Ce choix n’é­tait en fait qu’un moyen pro­vi­soire des­ti­né à com­pen­ser la faible capa­ci­té des machines pré­his­to­riques. Les pro­gram­meurs d’a­lors n’i­ma­gi­naient pas que cette façon de repré­sen­ter les années se per­pé­tue­rait au cours des décen­nies sui­vantes ; 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’illu­sion d’une ges­tion des années sur quatre chiffres ; l’é­di­tion de » 1998 » sur un rele­vé ban­caire ne prouve rien : les deux carac­tères » 19 » peu­vant avoir été ajou­tés a pos­te­rio­ri lors de l’im­pres­sion. De plus, les for­mats de la date varient 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 der­nière, l’al­go­rithme fré­quem­ment uti­li­sé consiste à recher­cher la valeur stric­te­ment supé­rieure à 31. Il est évident qu’à par­tir du pre­mier jan­vier [20]00 cette pra­tique sera défaillante, tout au moins jus­qu’en [20]32. Ain­si, ces deux exemples montrent que la repré­sen­ta­tion et la mani­pu­la­tion des dates dans les ordi­na­teurs ne sont ni aus­si simples, ni aus­si logiques que le bon sens le lais­se­rait supposer…

Ain­si, une ges­tion des années sur deux chiffres pour­ra conduire à des cal­culs de durée erro­nés, à des rela­tions d’ordre tem­po­rel inver­sées ou encore à des actions auto­ma­tiques déclen­chées au mau­vais moment ou pas du tout. Mal­heu­reu­se­ment, le pro­blème du codage des années sur deux chiffres n’est pas le seul : quatre autres l’accompagnent…

Les dates inac­ces­sibles : pour repré­sen­ter dans les pro­grammes cer­taines condi­tions par­ti­cu­lières telle une erreur ou la fin d’une liste d’ob­jets conte­nant des dates, une pra­tique très répan­due a consis­té à uti­li­ser une date (9/9/99…) ou une année (99…) par­ti­cu­lières, les ren­dant par là même inac­ces­sibles. Ces valeurs furent choi­sies parce que d’une part elles deman­daient la frappe d’une touche unique sur un cla­vier et que d’autre part elles sem­blaient appar­te­nir à un futur bien loin­tain. Cette ano­ma­lie n’a pro­vo­qué que quelques dys­fonc­tion­ne­ments mineurs : par exemple, elle a ren­du impos­sible la déli­vrance de pas­se­ports pro­vi­soires en Suède dans les pre­miers jours de 1999.

L’a­rith­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­tiel­le­ment codées sous forme de chaînes de carac­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 expli­ci­te­ment à la machine tout ce qui est fait lors d’un cal­cul manuel et en par­ti­cu­lier la pro­pa­ga­tion des rete­nues. Oublier cela lors de la déter­mi­na­tion de l’an­née sui­vante peut don­ner fré­quem­ment des résul­tats cor­rects (« 1998 » sui­vie de » 1999 ») et de temps en temps des sur­prises (« 1999 » sui­vie de » 199 : »). De telles ano­ma­lies ont déjà été ren­con­trées en Ita­lie, lors d’o­pé­ra­tions por­tant sur des cartes ban­caires, à la fin des années quatre-vingt.

La capa­ci­té limi­tée : il ne suf­fit pas à un ordi­na­teur d’ar­chi­ver des dates » sta­tiques « . Pour accom­plir ses mis­sions, il doit aus­si être capable de déter­mi­ner en per­ma­nence la date et l’heure cou­rantes. Cela est réa­li­sé à l’aide d’un ins­tant de réfé­rence arbi­traire et d’un comp­teur incré­men­té pério­di­que­ment d’une uni­té. Que se passe-t-il si ce der­nier est sous-dimen­sion­né par rap­port à l’u­sage prévu ?

Le sys­tème GPS (Glo­bal Posi­tio­ning Sys­tem) donne un exemple d’une telle ano­ma­lie. Celui-ci uti­lise une constel­la­tion de satel­lites et néces­site, au niveau des mobiles qui l’u­ti­lisent, des récep­teurs. Ces der­niers ont besoin de la date et ils la déter­minent, en par­ti­cu­lier, à l’aide d’un comp­teur de semaines qui ne peut comp­ter que de 0 à 1 023. Ain­si, tous les récep­teurs GPS sont repas­sés à 0 le 21 août 1999 à 23 : 59 : 47 UTC en ne pro­vo­quant aucune catas­trophe, mais seule­ment quelques ano­ma­lies dans des sys­tèmes grand public de navi­ga­tion (mari­time et auto­mo­bile). Mal­gré cela, le choix d’une telle limite (de l’ordre de vingt ans) dans un dis­po­si­tif d’o­ri­gine mili­taire semble tout à fait arbi­traire et mystérieux !

De telles ano­ma­lies se retrouvent poten­tiel­le­ment dans la plu­part des ordi­na­teurs. Remar­quons enfin que cette non-exten­si­bi­li­té des ordi­na­teurs concerne aus­si de nom­breuses autres infor­ma­tions : par exemple le sto­ckage des numé­ros de sécu­ri­té sociale ou encore de téléphone.

Les années bis­sex­tiles : les uni­tés de mesure du temps reposent his­to­ri­que­ment sur des consi­dé­ra­tions astro­no­miques. C’est ain­si que l’an­née cor­res­pond à la durée de la révo­lu­tion de la Terre autour du Soleil, soit envi­ron 365,2422 jours, ce qui n’est pas un nombre entier. Afin que l’an­née astro­no­mique reste en phase avec le calen­drier, la seule solu­tion est de don­ner à cette der­nière une lon­gueur variable de 365 ou de 366 jours. Ain­si, pério­di­que­ment, des années dites bis­sex­tiles sont introduites.

Jus­qu’à la réforme impo­sée par Gré­goire XIII en 1582, les années bis­sex­tiles reve­naient tous les quatre ans, ce qui don­nait une année moyenne de 365,25 jours donc légè­re­ment trop longue. Le calen­drier, dit gré­go­rien, fut donc des­ti­né à com­pen­ser cette ano­ma­lie au prix d’une défi­ni­tion plus com­plexe de la bis­sex­ti­li­té. Une année sera bis­sex­tile si elle est divi­sible par 4 sauf si elle est sécu­laire (c’est-à-dire divi­sible par 100) et non divi­sible par 400. Ain­si, 2000 et 1996 sont bis­sex­tiles, alors que 1900 et 1999 ne le sont pas.

L’en­semble de ces cri­tères est géné­ra­le­ment mécon­nu du public, même culti­vé, 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éfi­ni­tion Bis­sex­tile : se dit de l’an­née qui revient tous les quatre ans et dont le mois de février com­porte 29 jours ! Cela a don­né nais­sance à quelques logi­ciels et maté­riels pré­sen­tant des ano­ma­lies graves leur fai­sant consi­dé­rer que l’an 2000 n’é­tait pas bissextile.

Ain­si, ce qui est appe­lé com­mu­né­ment le bug de l’an 2000 est en fait l’u­nion d’un cer­tain nombre d’a­no­ma­lies 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 ano­ma­lies, qui sont plus le résul­tat de choix anciens que d’er­reurs, sont par­ti­cu­liè­re­ment élé­men­taires à spé­ci­fier. Cette consta­ta­tion a deux consé­quences immé­diates : la pre­mière concerne l’in­cré­du­li­té de ceux qui découvrent ces pro­blèmes, alors que la seconde fait croire à ces der­niers que la solu­tion est, elle aus­si, élé­men­taire. De par la nature non linéaire de ces » phé­no­mènes « , il n’en est rien, tout au contraire.

Les responsables

Mais avant de décrire les dif­fi­cul­tés cor­res­pon­dantes, il est bon de recher­cher les res­pon­sa­bi­li­tés et d’es­sayer de com­prendre com­ment il est pos­sible que la plu­part des acteurs concer­nés aient atten­du la der­nière minute pour agir, alors que ces pro­blèmes sont connus depuis plus de vingt ans, dans le milieu ban­caire en particulier.

Les infor­ma­ti­ciens semblent bien évi­dem­ment être les cou­pables tout dési­gnés. En effet, ils n’ont pas su voir à long terme les consé­quences de leurs choix et ils n’ont pas été capables d’é­crire des pro­grammes sans erreurs. Ils n’ont pas eu ensuite la fran­chise d’a­vouer leurs fautes, le cou­rage d’ex­pli­quer les consé­quences néfastes de ces der­nières et la force de deman­der les énormes moyens indis­pen­sables pour effec­tuer les répa­ra­tions utiles…

Rien ne sert de cou­rir, il faut par­tir à point, regret­tons donc que le néces­saire ne fût point fait lors­qu’il en était encore temps ; fait donc posé­ment, cor­rec­te­ment et non point dans la pré­ci­pi­ta­tion, elle-même source évi­dente de nou­velles ano­ma­lies. Mais arrê­tons là de les acca­bler : en effet, l’ab­sence de pré­vi­si­bi­li­té et de fia­bi­li­té est une constante dans toutes les acti­vi­tés humaines.

Mal­gré cela, pour­quoi les grandes asso­cia­tions pro­fes­sion­nelles que sont l’ACM (The Asso­cia­tion for Com­pu­ting Machi­ne­ry) ou encore l’IEEE (The Ins­ti­tute of Elec­tri­cal & Elec­tro­nics Engi­neers) n’ont-elles pas tiré le signal d’a­larme plus tôt ? Pour­quoi a‑t-il fal­lu attendre ces der­niers mois pour voir publier de trop brefs articles sur ce sujet ? Est-ce parce que la main­te­nance n’est pas une acti­vi­té digne d’in­té­rêt ou pire parce que qu’elle ne fait pas par­tie de l’u­ni­vers de l’informatique ?

Mais les ordi­na­teurs ne sont pas des objets abs­traits et simples ; ce sont des machines com­plexes, com­po­sées de nom­breuses enti­tés coopé­rantes pré­sen­tant toutes, de façon plus ou moins chro­nique, des ano­ma­lies. La main­te­nance fait donc par­tie de la vie de l’in­for­ma­ti­cien et doit donc être trai­tée avec tout le res­pect dû à ce qui fina­le­ment condi­tionne le bon fonc­tion­ne­ment quo­ti­dien de nos machines. Enfin, l’am­pleur des dif­fi­cul­tés aux­quelles nous sommes aujourd’­hui confron­tés aurait pu sus­ci­ter des voca­tions, par exemple dans le monde de l’in­tel­li­gence arti­fi­cielle. Mal­heu­reu­se­ment, il est trop tard !

Ain­si, les infor­ma­ti­ciens (des temps héroïques…) ont des cir­cons­tances atté­nuantes. Mais qu’en est-il des uti­li­sa­teurs eux-mêmes ? En effet, nom­breux sont ceux qui connais­saient ces pro­blèmes depuis long­temps : les ban­quiers, par exemple, ne font-ils pas des prêts à vingt ou trente ans ? Ils savaient donc dès les années soixante-dix que l’ab­sence du pseu­do-numé­ro de siècle était nuisible.

Il est cer­tain qu’a­lors seul le strict néces­saire a été fait ; n’au­rait-ce pas été faire preuve de clair­voyance que d’ex­tra­po­ler vers les domaines non encore cri­tiques ? Notons de plus qu’a­lors l’in­for­ma­tique était beau­coup moins omni­pré­sente, ce qui ren­dait ces pro­blèmes plus faciles à résoudre. Pour­quoi enfin n’ont-ils pas for­te­ment fait pres­sion sur les grands construc­teurs dont ils sont par­mi les plus gros clients ? Cela aurait cer­tai­ne­ment accé­lé­ré l’ar­ri­vée sur le mar­ché de sys­tèmes » com­pa­tibles » et peut-être étouf­fé l’in­cen­die avant qu’il ne se pro­page ! Là aus­si, il est mal­heu­reu­se­ment trop tard !

Que dire main­te­nant de la res­pon­sa­bi­li­té des médias ? Elle semble consi­dé­rable puis­qu’un évé­ne­ment n’existe que s’il est rela­té ; son impor­tance est alors pro­por­tion­nelle au nombre de lignes et de minutes qui lui est consa­cré. Il est donc regret­table de consta­ter le trop long silence de la presse, en par­ti­cu­lier infor­ma­tique, tant natio­nale 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 attendre le 20 février 1998 pour qu’une mis­sion pré­si­dée par Gérard Thé­ry soit consti­tuée. L’am­pleur du pro­blème est telle, qu’elle aurait deman­dé d’une part une coor­di­na­tion inter­na­tio­nale au plus haut niveau des États et d’autre part que des infor­ma­tions soient com­mu­ni­quées aux citoyens afin qu’ils sachent l’é­tat réel dans lequel se trouvent les admi­nis­tra­tions, les ser­vices publics et de san­té, la dis­tri­bu­tion des éner­gies, les sys­tèmes de trans­port, la défense nationale…

Les plans de secours mis en place fonc­tion­ne­ront-ils (le mal­heu­reux acci­dent sur­ve­nu dans la nuit du 25 au 26 sep­tembre 1998 à l’hô­pi­tal Édouard-Her­riot de Lyon est par­ti­cu­liè­re­ment ins­truc­tif) ? En cas d’in­ci­dents, le retour à la nor­male sera-t-il garan­ti rapi­de­ment ? Est-on capable de reve­nir pro­vi­soi­re­ment au papier et au crayon ? Autant de ques­tions que tous se posent natu­rel­le­ment ; l’ab­sence de réponses ne peut qu’en­gen­drer plus d’in­quié­tude et déclen­cher des mou­ve­ments de panique dont les consé­quences pour­raient être bien plus graves que celles des inci­dents réels, peut-être inexis­tants d’ailleurs…

Ces réac­tions pos­sibles pour­raient être déclen­chées par des pénu­ries arti­fi­cielles por­tant, par exemple, sur l’argent liquide ou encore les biens de pre­mière néces­si­té (dans les pre­miers jours de jan­vier 1999, quelques bureaux de poste fran­çais ont été pris d’as­saut à la suite de l’in­dis­po­ni­bi­li­té du sys­tème infor­ma­tique gérant les comptes d’épargne).

À cela, il convient d’a­jou­ter le calen­drier de la mise en place de l’eu­ro qui a été défi­ni, sans appa­rem­ment prendre en compte le fait évident qu’il est dif­fi­cile, pour ne pas dire impos­sible, de mener à bien et cor­rec­te­ment deux pro­jets infor­ma­tiques d’une telle ampleur simultanément.

Enfin, sachant le défi­cit géné­ra­li­sé en infor­ma­ti­ciens, la loi fran­çaise sur les 35 heures n’est-elle pas incom­pa­tible, pro­vi­soi­re­ment, avec l’ur­gence de la situa­tion (notons au pas­sage qu’il ne s’a­git pas ici de cri­tiques envers l’eu­ro et les mesures pour l’emploi, mais sim­ple­ment de remarques de bon sens : serait-il rai­son­nable de deman­der à des pom­piers qui éteignent un incen­die, d’a­ban­don­ner leur tâche, sous pré­texte qu’il est dix-sept heures trente ?).

Fina­le­ment, ne serions-nous tous pas à la fois res­pon­sables et cou­pables ? En tout cas, quelle que soit la réponse don­née à cette inter­ro­ga­tion, il paraît évident que nous devons tous nous sen­tir concer­nés, tant à l’in­té­rieur des struc­tures pro­fes­sion­nelles aux­quelles nous appar­te­nons, qu’en tant que citoyen.

Les solutions

Tous les pro­blèmes que nous venons de décrire sont élé­men­taires et ne demandent aucune com­pé­tence par­ti­cu­lière pour être com­pris. Alors où est la dif­fi­cul­té ? Les sys­tèmes infor­ma­tiques sont sem­blables aux ice­bergs : 10 % de réel émer­gé (le maté­riel) et 90 % de vir­tuel immer­gé (le logi­ciel) ; or autant il est facile d’ap­pré­hen­der la com­plexi­té maté­rielle car visible, autant cela est dif­fi­cile pour la com­plexi­té logi­cielle puisque intan­gible. En fait, les infor­ma­ti­ciens sont en face d’un pro­blème assez simi­laire à celui qui consis­te­rait à leur deman­der de comp­ter les grains de sable sur une plage.

En ce qui concerne la ges­tion des dates dans nos ordi­na­teurs, la situa­tion est iden­tique : les opé­ra­tions indi­vi­duelles de cor­rec­tion sont élé­men­taires ; la dif­fi­cul­té réside uni­que­ment dans leur nombre. Il y aurait actuel­le­ment, de par le monde, envi­ron cent mil­liards de lignes de pro­grammes concer­nées. Un mythe répan­du consiste à affir­mer l’exis­tence d’une solu­tion miracle.

Mal­heu­reu­se­ment, celle-ci n’existe pas ; en effet, pour qu’un outil uni­ver­sel de mise à jour puisse être conçu, il aurait fal­lu qu’au cours des décen­nies pas­sées, des méthodes strictes de déve­lop­pe­ment aient été uti­li­sées. Il n’en est rien et par exemple, le nombre de façons de repré­sen­ter une date dans un ordi­na­teur est éle­vé… Il convient d’a­jou­ter que même si cette solu­tion exis­tait elle ne dis­pen­se­rait pas de la pre­mière étape incon­tour­nable : l’inventaire.

En effet, avant de cor­ri­ger les maté­riels et les logi­ciels, il est néces­saire de dis­po­ser de leur liste exhaus­tive. Or, aus­si para­doxal que cela puisse paraître, ces inven­taires, en géné­ral, n’existent pas ; il faut donc com­men­cer par les éta­blir. L’ex­pé­rience montre que, pour une banque, plu­sieurs dizaines de mil­liers de logi­ciels sont uti­li­sés et ce dénom­bre­ment demande par­fois plus d’une année pour être réa­li­sé proprement !

Mal­heu­reu­se­ment, l’in­for­ma­tique concer­née par le bug n’est pas faite, loin s’en faut, d’or­di­na­teurs posés sur nos bureaux et conte­nant quelques logi­ciels bien ran­gés… Non, elle est par­tout : aus­si bien dans les ascen­seurs, les cli­ma­ti­seurs, les robots de fabri­ca­tion… Et c’est cer­tai­ne­ment là que le risque est le plus grand : dans cette infor­ma­tique qua­li­fiée d’enfouie qui assure en per­ma­nence le bon fonc­tion­ne­ment de tout notre envi­ron­ne­ment et dont nous igno­rons presque tout !

Il n’y a donc pas d’autre solu­tion que de pas­ser au peigne fin ces mil­liards de lignes de pro­grammes et ces mil­lions de sys­tèmes spé­cia­li­sés : nous sommes à la recherche d’ai­guilles (les dates) aux formes et en nombre incon­nus dans une meule de foin. Si la prise de conscience avait eu lieu en temps utile, il aurait été envi­sa­geable de rem­pla­cer l’an­cien par du nouveau.

Mais un point de non-retour a été fran­chi et donc seules les cor­rec­tions res­tent envi­sa­geables. En réa­li­té, la situa­tion est en géné­ral plus pré­caire que cela : lorsque sont pris en compte les res­sources humaines dis­po­nibles, le temps res­tant et la quan­ti­té de tra­vail à accom­plir, il appa­raît que, bien sou­vent, même ce « rafis­to­lage » exhaus­tif est impos­sible ! S’im­pose alors un tri per­met­tant de fixer les prio­ri­té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 évi­dem­ment asso­cié à une ana­lyse des risques encou­rus, ain­si qu’à la mise en place de plans de secours.

Mais en quoi consistent donc ces « rafis­to­lages » ? La bonne solu­tion au pro­blème du codage des années sur deux chiffres consis­te­rait à étendre les zones de mémoire des­ti­nées à sto­cker et à mani­pu­ler des années. Com­bien de chiffres seraient néces­saires ? Quatre paraissent a prio­ri rai­son­nables, mais ce pro­blème ne se repo­se­ra-t-il pas alors en 9999 ? Cette remarque en forme de bou­tade est des­ti­née à nous rap­pe­ler deux points essen­tiels : les limites arbi­traires (et sou­vent irré­ver­sibles) impo­sées par les pro­gram­meurs et le manque de visi­bi­li­té à long terme. Quatre chiffres sont évi­dem­ment suf­fi­sants ; mal­heu­reu­se­ment, la com­plexi­té des opé­ra­tions cor­res­pon­dantes est rédhibitoire.

“autres solu­tions doivent donc être mises en œuvre. L’une des plus répan­dues consiste à choi­sir, dans un cer­tain contexte, une année dite pivot codée sur quatre chiffres, par exemple 1960 ; ensuite toute année AA sera éten­due sur quatre chiffres uni­que­ment là où cela est utile. Cette exten­sion se fera à l’aide d’un test simple : si AA est supé­rieure à [19]60, il lui est sub­sti­tué 19AA et 20AA dans le cas contraire. Cette solu­tion pré­sente un cer­tain nombre de dan­gers. Le pre­mier concerne la cohé­rence ; en effet, il est impor­tant que la même date pivot soit uti­li­sée par tous les sys­tèmes en rela­tion : mais est-ce pos­sible ? Non en toute géné­ra­li­té, car cela signi­fie­rait à la limite que l’en­semble de la pla­nète uti­lise la même.

Le second dan­ger est plus loin­tain ; en effet, que se pas­se­ra-t-il lorsque tous les obs­tacles qui s’an­noncent devant nous auront été fran­chis avec plus ou moins de suc­cès ? La réponse est déjà connue : nous com­met­trons les mêmes erreurs que par le pas­sé et nous oublie­rons nos rafis­to­lages. Or la notion même d’an­née pivot contient sa propre limite, de l’ordre de quelques dizaines d’an­nées. Ain­si, sans résoudre les vrais pro­blèmes, nous sommes en train de mettre en place des bombes à retar­de­ment qui don­ne­ront bien des sou­cis à nos successeurs !

Dans tout pro­jet infor­ma­tique, il est essen­tiel de véri­fier la confor­mi­té de la réa­li­sa­tion par rap­port au cahier des charges et ces tests occupent envi­ron 50 % du temps glo­bal de déve­lop­pe­ment. Pour le bug, deux types de tests doivent être accom­plis ; d’a­bord des tests de non-régres­sion qui per­mettent de véri­fier que les cor­rec­tions appor­tées ont main­te­nu l’in­té­gra­li­té des fonc­tion­na­li­tés anté­rieures. Au niveau d’une banque, par exemple, cela se fait en met­tant en place un site indé­pen­dant du site opé­ra­tion­nel, puis en com­pa­rant leurs résul­tats ; cette approche est mal­heu­reu­se­ment plus sta­tis­tique qu’ex­haus­tive. Ensuite, des tests de com­pa­ti­bi­li­té doivent être conduits afin de véri­fier que les pro­blèmes de date ont été réso­lus. Cer­taines dates par­ti­cu­liè­re­ment cri­tiques doivent être exa­mi­né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­cu­liè­re­ment déli­cate, per­sonne ne sachant en toute géné­ra­li­té ni ce qu’il faut tes­ter, ni com­ment vieillir les jeux de tests sans intro­duire de biais pervers.

Éva­lué très gros­siè­re­ment, le coût des cor­rec­tions est au niveau de la pla­nète de l’ordre de mille mil­liards de dol­lars ! Mais il y a deux rai­sons pous­sant à aug­men­ter cette éva­lua­tion : d’une part l’ab­sence d’exemple de grands pro­jets infor­ma­tiques pour les­quels les bud­gets ini­tiaux ont été res­pec­tés et d’autre part les dédom­ma­ge­ments dus aux inévi­tables dégâts et catas­trophes : ils sont actuel­le­ment éva­lués à deux mille mil­liards de dollars !

Les assu­reurs ont tri­ple­ment à s’in­quié­ter : ils sont tout à la fois par­mi les plus gros uti­li­sa­teurs de l’in­for­ma­tique, les plus sen­sibles à ces pro­blèmes de ges­tion de dates et les plus concer­nés de par leur fonc­tion ; ils n’ont d’ailleurs pas man­qué de rap­pe­ler (fort jus­te­ment d’ailleurs !) que le bug ne com­por­tait aucun carac­tère aléa­toire, l’ar­ri­vée du 01/01/2000 étant connue 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’a­chè­ve­ment immuables. Or rares sont les pro­jets qui se sont ache­vés à temps, tout en res­pec­tant les bud­gets et les fonctionnalités.

Enfin, nous sommes en pré­sence d’un magni­fique exemple d’effet domi­no : de par l’in­ter­con­nec­ti­vi­té géné­ra­li­sée, il ne suf­fit pas qu’une entre­prise soit prête ; il importe que l’in­té­gra­li­té de ses clients et de ses four­nis­seurs avec les­quels 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 pro­cé­der à un colos­sal tra­vail externe de sensibilisation…

Le monde de la banque et de la finance est par­ti­cu­liè­re­ment sen­sible à ce phé­no­mène ; un scé­na­rio catas­trophe, indé­pen­dant du bug et des plus réa­listes mal­heu­reu­se­ment, consiste à ima­gi­ner sur une place bour­sière, n’im­porte où dans le monde, un ordi­na­teur défaillant qui pro­vo­que­rait une ano­ma­lie qui se pro­pa­ge­rait ensuite, de façon qua­si­ment irré­ver­sible, à une vitesse proche de celle de la lumière, cau­sant des ventes mas­sives, un krach, une récession…

Conclusion

Les pro­blèmes de ges­tion des dates dans les ordi­na­teurs, même s’ils sont élé­men­taires à spé­ci­fier, consti­tuent une réelle menace pour l’in­té­gri­té de nos éco­no­mies, voire même pour la sécu­ri­té de nos États. Il n’y a a prio­ri aucune acti­vi­té, ni per­sonne qui en soit réel­le­ment à l’a­bri, ne serait-ce qu’à cause des interdépendances.

Mal­heu­reu­se­ment il ne s’a­git là que d’un exemple concret d’une catas­trophe pos­sible par­mi d’autres, qui gisent poten­tiel­le­ment dans nos tech­no­lo­gies, prêtes à écla­ter à tout moment.

Nos réa­li­sa­tions reposent aujourd’­hui toutes sans excep­tion sur l’in­for­ma­tique. Pra­ti­quée au quo­ti­dien, celle-ci est à des années-lumière de la pure­té des 0 et des 1 de l’al­gèbre de Boole et de ses règles abso­lues : elle n’est ni Art, ni Science, mais bricolage.

Bri­co­lage de génie par­fois, ses réus­sites sont là pour en témoi­gner : l’or­di­na­teur est en par­ti­cu­lier un outil fan­tas­tique pour ampli­fier nos facul­tés intel­lec­tuelles et nous per­mettre des pro­grès sans pré­cé­dent dans le domaine de la connais­sance. Mais bri­co­lage approxi­ma­tif le plus sou­vent, qui pour­ra nous conduire vers d’autres catas­trophes aux consé­quences incal­cu­lables dans un ave­nir plus ou moins proche.

Le bug est une donc une oppor­tu­ni­té à sai­sir : le temps n’est-il pas venu de s’in­ter­ro­ger sur cette com­plexi­té dont nous sommes à l’o­ri­gine, que par­fois nous ne maî­tri­sons plus et qui nous échappe alors ? Soyons en tout cas conscients de notre res­pon­sa­bi­li­té aujourd’­hui et œuvrons cha­cun à notre niveau.

Biblio­gra­phie :
Le Bug de l’an 2000 – Com­prendre l’in­for­ma­tique jus­qu’à ses dys­fonc­tion­ne­ments, Ber­nard Aumont et Jean-Fran­çois Colon­na, Flam­ma­rion, Paris, mars 1999.

---

Articles similaires :

Gérard Ber­ry (67), l’esprit d’enfance Com­po­si­tion d’informatique (XCR) L’hyperpuissance de l’informatique Du Set packing au taxi aérien auto­nome, ren­contre avec une jeune cher­cheuse en recherche opérationnelle Allo­Hous­ton : créer des pro­duits numé­riques sur mesure