Passage à l'an 2000, le défi informatique

La version originale de cet article a paru dans la revue L'Economiste Maghrébin

No. 218, octobre 1998, pages 60-62


Par Mohamed Louadi, PhD

En 1946, le premier ordinateur entièrement électronique, l'ENIAC, fut assemblé avec pour fonction essentielle le traitement et le stockage des données. C'est dans les disques magnétiques de l'ordinateur que toutes sortes de données étaient stockées. Comme le coût des disques était très élevé, le stockage des données devint une affaire d'optimisation; les programmeurs de l'époque prirent pour habitude de ne stocker que le minimum de données nécessaire au traitement. Pour ce qui concerne les dates, un système de codification interne fut adopté qui transformait une date en une succession de six chiffres. Par exemple, le 18 juin 1958 deviendrait 580618: deux chiffres pour l'année, deux chiffres pour le mois et deux chiffres pour le jour. L'ordre des chiffres était inversé pour les besoins de tris chronologiques: 580618 précéderait 590101 dans l'ordre aussi bien chronologique qu'informatique.

En fait, les programmeurs de l'époque s'enorgueillissaient de ne pas inclure les deux chiffres «19», au demeurant «implicites», dans leurs dates pour économiser l'espace disque. Les informaticiens étaient par ailleurs certains que les programmes qu'ils écrivaient auraient une très courte durée de vie. La tendance continua durant les années 1960 et 1970 contaminant la totalité des programmes écrits à cette l'époque.

Le problème aujourd'hui est que le 31 décembre 1999, une minute après 23h59, plus d'un ordinateur au monde bondira d'un siècle en arrière parce que la date enregistrée sera le 1er janvier 1900. La date du 31 décembre étant codée dans le format 991231, la seule date possible qui lui succéderait serait 000101 (le «19» étant implicite comme à l'accoutumée). Pour certains ordinateurs, et particulièrement les PC de l'ère pré-Pentium, la date succédant au 31/12/99 sera le 04/01/80. Il y aura un problème même lorsque l'an 2000 sera entamé parce que hormis les erreurs dues à la codification interne des dates, les règles de César et de Grégoire vont toutes être effectives en même temps:

• 2000 est divisible par 4, l'an 2000 est donc une année bissextile;

• l'an 2000 marque un début de siècle;

• s'il marque le début d'un siècle, l'an 2000 est divisible par 400, il y aura donc certainement un 29 février 2000!

Ainsi, dépendant de nos connaissances des calendriers, on pourrait se contenter de la règle de César et conclure qu'il y aura un 29 février 2000 ou avoir une connaissance partielle des amendements de Grégoire et conclure qu'il n'y aura pas de 29 février 2000.

Les ordinateurs se sont généralement bien accommodés des années bissextiles. Pourtant, il faut croire qu'il y a encore une interprétation plus qu'approximative ne serait-ce que du calendrier julien. Quoique l'année 1996 était une année bissextile, plusieurs ordinateurs croyaient encore que le 28 février 1996 était suivi du 1er mars. Incidemment, le 29 février 1996, 60 000 personnes n'étaient pas capables d'acheter leur billet de loterie de fin de mois en Arizona parce que les systèmes informatiques de la loterie pensaient que ce jour là était le 1er mars. Une augmentation de tarif de taxi à New York devait être effective le 1er mars 1996, mais les usagers avaient dû payer la majoration le 29 février parce qu'il n'y avait pas de 29 février en 1996 pour les ordinateurs des compagnies de taxis. Les systèmes d'un laboratoire de chirurgie au Royaume-Uni avaient refusé de traiter les données d'analyses du 29 février et celles-ci avaient dû être renvoyées à d'autres laboratoires où les ordinateurs n'étaient pas encore arrivés au 1er mars 1996. Pourtant, il était clair que 1996 était une année bissextile puisque divisible par quatre. Si les ordinateurs sont moins à l'aise avec les années bissextiles qu'on ne l'aurait cru et ce bien qu'il y ait eu douze années bissextiles depuis l'avènement des ordinateurs, pensez que ces machines n'ont jamais eu affaire à des débuts de siècle ni à des années divisibles par 400.

