Discussion :

[jlliagre]

Faire du dev le bouc émissaire est beaucoup trop facile et simpliste.

Dans le blog, ce n'est pas "le développeur" qui est mis en cause, mais l'équipe qui a conçu cette interface:

Sure, the designers and developers that created the button weren't the ones that pressed it, but this disaster was their fault.

[Saverok]

Dans le blog, ce n'est pas "le développeur" qui est mis en cause, mais l'équipe qui a conçu cette interface:

Merci pour la précision
N'empêche que les utilisateurs et les équipes métiers sont également à blâmer.
Après tout, ils ont tout validé et utilisent l'appli depuis quelques temps maintenant.
Ce type d'erreur d'ergonomie aurait dû être signalé depuis longtemps maintenant.

[jlliagre]

Peut-être, mais c'est pas le genre d'interface utilisateur utilisée tous les jours par des dizaines de milliers de personnes, et ceux qui y ont accès sont des probablement des militaires. Ça doit freiner les velléités de remise en cause des systèmes...

[4sStylZ]

Sur Github, pour supprimer un repository, ou sur certains jeux vidéos, on a d’abord le message de confirmation bien dangereux ainsi qu’une input de saisie du genre :*« Veuillez-saisir le nom exact du repository que vous souhaitez supprimer à tout jamais ».

Ce genre de truc « Ne se valide pas tout seul ».

[Bryce de Mouriès]

De la pub bien sale pour se faire voir auprès de décideurs, et il donne l'exemple de son site qu'il a amplement le temps de réaliser avec soins et précisions...

Je partage vos avis, les développeurs n'y sont pour rien. C'est fatiguant de mettre des contrôles de champs partout parce que la personne ne sait pas saisir un numéro de téléphone etc. C'est aussi stupide que les indications "Ne mettez pas votre chat dans le micro-ondes". Le logiciel doit aider l'utilisateur et non pas effacer tout son bon sens.
D'ailleurs ça serait les derniers à blâmer, ça a dû être demandé par le métier, spécifier par la MOA, puis tester par les utilisateurs.

[Jarodd]

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.

Mais bien sûr. C'est toujours la faute du dév, c'est tellement pratique. Pas de celui qui a designé cette interface. Pas de son chef qui lui a demandé, et n'a probablement pas écouté le dév s'il a dit que c'était risqué. Pas sur le commercial qui veut économiser 1 jour de dév sur le design, les tests, l'ergonomie. Non, c'est la faute du dév, c'est le seul responsable. Je parierai même qu'il s'agit d'un stagiaire, les "vrais dévs" ne font pas ce genre de bêtise !

[joublie]

C'est pas une erreur humaine, c'est une erreur du développeur (" that is not a human error, that is a software design error ").
Ah bon, le développeur était donc un Martien ?

A part ça, il y a certainement eu un empilement anomalies tolérées qu'on pourrait appeler (pompeusement) normalisation de la déviance :
- interface mal faite à l'origine ;
- pas de correction apportée avant la mise en service ;
- pas de prise en compte des remarques des utilisateurs tout au long de l'utilisation du logiciel.

J'imagine que des utilisateurs avaient déjà évoqué la proximité risquée des options test et alerte, ainsi que l'absence de distinction visuelle entre la confirmation du test et celle de l'alerte réelle. Cela a pu arriver aux oreilles de tel ou tel prétendu " responsable " qui s'est probablement empressé de ne rien changer.

Si les utilisateurs commettent effectivement des erreurs, c'est justement une raison de ne pas négliger leurs remarques.

[grunk]

Bon, je pense qu'on est tous d'accord sur le fait qu'il y'a un "petit" soucis niveau UI :


Source : https://www.washingtonpost.com/news/...i-take-a-look/

[jlliagre]

Ouch, c'est pire que ce que je pensais. Ce n'est même pas un menu déroulant, juste une liste disparate de liens, du Web 0.0 quoi...

