Le bug de l'an 2000 a bien eu lieu

A la fin des années 1990 tous les médias nous mettaient en gardent contre le bug annoncé de l'an 2000 où tous les ordinateurs allaient s'arrêter de fonctionner ou produire des résultats erronés. La passage du siècle s'est finalement fait sans douleur. Mais il faut dire que l'industrie informatique y a mis les moyens.

Des millions de lignes de code à modifier

Pour éviter ce fameux bug il fallait revoir des millions de lignes de code pour gérer l'année sur 4 chiffres alors que dans certains cas les dates étaient stockées sur seulement 3 octets :
- deux demi-octets pour le jour
- deux demi-octets pour le mois
- un demi-octet pour le dernier chiffre de l'année et un demi-octet utilisé par le système (signe)

Pourquoi vouloir faire une telle économie de place ? C'est tout simplement historique et ça date de l'époque où l'informatique fonctionnait avec des cartes perforées qui pouvaient stocker seulement 80 caractères sur une ligne. Il fallait donc économiser au maximum la place. On allait souvent jusqu'à travailler au niveau du bit (un octet est composé de 8 bits). C'est ainsi qu'il n'était pas rare de voir des octets regroupant 8 drapeaux (on/off, oui/non, etc...).

En stockant la date sur 5 chiffres il y avait juste un inconvénient : tous les 5 ans il fallait recompiler les programmes pour changer l'année pivot. En effet, en 1972 on pouvait par exemple considérer que toutes les années > 7 correspondaient aux années 1968 et 1969 et les années <= 7 correspondaient aux années 197n. Mais en 1977 il fallait à nouveau changer la logique pour que les années sur un chiffre qui étaient supérieures à 7 correspondent à présent aux années 1978 et 1979 et les années < 3 correspondent à 1980, 1981 et 1982. On pouvait ainsi couvrir 10 ans. Dans certains cas où les programmes ne traitaient que des dates échues la recompilation pour changer l'année pivot pouvait se limiter à une seule fois par décennie.

Stocker les dates sur 6 caractères posaient moins de problème puisqu'il était possible de couvrir toutes les années de 1900 à 1999, ce qui était largement suffisant quand nous étions en 1960. Mais passé l'an 2000, comment interpréter, par exemple, la date 140301 ? Est-ce le 14 mars 1901 ou le 14 mars 2001 ?

La prise de conscience et la démarche des DSI

Dès le début des années 90 une prise de conscience à été faite par les directions informatiques. Bien souvent ça s'est limité à normaliser la création de nouveaux fichiers : tout nouveau fichier contenant des dates devaient les stocker sur 8 caractères au minimum. Ca serait autant de fichiers en moins à convertir et autant de nouveaux programmes pérennes pour le passage du siècle.

Les véritables chantiers ont commencé en 1998. Après avoir effectué l'inventaire complet de tous les fichiers et les programmes à modifier il fallait passer à l'action et réaliser ces évolutions. L'informatique, et en particulier l'informatique de gestion, a eu besoin d'énormément de main d’œuvre durant les années 1998 et 1999. En effet, il était impensable de mobiliser toutes les équipes de développement habituelles sur un seul projet « an 2000 » en négligeant tous les autres projets en cours.

Où trouver une main d’œuvre fraiche ?

Un pénurie d'informaticiens s'est très vite fait sentir. Il fallait trouver de nouvelles « petites mains » pour coder les évolutions des parcs informatiques en vue du passage en l'an 2000. On a vu arriver sur Paris des équipes de programmeurs russes. Mais ceci était surtout anecdotique. La majorité des intervenants a été puisé autre-part...

C'est chez les jeunes diplômés des autres corps de métiers scientifiques qu'ont été trouvé la plupart des programmeurs « an 2000 ». C'est ainsi qu'on a vu débarquer dans les métiers de l'informatique :
- des chimistes
- des généticiens
- des biologistes
- des docteurs
- des électroniciens
- des agronomes
- j'ai même connu un laitier
- etc.

Une rapide formation de 2 semaines à 2 mois suffisait pour en faire des programmeurs COBOL en mesure de réaliser les évolutions simples mais nécessaires pour prendre en compte le changement de siècle.

Et puis arrive l'euro ...

Aussitôt l'an 2000 passé avec succès qu'arrive un nouveau gros projet incontournable : le passage à l'euro en 2002.

Encore une fois, les services informatiques avaient besoin d'énormément de main d’œuvre. Mais celle-ci était déjà là : il suffisait de reprendre les mêmes qui avaient travaillé sur le projet An 2000 ! Un aubaine pour toutes les directions informatique.

C'est là où le bas blesse. Ces équipes de développeurs formés sur le tas ne sont pas retournés dans leurs métiers respectifs après les projets An 2000 et Euro. Ils sont restés dans les métiers de l'informatique et ont évolué en acquérant de l'expérience. Ceux qui n'étaient pas réellement fait pour l'informatique sont très vite passé au fonctionnel (MOA) ou au management. Certains ont trouvé une vocation dans les métiers de l'informatique mais c'est loin d'être le cas de la majorité.

Les directions informatiques ne se sont pas arrêtées en si bon chemin. Ayant constaté que des non-informaticiens pouvaient parfaitement réaliser le travail d'un véritable informaticien mais pour beaucoup moins cher, les DSI et les SSII ont alors continué à embaucher des non-informaticiens qui étaient formés en interne en quelques semaines.

Nous vivons le bug de l'An 2000 depuis 15 ans

On se retrouve donc avec une masse d'informaticiens qui n'ont absolument pas été formés correctement aux métiers de l'informatique. Il faut rappeler qu'une simple formation de BTS prenait pas moins de deux ans. Le DUT s'obtenait également en deux ans et ouvrait les portes des MIAGES ou autres écoles d'ingénieurs, maîtrise, etc... Comment se fait-il alors que des personnes débarquent dans le métier avec une formation de seulement 2 à 8 semaines et soient aussi capables que quelqu'un qui a étudié pendant deux ans ? Il y a un bug, vous ne trouvez pas ?

L'informatique est-elle une science si simple que n'importe qui peut se venter d'être informaticien en quelques semaines ?

Bien sur que non et c'est bien là que réside l'origine de bon nombre de problèmes rencontrés aujourd'hui dans les applications informatiques utilisées dans les plus grandes entreprises. Outre le code qui n'est pas forcément propre, clair, lisible et optimisé, on peut constater énormément de dysfonctionnements qui sont tout simplement dus à une très mauvaise conception des applications.

Nombreuses sont les applications qui sont nées après cette période trouble de l'An 2000 et de l'Euro et qui n'ont pas été pensées dans les règles de l'art. On se retrouve avec des programmes qui font à la fois des sélections en base, appliquent des règles de gestion et mettent à jour des bases, tout ça dans le même programme. Les non-informaticiens diront que le résultat est le même. Oui, c'est vrai, tant que ça fonctionne bien. Mais en cas de plantage comment on fait pour reprendre les traitements correctement ? Et pour faire évoluer l'application ? Est-ce aisé ? Bien sur que non car ça n'a absolument pas été pensé pour les évolutions ultérieures.

Chaque jour des traitements informatiques dans les grandes banques ou l'industrie connaissent des dysfonctionnements. Ce sont bel et bien des bugs informatiques. Beaucoup auraient sans doute été évités si les projets « An 2000 » et « Euro » n'avaient jamais existé. On se traine donc le bug de l'An 2000 comme un boulet depuis 15 ans mais il n'a rien à voir avec un changement de siècle. C'est un simple changement de mentalité de la part des directions informatiques : celui de ne plus employer d'informaticiens pour faire un travail d'informaticien...