Memoire Online - Mesures de l'utilisabilité du logiciel de transcription automatique nat braille v. 2.0 - entre ergonomie logicielle et design d'interaction homme-machine

erreur d'entrée sortie lors de la vérification de l'e.\tente d'une mise a jour

k Ouvrir le
· riscription

iJ Quitter

MESURES DE L'UTILISABILITÉ DU LOGICIEL DE TRANSCRIPTION AUTOMATIQUE
NAT BRAILLE V. 2.0

MÉMOIRE DE MASTER EN HUMANITÉ ET SCIENCES HUMAINES
MENTION SCIENCES COGNITIVES
SPÉCIALITÉ PROFESSIONNELLE SCIENCES COGNITIVES APPLIQUÉES
Niveau : M. 2

au Laboratoire d'Informatique en Image et Systèmes d'Information (LiRiS)
UMR 5205 CNRS / Université Claude Bernard LYON 1

À partir des recommandations issues de la littérature en ergonomie logicielle, nous avons proposé des corrections pour améliorer l'utilisabilité du logiciel de transcription braille NAT v. 2.0. Nous avons contrebalancé l'ordre de présentation des interfaces originale et corrigée pour deux groupes de cinq participants travaillant avec des enfants déficients visuels. Les enregistrements des passations ont permis de dégager qualitativement des problématiques d'utilisabilité, et quantitativement des scores de performance. Les résultats ont montré que les corrections apportées étaient efficaces de ces deux points de vue (scores et jugements subjectifs). Les tests ont été complétés par une inspection analytique d'interface ; les conseils et dessins techniques délivrés ont entraîné des modifications substantielles dans le design d'interaction entre l'opérateur et l'outil, ainsi qu'au sein même du système.

Mots-clés : NaT, braille, ergonomie, utilisabilité, inspection analytique, interaction homme-machine, design d'interaction.

1. INTRODUCTION

A l'aide d'observations et de mesures portant sur l'utilisation, en conditions écologiques, du logiciel de transcription automatique en braille « Not another Transcriber » (NAT)¹, nous nous proposons de fournir les conseils et recommandations issus de la littérature en ergonomie des logiciels et « design d'interaction homme-machine » afin d'améliorer l'utilisabilité générale de cette application.

Nous verrons ainsi en quoi NAT s'inscrit dans une démarche originale de compensation du « handicap », après un bref rappel des définitions et des situations nouvelles se rapportant à cette notion complexe et évolutive. Nous cernerons ensuite les différentes définitions et méthodes ainsi que les outils variés proposés par le domaine ergonomique pour la conception et l'évaluation d'interfaces sous l'angle de leur utilisabilité ; terme qui recouvre, selon la norme ISO 9241-11, « le degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d'utilisation spécifié ».

Les chiffres de l'enquête Handicap, Incapacités et Dépendances (HID) menée par l'Institut National de la Statistique et des Études Économiques (INSEE) pour l'année 2002 montrent qu'au total, ce sont 1,7 million de personnes qui souffrent d'une acuité visuelle (AV) faible en France :

560 000 malvoyants légers (AV comprise entre 3/10^e et 1/10^e) ; 932 000 malvoyants moyens (AV comprise entre 1/10^e et 1/20^e) ;

207 000 malvoyants profonds (AV comprise entre 1/20^e et 1/50^e), dont environ 61 000 aveugles complets (AV nulle).

- moins de 1% (8 000 personnes environ) se servent d'interfaces d'ordinateurs (reconnaissance vocale, écran tactile, synthèse vocale).

Enfin, 15% des aveugles seulement ont appris le braille², 10% l'utilisent pour la lecture et 10% pour l'écriture.

L'Organisation Mondiale de la Santé (OMS) a en outre proposé en 1989 les définitions suivantes relatives au domaine du handicap, qui distinguent :

la déficience : altération d'une structure ou fonction psychologique, physiologique ou anatomique ; l'incapacité : réduction partielle ou totale de la capacité à accomplir une activité ;

le handicap (ou « désavantage » selon les termes propres de l'OMS) : désavantage social résultant, pour l'individu, d'une déficience ou d'une incapacité, et qui limite ou interdit l'accomplissement d'un rôle « normal ».

L'OMS cite par exemple les désavantages de mobilité, d'activité occupationnelle, d'orientation... On vient à considérer qu'en fonction de la tâche à accomplir, de l'environnement dans lequel il est amené à l'accomplir, et des connaissances ou capacités dont il dispose relatives à cette tâche, tout individu peut être confronté, pour des durées variables, à des situations de handicap, et non plus seulement les seules personnes comptabilisées par les études statistiques. Par extension, on estime que s'attacher à la compensation d'un handicap donné, dans une situation et un environnement donnés, peut constituer un avantage pour des individus non concernés de prime abord par cette compensation. Archambault (2010, chap. 1) fournit l'exemple de plans inclinés bordant certaines portions d'escaliers : destinés à l'origine aux déficients moteurs, ils servent aussi à pallier des situations de « handicap » dans lesquelles se retrouvent d'autres populations (accidentés, parents avec poussettes, personnes âgées...). On ajoutera sur ce point précis que ce type d'aménagement peut aussi entraîner une détection plus difficile à la canne blanche et des problèmes de stabilité spécifiques pour les aveugles... Mais, d'une manière générale, s'attacher à favoriser l'accessibilité de documents, de lieux, ou d'activités, à des groupes d'individus présentant une déficience, a aussi des répercussions sur l'accessibilité de ces domaines au reste de la population. On ne considère donc plus le handicap comme seulement découlant d'une déficience organique, mais plus généralement comme une notion « situationnelle », rattachée à l'environnement.

Parmi les différents types de déficiences, une large part de la recherche technologique s'est orientée vers la compensation des situations de handicap générées par les déficiences sensorielles ; entre autres, celles résultant d'une déficience visuelle. Cette population bénéficie ainsi de la mise à disposition de moyens techniques nouveaux pour l'accès à l'information écrite (Thoumie, 2004).

2 Il est réputé difficile d'être performant en braille si l'apprentissage est trop tardif.

- les synthèses vocales logicielles couplées à des lecteurs d'écrans, pour un retour auditif du texte présenté ;

- les systèmes de reconnaissance de parole, utilisés pour la production écrite sur ordinateur personnel ;

- les plages braille éphémères³, utilisées par les non-voyants pour la lecture tactile des informations codées en braille ;

- mais aussi l'application de techniques laser à la canne blanche traditionnellement associée aux non-voyants, pour une meilleure perception de l'environnement.

D'un autre côté, cet accès à l'information reste difficile et incomplet, en particulier lorsque le contenu devient complexe. La lecture ou la production d'un texte long, trop (ou trop peu) hiérarchisé, présentant des écritures non-linéaires (par exemple, mathématiques), ou encore intégrant des tableaux ou des illustrations, fournit autant d'exemples d'un accès à l'information typiquement séquentiel, partiel, et gourmand en ressources cognitives pour les déficients visuels. Surtout, Uzan (2005) rappelle que l'accès à l'information reste encore caractérisé par sa lenteur (handicap temporel ou time disability).

Dans le domaine de la prise en charge scolaire de jeunes déficients visuels⁴, l'adaptation de contenus complexes (figures et équations en mathématiques, formules et schémas en physique et chimie, cartes en histoire et géographie, tableaux en sciences économiques) peut être réalisée, en application de normes précises, sophistiquées, et en constante évolution, par des transcripteurs-adaptateurs professionnels. Cependant, faire appel aux centres de transcription reste une démarche coûteuse en temps, comprenant le délai d'envoi du document, de réalisation de l'adaptation, et de retour du document adapté. Ce temps s'ajoute à celui qui pénalise déjà les aveugles dans leurs tâches pour l'accès à ces documents. Par ailleurs, tous les déficients visuels ne peuvent avoir accès à ce type de service : comme Archambault (2010, chap. 4) le souligne, la France a du retard à combler dans le domaine de « l'éducation pour l'inclusion ». C'est donc dans l'optique de fournir une solution automatisée « simple d'utilisation pour les non-professionnels, accessible pour les non-voyants, et suffisamment paramétrable pour intéresser les transcripteurs professionnels » (Mascret, Mille & Ollier, 2008) que NAT a été conçu.

3 La plage braille, ou plage tactile (refreshable Braille display en anglais) est un dispositif électro-mécanique servant à afficher les caractères braille envoyés par un ordinateur.

4 En France, la loi de 2005 pour l'« égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées » permet la scolarisation en « milieu ordinaire » de ces personnes.

Mascret et al. (2008) décrivent rapidement le système braille et la chaîne de transcription élémentaire, puis les principes généraux d'un transcripteur braille idéal : « une solution intégrée, d'utilisation polymorphe, accessible à tous et indépendante de configurations particulières ». Des précisions concernant les normes de transcription et le système braille sont reportées en annexe A.

Développé à partir de 2006 pour faciliter la diffusion mais aussi l'apprentissage du braille, NAT permet de réaliser la conversion automatique de textes littéraires ou scientifiques en format de fichier directement interprétable par les plages tactiles ou les embosseuses⁵ utilisées par les lecteurs de braille. Une large diffusion de NAT permettrait ainsi de dispenser les professeurs, accueillant des enfants handicapés en intégration scolaire, de la mise en place de procédures lourdes et chronophages pour la transcription de documents simples. Il permettrait aussi l'interaction, en classe, de l'élève non-voyant avec son enseignant, grâce à une fonction de dé-transcription du braille ; enfin, il pourrait par la suite être utilisé par les professionnels des centres de transcription (notamment pour sa puissance de traitement dans le domaine de la transcription scientifique).

C'est un logiciel que l'on peut donc ranger dans la catégorie des aides techniques, ou systèmes d'assistance, tels que Spérandio (2007) les différencie d'autres produits techniques (« produits généraux » et « aménagements particuliers »). Parmi ses particularités, on note qu'il s'agit d'un logiciel libre et multiplateforme, conçu de manière modulaire afin de permettre son intégration dans d'autres logiciels ou librairies et de garantir la réutilisation de ses composants en leur permettant de fonctionner de manière indépendante les uns des autres. NAT se compose de trois modules spécialisés qui réalisent :

- un post-traitement pour la mise en forme, l'exportation ou l'impression du fichier obtenu.

Il utilise des règles, implémentées par des feuilles de style en langage XSL (eXtensible Stylesheet Language), pour la reconnaissance d'éléments de texte (syllabes, mots, phrases, paragraphes) et d'écritures spécifiques (par exemple, les écritures scientifiques, les abréviations, etc.). De même, la transcription des textes en braille abrégé se fait à l'aide de règles implémentées, là où les autres solutions de transcription existantes utilisent des dictionnaires. Ce sont ces règles (ou filtres) qui serviront à la transcription automatique du texte.

5 L'embossage est une technique permettant de créer des formes en relief dans du papier ou un autre matériau déformable. L'embossage braille est réalisé à l'aide d'imprimantes dédiées, appelées embosseuses.

Outre son caractère compatible (avec plusieurs systèmes), interopérable (avec d'autres logiciels) et gratuit, c'est le développement de ces filtres qui confère aussi à NAT son originalité : ils s'approchent d'une modélisation de fonctionnement intelligent et concourent à l'idée, défendue par Abhishek et Basu (2006), de créer les conditions d'une vraie communication assistée, par le développement d'une étape d'interprétation automatique du texte. Ces filtres peuvent par ailleurs se combiner entre eux, fournissant des possibilités étendues de personnalisation de la transcription. L'enregistrement de ces combinaisons peut fournir les configurations utilisables par le public non-expert de NAT. Par exemple, les deux configurations présentées dans le tableau 1 peuvent constituer le paramétrage par défaut, en fonction de leurs besoins, soit d'un professeur d'intégration en Mathématiques, niveau 6^ème (son élève ne connaît pas le braille abrégé, et dispose d'une plage tactile : configuration 1), soit d'un professeur de Français en établissement spécialisé, niveau 2^nde (il dispose d'une embosseuse sur son lieu de travail, et son élève connaît bien le braille abrégé : configuration 2).

