Fausse alerte au missile à Hawaii : la faute de l'interface ? Pas sûr.

L’année 2018 avait commencé dans la panique à Hawaii, après la bourde d’un employé qui avait lancé une alerte au missile quand il aurait dû, simplement, lancer une procédure de test. Nous étions alors à l’aéroport de Los Angeles, de retour du CES, et nous suivions cette panique en temps réel sur les réseaux sociaux américains. Cela dit, peu de temps après, le rôle de l’employé était minimisé par l’ergonomie, a priori absurde, de l’interface de programmation de ces tests… ou de ces alertes. On apprenait qu’un menu déroulant à deux choix était l’une des fonctions qui séparaient le test des machines de l’alerte véritable.

Aujourd’hui, l’histoire se termine mal pour l’employé en question. Après l’enquête des autorités américaines, l’administration a décidé de le renvoyer. En effet, quelle que soit la responsabilité de l’interface dans l’affaire, l’employé n’était pas à sa première bourde : il aurait confondu plusieurs fois des essais et des événements véritables. Dans sa déclaration, il a lui-même estimé qu’il était convaincu qu’un missile était bien en route vers Hawaii. On dénombre donc plusieurs facteurs qui ont conduit à cette bourde qui reste majoritairement humaine : l’incompétence de l’opérateur et la confusion de l’interface ont été retenues.

Maintenant, restera à l’administration américaine de décider à quel point une interface aussi critique qu’une alerte au missile peut être manipulée dans ces conditions. D’une part, il n’est peut-être pas judicieux de laisser un employé plusieurs fois remarqué pour ses erreurs aux commandes d’un tel outil. D’autre part, si le logiciel n’a pas été conçu pour minimiser les erreurs humaines, alors c’est qu’il a été mal conçu. Peut-être qu’une reconception est à prévoir.

Partager sur les réseaux sociaux