Courrier des lecteurs : À propos de l’article “Réflexions sur le ‘bogue de l’an 2000’”

J.-M. BARDIN (72)

J.-M. BARDIN (72)

La lec­ture de l’ar­ti­cle d’Erik Egnell à pro­pos de l’an 2000 dans le numéro de mai m’a plongé dans un sen­ti­ment à mi-chemin entre la stu­peur et l’indig­na­tion. Après avoir hésité à répon­dre, je me suis résolu à le faire, non pas pour défendre mon statut de respon­s­able de pro­jet an 2000 dans une grande banque française, mais pour rétablir quelques vérités mis­es à mal dans cet arti­cle, qui pour­rait inciter à un cer­tain relâche­ment dans les efforts, pour­tant encore insuff­isants, engagés dans notre pays pour maîtris­er les risques liés au bogue de l’an 2000.

• Le bogue de l’an 2000 n’est pas une inven­tion d’in­for­mati­ciens désœu­vrés. C’est une réal­ité à laque­lle beau­coup d’en­tre nous ont été con­fron­tés ces derniers temps. Je n’en prendrai pour exem­ple que ces mil­liers de ter­minaux de paiement qui, au début de l’an­née 1998, refu­saient les cartes de paiement à échéance 2000, car ils les pen­saient périmées depuis qua­tre-vingt-dix-huit ans. Mais il y a quan­tité d’autres exem­ples plus discrets.
   
• La con­fu­sion sur les années se traduit par des erreurs dans des cal­culs ou des tris faisant inter­venir des dates, une des don­nées les plus fréquentes dans les pro­grammes (90 % des pro­grammes d’une banque manip­u­lent des dates !). Les sys­tèmes ren­trent alors dans des séquences d’in­struc­tions jamais testées : au mieux, ils s’ar­rê­tent, ce qui per­met de détecter l’anom­alie ; au pire, ils génèrent des erreurs sournois­es, qui, non décelées immé­di­ate­ment, sont très dif­fi­ciles à cor­riger quand on s’en aperçoit bien plus tard.
   
• Ce n’est pas parce qu’un pro­gramme de prêts immo­biliers sait depuis vingt ans traiter des échéances postérieures à l’an 2000 qu’il est vac­ciné con­tre le bogue. En effet, celui-ci peut affecter de manière dif­féren­ciée cha­cun des types de dates traitées dans un pro­gramme : les dates con­cer­nant les échéances à venir peu­vent ne pas pos­er prob­lème, alors que celles cor­re­spon­dant au prochain appel de fonds peu­vent en pos­er un.
   
• Les sys­tèmes infor­ma­tiques ne sont pas les seuls con­cernés. Tous les sys­tèmes élec­tron­iques sont sus­cep­ti­bles d’être affec­tés par le bogue, quand bien même il n’y aurait pas de dates appar­entes. Ce peut être le cas d’as­censeurs, dont l’élec­tron­ique peut gér­er les dates des vis­ites de main­te­nance, et qui peu­vent s’ar­rêter en cas de délai exces­sif depuis la dernière visite.
   
• L’in­for­ma­tique et l’élec­tron­ique ont envahi notre monde ; toute notre société en dépend. Vous ne seriez sans doute pas fâché si votre cen­tre d’im­pôts oubli­ait votre exis­tence suite au déclenche­ment intem­pes­tif d’un pro­gramme de purge de don­nées. Vous le seriez sans doute davan­tage, si vous appre­niez que les instal­la­tions de réan­i­ma­tion de votre hôpi­tal ou que les dis­posi­tifs de sur­veil­lance des cen­trales nucléaires d’Eu­rope de l’Est pou­vaient ne pas fonc­tion­ner cor­recte­ment au pas­sage à l’an 2000.
   
• Il est vrai que le bogue de l’an 2000 est finale­ment un bogue comme un autre, comme on en ren­con­tre tous les jours dans nos sys­tèmes. Sa seule par­tic­u­lar­ité est qu’il risque de frap­per au même moment dans de mul­ti­ples endroits, ren­dant insup­port­a­bles des prob­lèmes qui, sur­venant isolé­ment, pour­raient être réso­lus, sans même que vous vous en soyez aperçu. De plus, c’est un prob­lème sys­témique, c’est-à-dire que, même si vous avez tout fait pour adapter et véri­fi­er vos sys­tèmes, vous risquez d’être mis en dif­fi­culté par vos four­nisseurs ou vos clients.
   
