Les Défaillances de l'Informatique : une Nouvelle Menace ?
l'Exemple du Bug de l'An 2000
CMAP (Centre de Mathématiques APpliquées) UMR CNRS 7641, École polytechnique, Institut Polytechnique de Paris, CNRS, France
france telecom, France Telecom R&D
[Site Map, Help and Search [Plan du Site, Aide et Recherche]]
[Real Numbers don't exist in Computers and Floating Point Computations aren't safe. [Les Nombres Réels n'existent pas dans les Ordinateurs et les Calculs Flottants ne sont pas sûrs.]]
[N'oubliez pas de visiter Une Machine Virtuelle à Explorer l'Espace-Temps et au-delà où vous trouverez plus de 10.000 images et animations à la frontière de l'Art et de la Science]
(Site WWW CMAP28 : cette page a été créée le 10/01/2000 et mise à jour le 03/10/2024 17:00:37 -CEST-)
(publié dans la revue Les Cahiers du Radicalisme,
dernier trimestre 1999. Ce texte a été rédigé au mois de juillet 1999, soit avant
les dates du 21/08/1999, du 09/09/1999 et du 31/12/1999)
AVERTISSEMENT :
Ce site est strictement "personnel" et son auteur
est l'unique responsable de son contenu. Il ne reflète donc en aucune façon
les positions officielles que l'Ecole Polytechnique et France Telecom
ont ou pourraient avoir face aux problèmes qu'il décrit.
Enfin, il réside sur un ordinateur appartenant à l'Ecole Polytechnique.
INTRODUCTION :
Dire que l'informatique, les
télécommunications et l'énergie constituent les
infrastructures vitales de notre économie, de notre
défense et de notre confort est d'une extrême
banalité. Nous en connaissons déjà les faiblesses
face à des attaques externes tant physiques que
logiques, mais il existe aussi des risques internes,
voire intrinsèques. S'interroge-t-on suffisamment
sur leurs inter-dépendances que personne ne
maitrise complètement ainsi que sur leur robustesse
et leur capacité à résister à des perturbations ? Ne
seraient-elles pas que de gigantesques châteaux de
cartes prêts à s'écrouler à la moindre occasion ?
Nous allons montrer sur un exemple précis et
d'apparence anodine, celui de la mauvaise gestion
des dates dans les ordinateurs, qu'il en est
malheureusement ainsi, et qu'un malheureux grain
de sable dans le silicium de nos microprocesseurs
pourrait être à l'origine d'importantes défaillances,
tout ceci sans faire preuve d'un catastrophisme
excessif et en conservant présent à l'esprit que
mieux vaut prévenir que guérir.
A l'approche de l'an 2000 ressurgit un
millénarisme qui contrairement à celui de l'an
1000 n'annonce pas les splendeurs du Royaume de
Dieu. Bien au contraire nos peurs sont aujourd'hui
bien réelles, bien concrètes : le spectre de la
pollution, les risques nucléaires,... plannent au-dessus de nos têtes comme autant d'oiseaux de
proie ; qui n'a pas tremblê à la vue de ces sous-marins nuclêaires de l'ex-marine soviêtique en
train de pourrir dans les ports de la presqu'île de
Kola ?
La Science nous a appris au cours des
siècles passés que le premier janvier de l'an 2000
serait un jour comme les autres dans l'histoire de
l'Univers. Malgré cela, ce jour pourrait rester
inscrit dans l'histoire de l'Humanité comme celui
d'un cataclysme artificiel aux conséquences
aujourd'hui encore inimaginables.
LES PHENOMENES NON LINEAIRES NATURELS :
Pour bien comprendre cela, il est bon de
rappeler qu'il existe dans la nature des phénomènes
caractérisés par le fait que leurs causes,
généralement infimes, peuvent parfois s'amplifier
démesurement et avoir alors des conséquences sans
commune mesure avec ce qui leur a donén
naissance. La conséquence en est immédiate :
l'impossibilité, tant théorique que pratique, de faire
à leur sujet des prévisions à long terme. Les
exemples de tels phénomènes sont nombreux, mais
celui qui vient spontanément à l'esprit est celui qui
a donné naissance à l'expression faire boule
de neige : l'avalanche.
LES PHENOMENES NON LINEAIRES ARTIFICIELS :
Au cours des décennies passées, la Science
et la Technologie nous ont offert des phénomènes
non linéaires artificiels, par exemple, celui de
l'échec du vol Ariane 501, le 4 juin 1996. Une
petite anomalie dans un logiciel issu d'Ariane 4 et
dans laquelle elle ne s'était jamais manifestée, a
contraint à l'autodestruction de la fusée après
quelques dizaines de secondes de vol. Ainsi, une
infime anomalie s'est amplifiée jusqu'à avoir des
conséquences ayant coûte un nombre appréciable
de milliards de francs. Il convient, pour en
terminer avec cet incident "exemplaire", de
préciser que la compétence des ingénieurs
concernés ne peut être mise en doute : c'est
l'extrême complexité de ces systèmes qui rend
impossible (à jamais ?) leur maîtrise absolue.
LA PREHISTOIRE DE L'INFORMATIQUE :
Ne à la fin des années quarante,
l'ordinateur avait à sa naissance vocation de
machine à calculer et ses pères imaginaient que
seuls quelques exemplaires de ces monstres nous
seraient utiles. Pesant des dizaines de tonnes,
occupant des centaines de mètres carrés au sol, ils
étaient entourés d'armées de spécialistes. Puis, dans
les années cinquante, les premières applications de
gestion virent le jour. Au début des années
soixante-dix, les performances et les capacités
restaient très limitées : des mémoires centrales de
quelques dizaines de kilo-octets et des disques de
moins d'un méga-octet étaient la norme.
En ces temps reculés, point d'écran
couleur et de souris servant à l'interaction avec les
machines, mais uniquement les 80 colonnes des
cartes perforées. Tout cela contraignait les
programmeurs à beaucoup d'habileté et à certaines
pratiques dont quelques unes se sont perpetuées
jusqu'à aujourd'hui. L'une d'entre-elles fut la
transposition d'une habitude très ancienne,
consistant à omettre les deux premiers chiffres des
années. Mais si l'homme peut parler sans ambiguïté
de mai 68 et de la guerre de 70, il en va
malheureusement différemment pour nos
ordinateurs...
L'INFORMATIQUE AUJOURD'HUI :
En l'espace de quelques années, le paysage
informatique a bien changé. Cela est dû à
l'intégration à très grande échelle
(VLSI), technique qui permet de réaliser de façon
fiable, automatique et économique, sur une surface
de l'ordre du centimètre carre, des systèmes qui
hier demandaient des dizaines de mètres cubes.
Aujourd'hui, à côté des machines qui portent le
nom d'ordinateur, rares sont les dispositifs, mêmes
parmi les plus quotidiens, qui n'intégrent pas l'une
de ces "puces" (microprocesseurs, mémoires,...). A
cela s'ajoute la facilité avec laquelle tous ces
dispositifs peuvent communiquer entre-eux et
échanger de l'information. Ainsi l'informatique est
omniprésente et communicante.
La plupart des ordinateurs de la planète,
qu'ils soient visibles (un PC sur un bureau) ou
invisibles (un dispositif de contrôle de processus
industriel) communiquent donc entre-eux. Il est
alors possible d'affirmer qu'ils forment un système
non linéaire dont la complexité dépasse
l'entendement et qui peut, dans certaines
circonstances, devenir imprévisible et chaotique.
QUELQUES REMARQUES CONCERNANT LES DEVELOPPEMENTS INFORMATIQUES :
Avant de présenter le bug de l'an
2000, il semble utile de faire quelques remarques
très générales permettant de mieux appréhender
celui-ci, tout à la fois dans sa magnifique simplicité
et son effroyable complexité...
L'expérience montre que la durée de vie
des applications informatiques dépasse en général
largement celle qui est envisagée par leurs
concepteurs : il n'est pas rare de voir aujourd'hui
des chaînes de traitement conçues il y a plus de
vingt ans et encore opérationnelles.
Malheureusement, leurs développements eurent
lieu bien souvent sans que des méthodes strictes et
bien documentées soient utilisées. Et cela n'a fait
ensuite que s'aggraver au cours de leurs années
d'exploitation car, elles ont du évoluer pour
intégrer de nouvelles fonctionnalités et pour
corriger les inévitables anomalies (bugs ou
bogues en français) introduites par les
concepteurs et les programmeurs.
Le travail de celui qui doit s'introduire
dans de tels logiciels est semblable à celui du
géologue qui cherche à déchiffrer le passé à partir
des traces qu'il a laissé. Ainsi, un programme peut
être vu bien souvent comme un empilement
instable d'un certain nombre de couches déposées
de façon plus ou moins anarchique et précaire au
cours des années. Les informaticiens préfèrent
l'ajout à la suppression parce que cela est plus
simple et moins risqué. La complexité et
l'instabilité chronique qui en résultent ne peuvent
qu'aller en s'amplifiant : l'informatique au
quotidien n'est ni un Art, ni une Science, ce n'est
que du Bricolage...
Lorsqu'en 1875 Graham Bell inventa le
téléphone à l'Université de Boston, il n'imaginait
absolument pas la portée de son invention. Cette
absence de prévisibilité à long terme (voire à
moyen ou à court terme), de même que l'inévitable
existence d'anomalies et de risques, se retrouvent
tout naturellement lors de tout développement et de
toute innovation informatiques. Ainsi, l'écran et le
clavier facilitent l'interaction avec l'ordinateur,
introduisent une nouvelle forme d'ergonomie et de
confort ; mais inversement, nos vertèbres
cervicales et lombaires ne vont-elles pas en
souffrir, et ce temps réel qu'ils permettent ne va-t-il pas nous pousser à agir avec plus de
précipitation, moins de réflexion et de
discernement qu'en ces temps reculés ou la réponse
de la machine nous arrivait après de nombreuses
heures d'attente fébrile ?
Lors de développements informatiques,
les concepteurs sont amenés à faire des choix bien
souvent arbitraires et certains d'entre-eux s'avèrent
être par la suite irréversibles. Ils créent ainsi de
fortes relations de dépendance qu'il faut
absolument respecter : c'est la notion de
compatibilité. C'est le cas des codes utilisés pour
représenter les caractères d'imprimerie ou encore
les 80 colonnes des cartes perforées encore gravées
dans de nombreux logiciels d'aujourd'hui... Dans
tous les cas, l'ensemble des spécialistes
reconnaissent unanimement qu'il serait plus que
souhaitable de faire quelque chose : oui, mais quoi
et surtout comment ?
Les systèmes informatiques sont
généralement d'une complexité qui dépasse nos
capacités de maîtrise. L'attitude la plus répandue
consiste donc à éviter de toucher à ce qui semble
fonctionner correctement, sauf cas de force
majeure (cas du bug de l'an 2000). En
effet, l'expérience montre que toute modification,
même mineure, dans un logiciel fait courir des
risques graves à celui-ci, ainsi qu'à l'intégrité de la
mission qu'il remplit.
Enfin, contrairement à une idée très
répandue, les ordinateurs possèdent des limites qui
peuvent être soit intrinsèques (la continuité -au sens
mathématique du terme- n'existe pas dans un
ordinateur), soit imposées par les concepteurs et les
programmeurs, souvent de façon tout à fait
arbitraire. Celles-ci peuvent être atteintes avec plus
ou moins de facilité, mais systématiquement, cela
constitue une situation de grand danger car
généralement ignorée et donc non prévue...
LE BUG DE L'AN 2000 :
L'exemple bien trop réel que nous allons
maintenant décrire va nous permettre d'illustrer
concrètement ces différents points. Avant toute
chose, précisons que, pour simplifier, nous
supposerons les années écrites à l'aide de quatre
chiffres décimaux et nous appelerons
pseudo-numéro de siècle les deux
premiers chiffres de cette représentation (par
exemple 19 pour 1999). Précisons que ce pseudo-numéro de siècle ne correspond au véritable
numéro de siècle que pour les années dont
l'écriture se termine par 00 ; ceci implique en
particulier que l'entrée dans le vingt-et-unième
siècle et dans le troisième millénaire n'aura lieu
que le premier janvier de l'an 2001...
Le pseudo-numéro de siècle maltraité :
Déjà été évoqué, ce premier problème, est
très certainement le plus conséquent. La pratique
ancienne de n'utiliser que les deux derniers chiffres
des années, comme cela se retrouve dans le numéro
INSEE des français, fut donc transposée dans le
monde de l'informatique. En effet, les dates, et
donc les années, constituent des données
omniprésentes dans les ordinateurs et en particulier
dans les systèmes de gestion. Cela constitua donc
une véritable idée de génie, capable de faire
économiser 50% des octets nécessaires à la
mémorisation des années, tout en permettant de
faire correctement les opérations arithmétiques
utiles et en particulier les calculs de durées ; par
exemple, un enfant né en [19]90 aura [19]99-[19]90=9 ans en 1999. Malheureusement, cette
propriété ne se conservera pas au passage de la
Saint Sylvestre 1999 ; ce même enfant aura [20]00-[19]90=-90 ans en 2000. Il nous est évident qu'une
telle valeur est incorrecte, puisqu'un âge ne peut
être négatif, mais comment se comportera un
programme en sa présence ? Il est impossible de
répondre en toute généralité à cette question, mais
il est certain que ces circonstances n'ayant en
général pas été prévues, le résultat sera a
priori imprévisible...
Ce choix n'était en fait qu'un moyen
provisoire destiné à compenser la faible capacité
des machines préhistoriques. Les programmeurs
d'alors n'imaginaient pas que cette façon de
représenter les années se perpétuerait au cours des
décennies suivantes ; il est donc logique qu'il n'en
aient pas prévu les funestes conséquences.
Cette pratique est extrêmement répandue,
même sur des systèmes informatiques donnant
l'illusion d'une gestion des années sur quatre
chiffres ; l'èdition de "1998" sur un relevé
bancaire ne prouve rien : les deux caractères "19"
peuvent avoir été ajoutés a posteriori
lors de l'impression. De plus, les formats de la date
varient d'un pays à l'autre ; parmi trois valeurs
donnant chacune sur deux chiffres le jour, le mois
et l'année, pour retrouver cette dernière,
l'algorithme fréquemment utilisé consiste à
rechercher la valeur strictement supérieure à 31. Il
est évident qu'à partir du premier janvier [20]00
cette pratique sera défaillante, tout au moins
jusqu'en [20]32. Ainsi, ces deux exemples montrent
que la représentation et la manipulation des dates
dans les ordinateurs n'est ni aussi simple, ni aussi
logique que le bons sens le laisserait supposer...
Ainsi, une gestion des années sur deux
chiffres pourra conduire à des calculs de durée
erronés, à des relations d'ordre temporel inversées
ou encore à des actions automatiques déclenchées
au mauvais moment ou pas du tout.
Malheureusement, le problème du codage des
années sur deux chiffres n'est pas le seul : quatre
autres l'accompagnent...
Les dates inaccessibles :
Pour représenter dans les programmes
certaines conditions particulières telle une erreur
ou la fin d'une liste d'objets contenant des dates,
une pratique très répandue a consisté à utiliser une
date (9/9/99,...) ou une année (99,...) particulières,
les rendant par là-même inaccessibles. Cette
anomalie a rendu impossible la délivrance de
passeports provisoires en Suède dans les premiers
jours de 1999.
L'arithmétique sur les dates :
Dans les systèmes informatiques de
gestion, certaines données numériques, comme les
dates, sont préférentiellement codées sous forme de
chaînes de caractères. Ainsi, l'année "1998", sera
représentée par la suite {"1","9","9","8"}. Lorsque
des calculs doivent être effectués sur ces
représentations, le programmeur doit faire
accomplir explicitement à la machine tout ce qui
est fait lors d'un calcul manuel et en particulier la
propagation des retenues. Oublier cela lors de la
détermination de l'année suivante peut donner
fréquemment des résultats corrects ("1998" suivie
de "1999") et de temps en temps, des surprises
("1999" suivie de "199:"). De telles anomalies ont
déjà été rencontrées en Italie, lors d'opérations
portant sur des cartes bancaires, à la fin des années
quatre-vingt.
La capacité limitée :
Il ne suffit pas à un ordinateur d'archiver
des dates "statiques". Pour accomplir ses missions,
il doit aussi être capable de déterminer en
permanence la date et l'heure courantes. Cela est
réalisé à l'aide d'un instant de référence arbitraire
et d'un compteur incrémenté périodiquement d'une
unité. Que se passe-t-il si ce dernier est sous-dimensionné par rapport à l'usage prévu ? Le
système GPS [Global Positioning System]
donne un exemple d'une telle anomalie. Celui-ci
utilise une constellation de satellites et nécessite, au
niveau des mobiles qui l'utilisent, des récepteurs.
Ces derniers ont besoin de la date et ils la
déterminent, en particulier, à l'aide d'un compteur
de semaines qui ne peut compter que de 0 à 1023.
Tous les récepteurs GPS repasseront à 0 le 21 août
1999 à 23:59:47 UTC. Dans un dispositif d'origine
militaire, le choix d'une telle limite de l'ordre de
20 ans, semble tout à fait arbitraire ! De telles
anomalies se retrouvent potentiellement dans la
plupart des ordinateurs. Remarquons enfin que
cette non extensibilité des ordinateurs concerne
aussi le stockage des numéros de sécurité sociale ou
de téléphone.
Les années bissextiles :
Les unités de mesure du temps reposent
historiquement sur des considérations
astronomiques. C'est ainsi, que l'année correspond
à la durée de la révolution de la Terre autour du
Soleil, soit environ 365.2422 jours, ce qui n'est pas
un nombre entier. Afin que l'année astronomique
reste en phase avec le calendrier, la seule solution
est de donner à cette dernière une longueur
variable de 365 ou de 366 jours. Ainsi,
périodiquement, des années dites
bissextiles sont introduites. Jusqu'a la
reforme imposée par Gregoire XIII en 1582, les
années bissextiles revenaient tous les quatre ans, ce
qui donnait une année moyenne de 365.25 jours
donc légèrement trop longue. Le calendrier, dit
grégorien, fut donc destiné à compenser
cette anomalie aux prix d'une définition plus
complexe de la bissextilité. Une année sera
bissextile si elle est divisible par 4 sauf si elle est
séculaire (c'est-a-dire divisible par 100) et non
divisible par 400. Ainsi, 2000 et 1996 sont
bissextiles, alors que 1900 et 1999 ne le sont pas.
L'ensemble de ces critères est
généralement méconnu du public, même cultivé, et
aussi, bien souvent, absent des ouvrages de
référence. C'est ainsi que le Petit Robet, dans son
édition de 1976, donne à la page 179 la définition
"bissextile : se dit de l'année qui revient tous
les quatre ans et dont le mois de février comporte
29 jours" ! Cela a donne naissance à des logiciels
et à des matériels présentant des anomalies graves
leur faisant considérer que l'an 2000 n'était pas
bissextile.
Ainsi, ce qui est appelé communement le
bug de l'an 2000 est en fait l'union
d'un certain nombre d'anomalies de gestion des
dates dans la plupart de nos ordinateurs, tant au
niveau des matériels que des logiciels. Ces
anomalies qui sont plus le résultat de choix anciens
que d'erreurs, sont particulièrement élémentaires à
spécifier. Cette constatation a deux conséquences
immédiates : la première concerne l'incrédulité de
ceux qui découvrent ces problèmes, alors que la
seconde fait croire à ces derniers que la solution
est, elle-aussi, élémentaire. De par la nature non
linéaire de ces "phénomènes", il n'en est rien, tout
au contraire.
LES RESPONSABLES (LES COUPABLES ?) :
Mais avant de décrire les difficultés
correspondantes, il est bon de rechercher les
responsabilités et d'essayer de comprendre
comment il est possible que la plupart des acteurs
concernés aient attendu la dernière minute pour
agir, alors que ces problèmes sont connus depuis
plus de vingt ans, dans le milieu bancaire en
particulier.
Les informaticiens semblent bien
évidemment être les coupables tout désigné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 programmes sans erreurs. Ils
n'ont pas eu ensuite la franchise d'avouer leurs
fautes, le courage d'expliquer les conséquences
néfastes de ces dernières et la force de demander
les moyens indispensables pour effectuer les
rèparations utiles... Rien ne sert de courir,
il faut partir à point, regrettons donc que le
nècessaire ne fut point fait lorsqu'il en ètait encore
temps ; fait donc posèment, correctement et non
point dans la prècipitation, elle-même source
évidente de nouvelles anomalies. Mais arrêtons-là
de les accabler : en effet, l'absence de prévisibilité
et de fiabilité est une constante dans toutes les
activités humaines.
Malgré cela, pourquoi les grandes
associations professionnelles que sont l'ACM
[The Association for Computing Machinery]
ou encore l'IEEE [The Institute of Electrical & Electronics Engineers]
n'ont-elles pas tiré le
signal d'alarme plus tôt ? Pourquoi a-t-il fallu
attendre ces derniers mois pour voir publier de
trop brefs articles sur ce sujet ? Est-ce parce que la
maintenance n'est pas une activité digne d'intérèt
ou pire parce que qu'elle ne fait pas partie de
l'univers de l'informatique ? Mais les ordinateurs
ne sont pas des objets abstraits et simples ; ce sont
des machines complexes, composées de nombreuses
entités coopérantes présentant toutes, de façon plus
ou moins chronique, des anomalies. La
maintenance fait donc partie de la vie de
l'informaticien et doit donc être traitée avec tout le
respect dû à ce qui finalement conditionne le bon
fonctionnement quotidien de nos machines. Enfin,
l'ampleur des difficultés auxquelles nous sommes
aujourd'hui confrontés aurait pu susciter des
vocations, par exemple, dans le monde de
l'Intelligence Artificielle. Malheureusement, il est
trop tard !
Ainsi, les informaticiens ont des
circonstances attenuantes. Mais qu'en est-il des
utilisateurs eux-mêmes ? En effet, nombreux sont
ceux qui connaissaient ces problèmes depuis
longtemps : les banquiers, par exemple, ne font-ils
pas des prêts à vingt ou trente ans ? Ils savaient
donc dès les années soixante-dix que l'absence du
pseudo-numéro de siècle était nuisible. Il est
certain qu'alors seul le strict nécessaire a été fait ;
n'aurait-ce pas été faire preuve de clairvoyance que
d'extrapoler vers les domaines non encore critiques
? Notons de plus qu'alors l'informatique était
beaucoup moins omniprésente, ce qui rendait ces
problèmes plus faciles à résoudre. Pourquoi enfin
n'ont-ils pas fortement fait pression sur les grands
constructeurs dont ils sont parmi les plus gros
clients ? Cela aurait certainement accéléré l'arrivée
sur le marché de systèmes "compatibles" et peut-être étouffé l'incendie avant qu'il ne se propage !
Là aussi, il est malheureusement trop tard !
Que dire maintenant de la responsabilité
des mdéia ? Elle semble considréable puisqu'un
événement n'existe que s'il est relaté ; son
importance est alors proportionnelle au nombre de
lignes et de minutes qui lui est consacré. A titre
d'exemple, la maladie de la vache folle, tant au
niveau des média grand public que professionnels a
été plus longuement décrite que les problèmes liés
à la mauvaise gestion informatique des dates. Est-ce dire que leurs importances relatives sont dans
le même ordre ? Rien n'est moins sûr
puisqu'aujourd'hui toute nos activités reposent sur
les épaules de nos ordinateurs. Il donc dramatique
de constater le trop long silence de la presse, en
particulier informatique, tant nationale
qu'internationale.
Enfin, le monde politique a lui aussi fait
preuve d'une absence regrettable, mais encore faut-il que l'information remonte. Au niveau français, il
a fallu attendre le 20 février 1998 pour qu'une
mission présidée par Gérard Théry soit constituée.
L'urgence est telle aujourd'hui, qu'elle demande
d'une part une coordination internationale au plus
haut niveau des états et d'autre part que des
informations soient communiquées aux citoyens afin
qu'ils sachent l'état réel dans lequel se trouvent les
administrations, les services publics et de santé, la
distribution des énérgies, les systèmes de transport,
la défense nationale,... Les plans de secours mis en
place fonctionneront-ils (le malheureux accident
survenu dans la nuit du 25 au 26 septembre 1998 a
l'Hôpital Edouard-Herriot de Lyon est
particulièrement instructif) ? En cas d'incidents, le
retour à la normale sera-t-il garanti rapidement (au
mois de février 1998, la ville d'Auckland en
Nouvelle-Zélande a été complètement privée
d'électricite pendant plusieurs semaines à la suite
de la mise hors-service des câbles haute-tension qui
l'alimentaient) ? Est-on capables de revenir
provisoirement au papier et au crayon ? Autant de
questions que tous se posent naturellement ;
l'absence de réponses ne peut qu'engendrer plus
d'inquiétude et déclencher des mouvements de
panique dont les conséquences pourraient être bien
plus graves que celles des incidents réels, peut-être
inexistants d'ailleurs... Ces réactions possibles
pourraient être déclenchées par des pénuries
artificielles portant, par exemple, sur l'argent
liquide ou encore les biens de première nécessité
(dans les premiers jours de janvier 1999, quelques
bureaux de poste français ont été pris d'assaut à la
suite de l'indisponibilité du système informatique
gérant les comptes d'épargne).
A cela, il convient d'ajouter la relative
insouciance avec laquelle le calendrier de la mise
en place de l'Euro a été défini, sans apparemment
prendre en compte le fait évident qu'il est difficile,
pour ne pas dire impossible, de mener à bien et
correctement deux projets informatiques d'une
telle ampleur simultanément. Enfin, sachant le
déficit généralisé en informaticiens, la loi française
sur les 35 heures n'est-elle pas incompatible,
provisoirement, avec l'urgence de la situation
(notons au passage qu'il ne s'agit pas ici de
critiques envers l'Euro et les mesures pour
l'emploi, mais simplement de remarques de bon
sens : serait-il raisonnable de demander à des
pompiers qui éteignent un incendie, d'abandonner
leur tâche, sous prétexte qu'il est dix-sept heures
trente ?).
Finalement, ne serions-nous tous pas à la
fois responsables et coupables ? En tout cas,
quelle que soit la réponse donnée à cette
interrogation, il parait évident que nous devons
tous nous sentir concernés, tant à l'intérieur des
structures professionnelles auxquelles nous
appartenons, qu'en tant que citoyen. De notre
attitude responsable dépendra en grande partie la
victoire...
LES SOLUTIONS :
Tous les problèmes que nous venons de
décrire sont élémentaires et ne demandent aucune
compétence particulière pour être compris. Alors
où est la difficulté ? Les systèmes informatiques
sont semblables aux icebergs : 10% de réel émerge
(le matériel) et 90% de virtuel immergé (le
logiciel) ; or autant il est facile d'appréhender la
complexité matérielle car visible, autant cela est
difficile pour la complexité logicielle
puisqu'intangible. En fait, les informaticiens sont
en face d'un problème assez similaire à celui qui
consisterait à leur demander de compter les grains
de sable sur une plage. Il est bien posé (ou enfin
presque, car il suppose que la notion de plage est
définie sans ambiguïté), élémentaire, sans aucune
difficulté théorique. Comptons donc : un grain de
sable, deux grains de sable,... mille grains de sable.
Ici, déjà la fatigue se fait sentir, mais aussi le
découragement car, en effet, que sont mille grains
de sable par rapport à une plage ?
En ce qui concerne la gestion des dates
dans nos ordinateurs, la situation est identique : les
opérations individuelles de correction sont
élémentaires ; la difficulté réside uniquement dans
leur nombre. Il y aurait actuellement, de par le
monde, environ cent milliards de lignes de
programmes concernées. Un mythe répandu
consiste à affirmer l'existence d'une solution
miracle. Malheureusement, celle-ci n'existe pas ; en
effet, pour qu'un outil universel de mise à jour
puisse être concu, il aurait fallu qu'au cours des
décennies passées, des méthodes strictes aient été
utilisées. Il n'en est rien et par exemple, le nombre
de façons de représenter une date dans un
ordinateur est compris entre beaucoup et l'infini...
Il convient d'ajouter que même si cette solution
existait, elle ne dispenserait pas de la première
étape incontournable : l'inventaire.
En effet, avant de corriger les matériels et
les logiciels, il est nécessaire de disposer de leur
liste exhaustive. Or, aussi paradoxal que cela puisse
paraître, ces inventaires, en général, n'existent pas
; il faut donc commencer par les établir.
L'expérience montre que pour une banque,
plusieurs dizaines de milliers de logiciels sont
utilisés et ce dénombrement demande parfois plus
d'une année pour être réalisé proprement !
Malheureusement, l'informatique concernée par le
bug n'est pas faite, loin s'en faut,
d'ordinateurs posés sur nos bureaux et contenant
quelques logiciels bien rangés... Non, elle est
partout : aussi bien dans les ascenseurs, les
climatiseurs, les robots de fabrication,... Et c'est
certainement là que le risque est le plus grand :
dans cette informatique qualifiée d'enfouïe
qui assure en permanence le bon fonctionnement de
tout notre environnement et dont nous ignorons
presque tout !
Il n'y a donc pas d'autre solution que de
passer au peigne fin ces milliards de lignes de
programmes et ces millions de systèmes spécialisés
: nous sommes à la recherche d'aiguilles (les dates)
aux formes et en nombre inconnus dans une meule
de foin planétaire ! Si la prise de conscience avait
eu lieu en temps utile, il aurait été envisageable de
remplacer l'ancien par du nouveau. Mais un point
de non retour a été franchi et seules donc les
corrections restent envisageables. En réalité, la
situation est en général plus précaire que cela :
lorsque sont prises en compte les ressources
humaines disponibles, le temps restant et la quantité
de travail à accomplir, il apparait que bien souvent,
même ce "rafistolage" exhaustif est impossible !
S'impose alors un tri permettant de fixer les
priorités : quels sont les logiciels et les matériels
qui sont vitaux tant pour l'homme que pour
l'entreprise et quels sont ceux qui le sont moins ?
Tout ceci doit être évidemment associé à une
analyse des risques encourus, ainsi qu'a la mise en
place de plans de secours.
Mais en quoi consiste donc ces
"rafistolages" ? La bonne solution au problème du
codage des années sur deux chiffres consisterait à
étendre les zones de mémoire destinées à stocker et
à manipuler des années. Combien de chiffres
seraient nécessaires ? Quatre paraissent a
priori raisonnables, mais ce problème ne se
reposera-t-il pas alors en 9999 ? Cette remarque en
forme de boutade est destinée à nous rappeler deux
points essentiels : les limites arbitraires imposées
par les programmeurs et le manque de visibilité à
long terme. Quatre chiffres sont évidemment
suffisants ; malheureusement, la complexité des
opérations correspondantes est rédhibitoire.
D'autres solutions doivent donc être mise en
œuvre. La plus répandue, consiste à choisir, dans
un certain contexte, une année dite
pivot codée sur quatre chiffres, par
exemple 1960 ; ensuite toute année AA sera
étendue sur quatre chiffres uniquement là ou cela
est utile. Cette extension se fera à l'aide d'un test
simple : si AA est supérieure à [19]60, il lui est
substitué 19AA et 20AA dans le cas contraire.
Cette solution, présente un certain nombre de
dangers. Le premier concerne la cohérence ; en
effet, il est important que la même date pivot soit
utilisée par tous les systèmes en relation : mais est-ce possible ? Non en toute généralité, car cela
signifierait à la limite que l'ensemble de la planète
utilise la même. Le second danger est plus lointain
; en effet, que se passera-t-il lorsque tous les
obstacles qui s'annoncent devant nous auront été
franchis avec plus ou moins de succès ? La réponse
est déjà connue : nous commettrons les mêmes
erreurs que par le passé et nous oublierons nos
rafistolages. Or la notion même d'année pivot
contient sa propre limite, de l'ordre de quelques
dizaines d'années. Ainsi, sans résoudre les vrais
problèmes, nous sommes en train de mettre en
place des bombes à retardement qui donneront bien
de la peine à nos successeurs !
Dans tout projet informatique, il est
essentiel de vérifier la conformité de la réalisation
par rapport au cahier des charges et ces tests
occupent environ 50% du temps global ! Pour le
bug, deux types de tests doivent être
accomplis ; d'abord des tests de non régression qui
permettent de vérifier que les corrections
apportées ont maintenu l'intégralité des
fonctionnalités antérieures. Au niveau d'une
banque, par exemple, cela se fait en mettant en
place un site indépendant du site opérationnel, puis
en comparant leurs résultats ; cette approche est
malheureusement plus statistique qu'exhaustive.
Ensuite, des tests de compatibilité doivent être
conduits afin de vérifier que les problèmes de date
ont été résolus. Certaines dates particulièrement
critiques doivent être examinées à la loupe (le jeudi
09/09/1999, le lundi 03/01/2000, le mardi
29/02/2000, le mercredi 01/03/2000, le mardi
10/10/2000,...). Cette série de tests est
particulièrement délicate, personne ne sachant en
toute généralité ni ce qu'il faut tester, ni comment
vieillir les jeux de test sans introduire de biais
pervers.
Evalué très grossièrement, le coût des
corrections est au niveau de la planête de l'ordre de
mille milliards de dollars ! Mais il y a deux raisons
poussant à augmenter cette évaluation : d'une part
l'absence d'exemple de grands projets
informatiques pour lesquels les budgets initiaux ont
été respectés et d'autre part les dédommagements
dûs aux inévitables dégats et catastrophes : ils sont
actuellement évalués à deux mille milliards de
dollars ! Les assureurs ont triplement à s'inquiéter
: ils sont tout à la fois parmi les plus gros
utilisateurs de l'informatique, les plus sensibles à
ces problèmes de gestion de dates et les plus
concernés de par leur fonction ; ils n'ont d'ailleurs
pas manqué de rappeler que le bug ne
comportait aucun caractère aléatoire, l'arrivée du
01/01/2000 étant connue depuis quelques siècles...
Pour la première fois dans l'histoire de
l'informatique, des projets ont des dates
d'achévement immuables. Or rares, pour ne pas
dire inexistants, sont les projets qui se sont achevés
à temps, tout en respectant les budgets et les
fonctionnalités.
Enfin, nous sommes en présence d'un
magnifique exemple d'effet domino : de
par l'interconnectivité généralisée, il ne suffit pas,
qu'une entreprise soit prête ; il importe que
l'intégralité de ses clients et de ses fournisseurs
avec lesquels elle entretient en permanence des
relations informatiques, soient eux-aussi prêts, sous
peine de risques graves de "pollution". Ainsi, en
plus du délicat travail de mise à niveau interne,
chacun doit procéder à un colossal travail externe
de sensibilisation... Le monde de la banque et de la
finance est particulièrement sensible à ce
phénomène ; un scénario catastrophe, des plus
réalistes malheureusement, consiste à imaginer sur
une place boursière, n'importe ou dans le monde,
un ordinateur défaillant qui provoquerait une
anomalie qui se propagerait ensuite, de façon
quasiment irréversible, à la vitesse de la lumière,
causant des ventes massives, un krach, une
récession...
CONCLUSION :
Les problèmes de gestion des dates dans
les ordinateurs, même s'ils sont élémentaires à
spécifier constituent une réelle menace pour
l'intégrité de nos économies, voire même pour la
sécurité de nos etats. Il n'y a a priori
aucune activité, ni personne qui en soit réellement
à l'abri, ne serait-ce qu'à cause des
interdépendances. Malheureusement il ne s'agit là
que d'un exemple concret d'une catastrophe
annoncée parmi d'autres, qui gisent potentiellement
dans nos technologies, prêtes à éclater à tout
moment.
Nos réalisations reposent aujourd'hui
toutes sans exception sur l'informatique. Pratiquée
au quotidien, celle-ci est à des années-lumière de la
pureté des 0s et des 1s de l'algèbre de Boole et de ses
règles absolues : elle n'est ni Art, ni Science, mais
Bricolage. Bricolage de génie parfois, ses réussites
sont là pour en témoigner : l'ordinateur est en
particulier un outil fantastique pour amplifier nos
facultés intellectuelles et nous permettre des
progrès sans précédents dans le domaine de la
Connaissance. Mais bricolage approximatif le plus
souvent, qui pourra nous conduire vers d'autres
catastrophes aux conséquences incalculables dans
un avenir plus ou moins proche.
Le bug est une donc une
opportunité à saisir : le temps n'est-il pas venu de
s'interroger sur cette complexité dont nous sommes
à l'origine, que nous ne maîtrisons plus et qui nous
échappe ? Soyons en tout cas conscients de notre
responsabilité aujourd'hui et œuvrons chacun à
notre niveau pour faire de la Saint Sylvestre 1999
une Saint Sylvestre comme les autres...
Copyright © Jean-François COLONNA, -2024.
Copyright © France Telecom R&D and CMAP (Centre de Mathématiques APpliquées) UMR CNRS 7641 / École polytechnique, Institut Polytechnique de Paris, -2024.
