Ajout d’un feedback et d’un mécanisme de sécurisation

Un mode d’interaction de type agent conversationnel et l’usage d’une modalité gestuelle sémaphorique ont été choisis. On pourrait alors penser que cela est suffisant et adapté. Cependant, une évaluation heuristique révèle que deux éléments importants semblent manquer : un feedback et un mécanisme de sécurisation.

2.2.3.1 Évaluation heuristique

Pour déterminer si une interface, ou une proposition d’interface est adaptée, on peut effectuer une recherche des éventuels problèmes d’ergonomie en réalisant une évaluation heuristique, également appelée audit d’ergonomie (Cockton et al. 2008). Il s’agit alors de contrôler le respect d’un ensemble de règles pratiques : les heuristiques.

Différentes listes de règles ont été proposées par différents auteurs ; par exemple les 8 Golden rules de Shneiderman (Shneiderman & Plaisant 1987), les 7 principes de Norman (Norman 1988) issus de la théorie de l’action du même auteur, les 16 prin- cipes de Tognazzini (Tognazzini 1993), les critères ergonomiques de Bastien et Scapin (Bastien & Scapin 1993) ou encore, les 10 heuristiques de Nielsen (Nielsen 1995).

Parmi ces différentes possibilités, pour sa simplicité, nous avons choisi d’utiliser la liste proposée par Nielsen, composée des 10 règles suivantes :

1. Visibilité de l’état du système.

approprié.

2. Correspondance du système avec le monde réel.

Le système doit parler le langage de l’utilisateur, avec des mots, des phrases et des concepts qui lui sont familiers, plutôt que d’utiliser un langage propre au système. 3. Liberté et contrôle pour l’utilisateur.

Les utilisateurs peuvent faire des erreurs. Le système doit donc proposer des sorties de secoursclaires telles que l’annulation, défaire/refaire.

4. Cohérence et standards.

L’utilisateur ne doit pas avoir à se poser des questions pour savoir si différents mots, situations ou actions signifient la même chose. Il faut suivre les conventions liées à la plate-forme.

5. Prévention des erreurs.

La conception doit anticiper les problèmes que pourrait rencontrer l’utilisateur. 6. Reconnaître plutôt que se souvenir.

Rendre visibles les objets, les actions et les options. Pour éviter une surcharge de la mémoire de travail, il est préférable d’éviter de demander à l’utilisateur de se souvenir d’une information, d’une séquence de dialogue à une autre.

7. Flexibilité dans l’utilisation.

La conception du système doit tenir compte des différents profils d’utilisateurs. Notamment des utilisateurs experts et novices en proposant des contrôles adaptés à chacun. Les raccourcis par exemple, permettent de gagner en performance pour les utilisateurs experts.

8. Esthétique et design minimaliste.

Les dialogues ne doivent pas proposer d’informations qui ne sont pas pertinentes au risque de perdre l’utilisateur. Chaque information étant en concurrence avec les autres, un trop grand nombre diminue la lisibilité globale.

9. Faciliter l’identification, le diagnostic et la récupération des erreurs par l’uti- lisateur.

Les messages d’erreur doivent indiquer, en langage clair, le problème et suggérer une solution pour le résoudre.

10. Aide et documentation.

Lorsqu’il n’est pas possible d’afficher toutes les informations dans l’interface, de l’aide peut être apportée via une documentation. Celle-ci doit être facile à trouver, centrée sur les tâches de l’utilisateur, indiquer concrètement les étapes à suivre et ne pas être trop longues.

2.2. Design spécifique de l’interaction 37

2.2.3.2 Un feedback audio pour informer de l’état du système — (heuristique 1) Visibilité de l’état du système

— (heuristique 8) Esthétique et design minimaliste

Dans le modèle d’interaction proposé, seule une modalité en entrée du système a été présentée. Comment savoir alors, pour l’utilisateur, si le système comprend bien les com- mandes et si il les exécute ? La revue de la littérature des interactions homme-robot a montré que dans la majorité des cas, c’est l’observation et la compréhension du comportement du drone qui servent de feedback.

Cependant, cela suppose que le drone reste à vue de l’utilisateur ce qui n’est pas néces- sairement le cas sur le champs de bataille puisque son usage est d’acquérir de l’information dans les zones hors du champs de vision. De plus, cela impose à l’utilisateur de rester attentif au comportement du drone pendant toute la durée de son déplacement ce qui ne convient pas à la problématique de permettre une bonne conscience de l’environnement.