Pour les entreprises, le problème est réel parce que les programmes qui continuent à tourner dans leurs ordinateurs font partie de ceux hérités des années 1960. Les auteurs de ces programmes sont rarement disponibles (certains sont décédés), il n'existe aucune documentation et pis encore, il n'existe souvent pas de version humainement intelligible de ces programmes. Par ailleurs, le problème n'est pas rattaché uniquement aux programmes Cobol des années 1950-70, mais également aux systèmes d'exploitation et aux horloges internes des ordinateurs. Déjà un système TSO/ISPF sur lequel un administrateur a simulé l'an 2000 ne voulait rien entendre du 29 février 2000! Au lieu de 000229, l'horloge interne du système affichait 000301. Au lieu de 000301, elle affichait 000302, et ainsi de suite jusqu'à la fin de l'année: le 001231 (31 décembre) devenait le 001301 (le premier jour du treizième mois de l'année 00!). Plusieurs compte rendus de panne ont déjà été publiés par des administrateurs de réseaux informatiques qui ont dû composer avec des situations où l'échéance se situait au delà de 31 décembre 1999. Le 1er janvier 1995, des polices d'assurance de cinq ans ont expiré le 1er janvier 1901, par exemple.

Le problème atteint des proportions gargantuesques dès que l'on réalise les conséquences qu'il pourrait avoir sur les hauts lieux des finances internationales, Wall Street, la bourse de Londres, etc. qui dépendent des dates et des calculs de dates pour toutes sortes de transactions financières. Les systèmes de ces organismes sont si intimement liés qu'il suffirait que l'un d'eux commette une erreur pour que tout le système international de calcul de cours de change, d'intérêts, etc. s'effondre. L'effet domino sera irréversible et l'impact rivalisera en ampleur le crash financier de 1929. Le problème affectera tous les secteurs économiques, toutes les industries et tous les pays.

De plus en plus d'observateurs insistent sur l'urgence d'amorcer des projets de rectification de l'erreur. Ces «projets 2000» sont devenus la bête noire des directeurs de services informatiques et des revendeurs de logiciels mais l'aubaine des consultants. Gartner Group, une firme spécialisée du Connecticut, estime que le coût total de tous les projets 2000 du monde est de 600 milliards de dollars étalés sur quatre ans. Plus les entreprises retarderont l'échéance et plus le coût de l'opération augmentera. Si en 1996 la rectification d'une ligne de code coûtait 1dollar en moyenne, elle reviendra à 7dollars en 1999.

Les estimations du Gartner Group sont sujettes à caution. La plupart des entreprises utiliseront des ressources déjà existantes pour juguler la crise. Mais les salaires qui seront payés aux programmeurs, par exemple, auraient pu servir à d'autres fins. C'est donc davantage des coûts d'opportunité que de nouvelles dépenses qu'il s'agit. Les estimations du Gartner Group prennent aussi pour hypothèse de base que tous les systèmes devront être révisés et tous les programmes ré-écrits. Ce qui n'est pas toujours le cas. Mais les chiffres demeurent énormes.

S'il est vrai que le projet est probablement le seul à avoir une échéance immuable (les corrections doivent être effectives le 31 décembre 1999 à 23h59 au plus tard), il n'en est pas moins vrai que ceux qui ne l'ont pas entamé sont déjà très en retard.

En 1994, une firme canadienne a conclu que sur 104 systèmes, 18 étaient cruciaux pour le fonctionnement de l'entreprise et tomberont tous en panne en l'an 2000. Ces 18 systèmes comprennent 8 174 programmes et 3 313 fichiers et bases de données. L'étude préliminaire qui a abouti à ces résultats a duré dix semaines. Parce qu'elle a commencé son étude en 1994, cette entreprise avait cinq ans pour que tous ses systèmes soient convertis pour l'an 2000.

Si certaines entreprises préfèrent sous-traiter en engageant une firme spécialisée, d'autres essayent de minimiser les coûts en utilisant leur propre personnel informatique. D'autres encore optent pour des solutions plus économiques en expatriant le projet vers des pays comme les Philippines, Israël, la Russie et le Brésil, où la main d'œuvre est moins chère. En effet, si le salaire annuel moyen d'un programmeur américain est de 36.000-48.000$, celui-ci est de 15.600-32.500$ au Brésil. Il se situe aux alentours de 10.000$ en Inde et de 12.000$ en Russie.

Pour BankAmerica Corp., il s'agit de rectifier 95 millions de lignes de code; soit une cadence de 2700 lignes par heure. Il est clair qu'il ne reste pas assez de temps matériel (ni logiciel!) pour ceux qui ne se sont pas déjà attelés à la tâche. En somme, ce n'est pas le problème du millénaire qui est complexe mais bien sa solution. Le problème concerne les dates et sa solution dépend du temps qui nous sépare de l'an 2000.

Il n'existe pas encore de solution universelle miracle au problème de l'an 2000 et il serait contre indiqué de l'attendre car il n'y en aura vraisemblablement pas. La solution se trouve dans les compétences humaines et organisationnelles des entreprises ou dans leur capacité de négocier avec un bureau de conseil capable de gérer le projet 2000. L'origine du problème est informatique mais la solution la plus sure est manuelle. Le problème est surtout une question de temps. Et la solution aussi.

Notes