Td corrigé Chapitre 4 (style : Chapitre) - L'UTES pdf

Chapitre 4 (style : Chapitre) - L'UTES

Calculer la vitesse de rotation du moteur en charge : - par une méthode graphique. - par un calcul algébrique. En déduire le courant d'induit et la puissance utile ...




part of the document



Chapitre 10
Interfaces en EIAH
10.1. Introduction
Concevoir l’interface d’un système interactif est une entreprise complexe. Par interface, nous ne désignons pas seulement ce que le système affiche sur un écran mais nous adoptons la définition de Raskin [RAS 00] qui lui donne un sens plus large et voisin de « interaction » : « La façon dont vous accomplissez les tâches avec un produit, ce que vous faites et comment il réagit, voilà ce qu’est l’interface ». Depuis une vingtaine d’années les recherches en IHM ont permis la mise au point d’outils conceptuels et techniques pour guider et assister les concepteurs. L’historique de ce champ de recherches est hors de notre propos (Cf. par exemple [DOU 01], [CAL 02]) mais l’évolution du sigle en donne un aperçu. Dans les années 70-80, quand il s’agissait de rendre les machines plus faciles à utiliser avec l’apparition des premières interfaces graphiques, IHM signifiait « Interfaces Homme Machine ». Il est maintenant généralement décliné en « Interaction Homme Machine » indiquant ainsi que l’interface physique n’est que le sommet de l’iceberg dans les relations entre humains et ordinateurs. On rencontre quelques fois « Interactions Humains Machines » pour prendre en compte les activités collaboratives et les communications entre humains médiées par des machines en réseaux. Plus récemment, Grumbach [GRU 02] a proposé « Interactions des Humains avec des Mondes » pour indiquer que de plus en plus d’informatique est embarquée dans des objets physiques et qu’avec les concepts de réalité augmentée, d’interfaces tangibles, d’informatique disséminée, les frontières entre le « réel » et le « virtuel » tendent à s’estomper. Notons aussi que, à l’instar du sigle EIAH, le sigle IHM désigne ainsi à la fois le domaine de recherche et les artefacts construits en appliquant les méthodes et les outils issus de ce domaine.
La plupart des résultats en IHM n’ont pas été établis dans un contexte d’éducation ou de formation, mais nous estimons qu’ils sont pertinents pour la conception des EIAH. A travers un survol de différents travaux, l’objectif de ce chapitre est de montrer ce que les acquis des recherches en IHM et de « l’ingénierie des systèmes interactifs » [KOL 01a, b, COU 96] apportent à la conception des EIAH. Après avoir situé l’importance de l’IHM en EIAH, le sujet étant très vaste, nous nous limitons ici à trois aspects qui nous apparaissent particulièrement significatifs : tout d'abord la prise en compte des différents utilisateurs dans la démarche de conception d'un EIAH, puis certaines méthodes de conception développées en IHM et enfin nous évoquons les problèmes liés à l’évaluation.
10.2. Importance de l’IHM en EIAH
« Pour les utilisateurs de logiciels, l’interface est tout ce qu’ils voient du produit et, pour un certain nombre d’entre eux, le produit se réduit à son interface, pour le moins tant qu’il fonctionne conformément à leurs attentes » [RAS 00]. Les propos suivants, recueillis auprès de professeurs d’école stagiaires lors de formation à l’utilisation de logiciels de bureautique, illustrent cette constatation : «  j’ai sauvé dans ma disquette, dans Word enfin sur l’écran… », « pour moi c’est juste des informations au niveau de l’écran mais après ce qui se passe dans l’ordinateur… », « tu surlignes » (tu sélectionnes), « tu fais la croix » (tu fermes la fenêtre) etc. [NOR 01]. 
La conception de l’interface d’un EIAH n’est donc pas une opération cosmétique que l’on peut reléguer en fin de conception quand les problèmes d’ingénierie pédagogique, d’architecture pédagogique et d’interopérabilité sont réglés. C’est un processus étroitement couplé au processus de conception de l’EIAH et aux situations d’usage de cet EIAH. Ainsi, comme pour tout système interactif, en EIAH concevoir un logiciel « utilisable » pose des problèmes d’ordre cognitif, organisationnel et social. La spécificité des EIAH concerne les problèmes pédagogiques et didactiques. Pour l’appréhender, nous retenons ici trois approches : les approches épistémologiques, les approches instrumentale et médiationnelle et, enfin, l’approche sociale. Nous concluons cette section par une discussion sur la spécificité des interactions en EIAH. Au préalable arrêtons nous un instant sur le concept d’utilisabilité.
10.2.1. L’utilisabilité
Ce concept est né de la prise de conscience des difficultés d’utilisation des logiciels même lorsque leur interface se dit « conviviale ». Pour Senach [SEN 93], « L’utilisabilité sert à poser la frontière entre l’utilité réelle et l’utilité potentielle ». Dans cette optique, l’utilité concerne l’aspect fonctionnel d’un logiciel interactif i.e. la présence de fonctionnalités prévues dans le cahier des charges, alors que l’utilisabilité concerne l’aspect opérationnel i.e. la possibilité pour les utilisateurs finaux d’utiliser aisément ces fonctionnalités dans leur contexte habituel.
Cette notion a pris une telle importance en IHM qu’elle a été définie dans une norme (norme ISO 9241-11, 1998) : l’utilisabilité « est 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é ». Cette définition est plus large que la seule facilité d’utilisation et prend en compte également l’utilité et l’acceptabilité du produit. Elle met en évidence que l’utilisabilité n’est pas une qualité intrinsèque de l’artéfact mais est relative à un usage dans un certain contexte. Bastien et Scapin [BAS 01] proposent l’expression « qualité ergonomique d’un logiciel » pour éviter de restreindre le concept à la seule manipulation de l’interface.
Certains auteurs ajoutent une troisième composante qui est qualifiée d’accessibilité universelle pour tenir compte soit des personnes à besoins spécifiques comme les handicapés, les minorités (on parle alors de conception inclusive [BRA 03]), soit de la diversité des dispositifs d’interaction comme les stations de travail, portable, téléphone, PDA (on parle alors de plasticité des interfaces [CAL 02]). Coutaz définit ainsi la règle des 3U : Utilité, Utilisabilité et Universalité [COU 96]. D’autres auteurs estiment artificielle cette distinction entre utilité et utilisabilité ; ils insistent pour la prise en compte d’autres facteurs que les facteurs cognitifs et organisationnels, par exemple les facteurs identitaires, affectifs ou esthétiques ; certains utilisent alors l’expression « expérience utilisateur », par exemple [KUN 03].
Il nous semble que l’utilisabilité est un objectif à prendre en compte pour la conception des EIAH. Dans le sens large défini par la norme ISO, l’utilisabilité peut s’interpréter en EIAH comme facilité d’utilisation (utilisabilité) mais aussi à l’adéquation du logiciel aux objectifs d’apprentissage (utilité) pour un public cible donné dans un contexte donné (acceptabilité) [TRI 03].
10.2.2. Apprentissage, EIAH et interface
D’après Balacheff [BAL 94], pour un apprenant travaillant avec un EIAH, l’interface est le lieu où il observe des phénomènes, les étudie, les utilise et utilise ses connaissances pour donner du sens à ce qui est « montré » par la machine. C’est donc le lieu de l’interaction qui s’établit avec la machine à propos d’un contenu, c’est-à-dire de connaissances et informations contextualisées de façon formelle dans le système, contenu présenté sous forme de textes, d’images, de sons, de simulations et sur lesquelles l’apprenant peut agir grâce aux dispositifs techniques de l’interface. Balacheff appelle « transposition ou transmutation informatique » les transformations des différents modèles de connaissances lorsqu’ils sont représentés dans un langage informatique et à l’interface du système. Ce concept conduit à s’interroger sur la nature des significations rendues possibles par les propriétés des systèmes de représentation qui sont mis en œuvre par les logiciels. La conception d’interface pose ainsi des problèmes de validité épistémologique et didactique en particulier pour déterminer les variables sur lesquelles jouer pour que les connaissances construites par l’apprenant évoluent vers la connaissance instituée. Le chapitre 2 et les travaux autour de Aplusix (Cf. chapitre 15) et de Cabri (Cf. Chapitre 16) se situent dans cette problématique.
10.2.3. Interagir avec des artefacts : approches instrumentales et médiationnelles
D’autres auteurs (e.g. [HOY 97, GUI 02]) donnent des exemples de la façon dont des apprenants se construisent des outils mentaux en interagissant avec un dispositif technique, outils qu’ils utilisent en dehors du logiciel alors que ces outils n’étaient pas du tout anticipés par les concepteurs. Ces utilisations non prévues d’outils ne sont pas propres aux situations d’apprentissage. Elles sont appelées catachrèses par Rabardel [RAB 95] qui ne les considère pas comme des détournements d’usage mais comme des « indices du fait que les utilisateurs contribuent à la conception des usages des artefacts » et que le sujet se construit des « moyens adaptés en vue des fins qu’il poursuit, de l’élaboration d'instruments destinés à être insérés dans son activité en fonction de ses objectifs ». Selon cette approche, les usagers et, a fortiori, les apprenants, sont des sujets actifs qui cherchent à donner un sens à la situation d’interaction avec l’interface et imposent leurs perspectives.
Par exemple, Decortis et al. [DEC 01] montrent que, lors d’expérimentation de Pogo un système de création collective d’histoires par de jeunes enfants, les instruments modifient les différents processus d’exploration, de création, de partage des histoires et permettent de créer des histoires plus riches.
10.2.4. Interagir avec d’autres au travers d’artefacts
Si par exemple l’apprenant suit une formation en ligne c’est aussi le lieu où il interagit avec l’institution de formation, avec des tuteurs, avec d’autres apprenants, éventuellement avec des professionnels. Les recherches dans le domaine du Computer Supported Collaborative Learning (CSCL) montrent l’importance des ces relations pour les apprentissages. Reprenons l’exemple de Pogo [DEC 01], l’environnement a provoqué une diversification des rôles qui a permis une meilleure participation. En particulier, des enfants se sont spécialisés dans un rôle de technicien qui les oblige à suivre et mémoriser l’histoire alors qu’ils étaient inactifs dans des activités habituelles.
De plus ce qui est « montré » par la machine est le résultat d’une intention d’un (ou plus souvent d’une équipe de) concepteur(s) que ce soit les concepteurs d’un logiciel d’apprentissage spécifique, du dispositif de formation ou de ressources conçues en dehors de l’objectif de formation. Pour Pochon et Grossen [P0C 97], dans un dispositif d’apprentissage « l’interaction implique à un titre ou à un autre de nombreux acteurs, réels ou virtuels, présents ou absents, et donne ainsi lieu à un espace interactif.(…) Un ordinateur est un objet technologique sur lequel concepteurs et utilisateurs projettent des présupposés relevant de leurs propres présupposés, attentes, normes, valeurs. Dans cette perspective l’interface peut être considérée comme un concentré de cultures, puisqu’elle est le résultat d’un long processus à la fois technologique et social.».
10.2. 5. Spécificité des IHM en EIAH ?
Dourish [DOU 01] estime que : « l’IHM comme l’Intelligence Artificielle se préoccupe de formalisations des connaissances et de l’activité humaine ». Pour Tchounikine [TCH 01] l’ingénierie des EIAH quant à elle se préoccupe également de produire de telles formalisations mais aussi d’étudier le rapport entre les mises en œuvre de ces formalisations et l’évolution des connaissances et de l’activité des humains qui les manipulent. Ces deux citations mettent en évidence une certaine convergence des préoccupations entre les deux champs de recherche mais cependant, avec des orientations différentes.
Les travaux en IHM sont orientés vers la conception d’artefacts supportant des acteurs très divers dans leur activité professionnelle ou dans leur activité liée à la vie quotidienne (achat en ligne, téléphonie mobile, domotique etc.). Les EIAH concernent plusieurs types d’acteurs que l’on peut sommairement séparer en deux catégories : les apprenants et ceux que nous qualifierons de facilitateurs d'apprentissage que sont les enseignants, formateurs, tuteurs, concepteurs pédagogiques, voire les gestionnaires et techniciens. Pour les acteurs « facilitateurs », les EIAH ont aussi pour objectif de supporter leur activité professionnelle et les applications IHM sont ainsi donc directes. En ce qui concerne les apprenants, les travaux en EIAH sont orientés vers la conception d’artefacts destinés à favoriser des apprentissages. Burkhardt et Wolf [BUR 02], s’intéressant plus particulièrement à la formation professionnelle, distinguent les situations de formation reposant sur des méthodes analytiques ou fractionnées où le travail est fractionné en unités élémentaires qui sont apprises indépendamment d’abord avant d’être reliées et celles reposant sur des méthodes globales (apprentissage sur le tas, simulation) où le sujet est confronté à une situation de travail (réelle ou simulée). On rencontre ainsi deux points de vue selon les situations d’apprentissage considérées.
Le premier point de vue, défendu par exemple par Vivet [VIV 96] et Tricot [TRI 03], estime qu’un apprenant n’est pas un utilisateur comme les autres car il poursuit en permanence deux objectifs : la réalisation d’une tâche (de production d’un objet, de résolution de problème, de coopération etc.) et l’apprentissage (d’un concept, d’un savoir–faire, d’une méthode, de compétences etc.). Une dialectique permanente, subtile et complexe entre ces deux objectifs est à l’œuvre dans son activité [DEL 01]. La réalisation de la tâche est souvent une des conditions de l’apprentissage, par exemple dans les pédagogies de projet, la formation « sur le tas » ou l'apprentissage par la résolution de problèmes. Mais la performance du couple Humain-Machine dans la réalisation de la tâche n’est pas toujours le seul critère de succès pour l’objectif d’apprentissage. Par exemple, Corbett et al. [BAK 04] montrent que lors d’une expérimentation 10 % des élèves ont utilisé les aides pour piéger le système tutoriel et réussir les exercices proposés sans apprendre, alors même que ces aides se sont avérées capitales pour favoriser l’apprentissage de l’ensemble des autres élèves.
Ainsi, dans cette optique, pour que l’apprentissage ait lieu, l’application ne doit pas trop faciliter la tâche de l’élève mais au contraire lui laisser des défis à relever. Ce point de vue se rencontre plutôt auprès de concepteurs d’EIAH de type tutoriel ou environnements de simulation qui visent des apprentissages assez spécifiques dans des institutions (écoles, universités ou formation professionnelle) et conçoivent des applications qui prescrivent à l’apprenant des tâches dont les caractéristiques ont été spécifiées pour faciliter sinon provoquer ces apprentissages.
Un autre point de vue, ne distingue pas situation d’apprentissage et situation de travail. Il est soutenu principalement par les tenants de la cognition située lorsque les apprentissages sont issus de l’expérience de la vie quotidienne ou dans l’activité professionnelle, souvent collective. Par exemple, Goodyear [GOO 99] estime que si l’approche précédente est intéressante dans un certain nombre de cas, il est souvent beaucoup plus fructueux de considérer l’apprenant comme un « travailleur de la connaissance ».
D’une part, Goodyear s’appuie sur des études qui montrent que, dans l’ensemble, les étudiants n’utilisent pas plus les excellentes ressources interactives à leur disposition qu’ils n’allaient à la bibliothèque bénéficier des excellents livres mis à leur disposition. Au lieu de coupler les logiciels avec une tâche prescrite que les étudiants ne réalisent que si on les y oblige, il propose de faire des logiciels qui les assistent dans leurs activités et développent leur autonomie. Par exemple, au lieu de concevoir un tutoriel qui apprenne aux étudiants à faire une recherche bibliographique, Twidale et Nichols [TWI 98] se sont aperçus que les étudiants faisaient leur recherche à deux ou trois autour de l’ordinateur et ils ont reconçu l’interface de consultation du centre de documentation pour faciliter les interactions à plusieurs. D’autre part, Goodyear souligne que, dans la perspective d’apprentissage tout au long de la vie, les apprenants sont de plus en plus des gens très qualifiés et très sollicités qui ont besoin d’apprendre dans l’action. Un exempleprésenté par Clancey [CLA 04] étaye cette approche : les astronautes de la NASA qui sont les gens parmi les plus diplômés de la planète apprenent à coopérer avec un agent virtuel en prévision de futurs voyages sur Mars selon la métaphore du « coach in your ear » . Le coaching humain est impossible à une telle distance et l’objectif est ici d’améliorer la performance du couple humain/robot, la situation d’apprentissage est la situation de travail elle-même.
Dans ces situations d’apprentissage qui sont des situations de travail, les problématiques IHM et EIAH sont indissociables. Dans les situations crées spécifiquement dans l’objectif de faciliter des apprentissages, la facilité d’utilisation du logiciel par l’apprenant est subordonnée à cet objectif.
10.3. La prise en compte des utilisateurs dans la conception
Tous les processus de conception d’IHM se réclament de la conception centrée utilisateur. Dans la première section nous étudions les différentes acceptions de ce terme et ses implications en EIAH. La section suivante discute de la conception participative.
10.3.1. La conception centrée utilisateur (CCU)
Norman plaide dès les années 80 pour « a User-Centred Design (UCD), a philosophy based on the needs and interests of the user, with an emphasis on making products usable and understandable » [NOR 88]. En réaction à des approches de la conception fondée sur la tâche prescrite, il propose de distinguer aux moins trois modèles : le modèle que se fait le concepteur de l’utilisateur final, le modèle que se fait le concepteur du dispositif technique et enfin le modèle que se fait l’utilisateur du dispositif technique. Revenons sur ces trois modèles.
Lorsqu’un concepteur pense que « l’utilisateur doit » ou que « l’utilisateur va » il a dans l’idée un modèle implicite de l’utilisateur et de la tâche que ce dernier aura à accomplir via l’interface. C’est ce que les ergonomes appellent la « tâche prescrite » ou la « tâche attendue ». Quant à la tâche telle qu’elle est « redéfinie » par l’utilisateur et ensuite « réalisée », c’est ce qu’ils appellent la « tâche effective » [RAB 98]. Rogalski donne des exemples de ces différentes interprétations d’une même tâche dans une situation d’enseignement [ROG 03]. L’écart entre le travail prescrit et le travail effectif a des origines diverses liées à la variabilité des individus, des situations, aux implicites souvent inévitables et aussi à la nécessaire capacité d’adaptation des individus aux situations imprévues. Comme le souligne Tricot [TRI 03], c’est un phénomène bien connu des ergonomes et des didacticiens ; il l’est peut être moins des informaticiens.
Pour ce qui concerne le modèle du système, la première préoccupation d’un concepteur (en tout cas informaticien) est d’imaginer le fonctionnement du système. Le modèle qu’il se crée correspond donc, bien légitimement à une logique de fonctionnement du système Le modèle de l’utilisateur est tout autre : c’est une logique d’utilisation du système. Il n’est pas fréquent que ces deux logiques coïncident. Un des objectifs de la conception est d’emmener l’utilisateur à se construire un modèle opérationnel du dispositif. Par exemple dans le logiciel Pépite [Jean 02], un logiciel pour aider les enseignants à établir un bilan de compétences de leurs élèves en algèbre élémentaire, une palette comportant des symboles algébriques usuels est à la disposition des élèves pour faciliter la saisie d’expressions algébriques. Un nombre non négligeable d’élèves se sont représentés cette palette comme une calculatrice et attendaient l’affichage du résultat d’une opération après avoir tapé sur l’icone « = » (Figure 1).