Tableau 1. Deux types de configurations d'utilisation de NAT en fonction de la combinaison de filtres retenue.

Nom du filtre	Configuration 1	Configuration 2
Type de braille	intégral	abrégé
Traiter les Mathématiques	oui	non
Traiter les tableaux	oui	non
Couper les mots en fin de ligne	non	oui
Type de sortie	format électronique	embosser (embosseuse spécifiée)

Enfin, l'un des atouts prépondérants de NAT reste sa capacité à faire dialoguer voyant et non-voyant par l'intermédiaire d'une interface dédiée. Archambault (2010, chap. 2) souligne qu'il est « essentiel de développer de nouveaux outils de travail collaboratif entre voyants et aveugles ou malvoyants, [...] à la fois pour servir ces élèves ou leurs enseignants, mais aussi pour concourir à propager cette idée de l'intégration scolaire ». Sur deux aperçus placés en côte-à-côte, l'un affichant le texte braille, l'autre le même texte « en noir »⁶, élève aveugle et professeur peuvent mettre à jour en temps réel les modifications qu'ils apportent au contenu, chacun de leur côté. Ce système de dialogue écrit permet par exemple la supervision directe du travail effectué en classe, mais aussi la modification immédiate du texte présenté (par exemple, pour la correction d'une erreur en cours).

6 Formule communément utilisée pour désigner le texte lu par le voyant. La norme braille recommande le terme « texte imprimé ».

Par ailleurs, NAT fournit en tant que fonctionnalité spécifique, disposant de sa propre interface, la dé-transcription d'un texte en braille intégral ou mathématique vers le noir.

Pourtant, malgré ses nombreuses qualités et fonctionnalités, il semble que NAT ne bénéficie pas entièrement du succès escompté. Lors d'un test de ce logiciel en 2009 au service de transcription du Centre Technique Régional pour la Déficience Visuelle (CTRDV) de Villeurbanne, les transcripteurs-adaptateurs de documents n'ont pas réussi à comprendre son mode de fonctionnement. D'abord parce que NAT ne dispose pas encore d'un véritable éditeur de type « WYSIWYG⁷ », qui permettrait de modifier la mise en page et d'apporter des corrections éventuelles au texte braille (il est nécessaire actuellement de manipuler les balises d'un langage XML, puis de demander la mise à jour du résultat obtenu) : cet aspect limite très fortement son utilisation en conditions pratiques de travail. Ensuite parce, si NAT a pu faire l'objet de quelques recommandations en termes d'ergonomie, celles-ci ont uniquement porté sur les critères d'accessibilité, et non d'utilisabilité, d'une interface qui a par ailleurs beaucoup évolué au cours des développements successifs. Je me suis donc proposé pour appliquer au logiciel NAT Braille les recommandations issues des guides d'utilisabilité (usability guidelines) construits par la communauté des chercheurs en ergonomie logicielle.

Bobillier-Chaumon, Carvallo, Tarpin-Bernard & Vacherand-Revel (2005) expliquent comment est apparue la rationalisation à la fois de la conception - par balisage et création d'éléments réutilisables - mais aussi de l'utilisation - par l'uniformisation des interfaces et la création des premiers modes « expert » et « débutant » - des outils informatiques. Les modèles d'interaction engendrés par le paradigme cognitiviste du Système de Traitement de l'Information (STI) semblent mener à l'« évacuation des aspects sociaux et expérientiels de la cognition » dans la réalisation de la tâche, par absence de prise en compte du corps, de la situation, des intentions et des besoins, mais aussi de l'environnement (social, organisationnel...) de l'interaction homme-machine (IHM)⁸. Ainsi, « les propriétés physiques de l'objet technique ne sont pas pensées en tant que telles ; seules leurs dimensions informationnelles sont considérées et non leur dimension manipulable ». L'approche centrée

7 « What You See Is What You Get » : interface utilisateur intuitive, présente dans quasiment tous les éditeurs actuels (texte ou image), et qui permet de présenter directement à l'écran le résultat final des manipulations.

8 Tandis qu'Archambault (2010) préfère la dénomination, un peu plus précise, d'« interaction humain-machine », et que Bach et Scapin (2005) utilisent le terme d'« interaction homme-environnement virtuel (IHEV) », nous conserverons l'expression traditionnelle pour faciliter la lecture.

utilisateur marque en ergonomie une première distanciation avec ce paradigme, et l'interaction de-

