L UTILISABILITE DE LA SECURITE DES TRANSACTIONS MOBILES Amélioration d une interface m-wallet à l aide de la méthode IMaC Travail présenté à M. Jean-Yves Fiset, Ing. P.hD. dans le cadre du cours : IND6408 Ergonomie du contrôle de processus Par : Philippe-Antoine Dubé (Matricule 1022861) Christina Braz (Matricule 1271788) Date : 30 avril 2004 1
Table of Contents 1. Introduction...3 2. La problématique de l'utilisabilité de la sécurité...3 3. But du projet...5 4. Revue et synthèse de la littérature...6 4.1. Liste des articles...6 4.2. Synthèse de la littérature...7 5. Méthodologie...9 5.1. Définition...9 5.2. Critères de choix...9 5.3. Mise en œuvre...10 6. Recommandations...13 6.1. Interfaces-utilisateurs originaux...13 6.2. Interfaces-utilisateurs améliorées (IMaC)...15 7. Conclusions...23 8. Bibliographie...24 9. Annexes...26 9.1. Réseaux des moyens et des objectifs...26 9.2. Cadre proposé selon la confiance dans le commerce mobile...27 2
1. Introduction Pour la majorité des systèmes, la problématique de la conception ne se constitue pas de comment remplacer l'opérateur humain, mais plutôt de soutenir effectivement la fonction de surveillance de cet opérateur. Ainsi, l'interface homme-machine (IHM) est constituée d'un ensemble de dispositifs matériels et logiciels permettant à un utilisateur de communiquer avec un système informatique, quels que soient les échanges d'informations entre ces deux systèmes. Des exemples généraux d'ihm sont les fenêtres, les boîtes de dialogue, les boutons et menus déroulants. L'interface homme-machine représente un élément clé de l'utilisation de tout système informatique et conditionne pour une large part son succès. En général, une interface doit être naturelle, efficace, intelligente, fiable, de compréhension et d'utilisation facile, autrement dit la plus proche possible des différentes formes de perception et de communication humaine tel que la parole, l'écriture, les stéréotypes, la perceptions des formes et des couleurs, etc. Ceci est d autant plus vrai dans le contexte de transaction mobile puisque l interface de ses appareils est, même avec l avancement de la technologie d aujourd hui, très limitées en espace, en fonctions et en affichage. Nous essaierons donc, par une méthode connue d amélioration des interfaces hommes-machines, de vérifier l utilisabilité d une interface utilisateur (IU) en terme de sécurité et de proposer des recommandations. Partant du constat que nous sommes limités par le temps, nous allons présenter seulement l'analyse et les recommandations des interfaces-utilisateurs. En outre, nous ne pouvons pas procéder à la création d'un prototype, ni de test d'utilisabilité de la transaction mobile "Mobile-Accessed Bank Wallet"(mWallet) auprès d utilisateurs réels (end-users) afin de procéder à la validation des recommandations faites dans ce projet. Celles-ci pourront servir de base pour un futur travail en utilisabilité. 2. La problématique de l'utilisabilité de la sécurité La problématique de l utilisabilité vient de deux sujets, d une part, de la différence de perception de la sécurité dans les applications entre les concepteurs et les usagers et d autre part, quoiqu ils soient inter reliés, de la confiance des usagers dans le procédé. L organisation internationale des standards (ISO) définit l utilisabilité comme : "l efficacité, l efficience et la satisfaction avec lequel des utilisateurs spécifiques peuvent réaliser des buts spécifiques dans des environnements particuliers." (ISO DIS 9241-11) [JOR98]. Nous nous permettons un abus de langage en utilisant un mot qui n existe pas en français : utilisabilité. Tiré directement de l anglais usability, ce mot explique tout de même bien la situation en ce sens que l utilisabilité peut-être définit plus simplement comme l habilité d utilisé le produits, méthodes, concepts, etc. L adoption à l échelle mondiale des communications sans-fil et des technologies mobiles à amener plusieurs applications demandant l accès à ou la transmission de, certaines données sensibles à faire de la sécurité une facette de plus en plus importante dans les applications. De plus, depuis que les mécanismes de sécurité sont conçus, implémentés, appliqués et utilisés par des personnes, il est tout désigné d utiliser les facteurs humains dans le design de tel système. 3
Adams et Sasse [ADA&SAS99] ont montré que jusqu à présent l utilisabilité des mécanismes de sécurité n ont pas été investigués ce contexte amenant le système a ne pas être aussi efficace qu il le prétend. Ils ont montré aussi qu il y a un monde de divergence entre les utilisateurs et les concepteurs de mécanismes de sécurité. En fait, les deux parties ne se comprennent pas. Qui plus est, ils ne se comprennent pas sur les mêmes propos. Le fossé créer entre ses deux parties vient du fait que l on voulait augmenter la sécurité en cachant systématiquement aux utilisateurs les fonctionnalités sous-jacentes de la sécurité. Ainsi, les départements responsables de la sécurité argumentent dans le sens que s ils informaient les utilisateurs sur les mécanismes de sécurité, en même temps que les attaques potentiels sur la sécurité, ils diminueraient la sécurité du système en permettant plus de fuite d informations. Ils conçoivent donc des systèmes plus stricts, par exemple des identifiants et des mots de passe générés par ordinateur qui sont plus lourd pour l utilisateur. De l autre coté, les utilisateurs, ne connaissant pas les mécanismes de sécurité, n ont pas une conscience réaliste de la situation et donc n agit pas en conséquence. En effet, les systèmes de sécurité demandent à l utilisateur une charge additionnelle dans leur tâche (dans le cas de cryptage, de clef publique, etc.) ou puisqu un utilisateur est amené à rencontrer plusieurs systèmes de sécurité différents, il n est pas enclin à adopté un comportement sécuritaire. Ainsi, il n est pas rare de rencontrer des gens notant leurs mots de passe dans un endroit centrale (portefeuille, dessous de clavier, sur l appareil même, etc.), utilisant le même mot de passe à toutes les sources ou tout simplement en désactivant le mécanisme de sécurité lorsque possible. Ces comportements renforcent l idée des responsables en sécurité que les utilisateurs ne sont pas sécuritaires et qu il faut donc s assurer qu ils (les utilisateurs) ne compromettrons pas la sécurité résultant en la conception de mécanismes de sécurité qui ne sont pas ou presque pas, utilisable par les utilisateurs (s ils ne sont pas utilisés carrément). Nous nous retrouvons dans un cercle vicieux où les systèmes sont de plus en plus lourd pour les utilisateurs du au fait qu eux-mêmes sont considérer comme une menace à la sécurité et les utilisateurs utilisent «mal» les systèmes puisqu ils n ont pas les connaissances suffisantes (pour la plupart d entre eux) diminuant la sécurité générale de l application. Le deuxième point de la problématique est attribuable à l utilisation même des transactions mobiles. Il est évident que le succès du commerce mobile vient du fait que les personnes utilisent cette méthode de paiement. Selon Oliver Steeley, vice-président de Mobile Commerce chez Master Card 1 les consommateurs vont magasiner avec le commerce mobile s il est plus pratique que les alternatives et si les utilisateurs en retireront plus de bénéfices (plus de biens ou plus de services). De plus, il mentionne que les consommateurs paieront avec cette méthode s ils sont confortables avec le procédé en plus de la praticabilité comme nous venons de le mentionnée. Ce confort de l usager ne se traduit pas seulement dans l ergonomie du produit en terme de dimension ou de facilité d utilisation seulement mais aussi en terme de confiance que l usager a du procédé. Selon Siau et al. [SIA03], la confiance des utilisateurs est un facteur majeur dans le succès du commerce mobile. Un sondage effectué en janvier 2002 par A.T. Kearney 2 montre que seulement 1% d utilisateur de cellulaire l utiliseront à des fins de magasinage comparativement à 32% en janvier 2000. Selon l auteur, «the more they use-it, the less they like it». De plus, 41% ont maintenant un téléphone pouvant se brancher sur l Internet mais le nombre de personnes utilisant le service est resté stable. Enfin 44% sont intéressé à acheter de petits items comme des boissons gazeuses achetées directement d une distributrice ou des billets de spectacles. Parmi ceux-ci, seulement 2% l ont utilisé. Ces chiffres nous montrent que les transactions mobiles sont récentes et pas connues, mais aussi qu il faut faire attention à la conception du processus pour garantir son succès. 1 http://www.radicchio.org/downloads/t2r/ws3521-7-mastercard.pdf 2 Karry, Tiffany. Shopping Via Cell Phone Loses Interest, CNET.com. http://news.com.com/2100-1033_3-864655.html?tag=st_rn 4
3. But du projet Le but de notre projet consiste à faire l analyse et la recommandation des interfaces de conception d'interface homme-machine (IHM) par l'entremise d'une transaction mobile en utilisant une méthode spécifique de conception d'ihm appelé "Interactive Monitoring and Control" (IMaC) selon le Tableau 1: Les principes de conception IMaC (Voir section 4.3. Mise en œuvre). Cette transaction mobile, "Mobile Accessed Bank Wallet", que nous avons nommé "mwallet, appartient à la compagnie MasterCard International Incorporated [MAS00] et a été utilisée comme base pour notre projet d'analyse et de recommandation. mwallet se réfère à une des façons d'effectuer des paiements (acheter des biens) à partir d'un téléphone mobile avec l'accès à l'internet. En outre, nous allons aussi présenter une synthèse des articles sur le sujet de l'utilisabilité de la sécurité. Pour ce faire, nous avons procédé à une revue de la littérature sur les troubles de l'utilisabilité de la sécurité en ce penchant sur les mécanismes, les modèles, les systèmes et les logiciels de sécurité informatique, et des méthodes de conception des interfaces-utilisateurs. 5
4. Revue et synthèse de la littérature Le sujet choisi pour ce projet gradué, l utilisabilité de la sécurité dans les appareils mobiles, n a pas beaucoup de recherche faite à l heure actuelle. Les quelques sources qui ont été trouvés se situent entre 1996 et 2004. 4.1. Liste des articles Auteurs Titres Date Publieur Ville/État/P ays Josang, Audun & Patton, Mary User Interface Requirements for Authentication of Communication 2001 Security Usability White Paper, Distributed Systems Brisbane, (Australia) Smetters, D. & Grinter, R. Whitten, Alma & Tygar, J. Zurko, Mary & Simon, Richard Uwe Jendricke & Daniela Gerd tom Markotten Anne Adams & Martina Angela Sasse Tony Clear Keng Siau & hong Sheng & Fiona Nah Paul dourish & David Redmiles Moving from the Design of Usable Security Technologies to the Design of Useful Secure Applications Technology Centre 2002 Palo Alto Research Center Usability of Security: A Case Study 1998 School of Computer Science EECS Carnegie Mellon University Pittsburgh and University of California SIMS User-Centered Security 1997 The Open Group Research Institute Eleven Cambridge Center Cambridge Usability meets Security The Identity- Manager as your Personal Security Assistant for the Internet 2000 Albert-Ludwigs- University of Freiburg Institute for Computer Science and Social Studies Department of Telematics Users are not the enemy 1999 Communication of the ACM Design and usability in security systems- Daily life as a context of use Developpement of a framework for trust in mobile commerce An approach to usable security based on event monitoring and visualization Palo Alto, CA (United States) Pittsburgh, PA and Berkeley, CA (United States) Cambridge, MA (United States) Freiburg, (Germany) 2002 SIGCSE Bulletin Aukland university of technology, New Zealand 2003 Proceedings of the Seattle Second Annual Workshop on HCI Research in MIS 2002 Communication of the ACM University of California, Irvine 6
4.2. Synthèse de la littérature Le paradigme émergent de l'utilisabilité de la sécurité La plupart des modèles, mécanismes, systèmes et logiciels portant sur la sécurité sont simplement trop complexes et confondants pour qu un utilisateur d ordinateur ou d appareil sans fil puisse les gérer correctement; que ce soit pour un administrateur de systèmes, un programmeur ou un utilisateur moyen. Selon [BIS96], les erreurs de configuration sont vraisemblablement la cause de plus de 90% de tous les échecs dans le degré de sécurité d ordinateur. Concevoir un logiciel de sécurité qui est suffisamment utilisable pour être effectif est un problème spécialisé et les stratégies de conception d interface utilisateur (IU), qui sont appropriés pour d autres types de logiciels ne semblent pas capables de le régler. Relativement peu de travaux de recherche ont été menés par la communauté de l utilisabilité de la sécurité. Pareillement, différentes lignes de conduites et même quelques applications et mécanismes ont été proposé et sont mises en marché dans le but de réduire la charge mentale de l utilisateur ainsi que de permettre, à lui ou elle, de savoir en temps et lieu si les mécanismes de sécurité fonctionne ou non, dans une transaction bancaire effectuée à l aide d un ordinateur, un téléphone mobile ou un assistant personnel (PDA). Dans le domaine de l ingénierie du logiciel, une étude a premièrement attaqué l étude de l utilisabilité de PGP 5.0 (Pretty Good Privacy) [WHI&TYG98], qui est un programme de cryptage de clefs publique conçu principalement pour l authentification et l intimité (privacy) dans les courriels. Les conclusions de l étude sont dévastatrices pour le programme montrant son inefficacité d utilisation pour fournir une sécurité efficace pour la plupart des utilisateurs expérimentés de courriels. Même si le programme PGP a une IU conçu selon les conventions standard. Deuxièmement, dans [JEN&MAR00], les services Web ont montré leur force lors d une application appelée i-manager (Identity Manager), un assistant personnel de sécurité pour l Internet, qui se réfère comme un système sécuritaire mais facile d utilisation avec une interface utilisateur personnel (single user interface) permettant même aux utilisateurs novices de configurer et négocier leurs besoins en sécurité. L assistant i-manager se retrouve entre les applications Internet et les réseaux aidant les utilisateurs à gérer leurs identités (peu en avoir plus qu une) dans le but de faire des transactions sécuritaires. Finalement, comme plusieurs des aspects des ordinateurs tels que la performance, la modularité, l extensibilité et la flexibilité, la sécurité est rarement réalisée sauf s il a été conçu implicitement. Certaines approches, qui ont des potentielles, peut-être considéré, comme dans [ZUR&SIM97], pour la réalisation d une sécurité centrée sur l utilisateur. Comme par exemple, appliquer l utilisabilité au système de sécurité, appliquer la sécurité aux systèmes utilisables (intégrer les services de sécurité qui ont un logiciel avec une composante ergonomique (usability) forte comme des applications de marché de masse ou des applications de groupes (groupware)), et mettre les utilisateurs (end-users) directement au centre des relations de confiance (par exemple, pour chaque clef publique dans la chaîne de clef de l utilisateur, au travers d une interface simple, celui-ci indique le niveau de confiance de la clef lorsqu il garantit pour les autres clefs : aucun, pas de confiance, confiance marginale ou confiance complète). 7
Dans les domaines du design et de la conception d IU, nous nous déplaçons vers un nouveau monde où les utilisateurs vont probablement posséder plusieurs appareils mobiles (téléphones cellulaires, PDAs, etc.) et deviennent de plus en plus leur propre administrateur de système. Mais dans le but d accroître l utilisabilité des technologies et les applications de sécurité, il est nécessaire de les bâtir du début avec l utilisabilité comme premier critère, spécialement pour les nouvelles technologies pour qu ils puissent faire face au monde des appareils mobiles et des échanges omniprésents (Ubiquitous Computing). Mais comment concevons-nous une sécurité utilisable? La clef est de percevoir la sécurité d un point de vue d ingénierie du logiciel et de tester l utilisabilité des applications en sécurité. Trois approches d ingénierie peuvent être implantées comme l indique [SME&GRI02] ; Build in Implicit Security, Refactoring Security Infrastructure et le Building Lego Bricks for Security. Le premier est un mécanisme de sécurité principal qui est caché de l utilisateur, le deuxième est, par exemple, un endroit relativement sécuritaire pour emmagasiner les informations de clefs fournies par au moins un des systèmes d exploitation majeure en utilisation, et le troisième est une série de modules de sécurité qui sont intégrés facilement par les développeurs dans leurs applications. Comme le sujet de l utilisabilité de la sécurité intéresse de plus en plus la communauté, alors nous noterons certainement une granulation grandissante de ce sujet comme dans l étude de [JOS&PAT01] qui s est penché sur l authentification de la communication plutôt que sur l authentification de l utilisateur. Cette dernière est le processus d établir si l utilisateur est bel et bien lui. Habituellement une ouverture (logon) requiert que l utilisateur possède un nom d utilisateur (ID) et un mot de passe. L authentification de la communication, dans un autre temps, est reliée à la vérification de l identité de l origine de l information qui a été reçu dans une voie de transmission. Des exemples types sont de vérifier l identité de l envoyeur d un courriel ou de vérifier l identité d une organisation derrière le site Web. En effet, le but est de faire en sorte que l authentification est aussi transparente que possible dans le but de réduire la charge mentale de l utilisateur. Ceci dit, si le mécanisme était totalement hors de la vue de l utilisateur (cachée), il (elle) ne pourrait pas dire s il fonctionne ou pas. Ceci permettrait des attaques de ne pas être détecté et par le fait même de rendre le système pas sécurisé. Une des solutions proposées par les auteurs est d afficher un logo certifié de la compagnie dans le navigateur Web qui serait présenté aux utilisateurs dans le but d allouer une authentification en un clin d œil. Autrement, il a été montré qu un des obstacles majeurs dans les transactions mobiles est la confiance des utilisateurs dans le système. Il est évident que si l usager n a pas confiance dans le procédé, le mécanisme, le système ou l appareil, il ne l utilisera tout simplement pas. Et s il est obligé, tentera par tous les moyens de le contourner. Conséquemment, il est de mise de considérer les facteurs nécessaires pour augmenter la confiance des usagers. Ces facteurs sont résumés dans les Figures 1 et 2 en annexe. La méthode conception d IHM utilisé ici, IMaC, permet par ses principes de design d inclure ces facteurs en permettant de se pencher sur la visualisation des tâches et des buts de l utilisateur. 8
5. Méthodologie Pour l'analyse et la conception d'ihm (Interface humain-machine) dans les applications industrielles nous avons des méthodes qui permettent de concevoir des interfaces en respectant des principes, des règles de conception, des bonnes pratiques et des normes. Il existe actuellement des méthodes de conception d'ihm tels que la méthode traditionnelle que s'en sert de la réutilisation d'éléments d'ihm et de diagrammes décrivant les éléments structuraux du processus développées pour d'autres applications similaires, la méthode "Interactive Monitoring and Control" (IMaC) que se base notamment sur un modèle normatif de la tâche de l'opérateur, la méthode "Ecological Interface Design" (EID) que repose sur la hiérarchie d'abstractions, la méthode "Skill, Rules, Knowlede" (SRK) de Rasmussem et en dernier la méthode Tâches et architectures génériques pour la conception d'interfaces (TAGCI) que constitue un ensemble des tâches bien définis afin de décrire l'interaction entre l'opérateur qui agit sur un processus donné par l'entremise de modèles. 5.1. Définition La méthode "Interactive Monitoring and Control (IMaC)" est une méthodologie de conception d'ihm pour des systèmes d'ingénierie complexes. IMaC est proposée comme une méthode pour la conception des interfaces-opérateurs (IO) en engageant l'opérateur et en lui supportant pour une effective conscience de la situation selon [VIC87]. Cette méthodologie permet de concevoir des interfaces pour les situations normales et les situations anormales prévues. 5.2. Critères de choix Après avoir analysé chaque méthode en particulier selon ci-dessus, nous avons adopté la méthode IMaC pour l'analyse et la conception d'ihm de notre transaction mobile "mwallet". En ce qui concerne les critères de choix de cette méthodologie, ils ont été déterminés dû aux aspects suivants: La méthodologie, les principes de conception et les métaphores des interfaces pour le contrôle et la surveillance des systèmes IMaC démontrent une grande habilité à adresser des problèmes associés à la surveillance des systèmes dans un large éventail de différents domaines. Plus spécifiquement le domaine des communications sans fil (Télécommunications) lequel a été choisi pour ce projet. "mwallet" constitue une transaction mobile relativement simple mais qui est centré sur un modèle normatif de la tâche de l'opérateur, lui-même basée fortement sur des procédures. Les interfaces sont conçues en fonction des tâches de l'opérateur (Voir section 6. Recommandations). Nous avons une vue d'ensemble de l'état des sous-systèmes clés soit : l'état des sous-systèmes critiques et l'état des opérations (Voir section 6. Recommandations). IMaC possède un fort couplage du système qui correspond à la caractéristique de notre transaction mobile, que soit, toutes les tâches sont absolument liées pour que l'opérateur puisse atteindre son but d'acheter un billet de spectacle (un écran=une tâche; chaque écran représente en fait une tâche). 9
"mwallet" contient un des principes d'acid 3 (Atomicité, Cohérence, Isolation, Durabilité) d'une transaction qu est l'atomicité, le principe du "tout ou rien" (toutes les actions sont validées ou aucune n est validée). En outre, elle constitue une "représentation détaillée des buts, des fonctions et des tâches de l'opérateur (succès ou faute) sous forme d'un réseau d'automates 4 à états finis et d'une fonction de contrôle des transitions entre les états des automates. Les automates contiennent l'ensemble des actions (appelées fonctions) possibles de l'opérateur ainsi que des contraintes et des éléments du processus conditionnant l'exécution de ces actions" [FIS04]. IMaC nous permet de gérer des situations normales et des situations anormales prévues puisque les trois autres méthodes indiquées ci-dessus (EID, TAGCI, SRK) sont plutôt indiquées pour des situations prévues et imprévues que ne s'adaptent pas à IMaC. 5.3. Mise en œuvre La mise ne œuvre de cette méthodologie (IMaC) est guidée par une suite de quatre étapes lesquelles aident les concepteurs à concevoir des interfaces appropriées à des tâches de commande et de surveillance selon la Figure 1. IMaC soutient qu une interface est constituée à la fois d'un composant d'information et d'un composant d'interaction et que le processus de conception doit effectivement adresser les contenus de ces deux composants. Dans l'étape 1, "Operations Modeling", le concepteur construit un modèle normatif des tâches de l'opérateur à l'aide des tâches de commande et de surveillance. Le modèle d'opération est construit en utilisant des informations recueillies au travers de l'observation directe des opérations, des entrevues avec les opérateurs et les concepteurs des systèmes, et de documentation disponible sur le système. En parallèle avec l'élaboration du modèle normatif, l'étape 2, "Information Flow Analysis", consiste en une analyse du flux d'informations entre les activités de l'opérateur qui est employée pour l'identification de l'information requise par les tâches de surveillance. L'étape 3, "Requirements Identification", consiste à intégrer le modèle normatif et le modèle du flux d'informations pour l'identification des exigences de chaque tâche à l'égard des informations et des commandes requises. Ces commandes constituent notamment des tâches de commande et de surveillance que l'opérateur doit accomplir pour finir une activité donnée (e.g. la cueillette de données). 3 Atomicité: principe du "tout ou rien" (toutes les actions sont validées, ou aucune n est validée); Cohérence (prendre les données dans un état cohérent, les rendre dans un état cohérent); Isolation (les modifications d une transaction sont invisibles pour les autres transactions); Durabilité (les actions d une transaction ne peuvent pas être perdues si la transaction est validée). 4 Structure physique ou informationnelle qui fonctionne d'après des règles strictes, heuristiques ou probabilistes, sans l'intervention consciente de l'être humain. N'importe quel système est un automate. 10
La dernière étape, "Interface Design", s'agit de la conception d'ihm à partir de l'information collectée pendant les étapes antérieures. Cette interface possède deux parties: un composant d'information et un composant d'interaction. Ces composants fournissent à la fois un mécanisme pour réduire les écarts de l'évaluation et de l'exécution et entre le système et l'opérateur. Figure 1: La méthodologie de design IMaC [THU97]. Chaque composant en fait peut être décrit par ses affordances d action que lui-même peut nous offrir. Le composant d'information fourni l'affichage visuel de l'information à l'opérateur sur la forme de textes et de graphiques. Le composant d'interaction fourni alors des opportunités pour l'action que l'interface nous offre. La propriété d affordance est un résultat de l approche écologique de la perception [GIB79]. L'affordance désigne qu un artefact (objet), par sa caractéristique de la perception, induit à l utilisateur d exécuter les actions dont permet cet objet. Par exemple, un bouton suggère que l on puisse appuyer dessus ou encore l'exemple de [NOR88] des poignées de portes dont la disposition et la forme induiront plutôt à tirer, pousser ou tourner (application industrielle plutôt qu informatique mais l idée est là). L'étape 4 inclut un ensemble de principes de design (Tableau 1) pour guider la spécification et la configuration des composants d'information et d'interaction. Ces principes ont été développés en appliquant les principes de conception centrée sur l utilisateur de [NOR88] spécifiquement dans le contexte des interfaces de contrôle et de surveillance interactives pour des systèmes complexes. Celle-ci, aident alors à s'assurer que les interfaces résultantes rendent possible à l'opérateur de faire avec efficacité les points suivants: comprendre les tâches de contrôle et de surveillance (e.g. exigences) du système; comprendre les étapes exigées pour les entreprendre; identifier à quel moment les tâches nécessiteront d être réalisées. 11
Tableau 1: Les principes de conception IMaC Item Description 1. Fournir des opportunités évidentes pour l action qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et soutenir les activités cognitives que l opérateur doit exécuter pour surveiller le processus. 2. Emmagasiner l information importante dans l interface et la fournir à l opérateur au moment opportun; réaliser les calculs nécessaires pour fournir l information requise par l opérateur pour surveiller le système. 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriés. 4. Fournir les affichages intégrant la surveillance et la commande soutenant l'exécution des étapes d une tâche, ainsi que l information requise pour surveiller et évaluer l exécution de ces étapes. 5. Utiliser les contraintes sur les commandes de l interface pour communiquer les contraintes sur la surveillance et la commande du système. 6. Fournir des vues d ensemble montrant l état des sous-systèmes clés, identifiant les sous-systèmes critiques nécessitant de l attention et montrant l état des opérations. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information disponible et d exécuter toute commande. 8. Identifier et comprendre les attentes de l opérateur par rapport à la conception de l interface et à l interaction qu elle doit soutenir; éviter de violer les normes de la culture des opérations. 12
6. Recommandations Ce chapitre répertorie toutes nos recommandations émises des interfaces-utilisateurs de la transaction "mwallet" aussi bien que les interfaces-utilisateurs originales de cette même application qui nous ont servi de base pour nos recommandations. 6.1. Interfaces-utilisateurs originaux Description de la transaction mobile Le but de cette transaction mobile est d'acheter deux billets des spectacles pour le concert du groupe "Favorite Band" à travers le site Web de la compagnie www.ticketstore.com Dans le Tableau 2 ci-dessous nous décrivons le processus de la transaction "mwallet" ainsi bien que les interfaces-utilisateurs (écrans) de chaque étape de la transaction. Tableau 2: Interfaces originales "mwallet" Écrans Description Écrans Description 1 L'utilisateur reçoit une alerte, un message Push SMS 5 sur son téléphone mobile. Il clique sur le lien Read pour lire le message. 3 L'utilisateur reçoit l'information du spectacle disponible aussi bien que son lieu de présentation. Il a 2 L'utilisateur choisi de rentrer dans le site Web pou l'achat des billets de spectacle d'un groupe. 4 L'utilisateur choisi la date pour le spectacle. 5 Service Push SMS (Short Messaging Service): c'est un service de télécommunicatins permettant de fournir, après une activqitn réussie du service par les client mobile lui-m^me, des informations payantes sur un thème demandé au moyen de SMS. Le client mobile peut par exemple s'informer sur les actualités, les prévisions métereologiques, les spectacles, la bourse, etc. 13
Écrans Description Écrans Description 5 L'utilisateur décide d'acheter les deux billets de spectacle avec un montant de $40 et clique sur le lien Submit. 10 Le marchant demande la confirmation d'achat des deux billets à l'utilisateur. L'utilisateur confirme son achat et la livraison. 6 L'utilisateur décide d'acheter les deux billets de spectacle avec un montant de $80 et clique sur le lien Purchase Now. 7 L'utilisateur saisi les données d'authentification (Identifiant et mot de passe) et soumet la saisie. 10a 11 Le marchant affiche l'approbation du paiement. 8 Le marchant affiche à l'utilisateur quelle carte de crédit il faudra débiter le montant. 12 Le marchant affiche le code de confirmation de l'achat et remercie l'utilisateur pour l'achat. 9 Le marchant demande des informations sur la livraison des billets: Home or Work. L'utilisateur choisi sa maison. 14
6.2. Interfaces-utilisateurs améliorées (IMaC) Dans le tableau 3 ci-dessous, nous décrivons et démontrons l'utilisation des principes des interfaces-utilisateurs IMaC. Tableau 3: Interfaces améliorées "mwallet" Écran Description de l'amélioration Tâche de l'opérateur But Principe(s) appliqué(s) IMaC 1 Aucune Lire le message en et cliquer sur le lien "Read". Faire l'utilisateur lire le message qui vient d'arriver sur son téléphone mobille. Aucun 2 Icône de navigation "flèche d'avancement": dans le cas où l'utilisateur déciderait de retourner à cet écran à partir de la prochaine. Cliquer sur le lien "wap.ticketstore.com" Inciter l'utilisateur à visiter le site Web "wap.ticketstore.com" 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriée. 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriée. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information disponible et d exécuter toute commande. 8. Identifier et comprendre les attentes de l opérateur par rapport à la conception de l interface et à l interaction qu elle doit soutenir; éviter de violer les normes de la culture des opérations. 15
Écran Description de l'amélioration Tâche de l'opérateur But Principe(s) appliqué(s) IMaC 3 Icône d'authentification "Logo Ticket Store": Permet à l'utilisateur de s'assurer que le site Web qu'il vient de rentrer est bien le site de "Ticket Store". Il apparaît seulement dans cette interface. Ce logo (marque enregistrée) pourrait être un logo certifié et enregistré par exemple auprès d'une Autorité de certification. Icône de navigation "flèche de retour": dans le cas où l'utilisateur déciderait de retourner à l'écran antérieur. Icône de navigation "flèche d'avancement": dans le cas où l'utilisateur déciderait d'avancer retourner au prochain écran. Icône de sécurité "cadenas": désignant que la source (wap.ticketstore.com) utilise des mécanismes de sécurité pour protéger les données personnelles de l'utilisateur. L'utilisateur demande les dates disponibles des spectacles du groupe cliquant sur le lien "Search". Aller aux dates disponibles des spectacles. 1. Fournir des opportunités évidentes pour l action qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et soutenir les activités cognitives que l opérateur doit exécuter pour surveiller le processus. 2. Emmagasiner l information importante dans l interface et la fournir à l opérateur au moment opportun; réaliser les calculs nécessaires pour fournir l information. 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriée. 6. Fournir des vues d ensemble montrant l état des sous-systèmes clés, identifiant les sous-systèmes critiques nécessitant de l attention et montrant l état des opérations. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information disponible et d exécuter toute commande. 8. Identifier et comprendre les attentes de l opérateur par rapport à la conception de l interface et à l interaction qu elle doit soutenir; éviter de violer les normes de la culture des opérations. 16
Écran Description de l'amélioration Tâche de l'opérateur But Principe(s) appliqué(s) IMaC 4 Icône de navigation "flèche de retour": dans le cas où l'utilisateur déciderait de retourner à l'écran antérieur. Icône de navigation "flèche d'avancement": dans le cas où l'utilisateur déciderait d'avancer/retourner au prochain écran. Icône de sécurité "cadenas": désignant que la source (wap.ticketstore.com) utilise des mécanismes de sécurité pour protéger les données personnelles de l'utilisateur. Cliquer sur lien respectif pour le spectacle du groupe. Choisir la date du spectacle. 1. Fournir des opportunités évidentes pour l action qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et soutenir les activités cognitives que l opérateur doit exécuter pour surveiller le processus. 2. Emmagasiner l information importante dans l interface et la fournir à l opérateur au moment opportun; réaliser les calculs nécessaires pour fournir l information. 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriée. 6. Fournir des vues d ensemble montrant l état des sous-systèmes clés, identifiant les sous-systèmes critiques nécessitant de l attention et montrant l état des opérations. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information disponible et d exécuter toute commande. 17
Écran Description de l'amélioration Tâche de l'opérateur But Principe(s) appliqué(s) IMaC 5 Icône de navigation "flèche Spécifier la quantité Spécifier la quantité 1. Fournir des opportunités évidentes pour l action de retour": dans le cas où de billets et cliquer de billets de billets qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et l'utilisateur déciderait de sur le lien du spectacle. soutenir les activités cognitives que l opérateur retourner à l'écran antérieur. "Submit". doit exécuter pour surveiller le processus. Icône de navigation 2. Emmagasiner l information importante dans "flèche d'avancement": dans l interface et la fournir à l opérateur au moment le cas où l'utilisateur opportun; réaliser les calculs nécessaires pour fournir l information. déciderait 3. Utiliser un modèle normatif des fonctions de d'avancer/retourner au l opérateur pour identifier ses besoins prochain écran. d informations et de commandes. Fournir les Icône de sécurité "cadenas": informations requises dans l interface au moment désignant que la source et sous la forme appropriée. 6. Fournir des vues d ensemble montrant l état des (wap.ticketstore.com) utilise sous-systèmes clés, identifiant les sous-systèmes des mécanismes de sécurité critiques nécessitant de l attention et montrant pour protéger les données l état des opérations. personnelles de l'utilisateur. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information 6 Icône de navigation "flèche de retour": dans le cas où l'utilisateur déciderait de retourner à l'écran antérieur. Icône de navigation "flèche d'avancement": dans le cas où l'utilisateur déciderait d'avancer/retourner au prochain écran. Icône de sécurité "cadenas": désignant que la source (wap.ticketstore.com) utilise des mécanismes de sécurité pour protéger les données personnelles de l'utilisateur. Décider l'achat des billets et cliquer sur le lien "Purchase Now". Inciter l'utilisateur à acheter les billets. disponible et d exécuter toute commande. 1. Fournir des opportunités évidentes pour l action qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et soutenir les activités cognitives que l opérateur doit exécuter pour surveiller le processus. 2. Emmagasiner l information importante dans l interface et la fournir à l opérateur au moment opportun; réaliser les calculs nécessaires pour fournir l information. 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriée. 6. Fournir des vues d ensemble montrant l état des sous-systèmes clés, identifiant les sous-systèmes critiques nécessitant de l attention et montrant l état des opérations. 7.Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information disponible et d exécuter toute commande. 18
Écran Description de l'amélioration Tâche de l'opérateur But Principe(s) appliqué(s) IMaC 7 Icône de navigation "flèche Saisir son Obtenir l'identifiant 1. Fournir des opportunités évidentes pour l action de retour": dans le cas où identifiant et son et le mot de passe qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, l'utilisateur déciderait de mot de passe. de l'utilisateur. identifier et soutenir les activités retourner à l'écran antérieur. cognitives que l opérateur doit exécuter pour Icône de navigation "flèche surveiller le processus. d'avancement": dans le cas 2. Emmagasiner l information importante dans où l'utilisateur déciderait l interface et la fournir à l opérateur au moment opportun; réaliser les calculs d'avancer/retourner au nécessaires pour fournir l information. prochain écran. 3. Utiliser un modèle normatif des fonctions de Icône de sécurité l opérateur pour identifier ses besoins "cadenas/clé": les données d informations et de commandes. Fournir les saisies par l'utilisateur informations requises dans l interface au moment et sous la forme appropriée. (identifiant et mot de passe) 6. Fournir des vues d ensemble montrant l état des seront cryptés à partir du sous-systèmes clés, identifiant les sous-systèmes moment qu'elles seront critiques nécessitant de l attention et montrant soumises. l état des opérations. requise par l opérateur pour surveiller le système. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information 8 Icône de navigation "flèche de retour": dans le cas où l'utilisateur déciderait de retourner à l'écran antérieur. Icône de navigation "flèche d'avancement": dans le cas où l'utilisateur déciderait d'avancer/retourner au prochain écran. Icône de sécurité "cadenas/clé": les données saisies par l'utilisateur (identifiant et mot de passe) seront cryptés à partir du moment qu'elles seront soumises. Décider avec quelle carte de crédit l'achat sera réalisé et cliquer sur le lien respectif. Obtenir la carte de crédit choisie par l'utilisateur pour débuter le processus de paiement. disponible et d exécuter toute commande. 1. Fournir des opportunités évidentes pour l action qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et soutenir les activités cognitives que l opérateur doit exécuter pour surveiller le processus. 2. Emmagasiner l information importante dans l interface et la fournir à l opérateur au moment opportun; réaliser les calculs nécessaires pour fournir l information. 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriée. 6. Fournir des vues d ensemble montrant l état des sous-systèmes clés, identifiant les sous-systèmes critiques nécessitant de l attention et montrant l état des opérations. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information disponible et d exécuter toute commande. 19
Écran Description de l'amélioration Tâche de l'opérateur But Principe(s) appliqué(s) IMaC 9 Icône de navigation "flèche Décider quel sera le Obtenir le lieu de 1. Fournir des opportunités évidentes pour l action de retour": dans le cas où lieu de livraison et livraison choisi par qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et l'utilisateur déciderait de cliquer sur le lien l'utilisateur. soutenir les activités cognitives que l opérateur retourner à l'écran antérieur. respectif. doit exécuter pour surveiller le processus. Icône de navigation "flèche 2. Emmagasiner l information importante dans d'avancement": dans le cas l interface et la fournir à l opérateur au moment où l'utilisateur déciderait opportun; réaliser les calculs nécessaires pour fournir l information. d'avancer/retourner au 3. Utiliser un modèle normatif des fonctions de prochain écran. l opérateur pour identifier ses besoins Icône de sécurité d informations et de commandes. Fournir les "cadenas/clé": les données informations requises dans l interface au moment saisies par l'utilisateur et sous la forme appropriée. 6. Fournir des vues d ensemble montrant l état des (identifiant et mot de passe) sous-systèmes clés, identifiant les sous-systèmes seront cryptés à partir du critiques nécessitant de l attention et montrant moment qu'elles seront l état des opérations. soumises. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information 10 Icône de navigation "flèche de retour": dans le cas où l'utilisateur déciderait de retourner à l'écran antérieur. Icône de navigation "flèche d'avancement": dans le cas où l'utilisateur déciderait d'avancer au prochain écran. Icône de sécurité "cadenas/clé": les données saisies par l'utilisateur (identifiant et mot de passe) seront cryptés à partir du moment qu'elles seront soumises. Confirmer son achat et cliquer sur le lien "Confirm". Obtenir la confirmation d'achat de l'utilisateur disponible et d exécuter toute commande. 1. Fournir des opportunités évidentes pour l action qui correspondent aux besoins identifiés dans le modèle normatif; en particulier, identifier et soutenir les activités cognitives que l opérateur doit exécuter pour surveiller le processus. 2. Emmagasiner l information importante dans l interface et la fournir à l opérateur au moment opportun; réaliser les calculs nécessaires pour fournir l information. 3. Utiliser un modèle normatif des fonctions de l opérateur pour identifier ses besoins d informations et de commandes. Fournir les informations requises dans l interface au moment et sous la forme appropriée. 6. Fournir des vues d ensemble montrant l état des sous-systèmes clés, identifiant les sous-systèmes critiques nécessitant de l attention et montrant l état des opérations. 7. Toujours laisser une méthode à l opérateur lui permettant d accéder à toute information disponible et d exécuter toute commande. 20