• Il est vrai que cer­tains sont allés loin, trop loin, dans le cat­a­strophisme mil­lé­nar­iste, et ont fini par décrédi­bilis­er le prob­lème réel. Les médias à sen­sa­tions avides de sujets croustil­lants, les cab­i­nets d’av­o­cats améri­cains habiles à tir­er des mil­lions de dol­lars d’un fait sans impor­tance, cer­taines sociétés infor­ma­tiques peu scrupuleuses ont cher­ché à tir­er avan­tage en en rajoutant. Cer­taines entre­pris­es en font même un argu­ment com­mer­cial, en dénonçant l’in­suff­isante pré­pa­ra­tion de leurs con­cur­rents. Mais il ne faut pas jeter le bébé avec l’eau du bain. Si le sujet est cor­recte­ment traité, il peut être maîtrisé, mais, s’il est ignoré, il peut avoir dans cer­tains cas des con­séquences dra­ma­tiques. Com­ment réagis­sez-vous, quand vous apprenez, après l’in­cendie du tun­nel du mont Blanc, qu’un rap­port avait dénon­cé quelques mois plus tôt la sécu­rité insuff­isante de cette installation ?
   
• Il est vrai que les infor­mati­ciens por­tent la respon­s­abil­ité orig­inelle du prob­lème et ils n’ont jamais cher­ché à le nier. Il peut sem­bler sur­prenant qu’ils n’aient pas plus anticipé un prob­lème inéluctable con­nu depuis tou­jours. La rai­son en est sim­ple : il y a trente ans, les pre­miers infor­mati­ciens ne pen­saient pas que les sys­tèmes et les pro­grammes qu’ils fab­ri­quaient dur­eraient plus d’une dizaine d’an­nées et ils ont surtout cher­ché à économiser les ressources mémoire et machine, alors rares et chères, en codant les années sur deux car­ac­tères. Dans les faits, les pro­grammes ont duré beau­coup plus longtemps qu’ils n’avaient imag­iné, et les nou­veaux sys­tèmes n’é­taient jamais con­stru­its ex nihi­lo mais emprun­taient sou­vent à la généra­tion précé­dente, d’où la prop­a­ga­tion jusqu’à nos jours de cet anachronisme.
   
• Mais pourquoi leur reprocher d’avoir alerté le reste de la société sur ce sujet, au pré­texte qu’ils en étaient à l’o­rig­ine ? Fal­lait-il atten­dre que des prob­lèmes graves se pro­duisent pour réa­gir ? Auriez-vous préféré qu’ils imi­tent les organ­ismes de trans­fu­sion san­guine, qui ont atten­du que des mil­liers de per­son­nes soient con­t­a­m­inées avant de recon­naître leur responsabilité ?

J.-P. VIAL (65) (Auteur du progiciel ” Software ISO 2000 ”)

Informaticiens de l’an 2000. Félicités ? Remerciés ?

Il paraît presque super­flu de rap­pel­er dans ces colonnes la teneur du “bogue de l’an 2000”. Il existe, dans les ordi­na­teurs, comme dans les fichiers qu’ils utilisent, des lim­ites à la capac­ité d’af­fichage des don­nées. La capac­ité d’af­fichage est finie. Pour les dates comme pour les autres données.

Ce prob­lème d’af­fichage est, par nature, un prob­lème infor­ma­tique, mais il n’est pas pour autant un prob­lème unique­ment élec­tron­ique. Il existe, dans tous les instru­ments que nous util­isons, des lim­ites d’af­fichage. Nom­breux sont les affichages qui se font sur un nom­bre de chiffres lim­ité et choisi arbi­traire­ment. Par exem­ple, le kilo­mé­trage des voitures.

Dans les voitures des années 50, le comp­teur kilo­métrique com­por­tait cinq chiffres, parce que la plu­part des voitures de l’époque avaient une durée de vie estimée inférieure à 100 000 km. Depuis, on a con­stru­it des voitures plus solides, si bien que l’af­fichage du kilo­mé­trage à six chiffres s’est généralisé.

