Discussion :

[Coriolan]

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.

Ben Halpern

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 :

« Bannir utilisateur pour spam. Ceci est extrêmement destructif, ne prenez pas cette décision à la légère »

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é :

« Pour des raisons de sécurité, vous ne pouvez pas effectuer cette action à partir de cette interface, car il s'agit d'un utilisateur confirmé. »

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 ?

[Excellion]

Avant, je mettais des confirmations. Mais les utilisateurs me sortaient quand même des "ça s'est validé tout seul". Combien de gens lisent les écrans successifs à l'installation avant de faire "suivant-suivant-suivant"?

Rejeter la faute sur l'informatique est souvent la solution de facilité. Surtout chez les personnes qui ne sont pas du métier.

Ĺes paroles de l'auteur prouve qu'il a rarement été en contact, au niveau professionnel, avec d'autres corps de métiers que des informaticiens.

Bref. L'erreur est bien humaine. Et mettre des gros boutons et des alertes sert plus de parapluie en cas de pépin que de prévention à une éventuelle erreur...

[transgohan]

On pourra tourner les boutons dans le sens qu'on veut, formuler la demande de plusieurs façons, mettre en place des confirmations, cela ne changera rien au problème qu'une erreur est humaine.
Bon nombres d'utilisateurs lisent en diagonale, sont mal réveillés, font plusieurs choses en même temps, sont embourbés dans la routine et font des actions les yeux fermés, ect.

Bref, je ne suis pas d'accord avec la conclusion, pour moi cela reste une erreur humaine et on pourra mettre tous les gardes fous possibles il en restera toujours.
La seule façon de ne pas lever les fonctions critiques trop souvent à cause d'une erreur humaine est de faire en sorte qu'il faille une action de deux personnes différentes pour minimiser le risque d'erreur (comme pour le lancement des missiles nucléaires qui nécessite deux clés de deux personnes différentes).

[titip1995]

Avant, je mettais des confirmations. Mais les utilisateurs me sortaient quand même des "ça s'est validé tout seul". Combien de gens lisent les écrans successifs à l'installation avant de faire "suivant-suivant-suivant"?

Rejeter la faute sur l'informatique est souvent la solution de facilité. Surtout chez les personnes qui ne sont pas du métier.

Ĺes paroles de l'auteur prouve qu'il a rarement été en contact, au niveau professionnel, avec d'autres corps de métiers que des informaticiens.

Bref. L'erreur est bien humaine. Et mettre des gros boutons et des alertes sert plus de parapluie en cas de pépin que de prévention à une éventuelle erreur...

Certes, les erreurs arrivent. Le spam du bouton "suivant", aussi. Quand on parle de CGU ou d'installation de programme avec plein d'options.
Mais là, on parle d'un outil à l’échelle d'un pays pour prévoir des évacuations.

A ce moment, oui, il y aurait dû avoir des fenêtres de confirmation. Ou alors séparer les "drills" des vrais messages. (si je suppose bien, les incidents sont réunis par types puis par réel ou exercice.)
De plus, a ce niveau, le coup du "J'ai pas fait attention" n'est plus valable.
On ne parle d'un simple outil de gestion, où le plus gros risque serait la perte de données, mais d'un outil d'alerte qui peut créer une panique locale dans le moins pire des cas.

Donc pour moi cette conclusion me semble valable lorsque l'on prend compte du contexte. Il y a eu une erreur utilisateur, mais cette erreur aurait pu être évitée avec un peu plus de suretés.

[grunk]

Qu'on soit en présence d'un design malheureux c'est sans doute vrai. Mais perso le design c'est pas mon job. Sans un graphiste/ergonome mes applis ne sont en général pas exceptionnelle et pourtant c'est un domaine auquel je m’intéresse.

C'est aussi à l'utilisateur final de faire remonter ce genre de risque pour que ca puisse êtr epris en compte par l'équipe de dév. Si on leur à jamais dit , ce bouton faut qu'il soit rouge et qu'il clignote , l'équipe peut pas le deviner.

Dans tous les cas ce cher mr Halpern profite d'un événement malheureux pour faire sa pub en crachant sur ses confrères ...

[gstratege]

En plus c'est un drop box, il suffit d'un défilement avec un peu de retard et tu appuie sur le mauvais champ.

[Marco46]

Qu'on soit en présence d'un design malheureux c'est sans doute vrai. Mais perso le design c'est pas mon job. Sans un graphiste/ergonome mes applis ne sont en général pas exceptionnelle et pourtant c'est un domaine auquel je m’intéresse.

Le design (c'est pas du design c'est de l'ergo en l'occurrence) c'est pas ton job mais t'as quand même un cerveau et une conscience. Le dev qui a réalisé cette interface n'a visiblement ni l'un ni l'autre. C'est quand même évident qu'il ne faut pas mettre le bouton d'auto-destruction et le bouton de TEST d'auto-destruction l'un à côté de l'autre et qu'il est nécessaire d'informer largement l'utilisateur sur les conséquences de ses actions dans l'IHM.

