Le scénario « an 2000 » est inclus dans les études pour le compte d’autres clients, sans grand succès. Il apparaît au fur et à mesure que le phénomène an 2000 présente des caractéristiques très particulières : la date est incontournable, ce qui a pour effet de rendre le temps véritablement seul maître du jeu, tous les systèmes sont touchés, le monde entier est touché, la matière n’est pas noble, l’origine du bug est presque inexcusable, la valeur ajoutée est difficile à percevoir, il est urgent d’attendre, il faut faire peur pour convaincre, etc…
Les clients rejettent le risque pour l’essentiel parce qu’il n’est pas urgent. Les pays occidentaux sortent de la première guerre du golfe, le secteur automobile est secoué par les «primes Balladur », l’horizon an 2000 est souvent au-delà des perspectives de carrière des dirigeants informatique en place.
Les premiers document américains sont très difficiles à trouver (internet n’existe pas). Ils montrent que les anglo saxons sont partis sur une voie différente : seul le cobol est concerné, les millions de lignes sont comptabilisées, le nombre de programmeur aussi, une simple règle de trois permet de démontrer que le bug est impossible à corriger dans les temps.
La situation est donc claire : il ne faut pas tout corriger, seule l’analyse de risque permettra de réduire efficacement le périmètre et le coût de l’opération. L’an 2000 n’est pas un problème de programmeurs, c’est un problème de gestion de risque.