Il est cer­tain que la pré­ci­sion d’un affichage kilo­métrique ne revêt pas une impor­tance cap­i­tale. Cer­tains indéli­cats pour­raient même y voir un avan­tage, en sous-éval­u­ant l’an­ci­en­neté d’une voiture qu’ils comptent ain­si reven­dre à meilleur prix. Mais pourquoi les détracteurs du “bogue de l’an 2000” choi­sis­sent-ils juste­ment cet exem­ple-là pour en min­imiser les risques infor­ma­tiques ? Il y a tant d’autres sit­u­a­tions dans lesquelles l’af­fichage d’une don­née revêt une impor­tance bien supérieure, économique ou même vitale.

Les comp­teurs d’eau, de gaz, d’élec­tric­ité ont eux aus­si leurs lim­ites d’af­fichage, et on peut raisonnable­ment sup­pos­er que les com­pag­nies qui dis­tribuent les ressources cor­re­spon­dantes sont haute­ment intéressées, finan­cière­ment, à une cer­taine exac­ti­tude des infor­ma­tions affichées.

Et qui mon­terait à bord d’un avion si, tous les 10 000 pieds, l’al­timètre repas­sait par le zéro ?

Admet­tons donc, pour l’in­stant, l’ex­is­tence de lim­ites de capac­ité d’af­fichage : une infor­ma­tion affichée sur n chiffres s’af­fiche mod­u­lo 10ⁿ.

Comment exprimer les dates ?

Pour exprimer une date quel­conque, il faut d’abord choisir une date de référence. La lim­ite de capac­ité se traduit ici par un nom­bre de jours, comp­té pos­i­tive­ment ou néga­tive­ment, que l’on sait représen­ter à par­tir de la date de référence.

Selon les dates de référence choisies, et les nom­bres de jours per­mis, les sys­tèmes infor­ma­tiques peu­vent tomber en panne à des dates divers­es. Cer­tains sont déjà tombés en panne en 1970 ou en 1999. D’autres tomberont en panne en 2011, 2038 ou 2071. Sans action préven­tive, beau­coup pour­raient tomber en panne en 2000.

Seuls quelques spé­cial­istes, comme les astro­physi­ciens ou les géo­logues, ont besoin de toutes les échelles de temps, depuis le big bang orig­inel jusqu’à la fin sup­posée de l’u­nivers. Pour eux, la seule représen­ta­tion du temps qui con­vi­enne est la représen­ta­tion sci­en­tifique, que les infor­mati­ciens appel­lent représen­ta­tion en vir­gule flot­tante, c’est-à-dire :

± n . 10 ^{± p}.

En infor­ma­tique de ges­tion, comme dans la vie courante, on s’in­téresse à une tranche de temps, une fenêtre de temps, plus ou moins cen­trée sur la date du traite­ment. Du moins, la fenêtre de temps con­tient-elle, en plus de la date du traite­ment, un cer­tain laps (ou hori­zon) de temps dans le futur et un cer­tain laps de temps dans le passé. C’est ce que fig­ure le sché­ma suivant.

Les paramètres (- a, + b) de la fenêtre de temps vari­ent en fonc­tion des besoins des appli­ca­tions infor­ma­tiques. Par exem­ple, la ges­tion de prêts ban­caires aura sans doute un hori­zon (+ b) de quinze ou vingt ans. Pour gér­er la date de nais­sance des emprun­teurs, le passé (- a) pour­ra avoisin­er un siècle.

Comme les traite­ments infor­ma­tiques sont répéti­tifs, la date du traite­ment change con­tin­uelle­ment. Il en résulte que la tranche de temps gérée se déplace uni­for­mé­ment vers le futur. L’in­for­ma­tique de ges­tion a besoin d’une tranche, ou fenêtre, de temps glissante.

Les paramètres (- a, + b) de la fenêtre sont choi­sis à un moment don­né, en fonc­tion des besoins, des habi­tudes, des normes. Il est pos­si­ble que les choix effec­tués judi­cieuse­ment à un moment don­né ne soient plus val­ables ultérieure­ment. Mais pourquoi serait-ce la seule faute des informaticiens ?

Par exem­ple, si les gen­darmes vien­nent déranger une mamie de 106 ans, dans sa mai­son de retraite, pour la con­duire à l’é­cole manu mil­i­tari comme une gamine de six ans, c’est d’abord et avant tout une erreur infor­ma­tique (c’est “la faute de l’or­di­na­teur”). Mais on pour­rait tout aus­si bien soutenir que c’est une erreur de la médecine, qui s’évertue à pro­longer la durée de vie de l’e­spèce humaine, alors qu’il y a à peine de quoi nour­rir l’e­spèce tout entière.