vient un processus dynamique à sept phases (Norman, 1986, cité in Bobillier-Chaumon et al.,

« L'action ne se réduit pas à une logique instrumentale et gagne une valeur intentionnelle ; l'humain devient sujet intentionnel d'une action située et contextualisée ». Il faut alors lier le comportement intelligent « non pas au logico-symbolique, au calcul, mais à son caractère situé et incarné ». De là découle la nécessité de prendre en compte l'expérience de l'utilisateur, à travers la flexibilité des systèmes, qui ne doivent pas être trop dirigistes. Selon que les étapes d'initiation, de proposition, puis de sélection et d'exécution de l'adaptation sont effectuées, en tout ou partie, par l'utilisateur ou par le système, on obtient des configurations mixtes entre adaptabilité totale et adaptativité totale⁹. Cette rupture passe finalement par la prise en compte de données qualitatives et non plus seulement quantitatives de l'interaction, ainsi que des structures externes (« contraintes écologiques ») et de l'affordance.

NAT, entre autres, semble ainsi souffrir d'un défaut de visibilité de ses fonctionnalités, ou présente des fonctionnalités qui ne sont pas réellement implémentées : on peut dire qu'il présente, aux sens proposés par Gaver en 1991 (cité in Christou, 2006), des affordances fausses (des indices mènent à une fonction qui n'existe pas, par exemple dans le cas de son « éditeur »), ou des affordances cachées (une fonction existante n'est pas indicée : c'est le cas de son système de « dialogue voyant/non-voyant »). Or Norman, en 1988 (cité in Christou, 2006) rappelle qu'un objet bien conçu intègre des affordances perceptibles qui fournissent des informations pertinentes pour l'utilisation des fonctionnalités de l'objet. Au-delà de la question d'une définition précise et unifiée de ce terme, en constante évolution, on retiendra que c'est à travers la présentation des indices

9 Adaptabilité ou « customisation », qui vient de l'utilisateur : on parle aussi d'adaptation statique. Adaptativité ou « personnalisation », mise en oeuvre par le système : on parle aussi d'adaptation dynamique.

menant à la fonctionnalité proposée (la création d'une affordance en tant que telle) que le design d'interface conduit à l'utilisation correcte de l'objet technique.

Ces indices, dans le cas d'une application logicielle, sont présentés à l'utilisateur par le biais d'éléments d'interfaces constituant les menus, dont les avantages sont connus : faible charge mémorielle, facilité d'apprentissage et d'utilisation, faible taux d'erreurs, ou encore familiarité. Tandis que le menu dit « traditionnel », occupant tout l'écran (et rencontré par exemple aux distributeurs automatiques bancaires) est censé être plus intuitif et destiné aux utilisateurs novices, le menu « déroulant », commun sous WindowsTM, MacintoshTM ou LinuxTM, permet en particulier de rester sur le même espace de travail. Les études, assez rares, sont recencées par Henley et Noyes (2006) et montrent que si les temps de recherche sont plus courts pour les menus déroulants, en revanche les menus traditionnels occasionnent moins d'erreurs, sont préférés des novices et des participants âgés, et nécessitent moins d'opérations que les menus déroulants (qui ont plus de succès auprès des jeunes utilisateurs, et des experts). Il faudra donc tenir compte de ces résultats pour organiser les items d'interface sur la fenêtre d'application, et les distribuer dans les différents types de menus disponibles en fonction du niveau d'expertise auquel ils feront appel.

Une procédure pour l'évaluation de l'agencement des indices répartis dans les menus d'application logicielle a été proposée par Bastien et Scapin (1993a). Ils constituent un ensemble de Critères Ergonomiques (CE) répartis en huit notions primaires et treize secondaires et destinés à orienter des choix de conception en minimisant les effets des subjectivités personnelles (un récapitulatif succinct des CE est présenté en annexe B). Ces critères ont été soumis à leur propre évaluation (en dimensions ergonomiques : efficacité, efficience, satisfaction...) et ainsi modifiés et corrigés une première, puis une seconde fois (Bach & Scapin, 2005 ; Bastien et Scapin, 1996). Leur organisation permet alors une évaluation heuristique de l'interface observée, réalisable par des non-experts du domaine ergonomique et qu'ils nomment Inspection Analytique (IA). À l'occasion de ces travaux, et même s'ils soulignent que l'ergonomie « se doit de proposer et d'appliquer des méthodes génériques et non pas se contenter de jugements individuels », les auteurs rappellent que leur analyse, de type heuristique, doit venir en complément des méthodes empiriques existantes (par exemple, des tests d'utilisabilité). Karoulis, Demetriadis et Pombortsis (2006) montrent par exemple que les évaluations expertes sont souvent plus précises sur le guidage et l'utilisabilité générale de l'interface que sur les autres critères étudiés ; ils proposent en particulier que ces experts soient formés tant aux notions cognitives qu'aux critères d'interaction homme-machine. Bach et Scapin (2005) vont plus loin en présentant l'IA comme « une analyse de surface permettant de repérer des

problèmes pouvant perturber l'efficacité d'un test utilisateur ». Woolrych & Hindmarch (2006) estiment par ailleurs que très peu d'évaluations de ces méthodes, d'un point de vue ergonomique, ont été entreprises : on connaît mal le type de problème qu'elles prédisent bien, et surtout le type de problème qu'elles ne révèlent pas. Cinq types de données émanent selon eux des analyses ergonomiques (par comparaison entre les résultats de l'inspection analytique et ceux des tests utilisateurs) :

- vrai négatif : un problème trouvé et éliminé, ce que confirme la pratique ;

- faux négatif : un problème trouvé par l'IA puis éliminé, alors que réel ;

Danielson (2006) recense de son côté les concepts liés à l'utilisabilité et les pièges à éviter dans le recueil des données, leur analyse et la réponse à leur apporter. Ce sont l'efficacité, l'efficience, la satisfaction subjective d'un utilisateur effectuant une tâche donnée, avec un système donné, dans un contexte donné qui constituent donc les dimensions de l'utilisabilité, telles que définies par la norme ISO 9241-11 (fréquemment, on inclut aussi l'étude de la mémorisation et de l'apprentissage du système). Cette évaluation peut être analytique, ou empirique, et plus ou moins précoce ou tardive dans le développement du système, la contrainte la plus commune restant le « timing » du recueil de données : plus la collecte d'informations se fait tardivement dans le développement, moins elle a de chance d'entraîner des changements de design. La méthode de collecte de données la plus employée reste celle des tests d'utilisabilité, mais celle-ci suppose une verbalisation de l'usager qui peut perturber les processus cognitifs engagés dans la tâche. Ainsi (et même lorsque les systèmes disposent de moyens intégrés de rapport d'erreur), c'est le jugement personnel de l'usager sur la gravité de l'erreur qui permet ou non le « feedback » : un usager novice spéculera que son problème n'en serait pas un s'il était expert, tandis qu'un expert spéculera que des fonctions risquent de poser problème à un novice, sans se pencher sur ses difficultés propres. Pour ce qui est de la méthode, recueil direct (en face-à-face) et recueil indirect (par le réseau) des données d'utilisabilité possèdent leurs avantages et inconvénients : en termes de précision des mesures effectuées et des avis subjectifs rapportés, mais aussi en termes de coûts (temporels et financiers) engagés. Les auteurs recensés par Danielson (2006) s'accordent à reconnaître que les données optimales sont obtenues en coordonnant les différentes méthodes : inspection analytique (pour laquelle on recommande des évaluateurs multiples), tests d'utilisabilité en conditions

écologiques, recueil de données indirect par le réseau. Concernant le matériel, on rappelle que la fidélité du prototype testé par rapport à la version finale ne doit pas être trop grande, ou l'on s'attache à juger un logo et des couleurs ; en outre, le logiciel ne doit être ni trop « vertical » (fonctionnalité élevée, variété faible des tâches et des options), ni trop « horizontal » (tâches et options nombreuses pour une fonctionnalité faible). Enfin, Nielsen (2000) nous apprend, par l'analyse statistique d'un grand nombre de tests utilisateurs, que plus nous observons de participants, moins nous découvrons de problèmes différents : un seul test utilisateur dévoile en moyenne 30% des problèmes totaux, cinq tests environ 80%, et quinze tests 100%. Nielsen propose donc de tester trois versions successives de la même interface avec cinq participants, plutôt qu'une seule version avec quinze sujets. C'est que « les problèmes sont dûs à l'interface, non aux utilisateurs ».

En 2002, une étude de Schach (cité in Singh & Dix, 2006) résume les problèmes récurrents auxquels sont confrontés les développeurs logiciels : prise en compte des erreurs ou des crashs systèmes - moins poussée que dans l'ingénierie traditionnelle -, développement différencié du hardware et du software, évolution constante des buts finaux et des impératifs utilisateurs. Sur la base d'exemples tirés d'expériences utilisateurs sur le Web, Singh et Dix (2006) montrent que l'intégration des définitions et des techniques d'IHM, à travers des méthodes et des modèles de développement modifiant les « cycles de vie » du logiciel, permet de prendre en compte l'expérience utilisateur plus tôt dans les processus de conception et de générer moins de modifications dans les étapes tardives d'implémentation, et finalement moins de code informatique. Si développeurs et « designers d'interaction » ont donc une approche différente de la conception (les premiers cherchant une solution qui fonctionne, les seconds une solution utilisable), leurs domaines partagent trop de points communs pour pouvoir s'exclure mutuellement. En effet, le sentiment de la communauté des développeurs serait celui d'une application des techniques liées à l'utilisabilité sur le développement de la partie visible de l'interface, une fois que le système logiciel (SE pour Software Engineering) a été implémenté. La convergence actuelle de ces deux disciplines montre que l'intégration précoce de leurs techniques respectives devient incontournable pour la conception de systèmes hautement utilisables. Ferre, Juristo et Moreno (2006) relèvent que la conception strictement séparée des éléments d'interface et du système interne conduit à des contradictions d'usage et de perception du fonctionnement ; il serait alors utile d'introduire des termes nouveaux, tels que « design d'interaction » - en tant que coordination des échanges entre usager et système - pour faciliter la communication entre les deux communautés. Par ailleurs, le développement itératif est encore peu prisé dans le monde du SE : ce serait là un apport conséquent des techniques

d'interaction homme-machine pour la conception de systèmes moyennement à très complexes, le modèle itératif étant reconnu pour son efficacité par rapport au développement dit « en cascade » (waterfall : analyse, implémentation, installation) et permettant d'assurer que l'utilisateur reste au centre du processus de conception.

Enfin, accessibilité et utilisabilité ne devraient plus être les seuls critères évalués lors de la conception d'un produit d'interaction : Knight (2006) rappelle que, de plus en plus, les utilisateurs attendent des produits fonctionnels et supra-fonctionnels (qui font mais aussi expriment), et considèrent comme valorisantes surtout leurs expériences volontaires. Le critère « d'engagement » devrait pouvoir rendre compte des expériences virtuelles, complexes et souvent « sociales » des utilisateurs d'aujourd'hui. Les études réalisées suggèrent que de plus en plus de systèmes d'interaction feront appel aux processus émotionnels et superposeront des qualités hédonistes ou éthiques à leurs fonctionnalités de base, à travers une approche à la fois éthique et esthétique de la conception des produits.

Nous nous proposons de fournir à l'équipe de développement du logiciel NAT les recommandations issues des guides d'utilisabilité, en particulier celui construit puis corrigé par Bastien et Scapin (1996). Une première inspection analytique sera complétée par le recueil direct, en conditions écologiques, de données d'utilisabilité auprès de populations potentiellement intéressées par cet outil. Ces tests seront réalisés en deux temps, selon le principe itératif de développement recommandé : une première série de passations permettra de dégager les problèmes majeurs en termes d'interface et de fonctionnalités et de fournir les conseils ergonomiques et le dessin technique pour une interface que l'on dira « interface corrigée ». Une seconde série de tests portant sur cette interface modifiée pourra permettre de mesurer, de façon qualitative (par comparaison des verbalisations) et quantitative (par comparaison du nombre d'opérations effectuées), si l'utilisabilité de l'application a été améliorée. Nous nous attacherons, pour ce faire, à contrebalancer l'effet de l'apprentissage d'une interface à l'autre, en présentant aux participants les deux versions de l'application dans deux ordres différents.

2. EXPÉRIENCE

Deux groupes de cinq participants ont réalisé les tests d'utilisabilité de NAT. Ces participants

trois professeurs de physique-chimie, histoire-géographie, et économie-gestion ;

Tous les participants ne produisent pas forcément du Braille dans leurs fonctions, mais sont sensibilisés aux matériels spécifiques, aux procédures impliquées et aux difficultés inhérentes à cette modalité d'accès à l'information. Sur les dix sujets, neuf étaient de sexe féminin. Deux sujets déclaraient des niveaux très faibles en Informatique, les autres un niveau intermédiaire ; aucun n'avait pris connaissance du logiciel avant les tests. Les règles de braille abrégé n'étaient connues d'aucun participant.

Les deux phases de test n'ont pu, pour des raisons pratiques, être menées sur le même matériel informatique. Ceci peut avoir une incidence notamment sur les différences observées de temps général de passation. Chaque ordinateur possédait la version testée de NAT, le logiciel de capture « CamStudio¹⁰ » pour l'enregistrement des traces de souris et des commentaires du sujet ; par ailleurs le logiciel de nettoyage et d'optimisation « CCleaner¹¹ » était lancé avant chaque passation¹². On notera que la capture vidéo en arrière-plan au cours d'une passation est à l'origine d'une consommation de ressources non négligeable, ce qui peut influer sur les temps de traitement et de réponse de NAT, et donc sur le temps de passation global.

12 Tous les logiciels cités sont développés sous licence libre et disponibles gratuitement sur le Web.

Les sujets disposaient, à l'emplacement du Bureau (Desktop) du PC, d'un dossier à leur nom contenant trois fichiers nommés en fonction de la tâche à réaliser ; par exemple :

Ces fichiers ne comportaient aucune expression scientifique, mais quelques majuscules et quelques chiffres, caractères codés spécifiquement en braille. En annexe C sont reportées les deux interfaces (originale et corrigée) testées, ainsi que les deux configurations système du matériel informatique utilisé.

Chaque participant était invité à accomplir trois tâches à l'aide de NAT. Ces tâches, représentatives de situations de transcription de texte simple, font aussi appel à la majorité des fonctionnalités proposées par le logiciel. Les consignes sont présentées en annexe D. Aucune information n'était délivrée concernant le fonctionnement de l'application. Un premier groupe de cinq sujets réalisait les trois tâches, d'abord sur interface native et sur PC 1, puis sur interface corrigée et PC 2. Le dessin technique et l'implémentation de cette interface corrigée découlaient des remarques et difficultés rencontrées par ce groupe sur l'interface native, ainsi que de l'inspection analytique réalisée en parallèle des tests utilisateurs. Pour contrebalancer un éventuel effet d'apprentissage, un second groupe de cinq participants réalisait les mêmes tâches, d'abord sur interface corrigée, puis sur interface native, et sur le même PC 2. Si les sujets étaient informés du fait que les traces du pointeur et leurs commentaires seraient enregistrés, en revanche aucune consigne ne leur était donnée concernant les temps de réalisation ou les verbalisations.

L'analyse des enregistrements a permis le décompte, pour chaque tâche et chaque sujet :

Pour préciser ces différentes variables, nous allons prendre pour exemple le déroulement de la troisième tâche. Celle-ci est constituée de quatre étapes :

- indiquer au logiciel d'inverser le sens de traitement (dé-transcrire, du braille vers le noir) ;

Pratiquement, cela signifie que dans le cas où le sujet oublie d'inverser le sens et n'active pas la bonne configuration avant de lancer le traitement, il effectue alors trois étapes (« fichier », « configuration » et « transcrire ») mais aussi deux fausses manipulations (« configuration » et « transcrire », qui l'éloignent de son but) et une erreur (il s'apprête à écraser le fichier braille qui lui sert de fichier source, donc à détruire son travail). Par ailleurs, on notera que les mêmes étapes, en fonction de la tâche demandée, ne nécessitent pas le même nombre de clics minimums. Ainsi, pour la tâche 2, l'étape « transcrire » en abrégé réclame plus de précisions, donc de clics, de la part de l'utilisateur que pour les tâches 1 et 3. En résumé, certaines étapes sont considérées comme des fausses manipulations, dont certaines peuvent conduire à des erreurs ; et toutes les étapes ne comportent pas le même nombre d'opérations d'une tâche à l'autre, ainsi qu'au sein d'une même tâche. Les données optimales pour la réalisation de chaque tâche sont regroupées dans le tableau 2.

Tableau 2. Clics et étapes strictement nécessaires à la réalisation des tâches proposées.

	3	Choisir fichier
	2	Configuration
	1	Transcrire
	2	Ouvrir fichier (numérique)
Total :	8	4
2)	3	Choisir fichier
	2	Configuration
	3	Transcrire
	1	Éditer
	2	Embosser