Figure 1 : Un élève qui considère la barre de saisie d’expressions algébriques comme une calculatrice
De nombreux travaux ont été menés ont été menés en IHM afin de spécifier des processus, des méthodes et des techniques pour permettre que la conception ne soit plus fondée sur la seule subjectivité des concepteurs ou sur les seules contraintes techniques. Ces outils permettent au concepteur de recueillir des informations sur les futurs utilisateurs, de caractériser leurs tâches et les situations d’utilisation, d’anticiper leurs besoins, de produire des idées, de les évaluer et de les mettre en œuvre de façon satisfaisante pour l’utilisateur.
Ainsi en 1999, la norme ISO 13407 s’intéresse à la conception centrée utilisateur en tant que processus de développement. Elle s’appuie sur cinq principes : (i) une analyse des besoins des utilisateurs, de leurs tâches et de leur contexte de travail, (ii) la participation active des utilisateurs à la conception, (iii) une répartition appropriée des fonctions entre les utilisateurs et la technologie, (iv) une démarche itérative de conception, (iv) l'intervention d'une équipe de conception multidisciplinaire.
Cette norme caractérise aussi les principales étapes de la conception (Figure 2) : planifier le processus de conception, étudier le contexte d’utilisation et les différentes catégories d’utilisateurs, identifier les buts et les tâches des utilisateurs et ainsi que les exigences d’organisation, produire des solutions de conception et les matérialiser et enfin, évaluer les solutions et itérer le processus pour les affiner.
 SHAPE \* MERGEFORMAT 