Sans aller aus­si loin — je ris­querais de me fer­mer défini­tive­ment les portes des maisons de retraite — les infor­mati­ciens ne sont pas les seuls coupables. L’homme de la rue, les médias, notre cul­ture com­mune nous font tous com­met­tre la même erreur. On par­le des années 60 ou des années 90. Per­son­ne ne dit les années 1960 ou les années 1990. Même à l’ap­proche de cette fin de siè­cle et mil­lé­naire. Même sous la men­ace du “bogue de l’an 2000”.

Pour les dates, et pour les années en par­ti­c­uli­er, le prob­lème — car c’en est un — prend tout à coup une acuité démesurée, parce que tous les sys­tèmes risquent de tomber en panne en même temps, à la fin de l’an­née 1999.

J’en­tends au fond de la salle quelques cartésiens qui mur­murent “mais n’y a‑t-il pas une norme de représen­ta­tion des dates ?”

Ah ! s’il n’y en avait qu’une ! Dans le lan­gage courant, il y a une norme de fait : les années s’énon­cent avec deux chiffres. Dans les années 60, comme dans le lan­gage courant, il y avait aus­si une norme infor­ma­tique de fait : les années se représen­taient com­muné­ment sur deux chiffres. La mod­estie ou le manque de vision des infor­mati­ciens de l’époque les empêchaient d’en­trevoir que, non seule­ment leurs pro­grammes, mais aus­si, et surtout, leurs fichiers — voir plus loin — sur­vivraient jusqu’en l’an 2000 et au-delà.

La norme ISO 8601 traite de la représen­ta­tion des dates. Mais de quand date-t-elle ? Notre cal­en­dri­er lui-même date seule­ment d’un peu plus de qua­tre siè­cles, et son uni­ver­sal­ité est tout juste — est-ce un hasard ? — con­tem­po­raine de l’in­for­ma­tique. Com­bi­en de temps restera-t-il en vigueur sous cette forme ? Est-il seule­ment raisonnable d’af­firmer, aujour­d’hui, que le 1er jan­vi­er 2100 tombera un ven­dre­di, comme le prévoit le calcul ?

Le prob­lème n’est pas tant de normer que de renormer. C’est un prob­lème de volume.

Quelles sont les formes du “virus an 2000” ?

Il existe grosso modo trois vari­antes du “bogue de l’an 2000”.

• Les saisies ou les traite­ments infor­ma­tiques véri­fient les années traitées. Aucune saisie ni aucun traite­ment n’ont été prévus au-delà de 1999. Dans le futur, le sys­tème infor­ma­tique se bloque de lui-même.
  C’est le cas de fig­ure le plus “infor­ma­tique­ment cor­rect”. Le sys­tème infor­ma­tique n’a pas été prévu pour le futur, et il s’au­to­pro­tège. Néan­moins, s’il faut l’u­tilis­er après 1999, on doit le corriger.
• Les années ne sont pas véri­fiées, et le sys­tème les laisse pass­er sans contrôle.
  C’est déjà un cas de laiss­er-aller infor­ma­tique car­ac­térisé. Le sys­tème peut cal­culer les résul­tats les plus aber­rants. Et même peut-être les bons ; allez savoir ? Et, pour le savoir, il faut inspecter les pro­grammes de fond en comble.
• Cer­taines années, comme 00 ou 99, pren­nent une sig­ni­fi­ca­tion spé­ciale qui inter­dit de les utilis­er en tant que telles. Sou­vent, 00 sig­ni­fie don­née incon­nue, valeur non com­mu­niquée. 99 représente l’infi­ni, l’ab­sence de lim­ite supérieure.

C’est le cas de fig­ure le plus défa­vor­able. Encore que, pour 99, le prob­lème — s’il y a prob­lème — est déjà réglé.

Dans tous les cas de fig­ures, il faut inspecter les pro­grammes de fond en comble, pour y débus­quer l’une ou l’autre forme du “virus an 2000”, puis les décon­t­a­min­er. Avant le réveil­lon, s’il vous plaît.

Les risques de dys­fonc­tion­nements sont nombreux.