Total :	11	5
3)	1	Inverser le sens
	3	Choisir fichier
	2	Configuration
	1	Dé-transcrire
	2	Éditer
Total :	9	5

Pour les sept variables dépendantes (issues de l'analyse de l'enregistrement des tâches réalisées par les deux groupes de cinq sujets sur les deux versions de l'application), nous faisons donc l'hypothèse que la moyenne des scores obtenus avec l'interface corrigée sera meilleure que celle mesurée sur l'interface originale. Par ailleurs, ces scores devraient être meilleurs lors de la seconde présentation du logiciel, puisque le sujet aura bénéficié d'un apprentissage au cours de la première présentation. Nous appellerons « sens 1) » la présentation de l'interface originale (iO) suivie de l'interface corrigée (iC), et « sens 2) » le sens inverse (iC vers iO).

L'expérience est de type « split-plot », avec un facteur de groupe binaire G (Groupe) à cinq sujets (S), et un facteur intra-sujet I (Interface) à deux modalités. Le plan expérimental peut alors s'écrire :

Une analyse de la variance (ANOVA) a permis de déterminer si les résultats obtenus étaient significatifs¹³.

13 Les figures qui suivent sont décrites de façon succincte en « texte alternatif », par respect pour les règles d'accessibilité des documents numériques.

Les temps relevés pour la réussite des trois tâches sont toujours plus courts pour la seconde interface présentée. Cependant, cette différence est moins grande quand la seconde interface est l'interface originale. Dans le sens 1), les participants sont 2,21 fois plus rapides sur l'interface corrigée ; dans le sens 2), ils sont 1,37 fois plus rapides sur l'interface originale (cf. figure 1).

