Moderniser les forces armées est un processus lent, coûteux et plein de risques. D'un certain point de vue, il n'est pas surprenant que l'Allemagne utilise encore des disquettes de huit pouces, mais il faut bien évaluer de nouvelles technologies à un moment donné, et c'est exactement ce qu'a fait le croiseur USS Yorktown en septembre 1997. Intégré au programme Smart Ship de la marine américaine, le Yorktown a servi de banc d'essai pour un nouveau système de contrôle numérique... qui a fini par diviser par zéro, et s'est retrouvé immobilisé près de la côte de la Virginie pendant près de trois heures.
Le croiseur USS Yorktown (CG-48) de la classe Ticonderoga est entré en service le 4 juillet 1984. Il a été spécialement conçu pour tirer pleinement parti du système de combat Aegis, qui combine des ordinateurs et des radars pour le guidage et le suivi des armes. Le Yorktown a eu plusieurs interventions très médiatisées, dont l'interception de l'Achille Lauro (détourné par des terroristes en octobre 1985) et plusieurs opérations en Libye.
Fort d'un équipage de 33 officiers et de plus de 300 marins, le Yorktown a opéré dans les paramètres attendus et a reçu de nombreuses décorations. Cependant, en octobre 1995, le NRAC (Naval Research Advisory Committee) a publié une étude recommandant d'explorer différentes stratégies pour réduire les équipages et, par extension, les coûts opérationnels. Deux mois plus tard, le Bureau du programme Smart Ship a été créé, dans le but d'incorporer de nouvelles technologies et de réduire le nombre de membres d'équipage sans sacrifier les performances ou la capacité de combat. Le croiseur choisi... fut l'USS Yorktown.
USS Yorktown, une division par zéro de trois heures
Bishr Tabbaa nous explique dans son blog qu'un an plus tard, en décembre 1996, le Yorktown a reçu le premier prototype fonctionnel du système Smart Ship. Construit par Litton Industries, il était composé d'un réseau LAN de 27 terminaux dual-Pentium Pro à 200 MHz reliés par fibre optique à un serveur. Toutes les machines Smart Ship utilisaient Windows NT 4.0, un système d'exploitation relativement jeune à l'époque (la version Workstation avait fait ses débuts en août, et la version Server en septembre).
Les économies projetées étaient d'environ 2,8 millions de dollars par an (en tenant compte d'une réduction de 44 membres d'équipage et de multiples opérations manuelles redondantes). Le Yorktown a mené à bien une mission de cinq mois dans les Caraïbes et plusieurs exercices avec l'USS George Washington. Cependant, le 21 septembre (de 1997), il effectuait des exercices au large de Cape Charles (Virginie), lorsqu'un membre d'équipage a détecté une discordance dans une vanne de carburant.
La vanne était physiquement fermée, mais le module SMCS (Standard Machinery Control System) du système Smart Ship indiquait qu'elle était ouverte. La décision du technicien a été de lancer une recalibration numérique de la vanne, en saisissant la valeur 0 dans l'une de ses propriétés à l'aide du Remote Database Manager (RDM). Le problème est que le RDM a tenté d'initier une opération de division sur cette nouvelle valeur, divisant effectivement par zéro. Le module RDM s'est figé... tout comme les autres systèmes qui en dépendaient. L'effet domino a atteint la propulsion, et le pauvre Yorktown est resté à la dérive, inerte.
En 2 heures et 45 minutes, l'équipage du Yorktown a réussi à redémarrer tout le système et à regagner sa base de Norfolk. Le blog de Tabbaa explique également des incidents ultérieurs, des contradictions et d'autres détails faux comme le fait que le Yorktown a dû être remorqué. Cela a été démenti par le capitaine du croiseur, Richard Rushton, qui a ajouté que « ce n'était pas la première fois » que le RDM se figeait en raison de paramètres incorrects. D'autres sources ont pointé du doigt Windows NT 4.0 comme responsable de la défaillance, mais une fois de plus, le capitaine Rushton a nié que le système d'exploitation ait causé des problèmes.
Le Yorktown a poursuivi ses essais, est revenu en service actif en septembre 1999 et a été retiré en décembre 2004.
(N.d.l.r. : Bishr Tabbaa a publié d'autres défaillances similaires dans son livre « Bugs: A Short History of Computer System Failure »).
Accédez à l'article complet : Cliquez ici