[François DORIN]

Il faut remettre les choses dans leur contexte avant de crier au loup et incriminer qui que ce soit.

Ici, nous avons affaire à une procédure d'urgence à réaliser d'urgence, pas à une opération particulièrement destructrice en soit. Ce que je veux dire, c'est que quand on décide de supprimer un compte pour SPAM, réinitialiser une base de données ou que sais-je encore, l'utilisateur à le temps de le faire, de lire des messages de confirmation, etc...

Dans le cas qui nous occupe, le temps est justement quelque chose de très précieux. Que les deux options soient l'une à côté de l'autre n'a donc absolument rien de choquant. Ainsi, la procédure de test et la procédure réelle sont très proche. En cas d'attaque, l'utilisateur sait donc exactement quoi faire.

Faut-il avoir un mécanisme de confirmation ? Ca dépend du délai qu'il peut y avoir en cas d'attaque entre la détection de l'attaque, et l'arrivée de celle-ci. Une confirmation, ça prend certes quelques secondes, mais dans ce genre de situation, quelques secondes peuvent tout changer (par exemple, interception des missiles en plein vols). Il faut aussi prendre en compte l'état dans lequel serait l'utilisateur en cas de véritable attaque. Comment réagiriez vous si un missile allait vous tomber dessus d'ici 3 min ? Personnellement, je ne sais pas comment je serais. Mais je sais que même les choses simples peuvent devenir incroyablement compliquées. Donc vous pensez sérieusement que vous pourrez sereinement cliquer sur "oui je confirme" et saisir l'âge du capitaine ?