Les utilisateurs effectuent moins de clics sur l'interface corrigée, quel que soit le sens de passation (cf. figure 2). En moyenne, dans le sens 1), les utilisateurs effectuent 2,19 fois moins de clics sur la seconde interface présentée pour réaliser leurs tâches, et 1,11 fois plus dans le sens 2).

Il y a aussi interaction entre la variable « groupe » et la modalité d'interface :

Les sujets effectuent moins d'étapes sur la seconde interface, quel que soit le sens de présentation, mais cette différence est plus forte lorsque l'interface corrigée est présentée en premier. En moyenne, dans le sens 1), les utilisateurs effectuent 1,69 fois moins d'étapes sur l'interface corrigée pour réaliser leurs tâches. Dans le sens 2), ils effectuent 1,02 fois moins d'étapes sur l'interface originale (cf. figure 3).

En moyenne, les sujets effectuent moins de fausses manipulations pour la seconde interface présentée. Cet effet est plus faible lorsque celle-ci est l'interface originale (cf. figure 4).

En moyenne, l'utilisateur effectue moins d'erreurs sur l'interface corrigée, quel que soit le sens de passation (cf. figure 5).

Les sujets verbalisent, en moyenne, moins de remarques à connotation négative lors du travail sur interface corrigée que sur interface originale, et ce, quel que soit le sens de présentation (cf. figure 6).

Les verbalisations à connotations positives sont plus nombreuses, en moyenne, lors de la première présentation du logiciel. Cependant, l'interface corrigée recueille moins de remarques de ce type que celle originale, lors de la découverte de l'application.

Tous les sujets ont pu mener à bien leurs différentes tâches avec les deux versions de l'application, et tous se sont dits volontaires pour une utilisation future du logiciel dans le cadre de leurs activités. Un seul participant a estimé l'interface originale mieux conçue, plus intuitive et plus agréable (en seconde présentation) que celle corrigée (testée en premier). Les verbalisations et commentaires ont été utilisés pour compléter les recommandations ergonomiques délivrées à la suite des deux séries de passation.

3. DISCUSSION

L'expérience menée consistait à recueillir, de façon qualitative, les avis de sujets non-spécialistes sur l'utilisabilité de l'application NAT Braille 2.0, dans l'optique de son amélioration, mais aussi à mesurer, quantitativement, leurs performances pour étayer l'hypothèse selon laquelle l'interface corrigée avec leur aide est, sinon plus efficace, au moins plus efficiente et plus satisfaisante que la version native. Contrairement aux méthodes décrites dans la littérature, qui mesurent indirectement l'apprentissage au cours de plusieurs itérations successives de tests, corrections et implémentations, nous avons choisi ici de varier l'ordre de présentation des interfaces afin de contrebalancer son impact sur l'utilisation du logiciel.

L'analyse statistique des résultats obtenus montre un effet presque toujours significatif de l'interface corrigée sur l'amélioration des scores des participants ; cet effet reste encore tendanciel sur la diminution du nombre d'erreurs commises. La manière dont ont été comptabilisés les clics pointeurs, puis les étapes, les fausses manipulations et enfin les erreurs, variables dépendantes en quelque sorte imbriquées, permet de dégager une interprétation commune pour ces données : ce serait la multiplication des opérations qui conduirait l'utilisateur à perdre le fil de la tâche en cours, et à procéder par « essais-erreurs » dans la poursuite de son but. Ce type d'interaction avec le système pourrait provenir d'un manque de clarté, et surtout de linéarité, dans la présentation des différentes actions proposées par le logiciel pour la réalisation de la tâche. Les résultats quantitatifs suggèrent que le déroulement de la tâche a entraîné moins d'opérations et s'est fait de façon plus intuitive et plus efficiente à l'aide de l'interface corrigée. En dernier ressort, il apparaît que ce sont les temps globaux de passation qui ont été significativement améliorés.

Par ailleurs, on observe que les sujets se rapprochent du nombre optimal moyen d'opérations à l'aide du pointeur (environ 9) lors de l'utilisation de l'interface corrigée après présentation de l'interface native. Pourtant, cet effet est absent lorsque le sens de présentation change. De même, l'effet de l'interface sur d'autres variables est différent selon l'ordre de passation : présentée après l'interface native, l'interface corrigée permet de diminuer le nombre d'étapes effectuées (voisin du score optimal moyen qui est de 4,5 environ) et de fausses manipulations. En revanche, dans l'ordre inverse, l'utilisateur semble retomber dans les « pièges exploratoires » de l'interface originale, même après apprentissage du fonctionnement général du logiciel avec l'interface corrigée, et n'améliore plus son score ; on note par ailleurs que, s'il effectue un peu moins d'étapes et de fausses manipulations, celles-ci conduisent plus souvent à des erreurs que sur l'interface corrigée. Ce

« lissage » des scores observés lorsque l'interface corrigée est présentée en premier suggère que, indépendamment d'un effet d'apprentissage certain entre les deux tests, l'interface corrigée pourrait permettre de mieux percevoir le fonctionnement du logiciel, et donc d'orienter les scores vers ceux optimaux, même lors de l'utilisation de l'interface native.

Ces effets successifs sont probablement à mettre en lien avec l'évolution des remarques, à caractère négatif ou positif, verbalisées lors de la réalisation des tâches. Cette évolution tend à montrer que, si les sujets sont toujours plus enthousiastes à la découverte de l'application qu'au cours de sa seconde utilisation, ils semblent aussi avoir tendance à exprimer plus facilement les difficultés (déjà rencontrées ou non) sur lesquelles ils achoppent¹⁴. En seconde présentation, l'interface corrigée recueille ainsi moins de remarques négatives, et plus de remarques positives, que l'interface native. En revanche, on comptabilise moins de remarques positives pour cette interface en première utilisation ; nous n'avons pas effectué de tests de corrélation entre ces types de données, mais nous pouvons émettre l'hypothèse que, globalement, l'utilisateur « compense » ses remarques négatives avec d'autres plus positives ; et que dans le cas où la réalisation de la tâche ne soulève pas trop de difficultés, les commentaires (en « bien » ou en « mal ») se font plus rares.

Les commentaires relevés appuient finalement l'idée qu'une application peut être tout à fait efficace mais pour autant « mal aimée » si cette efficacité n'est pas adossée à d'autres critères, en particulier ergonomiques. Nous donnons en annexe E un aperçu d'une retranscription de la première rencontre d'un professeur d'intégration avec NAT (interface native). On remarque que l'utilisateur se rend souvent responsable de l'échec - mais aussi de la réussite - de la transcription, et blâme - ou félicite - rarement l'application elle-même.

Les figures en annexe F soulignent la complexité des chemins logiques (ou « attentionnels ») empruntés par l'utilisateur pour mener à bien les tâches proposées sur l'interface originale par rapport à ceux suivis sur l'interface corrigée. En particulier, la disposition des éléments de menus dans l'interface native n'incite pas l'utilisateur à vérifier ou modifier sa configuration avant de lancer le processus de transcription. De même, le participant ne fait pas le lien entre les messages de fin de traitement et l'utilisation de l'éditeur intégré, reporté en début de fenêtre et qui constitue pourtant la suite logique de la tâche de transcription. On comprend alors que les précisions demandées par NaT (sous formes de fenêtres supplémentaires) pour la transcription de texte en abrégé perturbent d'autant plus ce cheminement non-linéaire.