• Erreurs de comparaison
  Les erreurs de com­para­i­son sont liées au traite­ment des années mod­u­lo 100. Par exem­ple, une carte ban­caire dont l’an­née d’ex­pi­ra­tion est 00 risque d’être rejetée en 99, sous pré­texte que 00 est inférieur à 99 — cela s’est déjà vu. Les erreurs de com­para­i­son risquent de provo­quer la destruc­tion, à tort, de don­nées non expirées. Si une telle erreur n’est pas détec­tée rapi­de­ment, elle peut être très grave (destruc­tion d’archives).
• Erreurs de tri
  Les erreurs de tri, ou de classe­ment, sont de même nature que les erreurs de com­para­i­son, mais elles sont “sta­tis­tique­ment” moins graves, en ce sens que leur prob­a­bil­ité de pass­er inaperçues est plus faible. Par exem­ple, si notre mamie, née au siè­cle dernier, se retrou­ve mêlée à la jeune généra­tion, et con­vo­quée à l’é­cole pri­maire, il reste excep­tion­nel qu’au­cun recoupe­ment ne per­me­tte de détecter le prob­lème, quelque part dans le sys­tème infor­ma­tique, avant que l’in­for­ma­tion erronée ne sorte du sys­tème. Mais pour­tant cela arrive.
• Erreurs de calculs
  Les erreurs de cal­culs sont sans doute les plus spec­tac­u­laires.
  Sta­tis­tique­ment par­lant, elles peu­vent, comme les erreurs de com­para­i­son, pro­duire les résul­tats les plus aber­rants et, comme les erreurs de tri, con­duire à des prob­lèmes plus facile­ment déce­lables par recoupe­ments. Par exem­ple, si vous souhaitez la bonne année à l’un de vos proches, en l’ap­pelant un peu avant minu­it le soir de la Saint-Sylvestre, et si vous rac­crochez le com­biné à l’aube de l’an­née 2000, il n’est pas exclu — dans le cadre de cet arti­cle, bien sûr ! — que le sys­tème infor­ma­tique de votre opéra­teur télé­phonique vous décompte un siè­cle de com­mu­ni­ca­tion (entre fin 99 et début 00). Une telle erreur est pos­si­ble, mais elle a peu de chances de pass­er inaperçue. Soit le sys­tème infor­ma­tique respecte les règles de l’al­gèbre, et votre opéra­teur vous crédite d’un avoir de quelques mil­lions d’eu­ros, soit il ne s’embarrasse pas de con­sid­éra­tions de signes, et vous fac­ture froide­ment un mon­tant équiv­a­lent. Dans un cas comme dans l’autre, c’est la banque qui saute.

Quels sont les risques pour l’entreprise ?

Pour l’en­tre­prise, le risque est avant tout une désor­gan­i­sa­tion majeure de l’outil infor­ma­tique. Tant que l’on n’a pas inven­torié et cor­rigé les pro­grammes con­t­a­m­inés par le virus, le mal peut frap­per n’im­porte où.

Y a‑t-il des appli­ca­tions infor­ma­tiques plus sen­si­bles que d’autres ? Certainement.
La ges­tion actu­ar­ielle, celle des prêts ban­caires, celle des con­trats d’as­sur­ance sont des appli­ca­tions qui trait­ent le long terme, sur des fenêtres de temps par nature très larges. Pour elles, l’an 2000 a pu être un prob­lème dans le passé ; mais, en 1999, le prob­lème est très cer­taine­ment déjà résolu. Ces appli­ca­tions à hori­zon loin­tain peu­vent être, éventuelle­ment, sen­si­bles à un allonge­ment de la vie humaine, mais ce n’est déjà plus tout à fait le même prob­lème. Comme ces appli­ca­tions trait­ent le long terme, leur cor­rec­tion est moins urgente : les infor­mati­ciens dis­posent d’un temps, sinon con­fort­able, du moins suff­isant pour apporter les cor­rec­tions nécessaires.

À l’autre bout de l’échelle de temps, les appli­ca­tions qui con­trô­lent, en temps réel, des proces­sus indus­triels sont finale­ment peu sen­si­bles aux dates, même si elles sont sen­si­bles aux durées. Il est pos­si­ble qu’elles tombent en panne dans la nuit de la Saint-Sylvestre. Mais, si on les relance immé­di­ate­ment, il y a de fortes chances qu’elles fonc­tion­nent de nou­veau, par­faite­ment, à l’aube de l’an 2000. Le risque pour l’en­tre­prise est “sim­ple­ment” de gâch­er un cycle de pro­duc­tion. Le risque économique est plus ou moins impor­tant (cas de la sidérurgie, par exem­ple), mais il reste lim­ité. Existe-t-il un risque physique de mort d’homme ? Sans doute, dans quelques cas extrêmes (nucléaire, hôpi­taux), mais un tel risque sem­ble, là aus­si, très limité.