Qu'est-ce qui est le plus dramatique ? Qu'il y ait une fausse alerte suite à une erreur (je me garde bien de la qualifier d'humaine ici), ou que l'alerte ne soit pas déclenchée en cas de véritable alerte ?

Oui, il y a eu une erreur, puisqu'il y a eu une fausse alerte. Mais c'est le système dans son ensemble, incluant les acteurs humains qu'il faut donc revoir, au lieu de vouloir imputer toute la responsabilité sur une personne ou une équipe en particulier.

[Saverok]

@François DORIN
Je partage en partie ton avis même si

On parle de militaires entraînés à ce type de situation de stress, pas de monsieur de tout le monde.
Ce que l'on attend d'eux dans ce type de situation, c'est justement qu'ils gardent la tête froide et les idées claires là où les gus dans mon genre iront se planquer dans les abris

Même si, en cas d'alerte réelle, une demande de confirmation (par ressaisie du mdp, par exemple), n'est pas une précaution inutile.
Il existe beaucoup de procédures chez les militaires où il faut être 2 et/ou avec un tas de code de confirmation diverses à saisir avant d'agir, même en cas de d'urgence.

Les conséquences d'une fausse alerte sont assez importantes (économique et diplomatique notamment) pour nécessité ce type de mesure.

Là où je m'offusque, c'est de vouloir désigner un bouc émissaire (n voulant se faire de la pub au passage).
Si on "accepte" (façon de parler car il me semble que le gus qui s'est planté s'est fait sévèrement lourdé) une erreur une humaine de la part de l'utilisateur qui a cliqué sur la mauvaise option, un concepteur / designer / ergonome peut aussi en faire.
Par contre, dans le cas du concepteur / designer / ergonome, ce dernier n'est pas seul dans le processus de mise en oeuvre d'un logiciel et beaucoup de monde passe après eux.
L'utilisateur n'étant que le dernier maillon de la chaîne.

[François DORIN]

On parle de militaires entraînés à ce type de situation de stress, pas de monsieur de tout le monde.
Ce que l'on attend d'eux dans ce type de situation, c'est justement qu'ils gardent la tête froide et les idées claires là où les gus dans mon genre iront se planquer dans les abris

Même si ce sont des militaires (ce qui n'est pas forcément le cas, rien ne le précise !), ils n'en restent pas moins des êtres humains. Et pour ce genre de situation, il est difficile d'être préparé. D'autant plus que tous les militaires ne gèrent pas le stress de la même manière, même avec un entraintement. Certains y arrivent, d'autres non. Est-ce que la responsabilité de cliquer sur ce bouton incombe à un haut gradé ayant fait ses preuves ? A une personne qui n'est jamais allée sur le terrain ? Je n'en sais absolument rien, et rien ne le précise. On ne peut donc rien supposer sur la capacité à garder la tête froide de la personne qui est derrière la console.

Même si, en cas d'alerte réelle, une demande de confirmation (par ressaisie du mdp, par exemple), n'est pas une précaution inutile.
Il existe beaucoup de procédures chez les militaires où il faut être 2 et/ou avec un tas de code de confirmation diverses à saisir avant d'agir, même en cas de d'urgence.

Oui, et comme je le disais, reste à définir l'urgence. Cela se mesure en secondes ? minutes ? heures ? Personnellement, je ne sais pas pour le type d'attaque mentionné ici, mais je suppose qu'il s'agit de quelques dizaines de secondes, voire de minutes. Donc saisir un mot de passe, je peux comprendre que ce soit problématique.

Les conséquences d'une fausse alerte sont assez importantes (économique et diplomatique notamment)

Je ne dis pas le contraire. Je dis qu'entre une fausse alerte et une alerte non déclenchée, je pense que l'alerte non déclenchée à de plus lourdes conséquences. Du coup, à choisir entre les deux, je préfère qu'il y ait de fausses alertes...

[jlliagre]

Il n'y avait ce jour là aucune situation exceptionnelle. La procédure consistait, d'après ce que j'ai lu, à chaque prise de poste, pour la personne en charge des alertes de cliquer sur le lien de test. Il s'est juste trompé de lien et quand on voit la gueule de la page web, ça ne paraît pas très étonnant.

L'autre anomalie dans l'application utilisée, est qu'une fois l'alerte enclenchée, il n'existait pas d'interface permettant à l'opérateur de l'annuler. Cette annulation a pris beaucoup de temps car la procédure est très lourde, il fallait remonter la hiérarchie pour pouvoir donner le contre-ordre.

D'autre part, la personne qui a cliqué sur le mauvais lien ne s'est pas fait virer, elle a été réaffectée à un autre poste.

[Mat.M]

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.
[..]

+1000
c'est comme des maçons qui construisent une maison si la maison est de travers c'est la faute aux maçons pas à l'architecte.
Peut-être que pour faire un projet info il faudrait commencer par partir sur des bonnes bases , simple règle de bon sens.

Dans le blog, ce n'est pas "le développeur" qui est mis en cause, mais l'équipe qui a conçu cette interface:

mouais mais un projet informatique c'est tout de même tout le travail d'une équipe, non ?

[jlliagre]

Quand on voit la tête de la page web qui sert d'interface (si c'est bien à ça qu'elle ressemble), il est difficile de penser qu'une équipe avec chefs de projets, architectes, ergonomes, développeurs, testeurs, etc est impliquée. On dirait plutôt que la page a été composée par quelqu'un n'ayant à peu près aucune compétences web.

Mais ça grenouille pas mal à Hawaï en ce moment. Un article de presse indique qu'il y a une controverse à propos de l'ergonomie exacte de l'interface. Les autorités disent d'une part que la personne qui a transmis la photo à la presse n'était pas habilitée à le faire, et d'autre part qu'il ne s'agit pas de la vraie interface qui ressemblerait plutôt à ça:



Ca n'a pas convaincu tout le monde car cette nouvelle représentation de l'interface ne peut pas être exactement celle qui est à l'origine de l'affaire puisqu'elle inclut un choix (false alarm BMD) qui n'a été implémenté qu'après l'incident de samedi dernier...