14 Tandis qu'on compte souvent moins d'une verbalisation à caractère « positif » par passation, celles « négatives » oscillent entre une et six.

Nous nous sommes appuyés, en parallèle de la première série de tests utilisateurs, sur le guide d'utilisabilité et le modèle d'inspection analytique (IA) proposés par Bastien et Scapin en 1996 pour tenter de dégager les problématiques inhérentes à l'interface étudiée (les résultats de cette inspection sont rapidement exposés en annexe G ; les vrais et faux, positifs et négatifs, ainsi que les « véritables ratés », y sont précisés). Nous avons retrouvé - par comparaison des résultats obtenus avec les remarques émises par les participants - les critiques développées dans la littérature vis-à-vis de ce type d'analyse : une précision accrue concernant les défauts de guidage et d'utilisabilité générale de l'application, tandis que des difficultés, parfois importantes, qui apparaissent à des étapes précises ne sont pas relevées. Il est fort possible que ce décalage entre les recommandations issues de l'évaluation experte et celles émises par les sujets proviennent de la tâche : tandis que le participant est placé dans une situation d'utilisation effective du logiciel, l'évaluateur, adossé au guide d'utilisabilité, s'attarde sur des problématiques de surface (ordre de présentation, complexité des réponses du système, utilité ou aspect de certains boutons d'interface). Il aurait donc peut-être fallu réaliser cette inspection dans le même cadre et avec le même objectif que les utilisateurs, ce qui aurait sûrement permis de relever plus de défauts présents « en profondeur » dans l'application.

Rappelons que les participants n'étaient soumis à aucun impératif d'efficacité ou de temps, hormis leurs propres contraintes écologiques, lors des différentes passations : celles-ci prenaient place sur leur lieu professionnel, en des moments libres de leur emploi du temps, et les tâches proposées étaient en relation plus ou moins directe avec des aspects de leur travail. Nous avons estimé que le but principal était, du point de vue de l'utilisateur potentiel, de parvenir à réaliser la tâche, voire de pouvoir participer activement, volontairement, à un projet dont il pense qu'il peut impacter son quotidien. Finalement, nous estimons que le participant exécute bien la tâche le plus rapidement et le plus correctement possible, mais selon son propre emploi du temps, et sa propre motivation. Du point de vue de l'expérimentateur, le but de la passation est de pouvoir cerner les raisons d'un éventuel défaut d'utilisabilité, et donc de laisser le participant explorer, autant qu'il le souhaite et comme il le souhaite, l'outil avec lequel il est amené à interagir - et qu'il est invité à « commenter ». De la même façon, nous avons estimé qu'il était sûrement peu probable que les futurs utilisateurs de NAT puissent avoir accès à une formation raisonnable sur ce logiciel, ce qui nous a incité à ne pas en faire de présentation, même succincte, en début de passation comme c'est le cas habituellement lors de tests d'utilisabilité. Nous avons imaginé, au contraire, qu'une présentation de ses fonctionnalités de la façon la plus simple qui soit pourrait permettre une prise en

main plus rapide et intuitive ; les nombreuses options de personnalisation de NAT (qui constitue, en ce sens, un logiciel extrêmement adaptable) devraient permettre par la suite d'ajuster le niveau d'expertise du logiciel à celui de son utilisateur. Dans le temps séparant les deux séries de tests, nous nous sommes donc attachés à la réorganisation du « système d'options » de NAT.

Les options de l'application permettent en effet de contrôler à la fois les règles de transcription utilisées, la mise en page appliquée, le format d'entrée et de sortie des documents, les options générales d'interface, et enfin les options avancées du logiciel. Sur l'interface native, il s'est avéré que les utilisateurs montraient de grandes difficultés à comprendre la signification des « configurations » proposées par défaut (dites configurations système). Or, à peu de choses près, une configuration enregistre ensemble tous les paramètres décrits précédemment (cf. figure 8) : l'application testée présentait ainsi onze configurations système différentes, quand les recommandations ergonomiques en préconisent douze au maximum.

On note que la présence de l'« ascenseur » à droite de l'élément d'interface n'est pas toujours remarquée, et que certaines configurations deviennent alors invisibles pour l'utilisateur. Plusieurs termes n'étaient pas compris des sujets (« mep », « césure », « UTF8 », « 30x27 »...). Par ailleurs, sur l'interface native, les options de chaque groupe sont réparties en plusieurs onglets (huit) dans le menu d'options ; et modifier certains items d'un onglet entraîne des modifications sur d'autres onglets. Par exemple, choisir « Aucune mise en page » dans l'onglet « 1. Général » modifie le titre

et les options disponibles de l'onglet « 3. Mise en Page ». Plus généralement, le choix de présentation des options et leur activation par défaut tendent à montrer que NAT a été conçu dans une optique d'utilisation experte. La majorité des contributions utilisateurs ordinaires (recueillies à distance via le réseau) proviennent d'ailleurs de spécialistes en transcription braille - voyants ou non - et en informatique. Dans ce contexte, l'utilisateur non expert de l'un ou l'autre domaine, désireux de se confronter à ce type d'outil, se retrouve littéralement en situation de... handicap.

Cet utilisateur devrait pouvoir, en fonction des règles de transcription, de mise en page, et de

format, construire et enregistrer une ou plusieurs « configurations utilisateur », qu'il rappellera

ultérieurement en fonction de la tâche à réaliser. Pour ce faire, nous avons d'abord classé, en lien

avec l'équipe de développement, les variables contrôlées par les options de NAT en cinq groupes :

Nous avons ensuite fait le lien entre chaque variable et chaque proposition du menu d'options existant, puis nous avons classé ces propositions de façon "logique" (par exemple, en tenant compte de leur caractère « basique » ou « avancé ») dans chacun de ces cinq groupes.

Fonctionnellement, l'utilisateur pourra créer et modifier ses règles de transcription ou de mise en page (sortes de « sous-configurations »), puis les mélanger pour créer une ou plusieurs configurations de base. Dans ce cas, il peut aussi plus facilement créer « à la volée » une configuration précise, pour une tâche atypique par exemple. De plus, il est renseigné sur ce qui impacte directement le résultat de sa transcription, séparé de ce qui concerne son « environnement » de travail, puisque les options d'interface (taille des fenêtres, accessibilité...) et avancées (gestion des fichiers temporaires...) n'influent pas sur le résultat final fourni par NAT. Nous obtenons finalement la conversion des huit onglets du « système d'options » du logiciel en trois fenêtres de paramétrages (Mode de transcription, Mise en page et Formats : cf. figure 9), qui apparaissent à la demande de l'utilisateur en tant que « détails d'une configuration », et deux fenêtres d'options (d'interface et avancées).

Le mode (intégral, abrégé, mathématique) peut ainsi être combiné facilement avec la mise en page (aérée, basique, compacte) et le format (WindowsTM ou LinuxTM) pour la création de la configuration voulue. Plutôt que de décrire ces quelques paramètres dans la liste de choix déroulante, on préfère inciter l'utilisateur à découvrir par lui-même leur édition dans les fenêtres correspondantes, et donc à explorer plus avant les possibilités offertes par NAT. En annexe H sont reportés les dessins techniques finaux proposés pour les fenêtres principales, d'éditeurs et d'options.

Nous avons donc pu mettre en évidence des défauts d'utilisabilité importants de l'application testée. Les défauts de surface ont renvoyé à des problématiques plus « profondes » concernant le fonctionnement global, qui nous ont amené à revoir le paramétrage du logiciel. Cependant, du point de vue du développement, cette réorganisation implique un enregistrement des paramètres, leur prise en compte lors des calculs, et enfin leur présentation par le biais de l'interface, très éloignés de l'implémentation actuelle. Comme le prévoyait la littérature dans ce domaine, ces modifications, préconisées trop tardivement dans le processus de développement de l'application, se sont avérées très gourmandes en codage informatique et en temps. Cette suggestion - qui s'apparente plus à du « design d'interaction » qu'à de l'« ergonomie logicielle » -, ainsi que d'autres recommandations issues de l'inspection analytique ou des tests utilisateurs, avaient donc peu de chances d'être mises en place sur l'interface corrigée dans le temps imparti. Si les modifications de surface préconisées sur la fenêtre principale ont pu être en partie implémentées, en revanche les remarques concernant la gestion des erreurs ou l'uniformisation des différentes fonctionnalités de l'application n'ont pas pu, faute de temps, voir le jour. La refonte du paramétrage et des options, qui implique de modifier