Mon opin­ion est que les appli­ca­tions infor­ma­tiques les plus sen­si­bles au “virus an 2000” sont celles qui trait­ent le moyen terme, comme la plan­i­fi­ca­tion, la ges­tion des stocks, la dis­tri­b­u­tion, les réser­va­tions de places de trans­ports. La rai­son en est que le virus n’a pas encore eu l’oc­ca­sion de se man­i­fester dans ces appli­ca­tions. Si le virus appa­raît, ce sera vers l’au­tomne 1999. Or, cor­riger ces appli­ca­tions, qui trait­ent le moyen terme, risque d’être plus long que leur hori­zon de temps. Les inci­dents risquent de sur­venir plus vite que les cor­rec­tions ne seront ren­dues disponibles. Les pro­gram­meurs chargés de cor­riger pour­raient buter sur un mur du temps, comme les ondes sonores butent sur le mur du son. Les ser­vices infor­ma­tiques pour­raient se retrou­ver engorgés, étran­glés, par une cadence d’in­ci­dents supérieure au rythme des corrections.

Indus­triels qui tra­vaillez en flux ten­du, craignez l’an 2000 ! Ce sont les rela­tions avec vos four­nisseurs qui risquent d’être tendues.

Quelles corrections appliquer ?

Bien enten­du, inspecter un pro­gramme et le cor­riger pour le ren­dre “com­pat­i­ble an 2000” ne con­stitue pas un exploit hors de portée. Mais alors, pourquoi ne pas l’avoir fait au cours des dernières années ?

La dif­fi­culté tient au nom­bre de pro­grammes, à la méth­ode et au cadence­ment de l’opération.

Tan­dis que le com­porte­ment d’un seul pro­gramme est par­faite­ment déter­min­iste et, en principe, repro­ductible, le nom­bre des pro­grammes et leur com­bi­na­toire dans les sys­tèmes infor­ma­tiques ren­dent aléa­toire le com­porte­ment du sys­tème infor­ma­tique tout entier.

La méth­ode cartési­enne sug­gère d’ap­pli­quer la norme : puisque les années s’ex­pri­ment sur qua­tre chiffres, mod­i­fions les pro­grammes pour qu’ils trait­ent des années à qua­tre chiffres.

Le prob­lème, c’est qu’il ne suf­fit pas de mod­i­fi­er les pro­grammes. Il faut aus­si et surtout mod­i­fi­er les don­nées, c’est-à-dire les fichiers infor­ma­tiques. Un pro­gramme traite rarement une seule date. Il en traite com­muné­ment plusieurs, dans plusieurs fichiers. Dis­ons trois fichiers, pour don­ner un ordre de grandeur réaliste.

Les fichiers ser­vent d’in­ter­faces, de struc­tures d’échange entre pro­grammes. Lorsqu’on mod­i­fie un fichi­er, pour y chang­er la struc­ture des dates, la mod­i­fi­ca­tion con­cerne donc plusieurs pro­grammes. Au moins deux. Et, de plus en plus, les bases de don­nées prenant pro­gres­sive­ment la place des fichiers, les don­nées con­cer­nent un nom­bre crois­sant de pro­grammes. Lorsqu’on mod­i­fie la struc­ture d’une base de don­nées, la mod­i­fi­ca­tion con­cerne couram­ment des cen­taines de programmes.

Si bien que la mod­i­fi­ca­tion de notre pro­gramme d’o­rig­ine peut main­tenant con­cern­er des dizaines d’autres pro­grammes con­nex­es qui échangent des dates avec le pre­mier pro­gramme. Et, comme il serait dom­mage de s’ar­rêter en si bon chemin, autant cor­riger aus­si ces pro­grammes con­nex­es, liés au pre­mier, qui eux-mêmes sont liés cha­cun à quelques dizaines d’autres pro­grammes con­nex­es, etc.