[Lyons]

Bref le mec voulait just faire de la pub pour son site

[transgohan]

Le design (c'est pas du design c'est de l'ergo en l'occurrence) c'est pas ton job mais t'as quand même un cerveau et une conscience. Le dev qui a réalisé cette interface n'a visiblement ni l'un ni l'autre. C'est quand même évident qu'il ne faut pas mettre le bouton d'auto-destruction et le bouton de TEST d'auto-destruction l'un à côté de l'autre et qu'il est nécessaire d'informer largement l'utilisateur sur les conséquences de ses actions dans l'IHM.

Si tu prend le parallèle des votes de messages sur ce forum on se retrouve avec le pouce moins à côté du pouce plus.
On se retrouve dans les IHM avec le bouton suivant à côté de précédent, ou de ok à côté de annuler.
Quelle différence ? Pour moi aucune.

[titip1995]

Si tu prend le parallèle des votes de messages sur ce forum on se retrouve avec le pouce moins à côté du pouce plus.

Action annulable en cliquant sur le pouce adéquat en cas d'erreur

On se retrouve dans les IHM avec le bouton suivant à côté de précédent

Même intérêt, le changement de page. Et c'est pareil, en cas d'erreur y'a juste a cliquer deux fois sur suivant ou précedent (selon le cas).

Après, pour le OK a côté de annuler. Oui c'est plutôt bof.

[ManyTwo]

C'est aussi à nous développeurs d'assurer l'intégrité du système, et faire en sorte que les négligences / erreurs humaines soient évités ou repoussées au maximum, surtout dans les fonctionnalités (métier) critiques pour notre "logiciel".

Un principe commun est "ne pas croire les entrées utilisateur" non? Il nous paraitrait aberrent de ne pas contrôler les données d'inputs utilisateur puis dire après : "De toute façon ca arrive de se tromper il avait qu'a faire attention"

C'est fini le temps ou l'informatique était "juste un plus, et tant mieux si ca marche". C'est maintenant le centre névralgique de toute les decisions, avec un impact majeur sur la vie des gens et des entreprises. De plus en plus les éditeurs deviennent responsables du bon fonctionnement (l'ergonomie / sécurité compris).

Après on peut par contre se demander à quel niveau est la faute, plutôt que développeur ici je vois plus "l'éditeur", dans le sens ou l'erreur pourrait être imputé au niveau conception, ou niveau design.

Je pense que l'auteur a voulu surtout pointer du doigt le fait que la faute ne provient pas totalement du coté de l'utilisation, mais aussi du coté conception.

[e101mk2]

Qu'on soit en présence d'un design malheureux c'est sans doute vrai. Mais perso le design c'est pas mon job. Sans un graphiste/ergonome mes applis ne sont en général pas exceptionnelle et pourtant c'est un domaine auquel je m’intéresse.

Pour ma part, pour toute opération qui mal utilisée à des conséquence lourdes, je créer une demande de validation. C'est du bon sens, qui n'as jamais cliquer à cotés par inadvertance?

Et je part du principe que l'erreur qui peut être produite rarement par un professionnel, le sera souvent par un particulier.

[Glutinus]

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.

Y a que moi que ça choque ???
Le mec appuie sur le deuxième bouton alors qu'il devait appuyer sur le premier, et c'est un développeur qui dit que c'est la faute d'un développeur...


M'étonne en plus que sur une application de ce genre, aussi importante, il n'y ait pas une équipe complète...
C'est pas la faute de l'ergonome ou du designer, qui aurait pu faire un bouton plus gros, plus rouge ?
C'est pas la faute du business analyst, qui aurait pu proposer qu'une fois le bouton "missile alert" appuyé il y ait multitude de bouton de confirmation, avec un code à entrer ?

Encore une fois, un développeur qui veut créer le buzz pour faire du traffic sur son blog...

[jlliagre]

Je suis plutôt d'accord avec l'auteur du blog.

Bien que l'on ne connaisse pas l'interface utilisateur qui est affichée, on nous dit que le choix de lancer l'alerte de test et l'alerte réelle se faisait à partir d'un menu déroulant, donc d'un menu probablement écrit en petits caractères et dont les choix n'étaient probablement pas différenciés par autre chose que leur label. Il y a rarement des couleurs spécifiques dans un menu déroulant.

Ce que l'auteur du blog recommande, et je suis bien d'accord avec lui, est de passer par une étape bien différenciée affichant clairement le risque associé pour les actions ayant des conséquences exceptionnelles.

C'est vrai que tous les utilisateurs, et moi avec, ont tendance à cliquer machinalement sur tout les popup qui s'affichent, mais ici, on est quand même dans un cas particulier.

Le "gros bouton" de Donald Trump qui déclenche une riposte nucléaire n'a sûrement pas la même forme ni la même couleur que celui de sa lampe de bureau et il n'est sûrement pas situé juste à coté...