plus profondément l'implémentation actuelle de NaT, constituait selon nous un aspect critique de la perception du fonctionnement du logiciel et de son utilisabilité ; cette modification a donc été émulée dans la version corrigée (la fonctionnalité est visible sur l'interface, mais non implémentée dans le code).

Si NAT v. 2.0 est sans conteste une des solutions de transcription braille automatisée les plus efficaces et les plus puissantes éditées à ce jour, il reste que l'utilisation efficiente et satisfaisante de ses fonctionnalités - toujours plus nombreuses, en particulier à la demande de ses utilisateurs actuels - ne pourra se faire sans une refonte approfondie de son interface graphique et de ses principes d'interaction avec l'opérateur humain. Une prise en compte plus exhaustive et « anticipatrice » des possibilités d'erreurs, une gestion unifiée et précise des fenêtres de dialogue et des messages système, l'uniformisation globale de la sémantique, de la charte graphique et de l'emploi des icônes, enfin et surtout, l'implémentation d'un véritable éditeur intuitif, sont les défis à relever pour que NAT puisse bénéficier du succès et de la popularité qu'il est indéniablement en droit d'attendre.

Abhishek, & Basu, A. (2006). Iconic interfaces for assistive communication. (Indian Institute of Technology, Kharagpur, India). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 295).

Archambault, D. (2010). Interaction et usages des modalités non visuelles, accessibilité des

contenus complexes. Mémoire de synthèse pour l'obtention de l'Habilitation à Diriger les Recherches. Université Pierre et Marie Curie ; Paris VI. France.

Bach, C., & Scapin, D. L. (2005). Critères ergonomiques pour les interactions homme-environnements virtuels : définitions, justifications et exemples. Rapport de Recherche n° 5531. Institut National de Recherche en Informatique et en Automatique, Rocquencourt, France.

Bastien, J. M. C., & Scapin, D. L. (1993a). Ergonomic criteria for the evaluation of human-computer interfaces. Rapport Technique n° 156. Institut National de Recherche en Informatique et en Automatique, Rocquencourt, France.

Bastien, J. M. C., & Scapin, D. L. (1996). Inspection d'interfaces et critères ergonomiques. Rapport de Recherche n° 2901. Institut National de Recherche en Informatique et en Automatique, Rocquencourt, France.

Bobillier-Chaumon, E., Carvallo, S. Tarpin-Bernard, F., & Vacherand-Revel, J. (2005). Adapter ou uniformiser les interactions personnes-systèmes ? Revue d'interaction homme-machine, Vol. 6, n° 2, 2005.

Christou, G. S. (2006). The use and evolution of affordance in HCI. (Cyprus College, Cyprus). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 668).

Danielson, D. R. (2006). Usability barriers. (Standford University, USA). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 652).

Ferre, X., Juristo, N., & Moreno, A. M. (2006). Obstacles for the integration of HCI practices into software engineering development processes. (Universidad Polytécnica de Madrid, Spain). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 423).

Henley, M., & Noyes, J. (2006). Traditional vs. pull-down menus. (Flow Interactive Ltd., London,

UK et University of Bristol, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 622).

Karoulis, A., Demetriadis, S., & Pombortsis, A. (2006). Cognitive graphical walkthrough interface evaluation. (Aristotle University of Thessaloniki, Greece). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 73).

Knight, J., (2006). Engagability. (University of Central England, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 197).

Mascret, B., Mille A., & Ollier M. (2008). Un transcripteur braille idéal ? Conférence Handicap, Paris.

Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Retrieved March, 13, 2010 from Jakob Nielsen's Alertbox web site :

Singh, S., & Dix, A. (2006). Software engineering and HCI. (University of South Africa, South Africa, et Lancaster University, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 549).

Sperandio, J.-C. (2007). Concevoir des objets techniques pour une population normale, c'est-à-dire comprenant aussi des personnes handicapées ou très âgées. PISTES, Vol. 9, n° 2.

Thoumie, P. (2004). Recherche technologique et diffusion de l'innovation au service du handicap. Rapport public de mission de réflexion. Secrétariat d'État aux personnes handicapées ; ministère de la recherche et des nouvelles technologies ; France. Retrieved January, 27, 2010 from La Documentation Française, Bibliothèque des rapports publics web site : http://www.ladocumentationfrancaise.fr/rapports-publics/044000064/index.shtml

Uzan, G. (2005). Ergonomie cognitive du handicap visuel : une contribution à la conception d'aides informatiques. Thèse de Doctorat. Université René Descartes ; Paris V. France.

Woolrych, A., & Hindmarch, M. (2006). Understanding and improving usability inspection

methods. (University of Sunderland, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 641).

Brangier, E., & Barcenilla, J. (Eds.) (2003). Concevoir un produit facile à utiliser. Adapter les technologies à l'homme. Editions d'Organisation.

Nogier, J.-F. (2008). Ergonomie du logiciel et design web : le manuel des interfaces utilisateur. Dunod, collection InfoPro.

Valléry, G., Le Port, M.-C., Zouinar, M. (Eds.) (2010). Ergonomie et conception de produit et de services médiatisés. Presses Universitaires de France.

ANNEXES

Annexe A

Le braille est un système d'écriture tactile inventé en 1829 par Louis Braille, qui reprend et améliore le « code Barbier » utilisé dans l'armée napoléonienne pour la communication écrite de nuit. Le code braille est basé sur une matrice de six points, dite cellule braille :

En élevant ou abaissant les points saillants, on obtient ( 2⁶ - 1 ) = 63 combinaisons, codant pour les caractères de l'alphabet, les chiffres, la ponctuation ; les associations de points restantes permettent de coder certains caractères spéciaux ou certains indicateurs (« @ », « % », signe d'italique, majuscule, etc.). Par convention, on numérote les points braille du haut vers le bas, de gauche à droite. La lettre « é » est ainsi codée par les points [1,2,3,4,5,6] tandis que la lettre « a » est codée par le point [1], la lettre « b » par les points [1,2]... :

Les points [4,6] sont utilisés pour indiquer que la lettre suivante sera majuscule ; ils ne codent pour aucune lettre en braille intégral. En braille dit abrégé, ces points servent à contracter le son / eur /, sauf en début de mot :

L'expression mathématique plus haut peut aussi se coder, cette fois à l'aide du braille mathématique :

Il est nécessaire d'indiquer, à l'aide de caractères spécifiques, qu'il s'agit d'une expression mathématique (avec le point [6]) puis qu'un chiffre est en exposant (à l'aide du point [4]).

On comprend alors que, si les caractères restent identiques d'un type de braille à l'autre, en revanche leur transcription et leur dé-transcription nécessitent des étapes d'interprétation des expressions qui vont au-delà du simple transcodage « caractère à caractère ».

Annexe B

Les performances sont meilleures lorsque l'information est présentée sous une forme directement utilisable.

Annexe C

Se référer à la figure 9. pour la présentation des détails de la configuration.

Annexe D

« Dans le cadre de votre travail avec un élève déficient visuel, nous allons imaginer que vous souhaitez :

Annexe E

« Je vais tenter, mais là, je vais cliquer au pif. » 04:10 « Non, je ne sais pas, là. »

04:34 « Pourquoi en abrégé, où est-ce que je lui ai demandé de transcrire en abrégé, je me suis trompée ? »

04:40 « Houlà ; intégral aérée, basique ou compacte alors là ça se complique hein ; ya pas intégral tout court ? »

12:17 Ouverture boîte de dialogue Mots en intégral. « Non, je me suis trompée. »

« Vous ne l'aimez pas, en fait, cette fenêtre ? » : « Non, pas du tout ! »

« Pourquoi ? » : « Je ne sais pas... elle ne me plaît pas parce que je ne la comprends pas. »

18:04 « Ah mais c'est pas dans le bon sens, ça ; je peux le changer, ce truc ? » (survol de la flèche)

Annexe F

« Chemins logiques» empruntés sur les deux interfaces en fonction des tâches
1) Sur interface originale

Chemin parcouru sur l'interface native pour la réalisation des tâches 1) et 2). Les carrés signalent des opérations supplémentaires pour la tâche 2).

r=ontigu ration active : Abrégré aérée 43,0r" , césure,
· en bas, mep aérée]

TM erreur d'entrée sortie lors de la vérif dan de l'existence d'une mise àjour