Figure 2 : Différentes étapes de la conception centrée utilisateurs, traduit de [BEV 00]
De nombreuses méthodes ont été mises au point pour mettre en œuvre la démarche centrée utilisateurs : les méthodes issues de recherches francophones (e.g. MAD, MUSE, DIANE) sont décrites dans le livre collectif édité par Kolski [KOL 01a, b]. Parmi les méthodes anglo-saxonnes citons la méthode LUCID (exposée par exemple dans [SCH 04]), la méthode développée par Gould [GOU 97], l’approche « Usability Engineering LifeCycle » de Mayhew [MAY 03], l’approche fondée sur les scénarios développée par Carroll et son équipe [ROS 03]. Les méthodes proposées s’appuient sur des principes qui sont assez variés mais qui peuvent être résumés en quelques mots-clé (i) connaître ses utilisateurs, (ii) penser utilisateurs, (iii) concrétiser et matérialiser les idées le plus tôt possible, (iv) tester les idées le plus tôt possible, (v) impliquer les utilisateurs dans la conception, (6) multiplier les points de vue, (vii) itérer.
En ce qui concerne les logiciels éducatifs, Soloway et son équipe [QUI 02] estiment que l’approche UCD si elle est nécessaire, est insuffisante et doit être complétée pour favoriser des apprentissages. Ils insistent sur les différences entre la conception pour des utilisateurs qui sont des professionnels et pour des utilisateurs apprenants. Selon ces auteurs, les apprenants n’ayant pas d’expertise dans le domaine, la conception doit leur fournir un étayage (scaffolding) sans pour autant effectuer la tâche à leur place. Ces chercheurs développent une approche qu’ils appellent « Learner Centred Design » (LCD) ou Conception Centrée Apprenant qui a pour objectif de développer des outils à la fois attrayants, offrant des défis aux apprenants et, en même temps, qui les assistent dans la gestion de leur apprentissage, dans le domaine à apprendre et dans les processus pour effectuer les tâches qui leur sont proposées.
Nous avons déjà abordé la discussion sur la spécificité des logiciels éducatifs ; elle fait écho à une discussion sur la définition des utilisateurs. Si les apprenants sont au centre des situations d’apprentissage, d’autres acteurs et d’autres facteurs contraignent ces situations et y jouent un rôle fondamental. Bruillard et Vivet [BRU 94] proposaient de fonder la conception des logiciels éducatifs sur les situations d’apprentissage incluant différents agents contraints dont les apprenants bien sûr mais aussi les enseignants et évidemment les systèmes techniques. Certains préfèrent le terme de conception centrée « usager » qui sous-tend quelqu’un qui a droit à un service ; d’autres suggèrent le terme d’ « acteurs » mettant l’accent sur une activité complexe dans un contexte technique et social ; enfin on rencontre de plus en plus le terme de « stakeholders » que l’on peut traduire par « parties prenantes » ou « intéressés ». On parle alors de « conception centrée sur l’usage » [BRA 03] qui prend en compte non seulement le produit et le processus de conception, mais également les conditions de son intégration dans un environnement technique, social et organisationnel. Cette orientation de la conception vers un support à l’activité des différents acteurs est particulièrement utilisée pour la conception d’environnements d’apprentissage collaboratifs et des recherches s’appuyant sur une approche instrumentale [RAB 95, GUI 02, BRU 00, DEL 05]. Le chapitre 12 examine cet aspect pour les situations scoalires.
10.3.2. Conception participative (CP)
La participation active des utilisateurs à la conception est un principe de base de la conception centrée utilisateur réaffirmé par la norme ISO13407. Mackay et Fayard [MAC 97] différencient ainsi la conception participative de la conception centrée utilisateur : « La conception participative transforme une approche unidirectionnelle où l’on observe et interroge les utilisateurs en une approche bidirectionnelle où les utilisateurs sont non seulement interrogés et observés, mais aussi intégrés dans le processus de conception ». Cette approche s’appuie sur des cadres théoriques qui stipulent que les technologies et les usages sont co-adaptifs et donc non prédictibles. Dans cette approche la définition du problème et sa compréhension sont liés à la création d’une solution. Grønbæk et al. [GRØ 93] estiment que les méthodes de conception traditionnelles se centrent trop sur le produit et pas assez sur le processus de conception. Selon eux un produit ne se restreint pas à un ensemble de fonctionnalités et de procédures mais garde la marque des différents processus d’analyses, de conception, de développement mis en œuvre par des groupes de personnes investis de rôles différents. Spécifier les fonctionnalités et les besoins est une étape essentielle en ce qu’elle permet de démarrer un projet. Mais ces spécifications ne peuvent qu’être temporaires. Si on ne peut pas les modifier, on ne peut rien découvrir. Or les « vrais » besoins sont inaccessibles au départ et ceci aussi bien aux utilisateurs, qu’aux concepteurs et qu’aux donneurs d’ordre. Ils émergent du processus de conception. Les spécifications écrites contractuelles conduisent à livrer des produits qui ne correspondent pas vraiment à ce que les gens qui les ont produites avaient en tête, et que les gens à qui ils sont destinés trouvent difficiles à utiliser et inadaptés. Ainsi aucun expert, aucune discipline ne peut à elle seule fournir la connaissance suffisante pour créer une solution à un problème ouvert, complexe et mal défini comme le sont souvent les problèmes de conception en IHM et très souvent aussi en EIAH. Dans cette approche, le point de vue utilisateur est considéré comme un des points de vue concourant à l’élaboration de solutions. En effet les experts ont souvent une bonne appréhension d’ensemble des problèmes mais une méconnaissance des réalités quotidiennes, à l’inverse, les utilisateurs ont parfois une vision parcellaire qui les amène à envisager des solutions particulières qui peuvent s’avérer insatisfaisantes voir nuisibles à un niveau plus général [GRU 93].
Pour Muller [MUL 03] un des objectifs de la conception participative (CP) est de transformer la « symétrie d’ignorance » (la mutuelle incompréhension entre les développeurs et les utilisateurs) en « symétrie de participation » et en « symétrie de connaissances », les développeurs apportant leurs connaissances de la technologie et les utilisateurs leurs connaissances du travail et du contexte. Il considère que les développeurs et les utilisateurs vivent dans deux mondes distincts et que la CP permet de créer un univers « hybride » entre les deux à l’image des « troisièmes mondes » qui se créent dans des communautés interculturelles.
Cependant la participation des utilisateurs à part entière dans les équipes de conception ne se décrète pas, elle se construit. Caroll et al. [CAR 01] décrivent l’évolution professionnelle d’enseignants engagés dans un processus de conception participative et aussi l’évolution des pratiques des concepteurs professionnels pour leur laisser une place, les laisser s’exprimer et développer leurs idées. Ces travaux mettent en évidence la perspective « développementale » de la conception participative.
Des difficultés sont cependant mentionnées dans cette approche. La première est la gestion du temps des utilisateurs qui ont souvent d’autres charges ; la deuxième est le manque de formation des concepteurs professionnels qui noient les utilisateurs dans des problèmes techniques qui les dépassent. Le problème de l’incompétence technique des utilisateurs qui les empêcheraient d’avoir des idées novatrices est souvent mis en avant par les détracteurs de la conception participative. De plus les dispositifs innovants provoquent des remises en cause de pratiques installées et peuvent être déstabilisants. Ainsi Bruillard note que les enseignants ne sont alors pas toujours les mieux placés pour imaginer de nouveaux usages associés à ces dispositifs [BRU 00]. Un certain nombre de techniques mises au point pour faciliter le travail dans des équipes pluridisciplinaires comme le remue-méninges (brainstorming), la mise au point de scénarios, et le prototypage se révèlent productives pour intégrer des utilisateurs dans les équipes de conception et pour pallier ces difficultés. Par exemple Mackay et son équipe présentent des techniques fondées sur le prototypage vidéo pour développer ces pratiques de conception participative [MAC 97], [BEA 03].
Dans le domaine de l’éducation, le livre de Druin [DRU 99] donne des exemples de conception participative avec des enfants et des apprentissages mutuels qui en résultent. Cependant la conception participative est plus souvent mise en œuvre avec des enseignants ou des formateurs. Dans le projet Lingot cette démarche nous est apparue très productive mais n’a pas été très facile à mettre en œuvre. Dans les premières phases du projet, lors de la conception d’un logiciel de diagnostic de compétences, le logiciel Pépite [JEA 02, DEL 02], notre préoccupation première était de montrer la faisabilité de l’automatisation d’un outil de diagnostic issue de la recherche en didactique. Nous avons fait participer des enseignants à des séances de travail tout au long de la conception et du développement du logiciel. Ils nous ont donné leur avis, ont exprimé des besoins que nous avons tenu à satisfaire, ont vérifié le logiciel, nous ont permis de tester le logiciel avec leurs élèves, mais il a fallu plusieurs années pour qu’ils se considèrent comme membres à part entière de l’équipe et voient l’importance de leur contribution au projet en particulier sur le volet « acceptabilité » i.e. intégration du logiciel dans les pratiques quotidiennes.
10. 4. Méthodes de conception
Il n’existe pas de méthode de conception universelle applicable à toutes les situations de conception d’IHM, mais une multitude de méthodologies fondées sur des positions théoriques, des connaissances scientifiques et s’appuyant sur l’expérience accumulée dans le domaine par des professionnels. Toutefois, comme nous l’avons vu, toutes se réfèrent à l’approche centrée utilisateur. Dans la suite, nous présentons quatre approches de conception particulièrement importantes : la conception itérative, le prototypage, la conception fondée sur les scénarios et la conception fondée sur des modèles de tâches.
10.4.1. Conception itérative
Toutes les méthodologies de conception centrée utilisateuren sont, comme le spécifie la norme ISO 13407, fondées sur des approches itératives. Ce qui fonde cette approche itérative c’est ce que des ergonomes appellent le « paradoxe de l’ergonomie de conception ». L’ergonomie a mis au point des méthodes scientifiques pour observer et analyser les situations de travail. Par contre, aucune méthode ne permet d’analyser une situation de travail qui n’existe pas encore ni de prédire et anticiper avec certitude la façon dont les utilisateurs s’adapteront à un système qui n’existe pas encore. Bruillard et Vivet [BRU 94] relevaient également ce paradoxe sur la nécessité de respecter les pratiques usuelles d’enseignement tout en essayant d’en susciter de nouvelles lorsque l’on conçoit des logiciels pour des situations scolaires.

 SHAPE \* MERGEFORMAT 