En l’ab­sence de bases de don­nées, on pour­rait encore espér­er trou­ver des sous-ensem­bles de pro­grammes con­nex­es dis­joints dans le sys­tème infor­ma­tique, ce qui sim­pli­fierait notre prob­lème. Mais il ne faut pas se faire trop d’il­lu­sions : les bases de don­nées sont dev­enues omniprésentes, et le sys­tème infor­ma­tique est ain­si devenu un seul ensem­ble con­nexe de programmes.

Notre méth­ode cartési­enne, si ras­sur­ante au départ, nous con­duit en fin de compte à un prob­lème dont la com­plex­ité croît, par récur­rence, de façon expo­nen­tielle, et est seule­ment lim­itée par la taille du sys­tème. Véhiculé par les flux de don­nées entre pro­grammes, le “bogue de l’an 2000” se dif­fuse dans le sys­tème infor­ma­tique comme un virus dans un organ­isme vivant. La cor­rec­tion con­siste main­tenant à décon­t­a­min­er tout le sys­tème. Il faut éradi­quer le virus.

L’in­ter­ac­tion entre les pro­grammes et leurs don­nées est si forte que c’est bien la sur­vivance des don­nées, dans les fichiers puis les bases de don­nées, qui explique la sur­vivance des pro­grammes dans lesquels on exprime encore aujour­d’hui les années mod­u­lo 100.

Ce n’est rien de mod­i­fi­er un pro­gramme. Par con­tre, c’est une tout autre affaire de mod­i­fi­er les fichiers ou les bases de don­nées, de façon syn­chrone, dans tout un cen­tre infor­ma­tique ; ou, qui plus est, entre cen­tres infor­ma­tiques parte­naires (téléin­for­ma­tique). Pour don­ner quelques ordres de grandeur, dis­ons qu’il est courant, dans les grands sys­tèmes infor­ma­tiques, de compter les pro­grammes par mil­liers et les fichiers par dizaines de milliers.

Par ailleurs, il sem­ble exces­sif d’im­pos­er, en tant que norme, des années à qua­tre chiffres. C’est, d’une cer­taine façon, nier la con­ti­nu­ité du temps. Nulle appli­ca­tion infor­ma­tique courante n’a besoin de traiter tout le cal­en­dri­er depuis son orig­ine en 1582. Ce n’est pas l’an 2000 qui crée le besoin de normer les années. L’an 2000 est, tout au plus, une occa­sion de le faire. Mais le moment n’est sans doute pas le mieux choisi.

Les par­ti­sans des années à qua­tre chiffres arguent aus­si des meilleures per­for­mances des sys­tèmes infor­ma­tiques, en faisant observ­er que les cal­culs de dates sont sim­pli­fiés par les années à qua­tre chiffres. Et il est vrai qu’avec des années à deux chiffres les cal­culs doivent tenir compte de la représen­ta­tion mod­u­lo 100, et sont donc un peu plus com­plex­es. Mais est-ce là un argu­ment suff­isant ? C’est sous des pré­textes d’op­ti­mi­sa­tion ana­logues que l’on codait, dans les années 60, les années sur deux chiffres, pour éviter de gaspiller quelques bits. Avec le suc­cès que l’on con­naît. À quoi bon, aujour­d’hui, grap­piller quelques Mips ou quelques Flops ?

C’est ici, selon moi, que les infor­mati­ciens se sont offert un petit plaisir, en abon­dant dans le sens de la norme, à l’oc­ca­sion des “pro­jets an 2000”. Il suff­i­sait, dans la plu­part des cas (mais cela ne saurait, non plus, être une règle absolue), de con­tin­uer à exprimer les années mod­u­lo 100, et d’at­tribuer à ces années, au moyen d’une pro­gram­ma­tion adéquate, une sig­ni­fi­ca­tion com­pat­i­ble avec le change­ment de siè­cle. Au lieu de cela, un cer­tain nom­bre d’in­for­mati­ciens de tous bor­ds, sociétés de ser­vices, entre­pris­es clientes, gourous et autres tech­nocrates, ont cru bon de son­ner le glas de la con­ti­nu­ité du temps. L’an 2000 infor­ma­tique con­naî­trait le temps absolu.

Il en résulte qu’au lieu de mod­i­fi­er pro­gres­sive­ment, l’un après l’autre, les pro­grammes con­cernés par le prob­lème, en faisant en sorte que les pro­grammes attribuent à chaque date la sig­ni­fi­ca­tion qui lui revient, dans la fenêtre de temps impar­tie, nos défenseurs de l’an­née à qua­tre chiffres ont sol­idaire­ment alour­di de façon démesurée les “pro­jets an 2000”, en imposant de mod­i­fi­er les fichiers, les bases de don­nées et la plu­part des pro­grammes. Tous en même temps. Et avant le réveil­lon s’il vous plaît.