Iw[jr~w Çontiguralion active: II4i Détranscrenron{Con 6 pour la Détranscription) lm^,

erreur d'entrée sortie lors de la vérification de l'e. tente d'une mise àjour

Chemin parcouru sur l'interface corrigée pour la réalisation des tâches 1) et 2). Les carrés signalent des opérations supplémentaires pour la tâche 2).

Le trait pointillé signale une opération optionnelle (détails de la configuration).

_rês. Çonfi gurati on active: I _-" Détrans cri lotion (Configurut
· pour la Détranscriptionj .

Chemin parcouru sur l'interface corrigée pour la réalisation de la tâche 3).
Le trait pointillé signale une opération optionnelle (détails de la configuration).

Annexe G

( Faciliter la navigation, indiquer le mode ou l'état en cours ) Sens de transcription : flèche

La fonctionnalité du bouton n'est pas évidente. Le tag de l'élément désigne le résultat de l'action sur cet élément. Les noms de fichiers dérivés peuvent devenir confus.

La liste est trop complexe (voir concision). Les abréviations utilisées ne sont pas évidentes (ex. : « mep ») (voir signifiance des codes / compatibilité). Les types d'informations fournies varient d'une configuration à l'autre.

Les critères ergonomiques recommandent de donner un titre à chaque fenêtre à l'intérieur d'une application. Ce critère favorise le repérage du « chemin logiciel » parcouru par l'utilisateur (analogie avec les chemins des menus Web).

Pas de « scénario » clairement présenté (présentation temporelle / spatiale).

Les actions sont présentes sur la fenêtre principale, mais l'utilisateur peut ne pas comprendre leur relation dans la tâche, ou que d'autres outils sont disponibles : éditeur, embossage, dé-transcription... Une fois la transcription terminée, rien ne lui indique la suite des actions possibles ou nécessaires à entreprendre (voir feedback).

Par ailleurs, il faudrait pouvoir distinguer les actions « primaires » (transcrire, inverser le sens...) de celles optionnelles (options...) (voir groupement / distinction).

1.2. Groupement / distinction par le format ou le groupement ( Arrangement, positionnement, distinction des items )

On pourrait grouper les items « Ouvrir les fichiers... » et les items « Ouvrir les transcriptions... ». L'item d'Options est mal placé ; dans l'interface actuelle, il participe plus du groupe « Transcrire » que du groupe « Configurations » auquel il devrait se rapporter.

Les items de champs d'entrée, de commandes ou d'informations sont bien distingués entre eux. On pourrait jouer sur la forme / la couleur pour mieux différencier ces items et les groupes d'actions auxquels ils appartiennent.

( Information instantanée de l'utilisateur sur le résultat de ses actions ) Le feedback général de la fenêtre principale respecte les recommandations. (Véritable Raté)

(Le choix de la configuration peut entraîner un traitement plus long, qui n'est pas renseigné. L'utilisateur pense alors que son action n'est pas prise en compte et réitère son choix...).

Le renseignement des états de traitement fait partie des recommandations de feedback. La qualité lexicale du retour de cette fenêtre n'est pas satisfaisante, employant trop de termes techniques qui renseignent peu l'utilisateur. Par défaut, la verbosité est trop élevée, le message final est « noyé ». On peut mieux mettre en valeur le dernier message d'état final des traitements attendu par l'utilisateur.

S'il existe un feedback pour les actions précédentes, il n'y a pas suffisamment d'incitation à la réalisation d'étapes supplémentaires (ex. : ouvrir le fichier transcrit dans l'éditeur, embosser...) (voir incitation).

( Caractéristiques lexicales et typographiques : caractères, mots, phrases ) La lisibilité de la fenêtre principale est globalement très bonne.

Certains tags d'items sont un peu longs : « Sélectionner le fichier en noir », « Sélectionner le fichier en braille » sont redondants avec le tag du champ d'entrée : « Document en noir : », « Document en braille : »... et pourraient être regroupés sous une rubrique : « Sélectionner : » « Fichier noir », « Fichier braille » (voir : concision).

Les recommandations de lisibilité rappellent que le titre des fenêtres devrait être centré. (Faux Positif)

( Les entrées courtes limitent les risques d'erreurs ; les items succincts sont mieux lus )

Les items pertinents de la fenêtre principale sont présentés de façon succincte, sauf peut-être en ce qui concerne les entrées de fichier (voir : lisibilité).

À mon sens, le manque de guidage explicite pour les scénarios de transcription braille basiques et pour la découverte des possibilités offertes par le logiciel ne permettra pas de remplir ce critère. Les utilisateurs seront amenés à opérer dans le cadre d'essais-erreurs qui augmenteront le nombre final d'actions nécessaires.

(Charge de travail prise du point de vue des ensembles d'éléments et non du point de vue des items)

En particulier : « limiter la densité informationnelle de l'écran, en affichant seulement les items nécessaires ». On pourrait observer que les items « Rapport de bug », « Quitter », « Aide », « À propos », présentés comme d'importance équivalente (du moins dans la forme) aux actions principales, peuvent être considérés comme « superflus ». Ces items pourraient conserver leur place actuelle dans les menus déroulants du haut de l'interface.

Comme souligné plus haut, il y a redondance informationnelle entre les tags « Document en noir/braille » des champs d'entrée et ceux « Sélectionner le document en noir/braille » des boutons d'action.

( Le système effectue uniquement les opérations demandées, au moment où elles sont demandées ) Pas de problématique rencontrée.

( L'utilisateur doit pouvoir contrôler le déroulement des traitements informatiques en cours )

La fenêtre principale de NAT respecte les recommandations portant sur le contrôle utilisateur, à l'exception notable que l'utilisateur ne peut interrompre (Annuler) le traitement en cours d'une transcription...

( Capacité de l'interface à s'adapter à des actions variées de l'utilisateur )

NAT permet la réalisation d'une même tâche à l'aide de chemins variés (raccourcis système, menus déroulants, items d'interface...). Il suit donc les recommandations générales dans ce domaine.

NAT permet d'obtenir la réalisation de certaines tâches à l'aide du menu traditionnel, conçu pour un guidage « pas à pas », ou par l'intermédiaire de raccourcis pour l'appel direct de certaines fonctionnalités. On peut cependant observer que le logiciel, en l'état, est présenté pour une utilisation résolument experte dans les choix de présentation des options et des configurations, et dans les critères présentés par défaut.

( Moyens de prévenir les erreurs d'entrée, de commandes, ou les actions néfastes )

(Les erreurs d'enregistrement, de saisie d'extensions de fichiers, de noms de fichiers erronées ne sont pas ou très peu prises en compte par le système).

( Pertinence, facilité de lecture et exactitude des informations sur les erreurs commises )

Quelques messages restent surprenants : par exemple, il est question de « droit d'accès » lors de l'annulation d'un remplacement de fichier ; l'utilisation de la fenêtre de rapport de bug conseille de joindre le fichier de log (ou le document de travail ?) mais n'indique pas comment... Par ailleurs, les champs de cette fenêtre pourraient être pré-remplis par défaut ?

Recommandations : « fournir la possibilité de corriger la portion de données ou de commandes erronées »...

Note : même si le critère « Actions Minimales » ne concerne pas les procédures de gestion des erreurs, les problèmes liés à ce critère peuvent résulter de mécanismes de correction d'erreurs inadéquats.

( Conservation, ou non, des choix d'interface pour des contextes identiques ou différents )

( Les codes et significations doivent disposer d'une relation sémantique forte avec leur référent )

Pas de problématique rencontrée, mises à part les caractéristiques des configurations proposées ( ex. : « mep » ).

( Les performances sont meilleures lorsque l'information est présentée sous une forme directement utilisable )

Les problématiques rencontrées participent plus des critères de « Guidage », de « Flexibilité » ou de « Prise en compte de l'expérience » que de « Compatibilité ».

Annexe H

Dessins techniques pour le prototype d'interface corrigée de NAT Braille v. 2.0.

La première planche présente la fenêtre principale de l'application, et son évolution au cours d'une tâche de transcription. Nous avons imaginé faire précéder cette fenêtre d'une petite « fenêtre d'introduction », qui pourrait être désactivée plus tardivement dans l'apprentissage du logiciel. Son intérêt est de proposer directement au lancement de l'application les différentes fonctionnalités principales de NAT.

Concernant les fenêtres de paramétrages et d'options, la forme retenue est celle du menu latéral tel que décrit pour le « Mode de Transcription ». Pour des raisons de gain de place et de vue d'ensemble de la logique de tri, nous avons conservé une autre forme de présentation, non retenue (menu « déroulant » ou « déployable ») telle que dessinée pour « Options d'Interface ».