Figure 3 : La conception itérative [VAN 03]

La conception itérative est la solution la plus couramment mise en œuvre pour faire face à ce paradoxe. Elle permet d’approcher progressivement l’activité future par des évaluations sur des simulations. Ces simulations peuvent prendre différentes formes (maquettes, prototypes, scénarios etc.) et permettent de préciser les modalités de travail avec le logiciel, d’anticiper la dynamique de l’activité et d’appréhender la situation de travail dans sa globalité. Malgré tout, les situations de simulation sont forcément réductrices et il est nécessaire de procéder par ajustements successifs. Ceci donne des modèles de développement en spirale ou en hélice (Cf. par exemple [KOL 01a, b] et en EIAH [BRU 94]) où alternent des phases d’analyse, de conception, de prototypage et d’évaluation (Figure 3).
Les approches itératives mettent ainsi l’évaluation au centre du processus de conception et ce dès les premières phases d’un projet. Elles fournissent des méthodes et des techniques pour fonder les décisions de conception sur des données expérimentales (et leur interprétation) et non sur des a priori. La littérature IHM fourmille d’exemples d’a priori des équipes de conception qui se sont avérées inadéquates lors de tests utilisateurs.
Pour prendre un exemple dans ma propre expérience, quand nous avons conçu la première version du logiciel Pépite, je pensais que le logiciel devait fournir un « modèle de l’élève » « ouvert » et « inspectable » [KAY 01], c’est-à-dire un modèle sur lequel les utilisateurs aient le contrôle. Je pensais que les enseignants ne feraient pas confiance à la machine et voudraient vérifier, modifier le diagnostic automatique. Les tests avec le prototype mis au point par Jean [JEA 02] nous ont montré une situation bien différente [DEL 02]. Pour les chercheurs en didactique et les responsables de la ré-ingénierie du système, pouvoir inspecter le profil de compétences construit par le système s’est effectivement révélé fondamental. Mais, à de rares exceptions près, les enseignants se sont peu intéressés à la vérification du diagnostic automatique. Ils demandent plutôt un correcteur automatique de copies qui fasse ressortir les éléments importants du bilan de compétences de leurs élèves. C’est l’exploitation du diagnostic pour améliorer l’apprentissage de leurs élèves qui les intéressent plus que le diagnostic en lui-même. Ces expérimentations sur un prototype nous ont permis d’avancer dans la compréhension d’une activité qui n’est pas possible sans la mise à disposition d’outils informatiques performants et de développer de nouvelles idées pour faciliter l’exploitation du diagnostic en classe [VIN 05].
10.4.2. Le prototypage
Comme nous venons de le voir « HCI is both user-centered and iterative » [BEA 03]. Tous les manuels d’IHM placent le prototypage au cœur des processus de conception des logiciels interactifs. En effet en accord avec de nombreux auteurs, Beaudoin et Mackay [BEA 03] estiment que pour des systèmes assez novateurs et hautement interactifs, l’analyse des besoins a priori est chose impossible : les besoins des utilisateurs évoluent parallèlement à la conception du système et même lors de l’utilisation. Ces constatations ont amené à remettre en cause les méthodes de conception très prescriptives et rigides pour certaines catégories de logiciels en particulier pour ce que Fisher [FIS 01] appelle des « High Functionality Applications » (HFA). Ces applications sont utilisées par des millions de personnes avec des objectifs extrêmement divers et impossible à anticiper « at design time ». Le prototypage est un moyen de faire émerger ces besoins ou de comprendre quelles sont les parties stables et qu’elles sont les parties susceptibles de devoir être programmées lors de l’utilisation (« at use-time » par exemple [FIS 01], [LED 04]).
Le prototypage est un ensemble de techniques qui permettent de réifier les idées de conception. L’idée de base est que des objets que l’on peut voir ou encore mieux manipuler sont beaucoup plus efficaces auprès des humains qu’une documentation papier et ce sur deux plans. D’une part ils favorisent la créativité et développent la communication à l’intérieur de l’équipe de conception, avec les utilisateurs et les donneurs d’ordre. D’autre part ils permettent des évaluations précoces, de choisir entre des alternatives de conception, d’argumenter les choix de conception, de remettre en cause des choix ou de les corriger avant qu’il ne soit trop coûteux de revenir en arrière. Pour Beaudoin-Lafon et Mackay [BEA 03] les prototypes sont ainsi à la fois des artefacts (c’est-à-dire le résultat d’un processus de conception) et un outil de conception (c’est-à-dire un objet qui s’inscrit dans le processus de conception.
Ils analysent les prototypes en tant qu’artefact selon quatre dimensions : leur support (papier, vidéo, simulations informatiques etc.), leur précision (de sommaire et informelle à très fignolé), leur interactivité (pour seulement montrer ou bien pour être manipulés), leur cycle de vie (destinés à être jetés, à être réutilisés, à évoluer vers le produit final).
En tant qu’outils de conception, Beaudoin et Mackay ils estiment qu’ils ont un avantage énorme sur les idées, les modèles abstraits, les cahiers des charges papier : ils permettent de compléter ou de modifier l’analyse de besoins des utilisateurs dans le contexte du système qui est en train d’être développé. De plus, ce sont des objets qui peuvent être partagés et discutés. Ils constituent un outil de communication et une façon très efficace d’impliquer des utilisateurs dans le processus de conception pour tester les idées de conception (« usability testing ») mais aussi pour donner des idées novatrices (conception participative). Enfin ce sont des outils qui permettent à la fois d’explorer « l’espace de conception » (i.e. générer des idées) et de le contracter (i.e. sélectionner des alternatives de conception). On distingue quatre stratégies de prototypage en fonction des objectifs et du problème à résoudre : (i) Le prototypage horizontal utilisé dans les projets de grande ampleur pour avoir une vue complète du système du point de vue des utilisateurs. (ii) Le prototypage vertical se centre sur un problème spécifique de conception par exemple pour étudier la faisabilité d’une solution en partant du point de vue utilisateur et en analysant étape par étape la façon de la réaliser. (iii) Le prototypage orienté tâche se pratique à partir d’une analyse de tâches et se centre uniquement sur les fonctionnalités nécessaires à la réalisation d’un ensemble restreint de tâches.(iv) Le prototypage fondé sur des scénarios ne se focalise pas sur une tâche isolée mais sur un scénario qui envisage comment le système pourrait être utilisé dans un contexte réel.
Chacune de ces stratégies s’appuie sur des techniques de prototypage regroupées en trois types selon leur rôle dans le cycle de vie du systèmes : les prototypes rapides (les prototypes papier, les prototypes vidéo et les prototypes logiciels), les prototypes itératifs et les prototypes évolutifs (utilisé dans les méthodes agiles)..
Nous avons pu constater nous mêmes l’importance de la manipulation de prototypes pour évaluer nos choix de conception, pour l’implication des enseignants dans le travail de conception et aussi pour le partage de l’expertise didactique modélisée dans le logiciel [PRE 04].
10.4.3. Conception fondée sur des scénarios
La démarche adoptée par Carroll et son équipe pour créer un Laboratoire Virtuel de Sciences Physiques dans le cadre du projet LINC (Learning in Network Communities) [CAR 01]. Ce projet nous semble intéressant car Caroll et son équipe proposent depuis les années 90, une approche de la conception fondée sur l’utilisation de scénarios [ROS 03]. Ces techniques sont maintenant employées, à des degrés divers, dans toutes les équipes de conception en IHM . D’après mon expérience personnelle de conception d’IHM en EIAH, elles me semblent extrêmement fructueuses même dans leur forme simplifiée pour communiquer à l’intérieur d’une équipe de conception pluridisciplinaire, pour prendre en compte des contextes et des problèmes d’usage et enfin, pour organiser les réunions de conception et fonder les décisions de conception avec des enseignants ou des élèves.
Le projet LINC, commencé en 1994, a des objectifs au départ très généraux tels qu’encourager l’apprentissage collaboratif et la pédagogie de projet, accroître la participation de la population dans l’école ou améliorer l’accès à l’éducation des enfants des zones rurales. Les chercheurs ont fondé le projet sur trois hypothèses : (i) les besoins ne pré-existent pas mais ils émergent lors de l’interaction dans l’équipe de conception par accommodations entre les pratiques des utilisateurs et les produits technologiques développés, (ii) les tâches et les artefacts co-évoluent, (iii) une conception fondée sur les scénarios aide les enseignants à s’impliquer dans la conception d’activités d’apprentissage avec ordinateur et à leur déploiement dans le système scolaire. Dans une toute première étape, un scénario initial a été crée par les concepteurs (Cf. Figure 4).

Marissa est une élève de seconde qui étudie la gravité et son rôle dans le mouvement des planètes. De son ordinateur personnel, elle se rend au laboratoire virtuel dans la salle sur la gravité. Elle y rencontre 2 élèves Randy et David qui travaillent sur le "Alternate Reality Kit" (une simulation où l’élève modifie des paramètres et on observe les effets). Ils discutent tous les trois via l'ordinateur sur les expérimentations à tenter. Ils construisent ainsi plusieurs systèmes solaires et s'intéressent à la façon dont des comètes déstabilisent des systèmes. Ils recueillent des données sur leurs expérimentations, utilisent différents outils de visualisation et écrivent un rapport qu'ils adressent à Don un camarade de classe de Marissa et à Mme Gould le professeur de physique de Randy.Figure 4 : Scénario initial : Marissa [CAR 01]
L’étape suivante de la méthode consiste à mener une analyse du contexte de travail (ici : les classes des quatre enseignants participants au projet). Cette analyse, fondée sur le recueil des données par l’observation, la prise de notes, la vidéo et les interviews a mis en évidence :
-  la variété des stratégies mises en œuvre par un enseignant (démonstration, discussion, découverte guidée) et la variété des types d’activités qu’il met en place pour ses élèves (travail individuel, manipulation par petits groupes, débat avec toute la classe, présentation d’un groupe à la classe etc.),
-  l’importance des manipulations d’objets physiques pour l’apprentissage mais aussi le temps perdu à installer et manipuler des logiciels,
-  l’encombrement de la salle de classe,
- les nombreuses interactions de collaboration entre élèves (consensus, enseignement mutuel, prise d’initiative etc.)
-  la difficulté de faire entrer des personnes extérieures dans les classes.
Ces observations ont conduit les chercheurs à faire évoluer le projet sur 4 points principaux : (i) à se rendre compte de la nécessité absolue de diversifier les styles d’apprentissage et ne pas se contenter d’apprentissage par la découverte, (ii) à se rendre compte de la nécessité absolue de prendre en compte les interactions entre les élèves dans la classe et pas simplement à distance, (iii) de l’impossibilité de mettre un ordinateur par élève dans un espace aussi réduit et (iv) à abandonner l’idée de faire participer la population à la classe.
A partir des données recueillies, ils ont sélectionné des épisodes typiques des activités d’apprentissage en sciences, typiques des différentes stratégies d’enseignement et typiques des activités de collaboration. Ces épisodes constituent des scénarios observés. Pour chaque scénario, l’équipe a dégagé ses caractéristiques et discuté les conséquences positives et négatives (ce que les auteurs appellent « claims analysis »). Par exemple, pour la caractéristique « manipuler des objets physiques » les conséquences positives sont (i) le développement d’habilités de laboratoire, (ii) la stimulation de l’intérêt et (iii) la stimulation de la collaboration entre élèves. Les conséquences négatives sont (i) l’ennui pour certains, (ii) beaucoup de préparation pour l’enseignant, (iii) des défaillances techniques fréquentes, (iv) une distraction par rapport aux concepts de la physique. Le résultat de cette étape est une collection de scénarios observés avec leurs caractéristiques et les arguments (pour ou contre).
La troisième phase a consisté à explorer l’utilisation de diverses technologies dans la classe : video-conférences, chat, tableau partagé. Tout d’abord des scénarios pour tester ces technologies ont été mis au point par l’équipe puis expérimentés en classe. Il s’agit ici de scénarios d’évaluation pour mener des tests d’utilisabilité en situation. Cette phase exploratoire a mis en évidence de nombreuses difficultés : (i) la difficile concordance des emplois du temps, (ii) la nécessité de justifier l’usage de la technologie : « pour l’enseignant la technologie est plus souvent un problème qu’une solution », pour l’élève il est plus facile de demander à son voisin qu’au « mentor » du lycée voisin, (iii) la nécessité que les élèves fassent connaissance avant de collaborer, (iv) une gestion complexe de la classe pour organiser des ateliers et des rotations sur les ordinateurs qui rentrent dans l’espace réduit des classes et des problèmes de bruit par exemple quand un groupe est en video-conférence (v) la nécessité d’intégrer les activités dans le curriculum.
L’étape suivante s’est orientée vers la construction de scénarios s’appuyant sur une pédagogie de projet sur une période assez longue et l’intégration de travail collaboratif synchrone. Elle a donné lieu à des maquettes papier-marqueurs post-it, des storyboards (par exemple pour développer l’idée d’un espace de travail appelé cahier structuré pour gérer les projets des élèves, le cahier pouvant être personnel ou collectif). Enfin, un prototype a été développé et utilisé dans les classes.
Cette expérience montre bien la difficulté d’établir a priori une analyse de besoins et comment les besoins sont liés aux technologies proposées et aux contraintes de la situation. Elle montre aussi l’intérêt des scénarios et du prototypage pour à la fois créer une culture commune entre le monde des concepteurs professionnels et celui des utilisateurs, pour faire émerger des idées et pour évaluer les solutions proposées.
10.4.4. Conception fondée sur des modèles de tâches
Toutes les méthodologies de conception s’accordent sur l’importance de l’analyse de l’activité et des tâches. Celle-ci prend des aspects divers selon le type de projet (salle de contrôle d’une centrale nucléaire ou site web ou activité fortement coopérative), selon la discipline (informatique ou ergonomie), selon les budgets, la durée du projet, la disponibilité des utilisateurs. Les modèles produits peuvent être des modèles formels (par exemple [SCA 01], [BRA 03]) qui s’appuient sur une décomposition hiérarchique des tâches en sous-tâches et qui permettent d’obtenir des spécifications rigoureuses de l’interface. D’autres méthodes s’intéressent à des tâches complexes moins structurées et produisent des descriptions moins formelles par exemple sous forme de listes de tâches et de leurs caractéristiques, sous forme de scénarios d’utilisation, de personnages archétypes, de diagrammes d’affinités, de diagrammes de flux d’information, de séquence [RED 03, VAN 03]. L’analyse des tâches est utilisée à plusieurs étapes du cycle de conception : dans la phase d’analyse des besoins, au cours de conception pour une micro-analyse sur un point particulier, pour mettre au point les manuels utilisateurs.
Guéraud et ses collègues [GUE 04] décrivent comment ils ont conçu l’interface de la plateforme FORMID pour assister le formateur dans le suivi d’un groupe d’étudiants réalisant un TP. Ils s’appuient sur une approche fondée sur des modèles. Ils ont d’abord écrit des scénarios d’usage (par exemple l’histoire de Marc Dupont qui gère un TP de Génie Logiciel avec des groupes qui lui posent des questions etc.). L’analyse des scénarios leur a permis d’identifier les tâches des utilisateurs (par exemple suivre une séance) ainsi que les concepts intervenant dans ces tâches (par exemple séance et groupe). Les tâches sont ensuite décomposées en sous-tâches et forment un modèle de tâches exprimé à l’aide d’un formalisme arborescent. Ce modèle guide l’établissement de l’interface abstraite qui définit les espaces de travail (par exemple un espace de travail pour héberger la tâche de réalisation d’exercice), la navigation entre les espaces de travail ainsi que leur contenu conceptuel. L’interface concrète matérialise les espaces de travail en fenêtre et canevas, les concepts en objets d’interaction (champ de texte, bouton radio, case à cocher, images etc.), la navigation en objet de navigation (liens hypertexte, onglets, boutons etc.). L’interface finale est obtenue par codage puis compilation (ou interprétation) de l’IHM concrète.
10.5. Evaluation des IHM en EIAH
Dans des démarches de conception IHM, l’évaluation est une préoccupation constante et ce dès les premières phases de conception. Certaines techniques, nous venons de le voir, sont ainsi à la fois des coutils de conception et d’évaluation. En IHM on distingue souvent deux grandes classes d’approches de l’évaluation : les méthodes d’inspection et les tests d’utilisabilité [BAS 01].
Les méthodes d’inspection ne nécessitent pas l’intervention d’utilisateurs et peuvent être mises en œuvre à moindre frais dès les phases initiales pour évaluer des scénarios, des maquettes papier ou des prototypes logiciels. Une technique courante s’appuie sur des jugements d’experts qui remettent un rapport sur les points positifs, négatifs, les problèmes potentiels et leur pondération. Une autre consiste en un atelier appelé revue de conception (design walkthrough) où une personne joue le rôle d’un utilisateur en déroulant un scénario et où les autres participants (maximum sept) envisage des variantes ou précise le scénario pour essayer d’anticiper des problèmes potentiels d’utilisation.
Les tests d’utilisabilité sont utilisés sur des prototypes avancés et mettent en jeu des expérimentations avec des utilisateurs. Ils ont amené les ergonomes à produire un certain nombre de recommandations. Les concepteurs d’EIAH peuvent donc s’appuyer sur ces recommandations qui s’expriment de façon très diverse pour évaluer l’interaction en cours de conception : c’est ce que l’on appelle l’évaluation heuristique.
Un important travail, notamment pour ce qui concerne la conception des écrans et des sites web, a été accompli dans le domaine IHM pour fournir des heuristiques, des recommandations, des critères et des standards qui permettent d’évaluer le résultat de la conception [BRA 03], [VAN 01], [VAN 03]. Ce peut être des conseils très généraux : par exemple « Less is More » ou « cultivez l’art de la simplicité » [NIE 00]. Ce peut être aussi les célèbres critères ergonomiques de l’INRIA définis par Bastien et Scapin [BAS 01] qui concernent le guidage, la charge de travail, le contrôle explicite à l’utilisateur, l’adaptabilité, la gestion des erreurs, l’homogénéité et la cohérence, la signifiance des codes et dénominations et la compatibilité avec les tâches des utilisateurs et entre environnements. Des normes (comme la norme ISO), des standards (par exemple les standards W3C) et des guides de style définis par les grandes entreprises de développement logiciel sont également disponibles.
En EIAH, Tricot et al. [TRI 03] proposent une démarche d’évaluation reposant sur des critères et des mesures selon trois dimensions : l’utilité (« les moyens de faire réellement apprendre »), l’utilisabilité (« les moyens de faire un dispositif utilisable par les apprenants ») et l’acceptabilité (« les moyens de faire un dispositif compatible avec les pratiques, les ressources, les contraintes, les objectifs des apprenants et de l’institution de formation enseignement »). L’utilité met en œuvre des critères liés à la pédagogie et aux didactiques, l’utilisabilité à l’ergonomie, l’acceptabilité à des critères organisationnels, sociaux, affectifs ou culturels.
Hu et Trigano [HU 01] proposent une méthode d’évaluation et de caractérisation des logiciels multimédias de formation qui s’appuie sur un questionnaire organisé autour de cinq thèmes : la qualité technique, l’ergonomie, les documents multimédia, la scénarisation, les outils pédagogiques et les impressions générales. Le thème ergonomie qui, pour ces auteurs, concerne l’utilisabilité du logiciel se fonde principalement sur les critères de Bastien et Scapin.
Quelques travaux portent sur l’efficacité de l’apprentissage par rapport aux choix d’IHM suite à des expérimentations menées auprès d’apprenants. Selon Burkhardt et Wolf [BUR 02], les résultats, souvent liés au contexte et à la situation d’apprentissage, sont difficiles à transférer d’une situation d’apprentissage à une autre. Ils citent certains travaux sur l’utilisation des animations (qui semblent efficaces pour présenter des relations dynamiques mais peuvent provoquer une surcharge cognitive), d’agent pédagogique (l’interaction avec l’agent constitue l’intérêt essentiel alors que l’apparence de l’agent n’a pas d’effet sur l’apprentissage), de comparaison entre utilisation d’un langage de commandes et manipulation directe (le premier induisant de meilleurs résultats d’apprentissage que le second dans un logiciel de simulation). Tricot [TRI 03a] donne des exemples de résultats expérimentaux qui ont été répliqués dans plusieurs contextes : par exemple la structuration en hypertexte serait déconseillée pour l’apprentissage de procédures. Bruillard et Vivet [BRU 94] proposent de caractériser les situations et les objectifs pour la conception de l’interaction. Tricot fait la même proposition pour cerner, dans la littérature, les connaissances empiriques qui permettent de fonder cette conception en distinguant par exemple les apprentissages par l’action, par instruction et par exploration. Nous ne nous étendons pas plus sur la problématique de l’évaluation des usages, qui est étudiée dans le chapitre douze de ce livre.
10. 6. Conclusion
L’interface d’un simulateur, l’interface d’un logiciel d’éveil pour jeunes enfants, l’interface d’un cours de mathématiques en ligne ou d’un Cédérom d’apprentissage des langues, l’interface d’un logiciel pour supporter une pédagogie de projet sont conçues en fonction des spécificités des apprentissages visés. La conception de l’interaction est donc co-substantielle à l’apprentissage, la conception détaillée des interfaces dépend du type d’EIAH et du type d’apprentissage visé. Il n’existe donc pas de méthodes clé en main pour la conception de l’interaction dans les EIAH. Dans le cadre de ce chapitre, nous avons néanmoins présenté des démarches générales ancrées sur des définitions et exemplifiées par quelques systèmes en donnant des pointeurs vers des références plus conséquentes. Nous avons dressé un panorama des approches de conception d’IHM en étudiant les spécificités des EIAH, spécialement dans les systèmes visant des apprentissages spécifiques. Nous avons regardé différentes approches et techniques pour prendre en compte les différents utilisateurs, principalement les élèves et les enseignants, puis évoqué quelques résultats contextualisés sur l’évaluation ergonomique des EIAH. De nombreux autres aspects des recherches en IHM concernent les EIAH. Certains aspects n’ont pas été évoqués comme la multimodalité, les aspects sémiotiques des interfaces, les interfaces adaptatives, la réalité augmentée, les architectures logicielles, les outils et plateformes de développement, etc.). Nous renvoyons les lecteurs à un article de synthèse [CAL02] ou aux manuels d'IHM sur ces sujets (e.g. [RAS 00], [KOL 01b], [SCH 86-04] [JAC 03]. D’autres aspects sont évoqués dans d’autres chapitres de ce livre, en particulier dans le chapitre cinq qui porte sur la gestion de l’interaction, dans le chapitre onze qui porte sur la réalité virtuelle pour les EIAH et dans les chapitres quinze et seize qui décrivent des projets de recherche ayant abouti à des produits commercialisés.
10. 7. Bibliographie
[BAK 04] Baker R.S., Corbett A.T., Koedinger K.R. (2004) Detecting Student Misuse of Intelligent Tutoring Systems . Proceedings of the 7th International Conference on Intelligent Tutoring Systems, 531-540.
[Bal 94] Balacheff N., Didactique et intelligence artificielle, in Balacheff N. et Vivet M. (dir.), Didactique et intelligence artificielle, 7-42, Éditions La Pensée Sauvage, Grenoble, 1994.
[BAS 01] Bastien C., Scapin D., évaluation des systèmes d’information et critères ergonomiques, in Kolski C. (dir.), Environnements évolués et évaluation de l'IHM, Interaction homme-machine pour les systèmes d'information Vol 2, 51-75, Hermès, 2001
[BEA 03] Beaudouin-Lafon M., Mackay W.. Prototyping Development and Tools., In J.A. Jacko and A. Sears (dir.). Human Computer Interaction Handbook Lawrence Erlbaum Associates, 2003, 1006-1031.
[BEV 00] BEVAN, N. & BOGOMOLNI, I. Incorporating User Quality Requirements in the Software Development Process. In Proceedings of the 4th International Software & Internet Quality Week Conference [QWE2000], Brussels, Belgium, 20-24 November 2000, pp1192-1204. Available at: http://www.soft.com/QualWeek/QWE2K/Papers/11A.html
[BRA 03]. Brangier E., Barcenilla J., Concevoir un produit facile à utiliser : Adapter les technologies à l’homme, Editions d’organisation, 2003.
[Bru 94] Bruillard É., Vivet M., Concevoir des EIAO pour des situations scolaires : approche méthodologique, in in Balacheff N. et Vivet M. (dir.), Didactique et intelligence artificielle, 273-302, Éditions La Pensée Sauvage, Grenoble, 1994.
[BRU 00] Bruillard É., Delozanne É., Leroux P., Delannoy P., Dubourg X., Jacoboni P., Lehuen J., Luzzati D., Teutsch P., Quinze ans de recherche informatique sur les sciences et techniques éducatives au LIUM, in Grandbastien M. et Bruillard É. (dir), Revue STE, numéro spécial éducation et informatique, hommage à Martial Vivet, , volume 7-n°1/2000, Hermès, p. 87-145.
[BUR 02] Burkhardt, J.-M., Wolff M., Réalité Virtuelle et nouvelles technologies de formation : vers une formalisation des critères de choix et de la démarche centrée sur l'apprentissage (rapport final de contrat LEI-SNCF). Laboratoire d'Ergonomie Informatique, Université Paris V, 2002.
[CAL 02] Calvary G., Ingénierie de l'interaction homme-machine : rétrospective et perspectives, Interaction homme-machine et recherche d'information, Traité des Sciences et Techniques de l'Information, C. Paganelli Ed., Hermès 2002, 19-63
[CAR 01]. Carroll J. M., Chin G., Rosson M. B. & Neale D.C., The development of Cooperation : Five years of Particpatory Design in the Virtual School, Caroll J.M. (dir.), Human Computer Interaction in the new Millennium, Addison Wesley, 2001, 373-396
[CLA 04] Clancey B., Opportunities for Model-Based Learning Systems in the Human Exploration of Space, conference invitée, Intelligent Tutoring Systems, Maceio, Brazil, Août 2004.
[COU 96] Coutaz J., Ingénierie de l’Interaction Homme-Machine, In Caelen J. (dir.) Nouvelles Interfaces Homme-Machine, Observatoire Français des Techniques Avancées, Diffusion Lavoisier, Paris, Décembre 1996, 163-174.
[DEL 01] Delozanne E., Jacoboni P. (dir), Numéro Spécial, Interaction Homme-Machine pour la Formation et l’Apprentissage Humain, Revue Sciences et Techniques Educatives,vol. 8 n°3-4, Hermès, 2001.
[DEL 02] Delozanne E., Grugeon B., Jacoboni P., Analyses de l’activité et IHM pour l’éducation, In Proceedings of IHM’2002, International Conference Proceedings Series, ACM, 2002, Poitiers, France, 25-32.
[DEL 05] Delozanne E., Grugeon B., Rogalski J., Artigue M., Coulange L., Gélis J.-M, Prévit D., Normand S., Vincent C., Chenevotot F., Environnements Informatiques pour la régulation des apprentissages, le cas de l’algèbre avec le projet Lingot, rapport de fin de projet, programme Cognitique, Ecole et Sciences Cognitives, Les apprentissages et leurs dysfonctionnements, 2005.
[DOU 01]Dourish P.,Where the Action Is : the Foundations of Embodied Interaction, Bradford Book, MIT Press, 2001
[DRU 99] Druin A.(dir.), The Design of Children's Technology, Morgan Kaufman 1999.
[FIS 01] Fisher G., User Modeling in Human-Computer Interaction, User Modelling and User-Adapted Interaction 11 :65-86, 2001.
[GOO 99] Goodyear P., Seeing Learning as Work: implications for Understanding and Improving Analysis and Design, Journal of Courseware Engineering, (2)1999, 3-11.
[GOU 97] Gould J, How to Design Usable Systems, In Helander M., Landauer T., Prabhu P.(dir.), Handbook of Human Computer Interaction, Elsevier Science B.V., 1997 (second edition), 231-254.
[GRØ 93] Grønbæk K., Grudin J., Bødker S., Bannon L;, Achieving Cooerative System Design: Shifting from a product to a Process Focus, In Schuler D., Namioka A. (dir.), Participatory design : Principles and Practices, Erlbaum, Hillsdale, N.J., 1993, 99-121.
[GRU 93] Grudin J., Obstacles to Participatory Design in Large Product Developpement Organizations, In Schuler D., Namioka A. (dir.), Participatory design : Principles and Practices, Erlbaum, Hillsdale, N.J., 1993, 99-121.
[GRU 02] Grumbach A., Le rôle fondamental du système d’interaction dans une installation de réalité virtuelle, In Proceedings of IHM’2002, International Conference Proceedings Series, ACM, 2002, Poitiers, France, 1-6.
[GUE 04] Guéraud V., Adam J.-M., Pernin J.-P., Calvary G., David J.-P., L’exploitation d’Objets Pédagogiques Interactifs à distance : le projet Formid, Revue Sciences et Technologies de l’Information et de la Communication pour l’Education et la Formation, vol. 11, 2004, http://sticef.org
[GUI 02] Guin D., Trouche L. (dir.), Calculatrices symboliques, transformer un outil en instrument du travail mathématique : un problème didactique, La Pensée Sauvage, Recherches en Didactique des Mathématiques, 2002.
[HAN 99] Hanna L., Risden K., Czerwindski M., Alexander K., The Role of Usability Research in Designing Children ‘s Computer Products, in [DRU 99] Druin A.(dir.), The Design of Children's Technology, Morgan Kaufman 1999, 3-26.
[HOY 97] Hoyles C., Healy L., Un micro-monde pour la symétrie axiale : une base de co-constructions de concepts mathématiques, Revue Sciences et Techniques Educatives, vol. 4 n° 1, 67-97, Hermès, 1997.
[HU 01], Hu O., Trigano P., Crozat S., Une aide à l’évaluation des logiciels multimédias de formation, in Delozanne E., Jacoboni P. (dir), Numéro Spécial, Interaction Homme-Machine pour la Formation et l’Apprentissage Humain, Revue Sciences et Techniques Educatives,vol. 8 n°3-4, 239-274, Hermès, 2001.
ISO 9241:1998-11 Ergonomics of office work with VDTs - Guidance on usability.
ISO 13407:1999 Human-centred design processes for interactive systems.
[JEA 02] Jean S., Un système d'assistance au diagnostic de compétences en algèbre élémentaire, Revue Sciences et Techniques Educatives,vol. 9 n°1-2, 171-199, Hermès, 2002.
[KAY 01] Kay J., Learner Control, User Modeling and User-Adapted Interaction 11: 111-127, Kluwer Academic Publishers, 2001
[KOL 01a] Kolski C. (dir.), Analyse et conception de l'IHM, Interaction homme-machine pour les systèmes d'information, Vol 1, Hermès, 2001.
[KOL 01b] Kolski C. (dir.), Environnements évolués et évaluation de l'IHM, Interaction homme-machine pour les systèmes d'information, Vol 2, Hermès, 2001.
[KUN 03] Kuniavsky M., Observing the user experience, a practioner’s guide to user research, Morgan Kaufman, 2003.
[LED 04] Letondal C., Mackay W., Participatory Programming and the Scope of Mutual Responsability: Balancing Scientific, design and software commitment, Proceedings Participatory Design Conference, Toronto, Canada.2004
[MAC 97] Mackay W., Fayard A.-L., "Radicalement nouveau et néanmoins familier : les strips papiers revus par la réalité augmentée" , Actes des Journées IHM 1997
[MAY 03] Mayhew D., Requirements Specifications within the Usability Engineering Life Cycle, In Jacko J., Sears A. (dir.), The Human Computer Interaction Handbook, Lawrence Erlbaum, 2003, 913-921.
[MUL 99] Muller M.., Catalogue of Scenario-Based Methods and Methodology, IBM, Technical Report, 99-06, 1999. (accessible aout 2004 : http://domino.research.ibm.com/cambridge/research.nsf/pages/index.html)
[MUL 03] Muller M., Participatory Design: the third space in HCI, in Jacko J., Sears A. (dir.), The Human Computer Interaction Handbook, Lawrence Erlbaum, 2003.
[NIE 00] Nielsen J., Conception de sites Web, l'art de la simplicité, Campus Press Fr., 2000.
[NOR 88] Norman D., The Pschychology of Everyday Things, Basic Books, 1988.
[NOR 01] Normand S., Bruillard E., Que révèlent les discours de futurs enseignants sur leur compréhension du fonctionnement des applications informatiques, Revue Sciences et Techniques Educatives,vol. 8 n°3-4, 435-445, Hermès, 2001.
[POC 97] Pochon L.-O., Grossen M., Les interactions homme-machine dans un contexte éducatif : un espace interactif hétérogène, Revue Sciences et Techniques Educatives, vol. 4 n° 1, 41-65, Hermès, 1997.
[PRE 04] Prévit D., Delozanne É., Grugeon B., Modélisation cognitive en algèbre élémentaire : une conception itérative, Conférence Technologies de l’Information et de la Communication pour l’Enseignement Supérieur, Compiègne, 20-22 octobre 2004, 138 - 145
[QUI 02] Quintanna C., Krajcik J., Soloway E., Norris C, A Framework for understanding the development of educational software, In J.A. Jacko and A. Sears (dir.). Human Computer Interaction Handbook Lawrence Erlbaum Associates, 2002, 823-834.
[RAB 95] Rabardel P., Les hommes et les technologies, approche cognitive des instruments contemporains, Colin, 1995.
[RAB 98] Rabardel P., Carlin N., Chesnais M., Lang N., Le Joliff G, Pascal M., Ergonomie concepts et méthodes, éditions Octares, Toulouse, 1998.
[RAS 00] Raskin J., The humane Interface, New directions for Designing Interactive Systems, Addison Wesley, 2000.
[RED 03] Redish J., Wixon D., Task Analysis, In Jacko J., Sears A. (dir.), The Human Computer Interaction Handbook, Lawrence Erlbaum, 2003, 922-940.
[ROG 03] Rogalski J., Y a-t-il un pilote dans la classe ? Une analyse de l'activité de l'enseignant comme gestion d'un environnement dynamique ouvert, Revue de Recherche en Didactique des Mathématiques, La Pensée Sauvage, vol. 23-3, 2003.
[ROS 03] Rosson M. B , Carroll J. M., Scenario-Based Design., In J.A. Jacko and A. Sears (dir.). Human Computer Interaction Handbook Lawrence Erlbaum Associates, 2002, 1032-1050.
[SCA 01] Scapin D., Bastien C., Analyse des tâches et aide ergonomique : l’approche MAD*, in [KOL 01a] Kolski C. (dir.), Analyse et conception de l'IHM, Interaction homme-machine pour les systèmes d'information, Vol 1, Hermès, 2001.
[SCH 86-04], Schneiderman B., Designing the User Interface Strategies for Effective Human Computer Interaction, Addison Wesley, 2004 (4° edition, 1° edition en 1986).
[SEN 93] Senach B., Évaluation ergonomique des interfaces Homme-Machine, une revue de la littérature, in Sperandio J.-C., L'ergonomie dans la conception des projets informatiques, Octares éditions, 1993, p 69-122.
[TCH 02]Tchounikine P., 2002, Pour une ingénierie des EIAH, Revue I3 2 (1) www.revue-i3.org.
[TRI 03] Tricot A., Plégat-Soutjis F., Camps J.-F., Amiel A., Lutz G., et Morcillo A. Utilité, utilisabilité, acceptabilité : interpréter les relations entre trois dimensions de l’évaluation des EIAH, In C.Desmoulins, P. Marquet et D. Bouhineau (dir.). Environnements informatiques pour l’apprentissage humain, 391-402, Paris : ATIEF – INRP, 2003.
[TWI 98]  HYPERLINK "http://www.comp.lancs.ac.uk/computing/staff/mbt.html" Twidale M. B., HYPERLINK "http://www.comp.lancs.ac.uk/computing/staff/dmn.html" . Nichols D.,  HYPERLINK "http://www.comp.lancs.ac.uk/computing/research/cseg/projects/ariadne/docs/design.html" Designing Interfaces to Support Collaboration in Information Retrieval, 1998, Interacting with Computers, 10(2), 177-93.
[VAN 01] Vanderdonckt J., Farenc C. (dir.), Tools for Working with guidelines, Springer-Verlag, 2001.
[VAN O3] Van Duyne D. K., Landay J., Hong J., The design of sites : Patterns, Principles and process for crafting a Customer Centered Web experience, Addison-Wesley, 2003.
[VIN 05] Vincent C., Delozanne E., Grugeon B., Gélis J.-M., Rogalski J., Coulange L., Des erreurs aux stéréotypes : Des modèles cognitifs de différents niveaux dans le projet Pépite, Actes de la conférence EIAH2005, Environnements Informatiques pour l'apprentissage humain, Montpellier, 25-27 mai 2005, INRP, 297-308
[VIV 96] Vivet M., Evaluating Educational Technologies: Evaluation of Teaching Material Versus Evaluation of Learning? Proceedings of CALISCE 96, 37-38.
. Chapitre rédigé par Élisabeth Delozanne.
En particulier par l’Association Francophone d’Interaction Homme-Machine http://www.afihm.org/
 On trouvera dans [MUL 99] un catalogue d’une trentaine méthodes de conception utilisant les scénarios.
 L’ergonomie ne se réduit pas à l’étude de l’utilisabilité mais les critères cités sont des critères issus de l’ergonomie [BAS 01]









 PAGE 26 Titre de l’ouvrage

Titre du chapitre  PAGE 25



Version provisoire
É. Delozanne(2005), Interfaces en EIAH, in M. Grandbastien, J.-M. Labat (eds.), Environnements Informatiques pour l’Apprentissage Humain, chapitre 10, Hermes (à paraître).



Ce processus est amorcé dès la formulation des spécifications initiales du produit ou du système.

Proposer des solutions de conception

Évaluer les conceptions par rapport aux exigences

Spécifier les exigences liées aux utilisateurs et à l’organisation

Le système répond aux exigences des l’utilisateurs
et de l’organisation

Comprendre et spécifier le contexte d’utilisation

Identifier la nécessité d’une conception centrée sur l’opérateur
humain


 :