En réponse à ce problème, et puisque le mode d’interaction repose sur un agent conver- sationnel, il semble pertinent de munir celui-ci d’une modalité événementielle sonore. Par des messages audios (sons iconiques et synthèse vocale), l’utilisateur peut être averti par l’agent des informations pertinentes comme la bonne prise en compte d’une commande et de l’évolution de son exécution. Ainsi, l’utilisateur est complètement déchargé des tâches de contrôles à la fois en entrée et en sortie.

On peut cependant s’interroger sur la discrétion d’un retour sonore. En réalité, ceci ne constitue pas un réel problème puisque différents dispositifs techniques permettent un retour sonore individuel. Par exemple, les casques ostéophoniques (à conduction osseuse) permettent à un utilisateur d’entendre des informations audio sans qu’elles ne soit audibles par d’autres, et sans masquer l’environnement sonore.

2.2.3.3 Un mécanisme de confirmation des commandes — (heuristique 3) Liberté et contrôle pour l’utilisateur — (heuristique 5) Prévention des erreurs

— (heuristique 9) Faciliter l’identification, le diagnostic et la récupération des erreurs par l’utilisateur

De manière générale, il est fondamental qu’un système soit fiable. Cela est d’autant plus vrai lorsque la sécurité de l’utilisateur et de son équipe est engagée. Ainsi, il semble pertinent considérer l’existence d’erreurs, c’est à dire de les anticiper et de permettre un traitement simple et rapide de celles-ci.

Le modèle d’interaction basé agent, à modalité gestuelle en entrée et sonore en sortie semble présenter 3 types d’erreur :

— Le premier type d’erreur est lorsque l’utilisateur, veut exprimer une intention par geste, mais que celle si n’est pas comprise par l’agent. Soit parce que le geste employé est inconnu du système ou mal reconnu, soit parce que le geste est mal réalisé. L’utilisateur se retrouve alors confronté à un système qui ne répond pas et ce sans élément de compréhension.

— Le second type d’erreur est lorsque l’utilisateur exprime par geste une intention, que l’agent comprend, mais dont l’exécution échoue. L’exécution peut échouer pour des raisons environnementales imprévisibles (vent, obstacle), ou pour des raisons contextuelles (énergie faible ou commande incohérente).

— Enfin, le troisième type d’erreur est lorsque le système détecte une intention non exprimée par l’utilisateur, ou une intention qui n’est pas la bonne. Cela peut provenir d’une défaillance technique ou d’une réalisation involontaire d’un geste.

Les deux premiers types d’erreur semblent peu critiques et simples à traiter. En effet, dans ces deux cas, un message sonore peut être généré pour indiquer la présence d’une erreur et, lorsque cela est possible, expliquer sa cause.

Le troisième type d’erreur est cependant bien plus contraignant. En effet, que le drone ne réagisse pas est une source de frustration évidente, mais qu’il débute un déplacement de manière inattendue, ou un mauvais déplacement, peu avoir de lourdes conséquences. Le drone peut être trop proche d’un individu ou d’un bâtiment et ainsi risquer de bles- ser ou d’endommager. Il peut également trahir la présence de l’utilisateur en ayant un comportement stratégiquement inadéquat.

Une commande involontaire doit donc impérativement être évitée. Et pour cela, nous proposons l’utilisation d’un mécanisme de confirmation dont le fonctionnement est le suivant :

Lorsque l’agent détecte une intention de la part de l’utilisateur, il émet en premier lieu, un message audio qui indique quelle commande a été comprise. Puis, l’agent demande à l’utilisateur de confirmer (par geste) cette commande. Si l’utilisateur confirme, l’agent entreprend alors d’exécuter celle-ci et l’indique grâce à un élément sonore. Si l’utilisateur annule la commande, l’agent se contente d’émettre un élément sonore différent. Enfin, si l’utilisateur ne confirme ni n’annule la commande après un délai de quelques secondes, celle-ci est automatiquement abandonnée. En effet, l’utilisateur peut ne pas être disponible et donc ignorer les messages en provenance de l’agent. L’agent considère alors que la détection était erronée ou que l’activation de la commande n’est plus une priorité.

Un schéma synthétique de ce mécanisme de confirmation qui permet la sécurisation de l’activation des commandes, est présenté en Figure2.7.