Selon ce développeur, la fausse alerte de missile à Hawaii est due à la conception logicielle,

Elle est de la faute des développeurs !

Selon ce développeur, la fausse alerte de missile à Hawaï est due à la conception logicielle
Elle est de la faute des développeurs !

Samedi, le 13 janvier, peu après 8 heures du matin, heure locale d’Hawaï, une alerte a été envoyée à tous les habitants de l’archipel pour les prévenir de l’attaque imminente d'un missile balistique. « MENACE DE MISSILE BALISTIQUE SUR HAWAÏ. METTEZ-VOUS IMMÉDIATEMENT A L’ABRI. CE N’EST PAS UN EXERCICE », ce message en plus d'apparaître sur les smartphones des habitants, a été diffusé sur la radio et la télévision.


Près de 40 minutes après, un second message va informer qu’il s’agit d’une fausse alerte. Le gouverneur d’Hawaï, David Ige, a dit à CNN que cette fausse alerte provient d'une erreur survenue suite à une procédure standard de changement de période de travail. Le porte-parole du centre de commandement militaire pour la zone pacifique a assuré qu’aucune menace de missile balistique n’a été détectée.

Dans un contexte géopolitique tendu entre Washington et Pyongyang, comment une telle erreur a-t-elle pu avoir lieu ? Apparemment, c’est un employé qui a cliqué samedi sur le mauvais bouton, causant une vague de panique et de confusion chez des millions d’Américains. ٍ

Selon Washington Post, vers 8 h 05 du matin, un employé des services d’urgence d’Hawaï a effectué un test interne. À partir d’un menu déroulant sur un logiciel, il a vu deux options : Test missile alert et Missile alert. Il était censé cliquer sur le premier bouton, mais il a choisi l’autre option, déclenchant ainsi l’alerte à grande échelle d’une menace réelle de missile.


Vous l’avez bien lu, la personne qui a déclenché cette alerte l’a bel et bien fait en cliquant sur le mauvais bouton d'un menu déroulant. Ce n'est pas une erreur humaine, c'est une erreur de design logiciel, a écrit Ben Halpern, un développeur basé à New York, dans un son blog. Ne pas tenir compte de cet incident est faire preuve de beaucoup de légèreté. Je ne sais pas ce que font les autres développeurs, mais quand je conçois des interfaces utilisateur ayant des conséquences potentiellement destructrices, je le fais avec beaucoup de précautions.

Ben Halpern a donné l’exemple du site dev.to dont il est le fondateur et webmaster. Sur ce site, des développeurs partagent des informations à travers des blogs, forums de discussion, etc. Les administrateurs du site disposent d'interfaces pour exécuter des actions dont le comportement est « destructif ». Une des actions permet de bannir un utilisateur une fois pour toutes pour spam. Ce qui fait que tous les articles et les commentaires de l’utilisateur seront supprimés et il ne pourra plus s'enregistrer dans le site une autre fois. Voici le bouton qui permet aux administrateurs du site de déclencher cette action :


Comme l’a signalé Ben, cette action n’est pas aussi destructrice puisqu'on a la possibilité de restaurer les données en cas de besoin.

De plus, cette interface n’est accessible aux administrateurs du site que si un utilisateur est vraiment susceptible que l'on recoure à cette action contre lui. Pour la plupart des utilisateurs, un autre bouton apparaît aux administrateurs pour plus de sécurité :


Cela veut dire que l’administrateur du site doit effectuer toutes les actions de destruction manuellement. Une tâche longue et fastidieuse que personne ne peut prétendre avoir effectuée par accident.

« Dans notre cas, les conséquences d'une erreur sont minimes. Au pire une petite perte de données. C'est quelque chose que l'on veut éviter à tout prix, mais finalement pas aussi important que ça », a écrit le développeur.

Mais annoncer à toute une nation qu’elle fait l'objet d'une attaque imminente est une autre histoire. Les développeurs ne devraient pas fournir des interfaces utilisateur qui rendent possible ce genre d’erreurs humaines. S’il y a une possibilité d’erreur, alors cette erreur aura forcément lieu, explique le développeur. « Nous appelons ce genre d’erreur "fat fingering” (les gros doigts) et ça arrive tout le temps. »

Bien sûr, les designers et les développeurs qui ont créé le bouton n’ont pas cliqué dessus, mais il n’empêche que le désastre relève toujours de leur responsabilité, a ajouté Ben. « On ne peut pas dire que c’est la négligence de l’employé ou bien le manque de formation. Les erreurs arrivent, nous commettons des erreurs tout le temps, mais on doit apprendre de cette erreur pour écrire de meilleurs logiciels. »

Après cet accident, le gouverneur de l’État d’Hawaï a annoncé que l’activation du système nécessiterait désormais la présence de deux personnes au lieu d'une seule. Le but ? Éviter ce genre d’incidents dans le futur et restaurer la confiance du public pour le système Amber, le système d’alerte d’urgence utilisé régulièrement aux États-Unis, mais parfois critiqué pour son manque de fiabilité.

Source : DEV - Le Figaro

Et vous ?

Pensez-vous que cette erreur relève de la responsabilité des développeurs ?
Ou bien le développeur Ben Halpern a tort, il y a d'autres parties à blâmer ?

Voir aussi :

Des programmeurs avouent avoir écrit du code non éthique et parfois illégal, en raison des requêtes de plus en plus contraignantes de leurs employeurs
Quels sont les facteurs qui poussent les jeunes développeurs à travailler plus longtemps ? Un amour pour le travail ou un mauvais management ?