Et en ren­dant, au pas­sage, mon­strueux le futur “bogue de l’an 10000”.

Comment conduire un “projet an 2000” ?

Il me sem­ble inop­por­tun d’en dire plus sur la façon de men­er un pro­jet “an 2000”. Non pas que le sujet manque d’in­térêt — et je crois, à tort ou à rai­son, avoir acquis une cer­taine expéri­ence des con­ver­sions infor­ma­tiques, indépen­dam­ment de l’an 2000 — mais il est tout sim­ple­ment trop tard pour se lancer main­tenant dans un pro­jet important.

Les cam­pagnes de sen­si­bil­i­sa­tion, aux­quelles on assiste actuelle­ment, ne peu­vent plus con­cern­er que l’in­for­ma­tique indi­vidu­elle, ou celle de PME ayant un parc infor­ma­tique réduit. Pour les grandes entre­pris­es ou les admin­is­tra­tions qui ont un parc infor­ma­tique d’une cer­taine importance :

• soit elles ont com­mencé (et, je leur souhaite, large­ment avancé) leur projet,
• soit leur infor­ma­tique court de sérieux risques — voir plus haut.

Il n’est plus temps de se souci­er, en 1999, d’as­sou­plir les con­di­tions de pas­sa­tion des marchés publics, pour pré­par­er telle ou telle admin­is­tra­tion à franchir l’an 2000.

Finalement, faut-il féliciter ou… remercier les informaticiens ?

Par­tant d’un prob­lème sim­ple, à l’échelle du pro­gramme indi­vidu­el, la com­bi­na­toire ren­con­trée dans les sys­tèmes infor­ma­tiques fait que leur mod­i­fi­ca­tion, ou leur con­ver­sion, con­stitue un pro­jet complexe.

Oui, l’an 2000 présente un risque infor­ma­tique cer­tain. Et, comme l’in­for­ma­tique est partout, le “bogue de l’an 2000” peut se man­i­fester n’im­porte où. Il se présente comme un virus mul­ti­forme, en ce sens qu’il frappe à l’im­pro­viste, et que son iden­ti­fi­ca­tion puis son érad­i­ca­tion ont quelque chose de médical.

Les risques pour l’en­tre­prise sont une pro­fonde désor­gan­i­sa­tion infor­ma­tique, une perte majeure de crédi­bil­ité, une image de mar­que en chute libre.

Sans doute, les infor­mati­ciens sont-ils en grande par­tie respon­s­ables du prob­lème, mais ils ne sont peut-être pas les seuls. Qu’ils tra­vail­lent dans les sociétés de ser­vices ou les entre­pris­es clientes, les infor­mati­ciens se sont tous fait un peu plaisir en trans­for­mant, si com­mod­é­ment, un prob­lème sim­ple de con­ver­sion — qui pou­vait raisonnable­ment s’ef­fectuer pro­gres­sive­ment — en un prob­lème com­plexe de con­ver­sion de type big bang. Mais peut-être sont-ils seule­ment core­spon­s­ables de ce détournement.

Ils ont voulu, à cette occa­sion, appli­quer une norme, sans doute judi­cieuse, qui leur a peut-être été imposée, et ils ont seule­ment péché par omis­sion, en masquant la charge que représente un tel change­ment de norme.

Ren­dez-vous le same­di 1^er jan­vi­er 10000 — si notre cal­en­dri­er n’a pas changé entre-temps — pour véri­fi­er si l’ex­péri­ence acquise, à la fin de notre mil­lé­naire, pour cor­riger le “bogue de l’an 2000”, est réu­til­is­able pour traiter celui de l’an 10000…

---

Articles similaires :

Fron­tin, un ingénieur au pre­mier siè­cle (après Jésus-Christ) ? Caissier de la pro­mo 42–43 24 sep­tem­bre 1904 Le Principe de Rel­a­tiv­ité d’Henri Poin­caré (1854–1912) Éloge d’Auguste Comte (2ème partie) Un antique oublié : Eugène VERLANT (1867–1958) Égal­ité des chances ou égalitarisme