Y a que moi que ça choque ???
Le mec appuie sur le deuxième bouton alors qu'il devait appuyer sur le premier, et c'est un développeur qui dit que c'est la faute d'un développeur...

Ce n'est pas vraiment un bouton, c'est un choix dans un menu déroulant, mais tu as raison, ce n'est pas la faute du développeur qui a du faire ce qu'on lui a demandé, c'est plutôt la faute du designer qui a conçu une interface utilisateur mal fichue. Ce ne sont pas forcément les mêmes personnes.

[el_slapper]

Je mettrais plutôt l'amende sur le dos du décideur qui a décidé d'économiser 3 bouts de chandelle en se passant d'ergonome.

[Invité]

Pour ma part, je pense que l'erreur est humaine dans ce cas mais, c'est une erreur qui permet de découvrir une faille dans le développement (je n'irai pas jusqu'à dire une erreur de développement).

Comme dit plus haut, un affichage indiquant le risque d'utilisation de ce bouton aurait pu éviter l'erreur (ou pas...).

Ou sinon, afficher un message de confirmation après avoir appuyé sur le bouton, l'utilisateur aurait pu voir sa mauvaise manipulation de cette manière (ou pas... encore une fois).

Cependant, je reste assez étonné de l'absence de sécurité pour le déclenchement d'une telle alarme... Et ce n'est pas le développeur qu'il faut remettre en cause dans ce cas, il ne fait que ce qu'on lui demande.

[Freem]

Il n'y a que moi qui estime plus que probable le fait qu'en fait, c'est juste une appli qui lance des messages génériques, et qu'elle va chercher les titres des boutons dans une table (probablement triée, hein, et tant qu'à faire le mot TEST est en fin de champ...) de BDD, elle-même remplie par un opérateur qui ne connaît rien à la programmation?
Auriez-vous oublié que «l'informatique moderne», c'est aussi les applications vide dont tout le métier ou presque repose dans du paramétrage, pas forcément les trucs hyper spécialisés fait à la main...

Avec le peu d'informations que l'on a (deux entrées consécutives dans une liste à défilement dont la seule différence logique est la restriction du jeu de cible auquel est envoyé un message unique, autrement dit: un booléen, un flag, une référence dans une table, peu importe la méthode) comment peut-on oser prétendre juger? Sur un site lambda, venant de gens ne connaissant pas la programmation ni comment sont écrits les logiciels, j'aurai pu comprendre, mais ici?
À moins que le type derrière son blog ait plus d'info (non, j'irai pas lire un blog dont l'auteur se contente manifestement de taper sur les confrères pour se mettre en valeur) alors le seul jugement que l'on peut avoir, c'est que c'est lui, qui fait des choses sans réfléchir, et je préfère dire qu'il ne réfléchit pas, parce que je trouve moins graves l'incompétence ou la négligence que la malveillance.

Bref, l'erreur ne viens pas forcément des devs, si ça se trouve, ils n'ont pas écrit l'application d'origine pour ce genre de choses. La chaîne de construction d'un logiciel est trop grande pour que l'on puisse savoir d'où viens ce manifeste problème de vérification, et même si il manque des garde-fou, l'opérateur conserve une part de responsabilité de toute façon. Même si c'est un chat qui se promène sur le clavier (le chat est alors l'opérateur).

[jlliagre]

Une petite recherche montre que ce n'est pas le premier incident de ce type. Il y a juste six mois, il s'est passé à peu près la même chose à Guam suite à une mauvaise utilisation du même système d'alerte (EAS) par les opérateurs d'une radio :

Guam radio stations freak out island with emergency alert

A la suite de cet incident, les autorités ont déclaré:

GHS/OCD has worked with (the stations) to ensure the human error will not occur again.

[CaptainDangeax]

Il y a bien longtemps, j'avais développé un petit logiciel avec une interface utilisateur. Il y avait une fonction particulièrement destructrice, la réinitialisation complète des données. Pour la valider, j'ai mis 4 boîtes de dialogue parmi lesquelles 3 s'activaient avec un oui, et une s'activait avec un non. Et le logiciel les affichait dans un ordre aléatoire. Jamais personne n'a malencontreusement effacé la BDD.

[Saverok]

Je trouve ça fort d'incriminer de la sorte le développeur.
Pour commencer, pour être précis, c'est plus une erreur de design et de conception que de dev.
Ensuite, le gus, il n'est pas tout seul et décisionnaire.
Je suppose qu'il y a eu des maquettes et qu'elles ont été validées et qu'ensuite, il y a une phase de recette justement faite pour identifier les bugs et les anomalies d'ergonomie et de conception...
Pour finir, l'application est en run depuis pas mal de temps maintenant et qu'elle dispose d'une maintenance corrective et évolutive régulière où justement, sur les remontées des utilisateurs, ce type de chose peut être revu facilement.

Alors oui, il y a eu erreur mais celle-ci est collective et concerne beaucoup de monde.
Faire du dev le bouc émissaire est beaucoup trop facile et simpliste.