Mémoire de Master Recherche en Informatiquenocremetz.free.fr/DEA/Memoire/RapportLatex.pdf · 2007-06-06 · Mémoire de Master Recherche en Informatique MODÉLISATION DES MÉCANISMES

Mémoire de Master Recherche enInformatique

MODÉLISATION DES MÉCANISMES D’ADAPTATION DYNAMIQUE ET CONTEXTUELLED’UNE INTERACTION MULTIMODALE

par Olivier Cremetz

Stage de février à juin 2007

Encadré par :Alain Derycke, Professeur des Universités

José Rouillard, Maître de conférencesVincent Chevrin, ATER (Polytech’Lille), Docteur en Informatique

Tuteur Polytech’Lille : Vincent Chevrin

Effectué au laboratoire LIFL/TRIGONEÉquipe NOCE : Nouveaux Outils pour la Coopération et l’Éducation

Master 2 Recherche en Informatique, USTL Lille 13éme année Génie Informatique et Statistiques, Polytech’Lille

Résumé

L’informatique ubiquitaire est au cœur de la nouvelle société de l’information. En effet,l’émergence de systèmes informatiques massivement distribués constitués d’une infrastruc-ture traditionnelle (PC, serveurs, etc.) ainsi que de millions de petits objets mobiles (télé-phones, PDA, etc.) permet aux fournisseurs de services d’offrir à leurs usagers une grandeflexibilité grâce à un accès distant et personnalisé à un vaste éventail de services. Les usa-gers utilisent de plus en plus ces appareils et veulent retrouver les mêmes services que surleur ordinateur personnels mais avec des dispositifs limités (clavier spécifiques, écrans troppetits, ...). C’est pourquoi, nous cherchons à contourner les problèmes qui peuvent subsisteren offrant d’autres services d’interactions multimodales. Ces services pourront être appor-tés localement par d’autres appareils afin de limiter les ressources utilisées par l’application.On doit donc pouvoir découvrir et additionner dynamiquement ces modalités sans inter-rompre l’interaction en cours. Cependant il est nécessaire de pouvoir s’adapter au contexted’interaction afin de pouvoir créer une application générique qui sera réutilisable dans tousles cas.

Mots clés : Interaction Homme-Machine (IHM), Informatique Ubiquitaire, multimodalité,contexte, fusion dynamique du flux d’interaction, plasticité.

1

Abstract

Ubiquitous computing is the new part of the information technology. Indeed, the emer-gence of information processing systems massively distributed consisted of a traditionalinfrastructure (PC, Server, etc) as well as million small mobile objects (telephones, PDA, etc)allows to the suppliers to offer to their users more flexibility, thanks to a distant and perso-nalized access to a vast range of services. Users uses more and more these kind of deviceand want them to provide the same services but with limited devices such as limited key-boards, little screens, ... That’s why we search for new solution in offering other multimodalinteraction services. These services could locally be brought by other apparatuses in orderto limit the resources taken by the application. We must thus be able to discover and adddynamically these methods without stopping the interaction in progress. However it is ne-cessary to be able to adapt to the context of interaction in order to be able to create a genericapplication which will be reusable in all cases.

Keywords : Human–Machine Interaction, Ubiquitous computing, multimodality, context-awareness, dynamic fusion, plasticity.

2

Remerciements

Les études théoriques du premier semestre de Master 2 Recherche en informatique s’ac-compagnent d’une période de stage de cinq mois, afin de faire découvrir et d’intégrer lesétudiants au monde de la recherche.

Ce stage m’a permis de concrétiser les connaissances théoriques acquises durant le pre-mier semestre et de les appliquer sur le domaine des interactions Hommes–machines.

C’est pourquoi, je tiens à remercier Mr Alain Derycke, professeur d’université et direc-teur du laboratoire LIFL–TRIGONE qui a accepté de m’accueillir au sein de l’équipe NOCE,Mr Vincent Chevrin, mon tuteur école pour Polytech’Lille et Mr José Rouillard pour l’aideprécieuse qu’ils m’ont apporté aussi bien sur le plan technique que scientifique durant ledéroulement de mon stage

Je tiens aussi à remercier toutes les personnes qui ont suivi de près ou de loin mon travail,et plus particulièrement l’ensemble de l’équipe NOCE, pour leur professionnalisme et leurbonne humeur.

Le stagiaire.Olivier Crémetz

3

Table des matières

1 Introduction 71.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1.1 Cursus scolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.2 Présentation de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.3 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Plan du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Plan de travail 10

3 Multimodalité et fusion de données multimodale 123.1 Terminologie : Modalité et Multimodalité . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Modalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Définition de la multimodalité . . . . . . . . . . . . . . . . . . . . . . . 133.1.3 Les avantages de la multimodalité . . . . . . . . . . . . . . . . . . . . . 143.1.4 10 mythes de l’interaction multimodale [Oviatt 1999] . . . . . . . . . . 14

3.2 Les propriétés CASE et CARE de la multimodalité . . . . . . . . . . . . . . . . 163.2.1 Le point de vue système : CASE . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Le point de vue utilisateur : CARE . . . . . . . . . . . . . . . . . . . . . 17

3.3 La fusion et la fission du flux d’interaction . . . . . . . . . . . . . . . . . . . . 193.4 La fusion en entrée du flux d’interaction . . . . . . . . . . . . . . . . . . . . . . 203.5 Les différentes approches de fusion . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5.1 Dialogue multimodal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.2 Moteur de fusion à base de règles . . . . . . . . . . . . . . . . . . . . . 213.5.3 Moteur de fusion d’événements . . . . . . . . . . . . . . . . . . . . . . 233.5.4 Approche par creusets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5.5 Plate-forme d’intégration multimodale du W3C [W3C 03] . . . . . . . 243.5.6 Les autres approches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Espace Problème : plasticité, contexte et modèle de tâche 284.1 Tendance actuelle en informatique . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Utilité, Utilisabilté et Universalité . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 La plasticité : Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5 Utilisation d’un modèle de tâche . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.5.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5.2 ConcurTaskTrees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4

TABLE DES MATIÈRES 5

5 Réalisation logicielle 365.1 Présentation générale du projet : Définition de l’Extended Personal User De-

vice (EPUD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 Scénarios d’étude envisagés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 La méthode du magicien d’Oz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4 Choix de la technologie d’implémentation . . . . . . . . . . . . . . . . . . . . . 41

5.4.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4.2 La Technologie AJAX (Asynchronous Javascript And XML) . . . . . . 425.4.3 VoiceXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.4 X+V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5 Implémentation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6 Algorithme de prise en compte du choix de modalité . . . . . . . . . . . . . . 455.7 Résultats et synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Conclusion et perspective 476.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Table des figures

2.1 Plan de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Propriétés CASE de la multimodalité (Source [Caelen 2000]) . . . . . . . . . . 163.2 Propriétés CARE de la multimodalité (Source [Caelen 2000]) . . . . . . . . . . 173.3 Illustration de la multimodalité en entrée (Source [Nigay 2005]) . . . . . . . . 193.4 Parallèlle entre la fusion et la fission du flux d’interaction (Source [Rousseau 2003]) 193.5 Architecture de l’application LIMSI-DRAW (Source [Bellik 1995]) . . . . . . . 223.6 Le Framework d’interaction multimodale (MMI) du [W3C 03] . . . . . . . . . 243.7 Détail du Framework d’interaction multimodale (MMI) en entrée du [W3C 03] 253.8 Détail du Framework d’interaction multimodale (MMI) en sortie du [W3C 03] 25

4.1 Hétérogénéïté des plateformes : Vue d’ensemble des principaux appareils mo-biles du marché. (source [Vanderdonckt 05]) . . . . . . . . . . . . . . . . . . . 29

4.2 Les trois « U »(Utilité, Utilisabilité, Universalité) [Calvary et al. 2002] : les troismaîtres mots en Ingénierie de l’Interaction Homme-Machine (IIHM). Les tra-ditionnelles Utilité et Utilisabilité modèrent la plus récente Universalité. . . . 31

4.3 Exemple d’interface utilisateur plastique au regard du dispositif d’interac-tion. Ici, l’IHM sert à contrôler le confort du domicile [Thevenin 1999]. CetteIHM est sensible au changement de plate–forme mais pas au changement del’environnement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Notation de CTT. Opérateurs principaux de la notation CTT . . . . . . . . . . 344.5 Exemple de définition des tâches avec CTT (Source [Le Bodic 2005]) . . . . . . 35

5.1 Exemple de découverte d’une capacité . . . . . . . . . . . . . . . . . . . . . . . 375.2 Proposition d’architecture pour l’Extended Personal User Device . . . . . . . 385.3 Schema du scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Méthode du Magicien d’Oz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.5 Architecture du langage X+V (Source [VoiceXML Forum 2004] . . . . . . . . . 445.6 Algorithme de prise en compte du choix d’une modalité . . . . . . . . . . . . 46

1 Annexe 1 : Les modes en entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 Annexe 2 : Les modes en sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 Annexe 3 : Les modalités en entrée . . . . . . . . . . . . . . . . . . . . . . . . . 494 Annexe 4 : Les modalités en sortie . . . . . . . . . . . . . . . . . . . . . . . . . 505 Annexe 5 : Les médias en entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Annexe 6 : Code XML de création de questionnaire . . . . . . . . . . . . . . . 507 Annexe 7 : Code XML d’un modèle de tâche . . . . . . . . . . . . . . . . . . . 518 Annexe 8 : Code XHTML+VOICE d’une question . . . . . . . . . . . . . . . . 529 Annexe 9 : Prototype : opérations de l’administrateur . . . . . . . . . . . . . . 5310 Annexe 10 : Prototype : Réponse á un questionnaire . . . . . . . . . . . . . . . 54

6

Chapitre 1

Introduction

1.1 Contexte du projet

1.1.1 Cursus scolaire

Ce stage d’une durée de 5 mois, du 31 janvier au 30 juin, finalise mon cursus de Mas-ter 2 Recherche en Informatique ainsi que ma dernière année d’école d’ingénieur à Polyte-ch’Lille. Ce stage a l’avantage d’être positionné dans le domaine de la Recherche en interac-tion Homme–machine.

1.1.2 Présentation de l’équipe

Mes travaux se sont déroulés au sein de l’équipe NOCE (Nouveaux Outils pour la Coopé-ration et l’éducation) du laboratoire LIFL–TRIGONE, dirigé par Alain Derycke, Professeurdes Universités. Ce laboratoire est pluridisciplinaire et mène depuis 1992 des travaux derecherche et de développement dans le domaine des systèmes sociotechniques favorisantl’apprentissage coopératif. Il a, de plus, acquis une grande expertise de recherche dans ledomaine du Travail Coopératif Assisté par Ordinateur (TCAO). Il a également développéde nombreuses approches pour la conception des systèmes interactifs tant pour le travailcoopératif que pour la recherche d’information. Des travaux sur la théorie de l’activité y ontaussi été menés avec la thèse de Grégory Bourguin [Bourguin 2000], et plus récemment dans[Bourguin et Derycke 2005]. Aujourd’hui, ce laboratoire veut se donner les moyens d’êtreplus présent au niveau international dans le domaine des EIAH (Environnements Informa-tiques pour l’Apprentissage Humain). La dimension de recherche sur les interactions et lesusages des technologies de l’information et de la communication y est très présente.

1.1.3 Contexte du projet

Ce travail de recherche de ce stage se situe à la croisée de plusieurs actions de recherchemenées par le laboratoire LIFL–TRIGONE. Il s’effectue dans le cadre du projet ANR (AgenceNationale de la Recherche) p-LearNet (2007-2009), dont le laboratoire TRIGONE est leaderet dans lequel il coopère avec d’autres laboratoires de recherche français et des entreprisescomme par exemple Auchan et La Poste. Ce sujet de stage s’intégre également dans le projetde recherche régional MIAOU (Modèles d’Interaction et Architectures Orientées Usages),soutenu par le programme Technologies Avancées pour la Communication. Enfin, ce travailfait suite à la thèse de Mr. Vincent Chevrin [Chevrin 2006] soutenue en avril 2006 et s’insèredonc dans les travaux actuellement menés par le laboratoire sur l’intermédiation servicescanaux dans le cadre d’interactions entre un utilisateur (clients, apprenants, tuteurs, etc.) et

7

CHAPITRE 1. INTRODUCTION 8

une organisation (entreprise de Vente à distance, centre de formation d’une entreprise oupublic, etc.).

De plus, ce travail s’articule avec un projet d’étudiants en Master Pro e-Service au seindu laboratoire LIFL–TRIGONE qui ont réalisé la partie fission de données multimodales ensortie.

Ce travail est très novateur dans ce domaine car l’informatique ubiquitaire est au coeur dela nouvelle société de l’information. En effet, l’émergence de systèmes informatiques mas-sivement distribués constitués d’une infrastructure traditionnelle (PC, serveurs, etc.) ainsique de millions de petits objets mobiles (téléphones, PDA, etc.) permet aux fournisseurs deservices d’offrir à leurs usagers une grande flexibilité grâce à un accès distant et personnaliséà un vaste éventail de services.

Le secteur de la formation, notamment celui de la formation continue ou de l’apprentis-sage tout au long de la vie, a commencé à utiliser le réseau Internet et les technologies Webpour rendre accessible à distance des contenus pédagogiques et des ressources humaines(tuteurs). Les technologies de l’e-Formation (ou e-Learning) se sont développées avec l’ap-parition de technologies spécialisées et de standards mondiaux favorisant l’interopérabilitéet les échanges de contenus.

1.2 Présentation du sujet

Le travail proposé se décompose en trois parties :– Dans un premier temps, je présente un état de l’art sur les travaux de recherche por-

tant sur la modélisation du contexte pour l’interaction (dans le domaine des Interac-tions Homme–Machines IHM). Cette étude devra permettre de proposer une spécia-lisation (affinement) de ce type d’approche et la production d’un méta-modèle for-malisant les mécanismes régissant la fusion de données (voir seconde tâche) contex-tuelle. Le point de départ de ces travaux pourra être basé sur [Henricksen et al. 2005],[Henricksen, Wishart et al. 2005] et [Clerckx et al. 2006].En d’autres termes, le travail consiste à déterminer les liens entre la fusion de don-nées (dans le cadre de l’utilisation de la multimodalité) et le contexte d’interaction. Parexemple, l’aspect technologique (du canal utilisé pour interagir avec le système), l’ac-tivité effectuée par l’utilisateur, etc. seront des facteurs déterminants qui vont avoir unimpact sur les mécanismes de fusion.

– En deuxième temps, je ferai une étude de l’art sur les mécanismes de fusion des don-nées en entrée dans le domaine de la multimodalité. Le point de départ de ces travauxse base sur les différents cas de multimodalité décrits par [Caelen 2000], à savoir CASEet CARE. Cette étude permet donc de proposer une solution visant à rendre la multimo-dalité contextuelle (et donc dynamique en fonction de l’évolution du contexte d’interac-tion), en s’appuyant sur une approche Multi-Agents [Jade] (on se basera sur les travauxeffectués dans le cadre de OAA (Open Agent Architecture) [OAA] sur la multimodalité).Ce travail correspond donc aux résultats de la première partie, à savoir, le méta-modèleformalisant les mécanismes régissant la fusion de données.

– En dernier temps, je réaliserai une application permettant d’enrichir la plate-forme Ubi-Learn (basée sur un système multi-agents) pour supporter des interactions multimo-dales dynamiques et contextuelles (pour le moment, uniquement certaines interactionsmulticanales sont gérées). Cette implémentation sera basée sur un scénario de PersonalTraining Assistant (PTA) donné. Les sources de contexte seront simulées et l’implémen-tation d’un générateur de paramètres de contexte est envisageable.

CHAPITRE 1. INTRODUCTION 9

1.3 Plan du rapport

En premier lieu, ce rapport présente mon plan de travail, puis un état de l’art sur la mul-timodalité en présentant les principales propriétés. Ensuite, je présenterai un état de l’artsur la plasticité des interfaces hommes-machines et une présentation de ma solution propo-sée. Enfin, je terminerai par un bilan du travail effectué et les perspectives d’évolution de cetravail.

Chapitre 2

Plan de travail

Pour ce travail de recherche, nous avons convenu d’une organisation de la manière sui-vante :

Dans un premier temps, je dois regarder les états de l’art aussi bien pour la multimoda-lité que pour la plasticité. Celà me permet de mieux cerner et d’étudier les mécanismes defusion (propriétés CASE1 / CARE 2 de la multimodalité) et d’en proposer une spécificationgénérique.

Dans un deuxième temps, je dois m’interesser à la dynamicité de cette fusion. Nous sou-haitons faire apparaître une modalité (ajout d’une compétence) et de pouvoir s’en servir dèsque l’application le permet. Cette fusion dynamique sera bien entendu paramétrable. Le pro-blème réside dans le fait que cette fusion ne peut pas se faire immédiatement [Thevenin 2001].Nous devons respecter la plasticité qui se définit comme étant la capacité d’une interface às’adapter aux contraintes matérielles et environnementales dans le respect de son utilisabi-lité. Il faut aussi éviter les ruptures (seamlessness) dans l’utilisation de l’application. C’estpourquoi, nous avons opté pour un travail d’étude sur les modèles de tâches. (Commentdécrire une tâche ?). Je m’interesserai donc au modèle CTT 3.

Ces tâches seront contextuelles. On pourra au moment de la transition de modalité vérifiersi cette modalité est cohérente dans l’utilisation et si cette tâche permet ce changement demodalité. Il faudra bien sûr organiser le feedback utilisateur. Lors de la découverte d’unemodalité, un dialogue doit s’instaurer entre l’homme et la machine (qui peut être un ordina-teur ou tout autre appareil).

Une application permettant de présenter ce mécanisme de fusion dynamique sera déve-loppée (chapitre 5).

En parallèle, un méta-modèle de la tâche contextuelle d’interaction homme-machine deplasticité permettant d’éclaircir ce type d’application sera réalisé.

Le but est de pouvoir implémenter une application générique qui puisse réaliser la fusiondynamique suivant le modèle de tâche.

La figure 2 schématise les différentes étapes de mon plan de travail.

1CASE : Concurrent, Alterné, Synergique, Exclusive développé partie 3.2.12CARE : Complémentaire, Assigné, Redondant, Equivalent développé partie 3.2.23CTT : ConcurTaskTrees

10

CHAPITRE 2. PLAN DE TRAVAIL 11

FIG. 2.1 – Plan de travail

Chapitre 3

Multimodalité et fusion de donnéesmultimodale

Ce chapitre est consacré à la multimodalité. Nous commençons par définir la multimoda-lité afin de fixer la terminologie employée dans la suite de ce mémoire. Ensuite, je parleraides propriétés ergonomiques de la multimodalité à savoir les propriétés CASE et CARE.Ces caractéristiques sont utiles pour pouvoir présenter les différents travaux existants surles mécanismes de fusion de modalités en entrée. Ceci est donc une première étape de travaildans notre approche qui nous permettra de présenter ensuite notre version d’un mécanismede découverte dynamique de modalité.

3.1 Terminologie : Modalité et Multimodalité

La modalité et la multimodalité sont deux termes qui peuvent être attaqués différemmentsuivant le point de vue que l’on souhaite entreprendre. Ces notions sont soit abordées par lecôté utilisation ou soit par le côté technologique. Nous nous placerons ici dans le domainede la technologie bien que notre approche soit centrée sur l’utilisateur car notre objectif estde réaliser un outil de développement.

3.1.1 Modalité

Laurence Nigay dans [Nigay et Coutaz 1996] propose comme définition d’une modalité :« une modalité est définie comme un couple <d, l> où d, désigne un dispositif physique et l, unlangage d’interaction. Un langage d’interaction se définit par un vocabulaire d’éléments terminauxet une grammaire. Les éléments terminaux sont produits ou captés par les dispositifs d’entrée/sortie ».

Cette définition repère deux niveaux distinct d’abstraction : le niveau physique et le niveaulogique représenté par le langage d’interaction. On peut donc dire qu’une modalité est baséesur la communication entre ces deux niveaux, c’est à dire entre le matériel et logiciel.

Nous pouvons donc retrouver ces modalités en entrées ou en sortie :

Modalité en entrée

De nombreuses possibilités sont offertes pour la multimodalité en entrée. Chaque jour denouvelles sortes de capteurs sont inventées tels que les capteurs infrarouges, magnétiquesou encore de température. Cet état de fait laisse un grand éventail de choix. La communi-cation de l’homme vers l’ordinateur se compose essentiellement d’actions que l’ordinateurdoit effectuer. L’enjeu principal est de traiter le plus rapidement l’énoncé d’entrée afin degarantir un temps de réponse acceptable.

12

CHAPITRE 3. MULTIMODALITÉ ET FUSION DE DONNÉES MULTIMODALE 13

Modalité en sortie

Les modalités de sortie offrent un choix plus restreint car c’est l’homme qui joue le rôle derécepteur (vision, ouïe, toucher). L’odorat et le goût sont, à l’heure actuelle, trop difficiles àmettre en œuvre dans un système informatique. Contrairement à la communication en en-trée, l’ordinateur a souvent besoin de communiquer de grandes quantités d’ informationsà l’utilisateur. La vision est pour cette raison le sens le plus utilisé (texte écrit, icônes sym-boliques, graphiques, etc.). L’ ouie est un sens en pleine expansion en informatique depuisl’apparition des ordinateurs « multimédias » qui sont équipés de matériel d’acquisition etde restitution de sons. L’audition offre des possibilités différentes de la vision : par exempleprévenir l’utilisateur de l’arrivée d’un message quand ce dernier ne regarde plus son écran.Le troisième sens, et le moins employé, est le toucher qui regroupe un certain nombre de dis-positifs novateurs à retour d’effort [Cadoz 94] : les manches à balai de certains simulateursd’avion reproduisent les secousses dues aux turbulences ou encore les bras manipulateurspeuvent être découplés de la réalité pour servir à manipuler des molécules fictives et per-mettre de « sentir » le contour des atomes qui la constituent.

3.1.2 Définition de la multimodalité

D’aprés la définition d’une modalité, la multimodalité est caractérisée par le préfixe multi.C’est à dire qu’un système multimodal combine plusieurs modalités à la différence d’unsystème monomodal. Un système est dit « multimodal » si il comporte au moins soit deuxmodalités pour l’entrée ou soit pour la sortie.

Le concept de multimodalité diffère de la notion de multimédia. Le média désigne le dis-positif mis en place pour faire circuler l’information alors que la modalité correspond à lanature de cette information.

– média : microphone, écran, clavier, souris, caméra, etc.– modalité : parole, vision, écriture, geste, etc.

Une interface multimodale est donc une interface homme–machine qui combine plusieursmoyens de communication entre l’utilisateur et la machine. Pour entrer des informations,l’utilisateur peut utiliser la voix, l’écrit, le geste ou tout autres dispositifs permettant decapter une information et pour restituer des informations, le système exploite le graphisme,le texte, le son et la voix. L’exemple le plus souvent utilisé est la combinaison du geste et dela parole (Le célèbre « Mets-ça ici » de [Bolt 1980], accompagné d’un geste de désignation).

Cependant la multimodalité est de nos jours peu exploitée. Les interfaces graphiques ac-tuelles n’utilisent qu’une partie très restreinte des capacités. Ces interfaces ont tendance àtout focaliser sur la vue (les informations sont affichées sur un écran) et quelques mouve-ments gestuels limités de la main, récupérés par le clavier et la souris. La manipulation defenêtres avec une souris et un clavier atteint donc rapidement ses limites. Depuis les inven-tions de ces dispositifs, les ordinateurs se sont enrichis avec de nouveaux périphériques, etun micro-ordinateur peut être utilisé pour capturer, avec un niveau de précision très élevé,de la parole, du geste, des images, reconnaître l’écriture et la voix ou toute autre informationde contexte, ouvrant de nouvelles possibilités d’interaction.

La multimodalité se définit comme l’utilisation de plusieurs modalités de manière alternéeou parallèle, de façon combinée ou redondante [Nigay et Coutaz 1994].

Si à l’origine, la multimodalité était étudiée pour améliorer l’efficacité de l’interaction entreun utilisateur et un système, la multimodalité se voit aujourd’hui comme un facteur d’adap-tation des interfaces hommes–machines aux ressources physiques disponibles comme auxvariations de l’environnement. Un changement de modalité implique un changement de


présentation logique (si le système représentationnel est changé) et/ou du niveau d’interac-tion physique (si le dispositif d’interaction est changé).

3.1.3 Les avantages de la multimodalité

La multimodalité présente des avantages non négligeables :– Elle favorise l’adaptation à des situations et à des profils d’utilisateurs variés. Si l’en-

vironnement est bruyant, l’utilisateur dispose de différentes modalités pour entrer sesdonnées. Si des données complèxes doivent être restituées, le système peut compléterun message audio d’un affichage textuel ou de graphismes. La multimodalité a aussil’avantage de favoriser l’appropriation des outils informatiques par des personnes por-teuses d’un handicap temporaire ou permanent.

– L’interaction multimodale apporte un réel gain en efficacité, en particulier si des mani-pulations d’objets graphiques sont nécessaires.

– Elle optimise la robustesse des applications utilisant la reconnaissance vocale, d’unepart en favorisant des énoncés structurellement plus simples, mais aussi en autorisantune désambiguisation mutuelle avec d’autres modes utilisés en parallèle. Les interfacesmultimodales facilitent aussi beaucoup la correction d’erreurs de reconnaissance.

– Les interfaces multimodales sont cruciales pour développer l’accès à l’information ensituation de mobilité et dans les systèmes embarqués. Or avec l’arrivée des nouvellesnormes de diffusion hertziennes d’information, GPRS, UMTS, Wifi et Bluetooth, de plusen plus de personnes vont être connectées en permanence. Les usages mobiles s’en trou-veront renforcés.

– De nombreuses études ont montré qu’indépendamment de l’efficacité objective enre-gistrée, les utilisateurs affirmaient leur préférence pour les interfaces multimodales parrapport aux interfaces monomodales.

3.1.4 10 mythes de l’interaction multimodale [Oviatt 1999]

Cependant dans [Oviatt 1999], Sharon Oviatt a repéré les mythes de l’interaction multi-modale :

1. Ce n’est pas parce qu’une interface est multimodale que les utilisateurs vont utiliser lamultimodalité : Dans QuickSet la multimodalité est utilisée dans 20% du temps d’unesession de travail. Les utilisateurs passent d’un mode à l’autre sans raison apparenteet restent unimodaux certainement pour des raisons de confort personnel. Cependantles commandes spatiales sont plus fréquemment multimodales ainsi que les informa-tions de taille, de forme des objets, de nombres, de lieux et d’orientations. La richessesémantique de l’action favorise la multimodalité.

2. Le pattern parole-pointage n’est pas le plus intéressant : Depuis le fameux « mets çalà » [Bolt 1980], la multimodalité a été centrée sur le paradigme de l’interaction syner-gique. Dans ce paradigme la parole est considérée comme mode sémantique dominantet le geste de désignation comme subordonné. En fait cette conception est une survi-vance du concept clavier/souris (c’est-à-dire de sélection sur une icône ou un menu),bien plus pauvre qu’une interaction qui utiliserait les mouvements gestuels, les expres-sions faciales ou corporelles, etc. Par exemple des études avec un stylo/voix montrentque la multimodalité est de 14% plus utilisée qu’avec une entrée souris/voix. L’utili-sation des déictiques est aussi plus fréquent de 20%.

3. La multimodalité ne signifie pas obligatoirement « parallélisme » : En effet on a constatéque bien souvent le geste précède la parole (99% des cas), même lorsque les deux


modes dénotent des informations synchrones comme les déictiques. Le degré d’an-ticipation dépend de la langue. Il n’y a finalement que 25% des énoncés qui sont véri-tablement simultanés : synchronie ne signifie pas simultanéité.

4. La parole n’est pas un mode « de base » dans un système multimodal : Cela n’estvrai que sur le plan historique. Depuis il y a bien des systèmes qui utilisent la mainet le regard par exemple comme modes d’entrée, notamment dans les systèmes mi-litaires. Le problème général de la multimodalité ne se pose donc pas en termes decommande+sélection, la commande étant linguistique et la sélection manuelle. Le pro-blème ne se pose pas non plus en terme de source principale/source secondaire danslequel on utiliserait la source secondaire dans le cas où la source principale serait dé-gradée.

5. Le langage multimodal ne diffère pas du langage unimodal : On peut dire seulementque le langage utilisé en contexte multimodal est syntaxiquement moins complexe,que les énoncés sont plus courts et que le débit est moins hésitant. Les ellipses sontplus fréquentes et les constructions linguistiques sont moins ambigues, car les énoncéssont plus compacts. Il semble que ces propriétés rendent le langage multimodal plusapte à une intégration dans un système homme-machine.

6. L’interaction multimodale ne favorise pas la redondance : On pourrait croire le contraire,mais cela ne va pas dans un sens d’économie du point de vue de l’utilisateur. Celui-ci va donc privilégier la complémentarité. Même dans le cas d’échec puis d’essais decorrection, l’usage de la redondance n’augmente pas de façon significative. La redon-dance n’est pratiquement utilisée que dans le sens d’une recherche de fiabilité.

7. Les erreurs sur un mode ne sont pas compensées par un autre mode : Il est illusoirede penser que l’on va masquer les insuffisance d’un mode (par exemple les erreursde reconnaissance de la parole) par un autre mode. En réalité les erreurs se cumulentd’un mode à l’autre. Mais les utilisateurs optimisent l’usage d’un mode au profit de telautre, après expérience faite de ses performances, ce qui rend somme toute, par effetindirect de l’usage, l’interaction plus robuste. Dans quelques cas cependant, lorsqueune double incertitude se produit dans les deux modes d’entrée, il est parfois possiblede recouper l’information sur un critère de cohérence sémantique.

8. Les utilisateurs n’organisent pas « leur » multimodalité de la même manière : Pour lesuns, ce qui est séquentiel, est parallèle chez les autres. Tel mode est dominant chez lesuns, et ne l’est pas chez les autres. Tel mode est persistant, etc.

9. Les modes ne sont pas équivalents : Leur pouvoir d’expression est différent sans par-ler de leur pouvoir perceptuel, qui paraît plus évident. Cela signifie que le geste (etinversement la parole) ne peut tout exprimer dans une interaction, il y a des limita-tions cognitives. Même si parfois on eut rapprocher deux modes, ils n’en différent pasmoins par leurs propriétés différentes : précision, latence, etc. Certains modes sont plusinconscients ou passifs que d’autres : la direction du regard par exemple.

10. Un système multimodal n’est pas plus efficace qu’un autre : On croit souvent qu’unsystème multimodal sera plus efficace qu’un système monomodal, car on pourra faireplusieurs choses en même temps, se reposer en passant d’un mode à l’autre, réduirela charge perceptive et cognitive, économiser le temps de planification, etc. Des expé-riences ont prouvé le contraire : une commande multimodale est souvent plus longueà exprimer qu’une commande monomodale, car il y a un coût dû à la multimodalité(par exemple la multimodalité produit un débit de parole plus saccadé et des hésita-tions plus fréquentes).


3.2 Les propriétés CASE et CARE de la multimodalité

Les propriétés CASE et CARE ont été instaurées pour étudier et classer les interactionsmultimodales du coté utilisateur comme du coté système.

3.2.1 Le point de vue système : CASE

CASE : Concurrent, Alterné, Synergique, ExclusiveLes propriétés CASE, présentées dans [Caelen 1991], sont au nombre de quatre et défi-

nissent des liens entre les modalités, dans le contexte d’une interaction multimodale côtémachine/système. C, A, S et E sont les initiales de quatre propriétés :

– C = Concurrente : deux tâches distinctes, en parallèle, pas de coréférence,– A = Alternée : une tâche, entrelacement temporel, en coréférence de modalités,– S = Synergique : une tâche, en parallèle, en coréférence de modalité,– E = Exclusive : une tâche à la fois sans usage de la multimodalité.

FIG. 3.1 – Propriétés CASE de la multimodalité (Source [Caelen 2000])

La Figure 3.2.1 représente les propriétés CASE de la multimodalité en entrée.– La multimodalité concurrente : plusieurs énoncés correspondant à plusieurs actions

sont produits en même temps en utilisant des modalités différentes. Les modalités sontdites concurrentes lorsque sont exécutées en deux tâches distinctes en parallèle, sans co-référence. Par exemple, un utilisateur dicte des phrases à son logiciel de reconnaissancevocale pendant qu’il joue au démineur à l’aide de sa souris.

– La multimodalité alternée : une seule modalité est utilisée à un instant donné pour uneaction, mais plusieurs sont utilisées pour une même tâche. Les modalités sont dites al-ternées lorsqu’il y a un entrelacement temporel pour effectuer une tâche, en coréférencede modalité. Par exemple, je fais un cercle avec ma souris et puis, ensuite, je prononce« trace ». Un cercle est alors dessiné dans ma fenêtre. Il y a bien ici un entrelacementséquentiel de mes modalités, gestuelle et vocale.

– La multimodalité synergique : plusieurs modalités sont utilisées par énoncé et en mêmetemps. La modalité employée est de type synergique lorsqu’une tâche est effectuée en


parallèle, en coréférence de modalité. Dans l’exemple précédent, je prononcerai « trace » enmême temps que je ferais le geste à l’aide de la souris.

– La multimodalité exclusive : une seule modalité est utilisée à un moment donné, et pourune tâche. La modalité employée est de type exclusive lorsqu’une tâche est exécutée àla fois, sans usage de la multimodalité.

3.2.2 Le point de vue utilisateur : CARE

CARE : Complémentaire, Assigné, Redondant, EquivalentLes propriétés CARE sont au nombre de quatre et définissent des liens entre les modalités,

dans le contexte d’une interaction multimodale côté utilisateur. C, A, R et E sont les initialesde quatre propriétés :

– C = Complémentarité, chaque mode est nécessaire (et contribue) à la compréhension del’action

– A = Assignation, l’usager choisit un mode récurrent particulier (ou un sous–ensemblede modes) pour s’exprimer,

– R = Redondance, l’usager utilise simultanément plusieurs modes à travers lesquels lesinformations sont redondantes,

– E = Equivalence, l’usager choisit indifféremment tel ou tel mode (ou un sous–ensemblede modes).

FIG. 3.2 – Propriétés CARE de la multimodalité (Source [Caelen 2000])

La Figure 3.2.2 représente les propriétés CARE de la multimodalité en entrée.Ces notions ont été initialement présentées par Jean Claude Martin [Martin 1994],

[Martin 1999]. Dans [Nigay et Coutaz 1994], Joëlle Coutaz et Laurence Nigay leur donnentune facture formelle. Enfin dans [Nigay et Coutaz 1995] les auteurs montrent leur utilitépour classer et surtout évaluer les systèmes multimodaux, par l’analyse des propriétés CAREdu point de vue système (S-CARE, "System CARE") et du point de vue utilisateur (U-CARE,"User CARE").

A l’origine, ces propriétés ont été introduites pour caractériser l’interaction multimodaleen entrée, ce qui nous intéresse ici mais peuvent néanmoins s’adapter pour la multimodalité


en sortie. Par exemple, les propriétés U-CARE [Nigay et Coutaz 1995] décrivent les choixdes modalités et de leurs usages effectués par l’utilisateur pour communiquer avec un ordi-nateur.

– Assignation : Cette propriété exprime l’obligation pour un état de départ et d’arrivéefixés d’utiliser une modalité. Cette propriété exprime donc l’absence de choix pour réa-liser une tâche. C’est le cas d’un utilisateur qui utiliserait toujours la voix ou du textepour effectuer une tâche définie.

– Equivalence : L’équivalence d’un ensemble de modalités est vérifiée si chaque modalitépermet d’atteindre l’état d’arrivée fixé depuis l’état de départ en une seule étape. Lanotion d’équivalence fait référence au fait que l’utilisateur ou la machine peut avoir lechoix entre plusieurs modalités pour formuler un énoncé particulier. Un utilisateur peutavoir le choix entre prononcer le mot « suivant » ou cliquer sur le bouton « suivant » àl’aide de sa souris.L’équivalence et l’assignation soulèvent le problème du choix des modalités.

– Redondance : La redondance dénote l’utilisation séquentielle ou parallèle de plusieursmodalités équivalentes. Elle consiste à transmettre un même message via différentesmodalités. En entrée, la redondance d’informations en provenance de l’utilisateur im-plique la prise en compte d’une seule des modalités par le système, l’autre pouvantéventuellement contribuer à désambiguïser l’expression obtenue. En sortie, la redon-dance est un choix de conception liée aux deux critères d’ergonomie d’observabilité etd’insistance. En effet si le concepteur a choisi de montrer de différentes manières unemême information, cela a pour conséquence de renforcer son observabilité et constitueaussi un moyen pour attirer l’attention de l’utilisateur. La saturation de tous les canauxsensoriels de l’utilisateur, par exemple, renforce les chances de perception de l’informa-tion : cet assertion peut être expliquée avec la théorie ICS 4 [Barnard 1993], qui modélisel’activité mentale de l’utilisateur en termes de flux de données entre des sous–systèmesdédiés à la perception (sous–systèmes perceptifs), la cognition (sous–systèmes centraux)et l’action (sous–systèmes effecteurs).En principe, l’analyse d’un énoncé transmis à travers une des modalités est suffisantepour dégager toutes les informations sémantiques véhiculées par cet énoncé sans avoirbesoin d’analyser les autres énoncés transmis sur les autres modalités. Par exemple, unutilisateur reçoit le résultat d’une requête vocalement au travers d’enceintes et textuel-lement au travers de l’écran.

– Complémentarité : La complémentarité entre les modalités d’un ensemble M exprimele fait que pour passer d’un état à un autre, il faille utiliser toutes les modalités de l’en-semble M. Cela signifie qu’aucune des modalités de l’ensemble M ne suffise à elle seulepour passer de l’état de départ à l’état d’arrivée. Toutefois, il n’est pas exclu qu’unemodalité non contenue dans M puisse permettre cette transition. Elle consiste donc àtransmettre différents messages représentant les constituants d’un même énoncé surplusieurs modalités. La compréhension de l’énoncé nécessite ici une « fusion » entre lesdifférents messages transmis à travers les différentes modalités. Par exemple, le systèmedit vocalement : « le résultat de votre requête est : » et liste un ensemble de réponses surl’écran.Comme pour la redondance, l’utilisation complémentaire de modalités peut être paral-lèle ou séquentielle.En appliquant ICS [Barnard 1993] à la perception d’informations complexes, il est doncpossible, mais non étudié ici, de déterminer des critères afin que des informations com-plémentaires puissent être perçues et interprétées correctement. ICS montre aussi quela combinaison d’informations est un phénomène complexe qui peut intervenir à diffé-

4ICS : Interacting Cognitive Subsystems


rents niveaux d’abstraction.En synthèse, L’existence de choix de modalités se traduit par l’équivalence, tandis que l’as-

signation désigne l’absence de choix. Complémentarité et Redondance traduisent la compo-sition de modalités. Nous avons montré que nous pouvons les affiner en considérant diffé-rents niveaux d’abstraction issus de la théorie ICS de psychologie cognitive.

3.3 La fusion et la fission du flux d’interaction

Le problème majeur dans la construction d’interfaces homme–machines multimodales sesitue au niveau de la fusion (en entrée) et la fission (en sortie) des informations modales.

FIG. 3.3 – Illustration de la multimodalité en entrée (Source [Nigay 2005])

D’après la figure 3.3, l’interaction multimodale entre l’homme et la machine consiste àproduire à partir d’une information à véhiculer (suivant une modalité ou une compositionde modalité et le contexte d’interaction) un énoncé multimodal. Pour celà, on a besoin defusionner ces différentes modalités afin de produire un seul énoncé compréhensible.

D’une manière générale, le mot fusion (du latin fusio, du verbe fundere qui signifie fondre)désigne l’action consistant à faire d’une ou plusieurs entités une unique entité. Ici, les entitéssont les unités d’information. La fission correspond au processus inverse. L’une et l’autretraduisent deux activités importantes pour l’interprétation et la restitution d’un énoncé.

FIG. 3.4 – Parallèlle entre la fusion et la fission du flux d’interaction (Source [Rousseau 2003])

La fusion peut intervenir en interprétation sur différents niveaux : les informations peuventprovenir soit de plusieurs canaux d’entrée ou soit de contextes différents. L’exemple de lacombinaison de la parole et du geste de désignation de [Bolt 1980] (« Put-that-there » ), né-cessite la fusion de l’événement parole reçu via le canal du microphone avec les événements


souris provenant certainement d’un autre canal. Un deuxième exemple connu est la fusionde clics souris répartis sur une palette et une zone de dessin pour dessiner une figure géo-métrique. Ces informations issues du même canal transitent selon des contextes différentspour être regroupés à un haut niveau d’abstraction.

En restitution, La fusion intervient également à plusieurs niveaux d’abstraction. Au niveaule plus haut, elle a lieu dans l’adaptation des informations du noyau fonctionnel aux besoinsde l’interface adaptés à l’utilisateur et à sa tâche. Au niveau le plus bas, elle se manifeste parexemple sous forme d’incrustations (vidéo et graphique).

La fission en interprétation traduit le besoin de décomposer une information issue d’uncanal ou d’un contexte pour franchir un niveau d’abstraction. Par exemple, l’acte de parole« dessine un cercle dans une nouvelle fenêtre » fait référence à deux domaines de discours :les figures géométriques (« dessine un cercle » ) et l’interface homme-machine (« nouvellefenêtre » ). Cette phrase dont le sens a pu être identifié le long d’un canal unique doit êtredécomposée en deux primitives de haut niveau du système : « créer fenêtre » et « créercercle » dans la nouvelle fenêtre.

La fission en restitution peu prendre plusieurs formes. La plus courante est la représen-tation multiple d’un même concept sur un canal donné. Par exemple, le concept de tempé-rature est restitué sous forme d’un thermomètre gradué ou d’un réel. On dit que les deuxreprésentations sont équivalentes. La représentation multiple peut aussi s’effectuer en co-référence sur des canaux distincts tel le message oral « attention à cette température » ac-compagné de l’affichage en rouge du thermomètre à surveiller. Dans ce cas, nous parlons decomplémentarité.

3.4 La fusion en entrée du flux d’interaction

On s’interesse ici à la fusion du flux d’interaction en entrée, c’est-à-dire que celle-ci va êtrecomposée du ou des canaux utilisés vers le système. En fait, les flux d’interaction provenantde l’utilisateur, et donc de tous les canaux (et/ou modalités) qu’il utilise, que ce soit un fluxde données ou un flux de contrôle, vont fusionner. Par ailleurs, cette opération demande unesémantique véhiculée par cet énoncé sans avoir besoin d’une grande synchronisation des in-formations pour pouvoir donner du sens à cette interaction. Au niveau de la multimodalité,la fusion du flux se fera sur un laps de temps très court.

Jean Caelen, dans son cours sur les systèmes interactifs multimodaux [Caelen 1995], relèveplusieurs questions à se poser lors de la conception d’un moteur de fusion :

– Quand la réaliser ?– au plus tôt (précoce)– au plus tard (différé)– par étapes

– Comment ?– autour d’une structure commune et d’un mode dominant : par exemple, on trans-

forme la parole en texte– « grammaire » d’unification (langagière bien formée)– sans mode dominant « grammaire » multimodale– par une théorie de l’action sans structure commune

– Où ?– centralisée dans le contrôleur de dialogue– de manière répartie et progressive– Avec quelle logique ?

– Suivant quels critères de fusion ?


– de proximité temporelle (règles sensori-motrices)– de cohérence structurale et/ou de complétude sémantique– d’isotopie sémantique : On regarde si les informations sont représentées suivant la

même sémantique.– fonction du contexte d’interaction– fonction des performances de l’usager– de logique actionnelle ou intentionnelle– etc.

Ces questions résument bien celles que je me suis posées. En effet, dans mon approche, lafusion sera réalisée le plus tôt possible mais dès que la logique actionnelle (vérifiée par lemodèle de tâche) le permet. Cette fusion sera réalisée en récupérant les données sous formetextuelle. La synthèse vocale permettra de remplir des champs d’un formulaire. Cette fusionsera réalisée du côté client avant d’envoyer les données au serveur. Il faudra bien sûr bornerles systèmes de reconnaissance avec une grammaire limitée.

3.5 Les différentes approches de fusion

Comme vu précédemment, il existe une multitude de critères pour effectuer la fusion.Nous allons dans cette section vous présenter les différentes approches de moteurs de fu-sion qui ont été exploitées. Depuis les années 80, avec l’arrivée du paradigme « Put–that–there » de [Bolt 1980], les recherches n’ont pas été nombreuses. Ce n’est que depuis 1990que les recherches sur les interfaces multimodales se sont véritablement développées.

3.5.1 Dialogue multimodal

Ce type d’approche s’appuie sur une étude fine sur la répartition du sens entre le langageet geste. Dans ce type de dialogue (dialogue de commande), la référence aux objets et auxactions constitue l’élément fondamental de toute interprétation.

Ce moteur de fusion, présenté dans [Bourguet 1992], a été conçu pour une application dedessin architecturaux multimodal. Cette application permet de créer, d’assembler, de modi-fier et de positionner des objets à l’aide de la parole et de gestes de désignation. Les moda-lités peuvent être utilisées seules ou être combinées. Par exemple, pour dessiner une portesur un mur déjà existant, l’utilisateur peut prononcer « dessine une porte sur ce mur » touten désignant le mur avec la souris

Ce moteur est décomposé en trois niveaux d’abstraction différents : le gestionnaire d’évé-nements (bas niveau), l’analyseur multimodal (niveau intermédiaire) et le contrôleur de dia-logue (haut niveau). La fusion des modalités est réalisée dans le modèle de la tâche à un hautniveau d’abstraction et elle est faite à bas niveau si les événements sont proches temporelle-ment.

Ce moteur est limité aux modalités de la parole et du geste désignation. Par contre, il offreles outils nécessaires à la mise en œuvre d’un système de communication multimodal.

Cette approche ne correspond pas à nos besoins car elle n’offre pas la possibilité d’êtreétendue par d’autres modalités. Cette méthode est très utile afin de résoudre les référenceentre les objets mais cela n’est pas notre cas.

3.5.2 Moteur de fusion à base de règles

LIMSI-DRAW, [Bellik 1992] [IHM 1992], est une application graphique simple qui a été dé-veloppée afin de tester ce type d’approche. Elle permet de créer et de manipuler des formes


géométriques élémentaires suivant un ensemble de commandes multimodales. Elle intègretrois périphériques en entrée (fig 3.5.2 ) : un système de reconnaissance vocale, un écran tac-tile et une souris. L’utilisation conjointe d’un écran tactile et d’une souris, qui peut sembler apriori redondante, permet d’obtenir une rapidité maximale dans la formulation des énoncésmultimodaux.

Par exemple, l’utilisateur prononce la phrase « triangle vert » en désignant les trois som-mets par la souris et/ou l’écran tactile. En maintenant son doigt sur l’écran tactile lors de ladésignation du troisième sommet, il pourra faire varier la forme du triangle en jouant sur cedernier sommet et en faisant glisser son doigt sur l’écran.

La stratégie d’intégration adoptée est du type fusion retardé. L’intégration peut être réali-sée sur 2 niveaux :

– la fusion locale : consiste à associer une donnée avec une référence à un argument– la fusion globale : consiste à rassembler dans une structure commune toutes les don-

nées nécessaires à l’exécution d’une commande. C’est donc cette fusion qui produit desénoncés.

La fusion locale a lieue si deux informations ont une complémentarité logique, de mêmetype ou avec une proximité temporelle. La fusion globale est effectuée si la structure com-mune contient une seule information de type référence à une commande, si une informationde type « entrée de donnée » ne fait pas l’objet d’une fusion locale et si les types des infor-mations sont compatibles.

FIG. 3.5 – Architecture de l’application LIMSI-DRAW (Source [Bellik 1995])

Les interpréteurs ont pour fonction principale de traduire les événements de bas niveauprovenant des périphériques (coordonnées x, y pour l’écran tactile, chaîne de caractères pourle système de reconnaissance vocale etc.) en informations de plus haut niveau, ayant une re-présentation unifiée. Le modèle du langage permet de décoder les informations d’entréeafin d’en produire un élement compréhensible comme par exemple, reconstruire une com-mande à partir des mots dictés ou retrouver la sémantique d’un geste. Les informationssont ensuite stockées dans une file avant d’être traitées par le contrôleur de dialogue qui


effectuera la fusion. Ce module traite l’information suivant son type (argument, donnée oucommande) et regarde si la fusion peut se faire. Un détail de ces règles de fusion est donnéedans [Bellik 1995].

Cette stratégie de fusion ne correpond pas à l’utilisation que l’on souhaite avoir car elle sebase sur des commandes à interpréter.

3.5.3 Moteur de fusion d’événements

Cette approche présentée dans [IHM 1992] [Gaildrat et al. 1993] a été démontrée dans uneapplication de modèlisation 3D. L’utilisateur peut décrire une scène (placement des objets,descriptions des propriétés de textures, couleurs, etc.) à partir de commandes orales ouécrites ou multimodales combinant parole et geste de désignation. Par exemple, pour dé-placer un objet sur une table, l’utilisateur peut prononcer : « Mets l’objet ici » et désigne enmême l’endroit souhaité, ici sur la table.

Pour définir une commande complète, nous devons décrire les actions, les arguments né-cessaires à l’exécution de l’action et les relations entre objets (par exemple, -posé-sur-, -collé-contre-,...). Dans l’exemple ci-dessus, l’action correspond à mettre, les arguments sont l’objetet l’endroit indiqué par la souris, la relation correspond à celle qui existe entre l’objet et l’en-droit. La fusion repose sur des contraintes temporelles, des connaissances sur l’utilisationdes médias et des connaissances sur l’état du dialogue.

Ce moteur de fusion présente le gros inconvénient d’étre dépendant de l’application (né-cessité de connaître des informations sur les actions possibles et sur l’utilisation des moda-lités). Dans notre cas, nous ne connaissons pas ces informations.

3.5.4 Approche par creusets

MATIS [Nigay 1994]. (Multimodal Airline Travel Information System) est un système d’in-formation multimodal sur les transports aériens. L’utilisateur lance des requêtes sur les vols(horaires de départ et d’arrivée, déjeuner à bord ou pas, etc.) entre deux villes. Ces requêtespeuvent être exprimées à l’aide de la souris (manipulation directe), à l’aide du clavier, demanière orale ou par combinaisons de ces 3 modalités comme par exemple suivant : « Quelssont les vols » à destination en cliquant sur la souris sur une ville et décollant avant entapant au clavier. Les sorties sont uniquement visuelles (graphiques et textuelles).

MATIS présente la particularité d’autoriser le dialogue à plusieurs fils d’activité. Il estdonc possible d’exprimer une nouvelle requête avant d’avoir fini l’expression de la requêtecourante. Pour basculer d’une requête à une autre il suffit de changer de focus à l’aide de lasouris.

Ce moteur de fusion traite des informations représentées dans un formalisme unique. Lesdonnées à fusionner sont représentées par des « creusets ». Les « creusets » sont des matricescorrespondant aux champs des requêtes de l’application. La fusion de deux « creusets » estun creuset.

Trois types de fusion sont mises en oeuvre selon le critère sur lequel elles se basent. Lamicro-fusion combine des événements ayant des intervalles temporels entrelacés. La macro-fusion combine deux événements non entrelacés mais temporellement proches. La fusioncontextuelle utilise le contexte courant de l’interaction. Ce moteur respecte une stratégie defusion précoce, c’est à dire qu’il n’y a aucune mise en attente et le retour d’information estimmédiat. Cette méthode qui est appliquée consiste à traiter les informations directementdans l’ordre d’arrivée (ordre qui ne correspond évidemment pas à l’ordre chronologiqueréel des informations) et à effectuer les fusions éventuelles quitte à devoir les défaire plustard si elles ne sont pas pertinentes. Cette solution présente aussi un inconvénient au niveau


du feed-back utilisateur. Aucun retour n’est produit consécutivement à une opération defusion et avant que l’énoncé ne soit complètement traité. Cette fusion précoce peut doncêtre source d’erreurs et il n’y a donc aucun moyen de vérification ce qui est un grave défauten cas d’utilisation de cette méthode dans notre approche.

3.5.5 Plate-forme d’intégration multimodale du W3C [W3C 03]

Le W3C 5 propose un framework général pour les systèmes interactifs multimodaux duweb.

Ce modèle, appelé plate-forme d’intégration multimodale (MMI), n’est pas une architec-ture mais se situe à un niveau d’abstraction supérieur. Une architecture indique commentles composants sont alloués aux matériel et au système de communication permettant à cesdispositifs de communiquer les uns avec les autres. Le framework MMI ne décrit pas ce lien.

FIG. 3.6 – Le Framework d’interaction multimodale (MMI) du [W3C 03]

Comme présenté sur la Figure ci-dessus, la plate-forme est constituée des composantsentrées et sorties, du gestionnaire d’interaction et les composants Fonctions de l’application,Sessions, Système et environnement.

Les modalités sont gérées dans les composants d’entrée et de sortie : les informations desdispositifs d’entrée (resp. sortie) sont captées (resp. organisées) puis rendues. Le gestion-naire d’interaction est le composant logique qui permet de coordonner les données et decontrôler le flux d’exécution des divers objets des composants d’entrée et de sorties.

Sur le schèma détaillé du composant d’entrée (Figure 3.5.5), on peut observer que les don-née sont d’abord identifiées et reconnues à l’aide d’une grammaire spécifique (comme laliste de mots que l’ont peut prononcer ou des gestes qu’on peut effectuer), puis ces donnéessont interprétées suivant la sémantique de l’utilisateur. Enfin la fusion des deux énoncéss’effectue dans le sous–composant d’intégration. Les données sont interprétées et annotéessuivant le langage EMMA. L’énoncé est ensuite combiné dans le gestionnaire d’interaction.

EMMA (annotations Multi-Modales extensibles) est un format d’échange de données pourl’interface entre les processeurs d’entrée et les systèmes de gestion d’interaction. Elle définira

5W3C : Le World Wide Web Consortium, est un consortium fondé en octobre 1994 pour promouvoir lacompatibilité des technologies du World Wide Web telles que HTML, XHTML, XML, RDF, CSS, PNG, SVG etSOAP. Le W3C n’émet pas des normes au sens européen, mais des recommandations à valeur de standardsindustriels.


FIG. 3.7 – Détail du Framework d’interaction multimodale (MMI) en entrée du [W3C 03]

les moyens pour que les systèmes de reconnaissance annotent des données spécifiques àl’application avec l’information telle que des niveaux de confiance, des intervalles de temps,le mode d’entrée (par exemple : combinaison de touches, parole ou stylet), des hypothèsesalternatives d’identification, et des résultats de reconnaissance partiels etc.

Le composant de sortie permet de générer du code suivant la modalité choisie. Cette gé-nération est complétée par l’utilisation des feuilles de style qui permettent d’améliorer lerendu de l’information.

FIG. 3.8 – Détail du Framework d’interaction multimodale (MMI) en sortie du [W3C 03]

À ce jour, ce framework reste une spécification. Les choix de stratégie et les critères defusion comme la proximité temporelle, la complémentarité logique, etc. sont laissés au dé-veloppeur.

Cette solution se base sur l’annotation EMMA afin de créer une structure commune mais


elle ne prend pas en compte le modèle de l’utilisateur et de son environnement. Cette nota-tion vient de plus allourdir et complexifier les informations à intégrer.

3.5.6 Les autres approches

Approche par composants : Application NEMO

Cette application a été présentée dans [Bouchet 2003] et permet à un utilisateur de décou-vrir, lire, poser ou supprimer des mémos liés à un endroit physique. Sur cette application 5modalités sont définies et peuvent être composées. : L’orientation, la géolocalisation, l’entréeau clavier, la souris et la voix. Cette approche se décompose en 3 composants :

– des composants élémentaires symbolisant les modalités (entrée et sortie), l’utilisateur etl’environnement,

– des composants de composition permettant la fusion des composants élémentaires enrespectant les propriétés ergonomiques des systèmes multimodaux,

– des composants d’assignation permettant de lier la partie interactive avec le reste del’application.

Ces composants permettent au concepteur et au développeur de disposer d’une plate-forme permettant la mise en place de plusieurs modalités et de réaliser leur combinaisondans un moteur de fusion général et paramétrable.

L’approche X+V [VoiceXML Forum 2004]

Une approche basées sur les standards pour les interfaces utilisateurs Multimodal est X+V(Xhtml + VoiceXML), qui a été spécifié dans le [VoiceXML Forum 2004]. X+V combine leXHTML pour l’interaction visuelle et le VoiceXML pour les interaction auditives, qui peutêtre supplémentaire ou exclusive pour interagir avec une application. La connexion entre lesdeux modèles séparés de dialogue est créée en utilisant Javascript et des définition implicitesdes dépendances sans l’utilisation d’aucune abstraction.

Cette solution m’est apparue comme une bonne approche de fusion car elle permet degérer les modalités voix et l’entrée au clavier seules ou combinées. Les données ainsi récu-pérées peuvent être manipulées facilement. Un détail des raisons techniques de ce choix estdonné dans la section 5.4.4.

D’autres approches comme l’utilisation des architectures distribuées d’agent, telles quel’architecture ouverte d’agent (OAA) [OAA], dans lequel les agents communiquent les unsavec les autres à l’aide d’un tableau noir central, est également pratique courante dans lessystèmes multimodaux. Cette méthode est assez lourde à mettre en place. L’utilisation dutableau noir correspondra donc aux champs permettant de récupérer les informations en-trées. D’autres systèmes comme le projet NICE [Corradini et al. 2003] mettent en place unsystème de scoring afin de choisir la modalité adéquate. Ce système doit connaître les mo-dalités disponibles avant l’execution du programme. Cette solution sera reprise pour classi-fier les modalités attachées aux tâches suivant leurs pertinences et pour assurer un meilleurchoix dans l’utilsation de l’application.

3.6 Conclusion

Ce chapitre a permis de comprendre ce qu’est la multimodalité avec ses avantages et sesinconvénients, et de montrer les avancées réalisé dans le domaine de la fusion d’interaction


multimodale. Les approches de fusions présentées dans ce paragraphe montrent une grandediversité. Tous proposent des solutions différentes pour fusionner les données. Le modèledu W3C permet d’avoir une approche générique pour les applications de type Web, ce quiest un de nos objectifs. Aucune de ces approches ne sont dynamiques. Les modalités sontconnues à l’execution du logiciel, c’est pourquoi, nous voulons qu’une découverte dyna-mique permette d’ajouter ou de retirer une modalité à la volée sans interrompre le dialogueentre l’utilisateur et la machine.

Chapitre 4

Espace Problème : plasticité, contexte etmodèle de tâche

L’arrivée massive de nouveaux dispositifs portables comme les PDA, les écrans tactiles,etc. a changé la vision de l’informatique et a créé de nouveaux besoins concernant la concep-tion et la réalisation des systèmes et des interactions hommes–machines.

Je commencerai donc par faire un point sur les nouvelles tendances de l’informatique, puisintroduirai le concept de contexte et d’utilisabilité, afin de présenter la notion de plasticitéet je terminerai par la présentation du modèle de tâche.

4.1 Tendance actuelle en informatique

L’emergence des réseaux sans fil et la multiplication des dispositifs (Figure 4.1) commeles PDA, smartphones ont révolutionné les applications informatiques, tant au niveau de laconception qu’au niveau de l’utilisation. L’informatique devient omniprésente. Nous sommespassés progressivement de l’informatique confinée aux systèmes ambiants, de l’utilisationsédentaire à une utilisation interactive mobile. Ceci nous amène à introduire les notionsd’ubiquité et de mobilité. Ces notions sont fondamentales pour l’évolution de l’informatiqueévanescente, pervasive, ubiquitaire ou ambiante (disappearing computer, pervasive compu-ting [Satyanarayanan 2001], ubiquitous computing [Weiser 1991] et [Weiser 1993], ambientintelligence [Ducatel et al. 2001], nomadic computing [Bagrodia et al. 1995] et[Cross-Industry Working Team 1995]).

La montée en puissance d’Internet et l’intégration des technologies adaptées à la mobilitévont changer les méthodes de développement des nouvelles applications en introduisant laprise en compte des informations contextuelles comme les données spatiales et temporellesrelatives à l’utilisateur.

Les applications doivent respecter les caractéristiques spécifiques aux environnementsmobiles. Ces appareils devront permettre de fournir un accès à des services et des ressourcesavec des entrées et sorties limitées, des capacités de stockage réduites mais qui nécessite unegrande puissance de calcul. Cela oblige donc à adapter la conception des applications auxcaractéristiques des réseaux et à l’adaptation au contexte géographique.

28

CHAPITRE 4. ESPACE PROBLÈME : PLASTICITÉ, CONTEXTE ET MODÈLE DE TÂCHE 29

FIG. 4.1 – Hétérogénéïté des plateformes : Vue d’ensemble des principaux appareils mobilesdu marché. (source [Vanderdonckt 05])

En résumé, pour créer une application mobile, il faut tenir compte des contraintes :– de mobilité : les utilisateurs seront en situation de mobilité ce qui rend l’utilisation com-

plexe. On est loin d’avoir un environnement de travail idéal et fixe, d’autant plus qu’ilsera susceptible de changer totalement avec les mouvements de l’utilisateur (mobilité).

– d’adaptation au public visé par l’application : les utilisateurs n’auront, dans la plupartdes cas, aucune formation formelle pour utiliser leurs technologies (périphériques). Lesconcepteurs devront penser que l’utilisation doit se faire de la manière la plus intuitiveplutôt que des ordinateurs à configurer, maintenir, etc.

– des capacités d’entrée/sortie limitées : les tailles d’écran vont s’améliorer en résolution,en termes de couleurs et de pixels par cm, mais ils seront toujours de petite taille étantdonné leur nécessité de portabilité. On peut d’ailleurs s’apercevoir que les appareilsmobiles tendent à être de plus en plus petits et légers et surtout hétérogènes. En ce quiconcerne le son, la qualité en sortie est bien souvent médiocre et en entrée la recon-naissance de la parole est généralement limitée. Les claviers sont limités en taille et ennombre de touches. En ce qui concerne les systèmes de pointage, ils sont habituellementdifficiles à utiliser, surtout dans un contexte de mobilité. De plus ils sont hétérogènes, cequi ne facilite pas le travail des concepteurs.

– de prise en compte des informations contextuelles comme par exemple la position cou-rante de l’utilisateur via un système GPS.

– d’adaptation pour le traitement multitâche. Le multitâche et le support pour l’interrup-tion d’une tâche sont un des points forts dans la conception pour les ordinateurs debureau. Les appareils mobiles sont plus sujet aux interruptions étant donnés les envi-ronnements dans lesquels ils sont utilisés.


Comme vu précédemment, la multimodalité joue de nos jours un rôle important dans lesnouvelles applications. L’utilisateur et le système ont la possibilité de combiner plusieursmodalités en fonction de la tâche, des préférences ou des intentions communicationnellesde l’utilisateur. Cependant, leur utilisation pose des problèmes d’interaction de plus en plusdifficiles à résoudre car les dispositifs d’entrée/sortie se multiplient et de très nombreusesmodalités d’interaction sont envisageables. Les combinaisons de ces modalités élargissentencore un espace de possibilités déjà très vaste.

4.2 Le contexte

Le besoin d’un accès ubiquitaire à l’information (au bureau, chez soi, dans le train, etc.) sefait sentir avec la venue de nouveaux matériels et le succès des ordinateurs de poche ou destéléphones portables, les avancées des technologies réseaux et du sans fil, offrent de nou-velles formes perspectives d’utilisation de ces appareils. Cette mobilité amène à prendre encompte les informations de contexte. Ceci est en particulier rendu possible par la création denombreux capteurs miniaturisés disponibles à des coûts réduits et permettant d’instrumen-talisé les environnements. De nombreux travaux de recherche s’intéressent à l’utilisation desinformations contextelles dans lequel l’utilisateur interagit avec le système. Cela permet auxapplications de s’adapter à la taille de l’écran ou à la présence ou non d’un clavier ou à d’autres contraintes comme les profils ou les préférences.

Selon Dey [Dey 2000], « Le contexte est toute information pouvant être utilisée pour carac-tériser la situation d’une entité. Une entité est une personne, un lieu ou un objet considérécomme pertinent pour l’interaction entre l’utilisateur et l’application ». Cette définition per-met de clarifier la notion de contexte mais elle soulève la problématique de définir ce qu’estune entité pertinente.

Bellik dans [Bellik 2006] étend cette définition en ajoutant la prise en compte de la dimen-sion temporelle et la dimension spaciale.

Dans mes travaux, je me baserai sur une approche à base de modèles [Arens 1995] pourspécifier le contexte d’interaction (modèle du système, modèle de l’utilisateur, modèle del’environnement, etc.). Pour développer le mécanisme de fusion dynamique des informa-tions multimodales, je dois prendre en compte, lors de l’ajout d’appareils offrant des nou-velles capacités d’interaction, certaines données contextuelles comme la disponibilité desmédias, les préférences de l’utilisateur, la localisation géographique des appareils etc. Dansle cadre du scenario de l’EPUD (section 5.1), La géolocalisation pourra être effectuée pardes capteurs de position GPS ou par le regroupement des informations des bornes WIFI. Ladisponibilité des médias sera donnée par l’acceptation ou non de l’ajout d’une compétenceet les préférences de l’utilisateur seront récupérées lors de la phase d’identification.

De nombreux travaux de recherche sont en cours pour définir une ontologie du contexted’interaction [Gu 2004] mais ils ne sont pas encore suffisamment abouti pour pouvoir êtrepris en compte. C’est pourquoi, pour le moment, il revient au concepteur de l’application dedécider des modèles et des critères à prendre en compte pour une application donnée.

4.3 Utilité, Utilisabilté et Universalité

La plasticité des interfaces est une combinaison de trois règles en ergonomie. Les applica-tions doivent être utiles, utilisables et universelles [Scholtz et al. 1999] face à la diversité desplates-formes, des environnements et des utilisations.

L’universalité est un thème de recherche nouveau et ses propriétés restent floues.[Calvary et al. 2002] définissent cinq dimensions émergentes de ce domaine :


– l’accessibilité humaine : offrir l’accès à tout individu quels que soient ses capacités ouhandicaps physiques et intellectuels, ses origines culturelles, sociales, etc. ;

– l’accessibilité fonctionnelle : donner à l’interface un caractère multi-usage et donnerainsi aux utilisateurs l’accès à différents services et informations. Cette dimension re-joint la notion de portail ou tunnel ;

– l’accessibilité topologique : permettre l’interaction quelle que soit la localisation phy-sique de l’utilisateur ;

– l’accessibilité temporelle : permettre l’interaction à tout instant ;– l’accessibilité matérielle : permettre l’interaction sur toute plate-forme.Le but de cette propriété n’est pas de donner accès à tout le monde (équité), pour tout (libéra-

lité), partout (ubiquité), toujours (atemporalité), sur tout (portabilité), mais de réfléchir á ce quel’application veut offrir en prenant compte de l’utilité et l’utilisabilité. (Fig. 4.2).

FIG. 4.2 – Les trois « U »(Utilité, Utilisabilité, Universalité) [Calvary et al. 2002] : les troismaîtres mots en Ingénierie de l’Interaction Homme-Machine (IIHM). Les traditionnelles Uti-lité et Utilisabilité modèrent la plus récente Universalité.

4.4 La plasticité : Définition

De nos jours, le nombre de périphériques ne cesse d’augmenter. Or ces périphériques sontde plus en plus différents. Certains ont des écrans très petits, d’autres plus grands, les réso-lutions sont aussi différentes et tous permettent de lire des contenus provenant d’Internet,certains périphériques n’ont même pas d’écran.

Actuellement, lorsque l’on doit concevoir une application Internet composée de N pageset que l’on a M périphériques, on doit créer N x M pages. On voit bien par cela que plusil y aura de périphériques, plus cela prendra de temps de créer une application multi-plateforme.

La plasticité des interfaces décrit une interface de manière abstraite. Si toutes les interfacesétaient créées de manière abstraite, on pourrait les transformer directement pour le péri-phérique demandé, on gagnerait alors beaucoup plus de temps dans le développement del’application.

La plasticité d’une Interface Homme–Machine dénote sa capacité à s’adapter au contexted’utilisation dans le respect de son utilisabilité [Thevenin 1999]. Dans cette définition :


– Le contexte est un couple « plate-forme / environnement » où la plate-forme est lesupport matériel et logiciel sous–tendant l’interaction. Par exemple, pour un PDA ouun téléphone portable. La taille de l’écran, les dispositifs d’interaction, les capacités decalcul et de communication doivent être modélisés dans le système afin qu’il soit capablede s’adapter à leur variabilité. L’environnement se réfère à l’environnement physiqueaccueillant l’interaction. Il est décrit par un ensemble d’informations, périphériques à latâche en cours, mais susceptibles de l’influencer. Par exemple, la luminosité, le bruit, lalocalisation géographique.

– L’adaptation est une réaction au changement de contexte. Comme le montre la figure 4.3,elle peut consister en un remodelage de l’interface ou en l’exécution d’une tâche (déclen-cher le chauffage à l’approche de l’occupant ; masquer les informations confidentiellesà l’entrée d’une personne dans une pièce). L’adaptation est faite pour le bien-être del’utilisateur, mais elle ne cible pas l’utilisateur. L’utilisateur est un utilisateur type définidans le cahier des charges.

– L’utilisabilité est évaluée sur la base de propriétés énoncées dans le cahier des charges.

FIG. 4.3 – Exemple d’interface utilisateur plastique au regard du dispositif d’interaction. Ici,l’IHM sert à contrôler le confort du domicile [Thevenin 1999]. Cette IHM est sensible auchangement de plate–forme mais pas au changement de l’environnement.

En bref, la plasticité d’une interface est une adaptation résolument ancrée sur la varia-tion des conditions physiques. Elle ne couvre donc pas l’adaptation aux changements d’étatmental de l’utilisateur.

4.5 Utilisation d’un modèle de tâche

Afin de se repérer dans les actions possibles dans notre application il est nécessaire demettre en place une analyse des tâches. Cette utilisation permettra de comprendre la dé-composition en action afin de réussir un objectif fixé et de pouvoir évaluer si une tâche esten cours ou non afin de basculer de modalité sans interrompre le dialogue avec l’application.Le modèle de tâche permet d’ordonnancer les actions à réaliser aussi bien sur la phase dedéveloppement que sur la phase d’éxecution. J’utiliserai ce type de modèle afin de me situerdans l’application et pour savoir si je peux déclancher ou non la découverte de modalités.Les tâches initialement terminées seront enregistrées comme telles et ne prendront pas encompte ce changement.


4.5.1 Définitions

Avant de définir la tâche, je commence par une définition d’un objectif. Un Objectif estdonc un état d’un système qu’un agent (humain) souhaite atteindre (écrire une lettre, obte-nir un diplôme, etc.) Un objectif peut être réalisé par des méthodes ou des outils différents.Suivant ces méthodes, on peut donc déterminer la tâche à effectuer. Pour accomplir un ob-jectif, il faut aussi s’y tenir dans le temps.

Une tâche est une activité (considérée comme) nécessaire, ou utilisée pour atteindre unobjectif en utilisant une méthode donnée. Une tâche est en général décomposable en sous–tâches, jusqu’à la une tâche élémentaire qui ne peut plus être redécoupée. Ces tâches élé-mentaires sont aussi appelées actions.

L’analyse des tâches consiste à relier objectifs, tâches et actions. Elle permet de comprendrela décomposition en action puis en tâche afin de réussir un objectif fixé. Cela permet dedéterminer la source d’un problème.

Le but de l’analyse des tâches est de produire une liste des tâches et avec leurs des-criptions et de leurs interactions. De nombreux modèles (formalismes) ont été dévelop-pés pour cela par exemple : MAD [Pierret-Golbreich et al. 1989], CTT [Paternò et al. 1997],GOMS [Card 1983], UAN [Hartson et al. 1992], etc..

Ces modèles permettent en général d’exprimer la décomposition d’une tâche en sous–tâches, l’ordonnancement de ces sous–tâches, de définir les buts et sous–buts de ces tâcheset les objets et moyens utilisés pour accomplir une tâche ou une action

Dans le domaine des interfaces homme–machine (IHM), L’analyse des tâches est une étapeinévitable car elle fixe un cadre et des objectifs au concepteur d’interfaces. Chaque interac-tion doit permettre de réaliser une tâche ou une partie d’une tâche de l’utilisateur.

L’analyse des tâches peut également servir à prédire ou à expliquer les performances d’unutilisateur avec une interface donnée. Il existe des modèles conçus pour effectuer une ana-lyse cognitive des tâches, dans l’idée de calculer à l’avance ou d’expliquer les performancesdes utilisateurs. Le plus connu de ces modèles est GOMS (goal, operator, method selection).Pour prédire les performance d’un utilisateur, GOMS prend en compte non seulement letemps d’exécution des opérations élémentaires (frappe d’une touche, mouvement de la sou-ris, etc.) et le temps nécessaire à la sélection des tâches.

L’utilisation d’un modèle de tâche permet donc :– d’améliorer la compréhension de l’application (et en particulier de son utilisation) ;– de découper les objectifs á atteindre en actions et d’enregistrer les résultats correspon-

dants ;– d’aider à la conception ;– d’évaluation l’utilisabilité et l’efficacité de l’application ;– d’aider l’utilisateur durant son travail (aide contextuelle) ;– de documenter l’application.

4.5.2 ConcurTaskTrees

Lors de mon étude, je me suis concentré sur le modèle de tâche ConcurrTaskTreesLa notation ConcurTaskTrees (CTT) peut être utilisée pour créer des interfaces utilisateurs

pour des appareils hétérogènes. Bien que la notation des tâches abstaites peut être employéepour créer des interfaces utilisateur multimodales, elle n’énonce rien au sujet de l’exécutionet du support réels des aspects d’exécution comme l’intégration de l’entrée utilisateur oul’adaptation de l’interface utilisateur selon les dispositifs disponibles.

Le modèle CTT (ConcurTaskTrees) élaboré par [Paternò et al. 1997] est une notation despécification de modèle de tâches définie pour surmonter les limitations des notations préa-


lablement utilisées pour concevoir des applications interactives. Sa principale caractéris-tique est d’être une notation facile à utiliser pour la conception d’applications industrielles.Le modèle CTT est basé sur trois points :

– une structure hiérarchique des tâches, orientée action utilisateur,– une identification des relations temporelles issus de Lotos [Bolognesi et Brinksma 89],– une identification des objets associé à chaque tâche et les actions permettant aux tâches

de communiquer entre elles.Le modèle CTT, qui est un modèle graphique (voir figure 4.5), possède quatres catégories

de tâches :– les tâches utilisateurs, ou cognitives réalisées entièrement par l’utilisateur,– les tâches applications effectuées complètement par le système,– les tâches interactions réalisées par les interactions de l’utilisateur avec le système,– les tâches abstraites raffinées par les catégories précédentes.Il existe dans cette notation de nombreux opérateurs temporels pour relier les tâches, La

figure 4.4 présente les principaux opérateurs de cette notation avec T1 et T2 représententdeux tâches distinctes d’un même niveau.

Notation SignificationT1|||T2 T1 et T2 peuvent être exécutées dans n’importe quel ordreT1 > > T2 T2 démarre après la fin de la tâche T1

T1 [] > > T2 idem avec en plus un passage d’information de la part de T1T1 [ > > T2 quand T2 démarre, elle désactive la tâche T1

[T1] T1 est une tâche facultativeT1* T1 est une tâche qui peut être répétée plusieurs fois

FIG. 4.4 – Notation de CTT. Opérateurs principaux de la notation CTT

Les tâches systèmes sont parfois omises afin d’améliorer la lisibilité du modèle en suppri-mant les activités cachées. C’est le cas pour l’exemple de la figure 4.5. Dans cet exemple, undécoupage plus fin des actions aurait pu être choisi, mais CTT à pour but d’exprimer l’en-semble des tâches réalisables par un utilisateur sur un système donné. Les tâches d’inter-action ne sont pas détaillées plus précisément. Leurs complexités ou leurs médias supportspeuvent toutefois être suggérés par un libellé.

Ce modèle a pour inconvénient de ne pas inclure la description des objets manipulés parles tâches, l’existance de modalités et le mode de présentation (graphique, sonore).


FIG. 4.5 – Exemple de définition des tâches avec CTT (Source [Le Bodic 2005])

4.6 Synthèse

Ce chapitre a présenté une vision des tendances actuelles présentes en informtique et apermis d’introduire les différents concepts utiles à la conception d’application plastique.Nous retiendrons ici la définition de la plasticité qui est la capacité à s’adapter au contexted’utilisation dans le respect de son utilisabilité [Thevenin 1999]. Enfin, j’ai présenté l’utilitéde la mise en place d’un modèle de tâche afin de pouvoir se repérer dans les actions quel’utilisateur entreprendra dans l’application. Ce modèle de tâche permettra de structurerl’utilisation de l’application et servira à ne pas interrompre le dialogue entre l’utilisateur et lamachine durant la découverte des modalités. Ces concepts seront utilisés dans le prototypedéveloppé (section 5).

Chapitre 5

Réalisation logicielle

L’objectif de ce travail de recherche est de définir, concevoir et réaliser un environnementlogiciel pour la conception et la réalisation d’interfaces multimodales. Comme étudié précé-demment, l’application doit donc être générique afin de pouvoir être extensible à d’autresmodalités et accepter la connexion aux différentes applications métiers.

Dans un premier temps, je vais présenter une vue générale du projet dans lequel ce tra-vail s’intègre, puis les scénarios d’étude et enfin l’implémentation de l’application avec sesdifférentes caractéristiques.

5.1 Présentation générale du projet : Définition de l’Exten-ded Personal User Device (EPUD)

Ce projet permet de poser les bases afin de créer l’Extended Personal User Device (EPUD)proposé par Alain Derycke. Cet appareil mobile se présente sous la forme d’un PC Portable,d’un UMPC, d’un PDA ou d’un smartphone qui peut être étendu par d’autres élémentsen apportant une compétence supplémentaire, comme par exemple, l’ajout d’un PDA per-mettant de réaliser la partie de synthèse vocale. Cette extensibilité permettra de résoudreles problèmes liés aux limitations des systèmes, comme les écrans trop petits, l’absence declavier, ...

L’EPUD sera surtout utilsé dans le contexte de la vente mais son application pourra êtreétendue à d’autres utilisations. Dans ce contexte, l’EPUD sera repésenté sous la forme d’unassistant de vente (PTA : Personal trading assistant) dans les domaines des produits de hautetechnologie. Ce PTA pourra être augmenté par de nouvelles capacités en entrée comme :

– Un dispositif de capture de la voix (micro Bluetooth). Le vendeur pourra reformuler lesrequêtes du client, ce qui lui permettra de ne pas taper sur un clavier très petit.

– D’autres dispositifs de capture d’informationL’ajout de capacité pourra se faire aussi en sortie comme :– Une oreillette Bluetooth pour communiquer des données privées au vendeur.– Un afficheur numérique grand format et pouvant être public (Shared Display). Cela

permettra de présenter les caractéristiques d’un produit au client du magasin sur ungrand écran et une fournir information précise. Le vendeur pourra connaître ou réviserses compétences techniques directement avec le client sans le laisser à l’abandon durantun recherche de renseignements. Cet afficheur si il n’est plus utilisé pourra servir desupport publicitaire pour le rayon.

– Un canal sonore public– D’autres dispositifs de partage d’information futurs.Cet EPUD est un dispositif équipé d’un processeur, d’un système d’exploitation adapté

36

CHAPITRE 5. RÉALISATION LOGICIELLE 37

et d’une machine virtuelle Java ou d’un navigateur internet par exemple. Ce dispositif pos-sède des caractéristiques limitées en entrée et en sortie mais l’utilisation du son ou d’unecamera video reste possible. On partira de l’hypothèse que cet EPUD possède les capacitésde traitement et de stockage suffisantes pour pouvoir supporter les opérations d’adaptationlocales. Cet appareil est aussi personnel, il est donc une partie de l’identité numérique del’utilisateur. Il pourra fournir par exemple une identification par mot de passe biométriqueafin de récupérer les informations du profil de l’utilisateur local.

Le Personal User Device joue le rôle de pivot, il est le seul appareil connu et accepté entrele mode local et internet, contrairement à beaucoup de travaux context-aware où le systèmepossède une connaissance globale des éléments. L’EPUD possèdra la faculté de découvrir etde réaliser la fusion et la fission des modalités grâce au module d’extension. Dans le domainede la vente, le PTA pourra accéder au système d’information du magasin et de l’enseigne etcommuniquer vers l’extérieur (Web et téléphone via VOIP). L’assistant de vente jouera aussile rôle de compagnon pour la formation en permettant de réviser ses compétences sur lesproduits mis en vente.

L’ajout des capacités d’interaction pose néanmoins des problèmes comme par exemple leproblème de la sémantique de découverte du contexte. On reste donc limité à un micro–monde. On ne pourra découvrir des éléments que si ils sont proches géographiquement etsi ces éléments autorisent l’utilisation de leurs compétences.

FIG. 5.1 – Exemple de découverte d’une capacité

L’exemple de la figure 5.1 montre l’arrivée de la compétence de reconnaissance vocaledans l’environnement de l’EPUD. Dans un premier temps l’EPUD détecte cet appareil puispar un dialogue entre ces deux dispositifs (acceptation, langage de communication) décide


d’ajouter cette compétence. Sur ce schéma, nous pouvons observer que l’EPUD est déjà reliéavec un système Large Display.

Le mécanisme de découverte se présente sous la forme suivante : Après l’identification,l’EPUD envoie la liste des compétences qu’il possède au serveur et commence le dialoguesuivant une utilisation normale. Lorsqu’un appareil doté des capacités d’extension se pré-sente à proximité, l’EPUD regarde et étudie les compétences de cet appareil et fait la de-mande d’ajout auprès de cet appareil. Si la demande est acceptée, l’EPUD envoie donc auserveur ses nouvelles compétences qu’il a reçu et demande donc de récuperer les informa-tions suivant ces capacités ajoutées. Le serveur, pour cela, étudiera la possibilité d’ajout ettransformera les informations à fournir.

L’aspect dynamique, l’acquisition, la notification de service, l’adaptation, l’utilisation de lanouvelle configuration peut donc poser des problèmes d’ergonomie : à quel moment peut-on basculer ? (surtout critique en entrée avec la multimodalité). C’est pourquoi je me basesur le modèle de tâche contextualisable : on peut décider si une modalité est disponible ounon afin de réaliser cette tâche. Pour celà je pose un verrou suivant que l’on est en train deréaliser la tâche ou non jusqu’à ce que la tâche permette le changement de modalité.

L’EPUD devient donc un nouveau terminal virtuel pour l’application et il sera le seulconnu des autres services. L’architecture de ce projet est construite de la manière suivante :

FIG. 5.2 – Proposition d’architecture pour l’Extended Personal User Device

L’architecture se décompose en 3 niveaux :– Le Niveau PAN (Personal Area Network) : qui comprends l’EPUD. Ce niveau est étendu

par d’autres appareils comme par exemple une oreillette BlueTooth, soit en local ou àl’aide d’un reseau local LAN1 non relié au réseau intranet ou internet.


– Le Niveau LAN (Local Area Network) : qui permet de communiquer avec les autresappareils du réseau sur l’intranet

– Le Niveau WAN (Wide Area Network) : qui permet de communiquer avec le réseauinternet

Les types d’extensions peuvent être variés : comme l’extension des modalité d’interactionen entrée ou en sortie avec l’utilisation de display ou le son mais des problèmes de confi-dentialité des informations sont à prendre en compte (doit-on diffuser ou non les données ?)

L’acquisition d’une nouvelle capacité via une extension repose sur la résolution du pro-bléme de cycle d’acquisition « agent »(pull ou push ?) et sur les contraintes des systèmesétendants comme le problème de la sémantique (assistée par l’usager), la décision d’inclu-sion ou non (contrôle par l’usager).

5.2 Scénarios d’étude envisagés

Le but de ce travail est donc de pouvoir réaliser une application multimodale : un moteurde fusion dynamique paramétrable.

Nous avons pensé à deux scénarios différents de type PTA (Personal Training Assistant) :

1. Formulaire riche avec multimodalité à la demande :Il s’agit de réaliser comme le montre la figure 5.3 une application de type web (Ajax)présentant un formulaire riche (champs texte, boutons radios, checkbox, listes, Dragand Drop, ...). Ce formulaire sera découpé en tâches. On remplit celui-ci au clavier eton simulera la découverte de la modalité à l’aide d’un bouton ou autre (arrivée d’unsignal provenant du réseau par une autre personne). Le but sera de proposer cettemodalité sans interrompre le dialogue de la tâche en cours. Ensuite on pourra revenirà une modalité de type entrée au clavier.

2. Recherche contextuelle de préférence à partir d’un enrichissement vocal :Cette application qui a un but plus pratique se présente sous la forme d’un assistantde vente. On choisit un domaine précis comme la vente d’appareil hifi ou télévision.L’objectif est de pouvoir proposer un choix suivant différents modèles proposés. Levendeur commence l’interaction en préselectionnant le type de produit sur son PTA etpourra déclencher la reconnaissance vocale grâce à un bouton, pour affiner son choixen répetant des mots clés (d’une grammaire chargée au préalable). Ces choix viendrontremonter les informations correspondants à ces critères dans le haut de la liste des pro-duits. Cela permet de présenter l’information rapidement au vendeur afin de proposerle meilleur choix à son client.

Dans un premier temps nous avons retenu le premier scénario qui permettra de mieuxmettre en avant les difficultés du modèle de tâche à utiliser.

En parallèle, il sera aussi important de développer le métamodèle d’IHM contextuelle.


Scénario 1

FIG. 5.3 – Schema du scenario 1


5.3 La méthode du magicien d’Oz

Afin de pouvoir simuler les parties du moteur de fusion qu’on ne peut dès lors implé-menter, comme la partie de découverte d’une modalité, on utilise la technique du magiciend’Oz :

Le principe est le suivant. Un opérateur humain, caché du sujet dans une autre pièce,simule une partie du fonctionnement du système sans que l’utilisateur le sache. Le sujet croitêtre face à un système déjà opérationnel alors qu’en fait, il ne l’est pas. Cette méthode dumagicien d’Oz est apparue dès 1988 dans l’étude de [Kennedy et al. 1988], et a été largementutilisée depuis. [Dahlback et al. 1993] a défini une amélioration de ce protocole. L’approchedu magicien d’Oz est souvent utilisée pour dépasser les limites des technologies actuelles.Ainsi, ce que les IHM multimodales informatisés ne sont pas encore capables d’accomplirefficacement et sans erreur, est simulé par un homme. L’utilisateur a donc plus de libertépour s’exprimer et pour interagir avec le pseudo-système, ce qui nous permet d’étudierses comportements de manière plus approfondie. La méthode du magicien d’Oz est aussiutilisée pour prédire si une interface sera efficace et/ou utilisable. On teste alors l’usage del’interface avant même de la concevoir dans sa globalité. Cela permet d’avoir un aperçu desdifficultés et de l’efficacité du système.

Dans notre étude, le compère changera le fichier XML contenant les modalités disponiblesdu coté client.

FIG. 5.4 – Méthode du Magicien d’Oz

5.4 Choix de la technologie d’implémentation

Afin de pouvoir développer une application générique, nous avons décidé de mettre enplace une architecture de type application internet. Dans les sections suivantes, je présentedonc les langages de programmation utilisés.

5.4.1 XML

Afin de construire notre modèle de tâche et de représenter les informations de la partiemétier, notre choix s’est porté sur le XML (eXtensible Markup Language). Ce langage a été


développé par le XML Working Group en 1996. En 1998 les spécifications XML 1.0 ont étéreconnues par le W3C (World Wide Web Consortium). Depuis, la notoriété et l’utilisation dece langage sont de plus en plus importants.

De nombreuses qualités peuvent lui être associées. Nous allons les rappeler brièvement.Tout d’abord, le XML doit se conformer à une spécification (XML 1.0) définie par le W3C, cequi fait de lui un standard. De plus, tout comme Java ou php, XML est portable. En effet, lecode XML se limite à du texte et il peut ainsi facilement se déplacer de plate forme en plateforme. L’utilisation d’XML va donc permettre une portabilité des données.

Pourquoi le XML ?

XML est un langage adapté à nos besoins car c’est un langage souple. A la différencede HTML, l’ensemble des balises utilisables n’est pas fixé au préalable, c’est un langagede balisage extensible. Cette propriété lui confère la possibilité de définir n’importe queldomaine d’application. De plus, ce langage permet une séparation totale du contenu et dela forme de représentation. En effet, les balises XML sont définies non pas en fonction de laforme de présentation finale mais en fonction du contenu associé à ces balises. Enfin, XMLoffre une totale liberté dans la définition des spécifications. Le contenu ainsi que les élémentset les attributs utilisés ne dépendent que du concepteur.

XML est particulièrement bien géré en PHP, qui propose dans ses librairies des parsersrapides et simples d’utilisation (notre choix a porté sur les plus connu d’entre eux DOM etsimpleXML). La combinaison PHP XML va nous permettre de faire du code portable avecdes données portables. Cette technologie peut être aussi utilisée facilement avec du codejavascript.

5.4.2 La Technologie AJAX (Asynchronous Javascript And XML)

AJAX, ou Asynchronous JavaScript And XML (« XML et Javascript asynchrones »), est unacronyme désignant une méthode informatique de développement d’applications Web. Àl’image de DHTML ou de LAMP, AJAX n’est pas une technologie en elle–même, mais unterme qui évoque l’utilisation conjointe d’un ensemble de technologies couramment utili-sées sur le Web :

– HTML (ou XHTML) pour la structure sémantique des informations ;– CSS pour la présentation des informations ;– DOM et JavaScript pour afficher et interagir dynamiquement avec l’information présen-

tée ;– l’objet XMLHttpRequest pour échanger et manipuler les données de manière asyn-

chrone avec le serveur Web.– XML et XSLT

Les applications AJAX peuvent être utilisées au sein des navigateurs Web qui supportent lestechnologies décrites précédemment. Parmi eux, on trouve Mozilla, Firefox, Internet Explo-rer, Konqueror, Safari ou encore Opera.

Avantages et Inconvénients de cette technologie

L’avantage de cette méthode est la vitesse à laquelle une application AJAX répond auxactions de l’utilisateur, dont les actions sont traitées (en partie au moins) localement par lenavigateur. L’utilisateur d’applications AJAX doit autoriser l’exécution de code Javascriptpar son navigateur, ce qui peut laisser craindre des problèmes de sécurité. Avec les versionsd’Internet Explorer 5 ou 6 pour Windows, il doit aussi autoriser les ActiveX car le composant


XMLHTTP n’y est pas natif comme dans ses concurrents (Firefox, Safari, Opera, etc.) ou laversion 7. Utilisant des techniques apparentées au HTML dynamique, les applications AJAXdoivent être testées sur chaque navigateur, en raison du non respect des normes officielles.Un autre inconvénient que l’on peut avancer est la question du référencement puisque les ro-bots d’indexation ne sont pas en mesure d’indexer les contenus engendrés dynamiquement.Enfin, en modifiant le contexte de navigation sans que l’utilisateur n’en soit nécessairementaverti (en fonction de son mode d’accès au Web), AJAX pose de nombreuses questions d’ac-cessibilité. C’est le cas notamment pour les utilisateurs de lecteurs d’écran ou de dispositifsd’agrandissement (loupes virtuelles).

Comparaison avec les applications Web traditionnelles

Les applications Web permettent aux utilisateurs d’effectuer des choix (suivre un lien,remplir et valider un formulaire). Une requête est alors envoyée au serveur HTTP, qui agiten fonction de l’action et des données reçues, et renvoie une nouvelle page. Ce fonctionne-ment consomme inutilement une partie de la bande passante, une grande partie du code(X)HTML étant commune aux différentes pages de l’application. Et parce qu’une requête auserveur HTTP doit être réalisée à chaque interaction avec l’application, le temps de réponsede l’application dépend fortement du temps de réponse du serveur HTTP. Cela conduit àdes interfaces utilisateurs plus lentes que leurs équivalents natives. Les navigateurs actuelsmettent les éléments communs en cache, donc le chargement de pages nouvelles n’obligepas le serveur à redonner les mêmes éléments à chaque fois.

Les applications utilisant les techniques AJAX quant à elles peuvent envoyer des requêtesau serveur HTTP pour récupérer uniquement les données nécessaires en utilisant la requêteHTTP XMLHttpRequest, et en utilisant la puissance des feuilles de style (CSS) ainsi que lelangage Javascript côté client pour interpréter la réponse du serveur HTTP. Les applicationssont alors plus réactives, la quantité de données échangées entre le navigateur et le serveurHTTP étant fortement réduite. Le temps de traitement de la requête côté serveur est égale-ment légèrement réduit, une partie du traitement étant réalisé sur l’ordinateur d’où provientla requête. En contrepartie, le chargement de la première page peut être pénalisé si l’appli-cation utilise une bibliothèque AJAX volumineuse (certains frameworks pèsent plus de 500ko !). Cependant cette application n’utilisera aucun framework afin de rendre l’applicationla plus légère possible.

La technologie AJAX est basée fortement sur l’objet XMLHttpRequest. Cet objet Javascriptpermet d’obtenir des données au format XML, mais aussi HTML, ou encore texte simple àl’aide de requêtes HTTP. On explique le succès récent de cet objet et la très grande utilisationqui en est faite actuellement (parfois au détriment de l’accessibilité d’un site) par la simplecréation du nom AJAX.

5.4.3 VoiceXML

Afin de réaliser la partie de traitement vocal de l’application, on utilise une technologievalidée par le W3C : le VoiceXML. Ce langage permet de réduire les charges de développe-ment des applications vocales. À ce jour, un très grand nombre d’acteurs de cette industries’accorde sur le fait que le développement de scénario vocaux est jusqu’à dix fois plus ra-pide en VoiceXML qu’avec un langage d’ancienne génération. Ce facteur est d’autant plusgrand que le projet est important. Dans le cadre de renouvèlement de plateforme, plusieursréférences récentes dans le monde bancaire et d’assurance ont permis à des intégrateurs dedéployer des services vocaux sur les mêmes webservices que ceux déployés pour le web.Le service vocal qui aurait nécessité 5 à 6 mois de développement spécifique et de mise


au point a été réalisé en 10 jours en VoiceXML. Cette rapidité de développement s’expliqued’une part par l’utilisation de standard et non d’un langage propriétaire nécessitant des spé-cialistes. D’autre part la « webisation » des applications métiers (accès en mode client légerweb) permet l’utilisation des mêmes infrastructures que celles développées par les serveursWeb, pour accéder aux systèmes d’informations (sécurité, passerelle, SGBD, serveur d’ap-plications). Tous ces services sont réutilisés pour accéder aux données centrales en tempsréel.

L’intégration d’un programme VoiceXML ne nécessite aucune recompilation du noyau carle VoiceXML est un langage interprété en temps réel. Parce qu’il est basé sur les technologiesWeb, le VoiceXML est adopté par les développeurs du Web et la création de portails vocauxs’effectue sans compétences particulières dans le domaine vocal.

5.4.4 X+V

Actuellement, les navigateurs Web courants n’intègre pas le langage VoiceXML mais il estutilisé en langage X+V (XHTML + Voice Profile) qui permet de combiner la partie graphiqueet la partie vocale en un seul langage. Cette technologie est actuellement supportée par deuxtypes de navigateurs web : Opéra et Access NetFront. Ces navigateurs ont l’avantage d’êtreimplémenté dans le monde de l’embarqué.

X+V combine le langage XHTML [XHTML] et une partie du langage VoiceXML (voir Fi-gure 5.5). Le code des deux langages est séparé, ce qui simplifie le développement et permetde développer le visuel indépendamment du vocal. Rappelons que XHTML est un langageHTML réajusté pour respecter totalement les règles XML. Ensemble, ces deux langages per-mettent aux développeurs d’ajouter de la voix en entrée et en sortie aux traditionnelles pagesWeb.

FIG. 5.5 – Architecture du langage X+V (Source [VoiceXML Forum 2004]


5.5 Implémentation de l’application

Afin de pouvoir développer un exemple concret d’application multimodale du scénario 1,nous avons pensé à concevoir une application de type Questionnaire multimodal éducatif.La prise en compte de la mesure de l’apprentissage grâce à l’utilisation de la multimodaliténe fait pas l’objet de cette étude.

Pour cela, j’ai mis en place une application de type Web avec l’utilisation des langages PHP5, suivant la technologie AJAX et l’utilisation du XHTML+Voice Profile (X+V) disponiblesur certains navigateurs comme Access NetFront et Opera 9.2. Cette technologie evite d’êtredépendant par rapport à un langage propriétaire. La partie voix respecte la norme du W3C :VoiceXML.

Cette application prend actuellement en compte les modalités entrée au clavier, souris etvoix.

Notre application se décompose en trois grandes parties :– La partie Métier : les questionnaires peuvent être créés par une interface permettant de

construire les fichiers XML de questionnaires. Une question est représentée par son in-titulé, une description facultative ainsi qu’une image permettant d’illustrer la question,le type de question : soit un Choix simple (Bouton radio, Liste déroulante ou texte libre)ou multiple (Checkbox, Liste multiple, drag and drop), afin de pouvoir répondre auxdifférentes questions.

– La partie Modèle de Tâche : comme pour la partie métier, est composée d’une interfacepermettant de construire le fichier correspondant à ce modèle. Un questionnaire est re-lié à un seul modèle et une tâche peut correspondre à une ou plusieurs questions. Lemodèle se compose de tâches caractérisées par un identifiant, le nom, la description dela tâche, puis l’ensemble des modalités disponibles par ordre de préférence et de possi-bilité ainsi qu’une modalité par défaut et le temps utile à l’execution de la tâche.

– La partie Framework : l’affichage des questionnaires se fait grâce à la mise en placed’un framework qui permet de construire les différents objets manipulables utilisant lamodalité parole ou l’entrée au clavier. L’ajout de nouvelles modalités pourra se faire fa-cilement car il suffira d’ajouter le code correspondant pour l’utilisation de cette nouvellemodalité.

La partie de découverte de modalité est simulée à partir de la technique du magicien d’Ozprésentée à la section 5.3. Actuellement, elle est gérée par la lecture d’un fichier XML conte-nant la liste des modalités du client. Ce fichier est lu si aucune tâche n’est en cours suivantun délai préalablement réglé. Cela permet de contourner la difficulté de reconnaissance d’unbranchement de microphone ou d’un clavier.

5.6 Algorithme de prise en compte du choix de modalité

Notre application permet, grâce à l’utilisation de la technologie AJAX, de gérer la décou-verte de modalités en raffraichissant la partie cliente sans recharger la page coté serveur.Le serveur contient toutes les modalités possibles pour réaliser une tâche, mais c’est du côtéclient que l’on doit faire la découverte et réaliser le choix ou non d’utilisation d’une modalitéparticulière.

Cette recherche d’appareils pouvant étendre l’EPUD, symbolisé dans l’application parl’ajout d’une modalité dans une liste, se fait lorsqu’une tache sera finie suivant un délaidonné. Le délai sera réglé au préalable par le concepteur du site Web.

Le questionnaire est décomposé en tâches et sous–tâches suivant un modèle spécifié.L’application respecte l’algorithme présenté figure 5.6 lors de l’ajout d’une modalité.


Si ajout ou retrait de modalité alorsSi tâche ou une sous–tâche est en cours alors

Enregistrer le changement et Attendre fin tâchefin siSi tâche est finie alors

Pour toutes les sous–tâches non finies faireNotifier serveur et récuperer le code généréAfficher code et Notifier le changement

fin pourfin si

fin si

FIG. 5.6 – Algorithme de prise en compte du choix d’une modalité

Afin de ne pas interrompre la tache en cours lors de la découverte d’une modalité, onattend que la tâche soit achevée. Un verrou est donc posé dès que le client a envoyé le signalde début de tâche : Soit par l’appui sur un bouton start ou soit par réception d’un focus surle tâche et est relaché à la validation de celle-ci.

La détection de modalité est réalisé par la technique du magicien d’Oz du côté client maispourra être rêalisée par la suite par un démon logiciel permettant la détection de matérielcomme par exemple l’ajout d’un périphérique amovible dans windows. Dans notre cas laliste des modalités est reconstruite à chaque fin de tàche ou si aucun verrou n’est posé,suivant un délai fixé par le concepteur de l’application.

5.7 Résultats et synthèse

Ce chapitre a pu démontrer notre proposition de réalisation d’un moteur de fusion dy-namique d’une interaction multimodale par une application concrète et générique : en casde changement d’application, il suffit juste de changer l’application métier correspondante.Ce prototype utilise des langages libres et est découpé de manière à être réutilisable dans laplupart de cas.

L’application a été testée et montre que cette technique permet bien de pouvoir changerles modalités dynamiquement sans interrompre l’interaction. L’annexe 9 montre les opéra-tions possibles pour un administrateur, c’est à dire l’enregistrement des modèles de tâche(annexe 7) et des questionnaires (annexe 6). Ces fichiers sont crées à l’aide d’une interface.Cette application est composée d’une soixantaine de scripts assez volumineux (entre 100 et600 lignes de code) mais ces applications sont très rapides au chargement. Des évolutionssur la découverte de modalités, comme par exemple, la mise en place d’un microphone,permettront d’arreter la simulation par la technique du magicien d’oz.

Chapitre 6

Conclusion et perspective

Nous concluons ce mémoire de master recherche par un bilan de notre travail puis nousexposons les perspectives que nous envisageons tant sur le plan théorique que sur le plande la réalisation logicielle.

6.1 Conclusion

A travers cette étude, nous avons tout d’abord présenté le domaine de la multimodalité.Cette présentation s’est traduite par l’introduction du vocabulaire et des notions rattachésà ce domaine. Nous nous sommes donc attachés au problème de la fusion du flux d’in-teraction. Une analyse d’un ensemble de systèmes de fusion multimodal a également étéeffectuée afin de souligner et caractériser l’évolution du domaine. Enfin, nous avons mis enévidence les composantes pertinentes à prendre en compte dans le cadre de la conceptiond’un système multimodal.

Afin de réaliser notre application de fusion multimodale, il a fallu présenter les conceptsd’utilisabilité, de plasticité, de prise en compte du contexte et d’introduire les modèles deTâches.

Puis, nous avons validé les concepts émis au cours de cette étude à travers une appli-cation ayant pour objet la simulation de la découverte dynamique de modalité sans inter-rompre l’interaction en cours. Cette application test a été l’occasion de mettre en œuvre demanière concrète le processus de fusion dynamique et de souligner l’intérêt des différentspré-traitements mis en place.

Cette étude fera l’objet d’une soumission d’un article pour présenter ce nouveau méca-nisme de fusion dynamique et contextuel d’un flux d’interaction multimodal. En effet, à cejour, tous les systèmes présentés ont connaissance des modalités présentes avant l’éxecu-tion de l’application. Cette approche innovante de découverte pourra ouvrir la porte à unnouveau style de conception et d’implémentation de systèmes multimodaux.

6.2 Perspectives

Cette proposition de mécanisme de fusion dynamique et contextuel d’un flux d’interac-tion multimodal n’est pas parfaite en tous points. L’application fait appel au langage X+Vqui limite pour l’instant l’utilisation de la plate–forme : en effet, à ce jour, ce langage estimplémenté dans deux navigateurs : Access Netfront et Opera. Ce choix du langage m’a étéimposé par les contraintes techniques. Il limite l’utilisation de nouvelles modalités à causedu respect du schéma de conception (la DTD) du langage. Il faudrait prévoir une application

47

CHAPITRE 6. CONCLUSION ET PERSPECTIVE 48

permettant de réaliser la reconnaissance vocale sur l’appareil local et envoyer cette recon-naissance à un serveur vocal afin qu’il nous renvoie la valeur interprétée. Cependant cettesolution aurait rendu l’application trop lourde en temps d’accès et de réponses, ce qui n’estpas le but recherché.

Cette application permet de gérer la découverte dynamique de modalités de façon géné-rique pour les applications Web sous PHP et AJAX. Le découpage de l’application avec lapartie métier permet de construire d’autres systèmes. Cette application mise en place a ététestée de manière exhaustive : Des tests sur d’autres applications et d’utilisateurs devrontêtre menés.

Le mécanisme de découverte de modalités devra être implémenté. À ce jour cette partie estsimulée grâce à la technique du magicien d’Oz par une lecture d’un fichier XML côté clientreprésentant les modalités disponibles. Pour ce type d’application, un mécanisme Plug andPlay de découverte de présence d’un microphone serait nécessaire.

Enfin, cette application pourrait faire aussi l’étude de la mesure de la capacité d’apprentis-sage dans le contexte de la multimodalité. Apprenons nous mieux en utilisant notre mémoirevisuelle ou auditive. Cette étude pourrait donc ainsi être menée.

Annexes

Systèmes moteurs Organes correspondants Modes correspondantsSystème vocal Le larynx, et la cavité bucco-pharyngée Oral

Système musculaire Les fibres musculaires,nerfs ... les Actionnel ou Gestuel

FIG. 1 – Annexe 1 : Les modes en entrée

Sens Organes correspondants Modes correspondantsLa vue Les yeux VisuelL’ouïe Les oreilles Auditif

Le goût La langue GustatifL’odorat Le nez Olfactif

Le toucher L’enveloppe corporelle, les couches musculaires, TPK (Tactilo–les récepteurs articulatoires et vestibulaires Proprio–Kinesthésique)

FIG. 2 – Annexe 2 : Les modes en sortie

Entrée Dispositifs CorrespondantsVisuel Désignation, capture du regardAuditif Reconnaissance VocaleTactile Clavier, souris, stylet, écran tactile, interface tangible,

Gant de données, reconnaissance du geste, etc.

FIG. 3 – Annexe 3 : Les modalités en entrée

49


Modes en sortie Exemples de modalitésVisuel Photo, Dessin, Peinture, Logo, Icône,

Diagramme, Texte, Image de synthèseAuditif Parole, Voix de synthèse, Musique, Chant

TPK Texte Braille, Image en relief,Retour tactile et//ou d’effort

FIG. 4 – Annexe 4 : Les modalités en sortie

Modes d’entrée Médias du modeOral Système de reconnaissance vocale

Gestuel Clavier, souris, TrackBall, joystick, stylo, écran tactile,gant numérique, caméra, oculomètre

FIG. 5 – Annexe 5 : Les médias en entrée

<?xml version="1.0" encoding="ISO-8859-1"?><qcm>

<titre>QCM sur les Capitales</titre><description>Questionnaire sur les Capitales</description><ModeleTache>462379607b5a4</ModeleTache><question><q>Capitale de L’Italie</q><image>imgq_0.png</image><explic>Italie est un pays d’Europe meridionale.</explic><typeQuestion>radio</typeQuestion><idTache>T1</idTache><reponses><rep bonne="faux">Milan</rep><rep bonne="vrai">Rome</rep><rep bonne="faux">Naples</rep><rep bonne="faux">Parme</rep><rep bonne="faux">Turin</rep>

</reponses></question><question><q>Villes de la france</q><image>imgq_1.png</image><explic>France est le plus grand etat de l’Union europeenne</explic><typeQuestion>select</typeQuestion><idTache>T11</idTache><reponses><rep bonne="faux">Milan</rep><rep bonne="vrai">Paris</rep><rep bonne="faux">Berlin</rep>

</reponses></question>

</qcm>

FIG. 6 – Annexe 6 : Code XML de création de questionnaire


<?xml version="1.0" encoding="ISO-8859-1"?><taskModel>

<titre>Modele de Tache N1</titre><description>Modele de Tache Exemple pour QCM</description><task><id>T1</id><nom>Tache1</nom><description>Tach e1Desc</description><TypeModaliteDefault>VOIX</TypeModaliteDefault><tempsTache>55</tempsTache><modalite><modaliteTache ordre="1">VOIX</modaliteTache>

</modalite><task><id>T11</id><nom>Tache11</nom><description>Tache11Desc</description><TypeModaliteDefault>VOIX</TypeModaliteDefault><tempsTache>225</tempsTache><modalite><modaliteTache ordre="1">VOIX</modaliteTache><modaliteTache ordre="2">ENTREECLAVIER</modaliteTache>

</modalite></task><task><id>T12</id><nom>Tache12</nom><description>Tache12Desc</description><TypeModaliteDefault>VOIX</TypeModaliteDefault><tempsTache>34</tempsTache><modalite><modaliteTache ordre="1">VOIX</modaliteTache><modaliteTache ordre="2">ENTREECLAVIER</modaliteTache>

</modalite></task>

</task><task><id>T2</id><nom>Tache2</nom><description>Tache2Desc</description><TypeModaliteDefault>ENTREECLAVIER</TypeModaliteDefault><tempsTache>500</tempsTache><modalite><modaliteTache ordre="1">ENTREECLAVIER</modaliteTache>

</modalite></task>

</taskModel>

FIG. 7 – Annexe 7 : Code XML d’un modèle de tâche


<?xml version="1.0"?><html xmlns="http://www.w3.org/1999/xhtml"

xmlns:vxml="http://www.w3.org/2001/vxml"xmlns:ev="http://www.w3.org/2001/xml-events"xmlns:xv="http://www.voicexml.org/2002/xhtml+voice">

<head><title>Capital de la France</title>

</head><body bgcolor="pink" ev:event="load" ev:handler="#capital"><h1> Capital </h1>

<vxml:form id="capital">

<vxml:field xv:id="capital_name" name="capital_name"><vxml:grammar> <![CDATA[

#JSGF V1.0;grammar m_name;public <m_name> = Lyon | Londres | Paris | Miami | New York | chicago ;

]]></vxml:grammar>

<vxml:prompt> Capitales</vxml:prompt>

<vxml:prompt xv:src="#capital_label"/><vxml:catch event="help nomatch noinput">Quelle est la capitale de la france

</vxml:catch></vxml:field>

</vxml:form>

<xv:sync xv:input="ml" xv:field="#capital_name"/><xv:cancel id="voice_cancel"/>

<p>Selection de la capitale de la france</p><form id="movie_query" >

<p>Le choix peut se faire selon les valeurs suivantes :</p><br/><table border="0" cellpadding="10" ><tr><td>Lyon</td> <td>Londres</td><td>Paris</td></tr><tr><td>Miami</td><td>New York</td><td>Chicago</td></tr></table><br/><br/>

<label id="capital_label"> Quelle est la capitale de la France<input name="ml" type="text"/></label><br/><br/><input type="submit" value="Submit"/><input type="reset" value="Reset" ev:event="click"

xv:handler="#voice_cancel"/></form>

</body></html>

FIG. 8 – Annexe 8 : Code XHTML+VOICE d’une question


FIG. 9 – Annexe 9 : Prototype : opérations de l’administrateur


FIG. 10 – Annexe 10 : Prototype : Réponse á un questionnaire

Bibliographie

[Arens 1995] Arens, Y., Hovy, E. H., The Design of a Model-Based Multimedia Interaction Mana-ger, in Artificial Intelligence, vol. 9, num. 3, pp. 167–188, 1995.

[Bagrodia et al. 1995] Bagrodia, R., Chu, W.W. et Kleinrock, L., Vision, Issues, and Architecturefor Nomadic Computing, IEEE Personal Communications, pp. 14-27. December 1995.

[Barnard 1993] Barnard, P. et May, J., Cognitive Modeling for User Requirements. Livre édité parByerley, Barnard, et May, Computers, Communication and Usability : Elsevier. 1993.

[Bellik 1992] Bellik, Y., Teil, D., Multimodal Dialog Interface, WWDU’92, Berlin, Septembre 1992.

[Bellik 1995] Bellik, Y., Interface multimodales : concepts, modèles et architectures, Thèse de Doc-torat en Informatique, Université de Paris XI, 1995.

[Bellik 2006] Bellik, Y., Présentation multimodale de l’information, Habilitation à diriger des re-cherches, Université de Paris XI, 2006.

[Bolognesi et Brinksma 89] Bolognesi, T. et Brinksma, E., The formal description technique LO-TOS, introduction to the iso specification langage lotos. Elsevier Science Publishers.1989.

[Bolt 1980] Bolt, R.A., Put-that-here : voice and gesture at the graphic interface. Computer Gra-phics, 14, pp. 262–270, 1980.

[Bouchet 2003] Bouchet, J., Approche à composants pour la conception et le développement d’in-terface multimodales, mémoire de DEA, Université de Grenoble 1, 2003.

[Bourguet 1992] Bourguet,M. L., ICPplan : dialogue multimodal pour la conception de plans ar-chitecturaux, 19èmes JEP, pp. 369-374, Mai 1992.

[Bourguin 2000] Bourguin, G., Un support informatique à l’activité coopérative fondé sur la Théo-rie de l’Activité : le projet DARE, Thèse de Doctorat en informatique, USTL, 2000.

[Bourguin et Derycke 2005] Bourguin, G., Derycke, A., Co-evolution inside Interactive Systems- Reflections about results coming from the Activity Theory for supporting Collectiveand Distributed Practices. RIHM, vol6, N1 pp 1-31, 2005.

[Caelen 1991] Caelen, J., Coutaz, J., Interaction multimodale Homme-Machine : quelques pro-blèmes généraux., IHM’91, Dourdan, pp 41-57, 1991.

[Caelen 1995] Caelen, J., Systèmes interactifs multimodaux, 1995.

[Caelen 2000] Caelen, J., 10 ans de recherches ... en multimodalité(s), Colloque sur les InterfacesMultimodales, IRIT. Toulouse, 09/10 Mai 2000.

[Calvary et al. 2002] Calvary, G., Coutaz, J., Plasticité des interfaces : une nécessité, Actes desdeuxièmes assises nationales du GdR I3, Nancy, Décembre 2002.

[Card 1983] Card, S.K., Moran, T.P., Newell, A., The psychology of Human Computer Interac-tion, Lawrence Erlbaum Associates, 1983.

[Chevrin 2004] Chevrin, V., Les interactions multimodales et multicanales dans UMR. RencontreJeunes Chercheurs IHM, Lacanau. 2004.

55

BIBLIOGRAPHIE 56

[Chevrin 2006] Chevrin, V., L’Interaction usagers/services, multimodale et multicanale : une pre-mière proposition appliquée au domaine du e-Commerce, Thèse de Doctorat en informa-tique, USTL, 2006.

[Clerckx et al. 2006] Clerckx, T., Van den Bergh, J., Coninx, K., Modeling Multi-Level ContextInfluence on the User Interface. PerCom Workshops 2006 : 57-61., 2006.

[Corradini et al. 2003] Corradini, A., Mehta, M., Bernsen, N. O., Martin, J.-C., Abrilian, S.,Multimodal input fusion in human–computer interaction. To appear in Proceedings ofthe NATO-ASI Conference on Data Fusion for Situation Monitoring, Incident Detec-tion, Alert and Response Management. Yerevan, Armenia, 18-29 August 2003.

[Cross-Industry Working Team 1995] Cross-Industry Working Team, Nomadicity in the NII,Disponible sur http ://www.lk.cs.ucla.edu/LK/lkxiwt/, 1995.

[Dahlback et al. 1993] Dahlback, N., Jonsson, A., Ahrenberg, L., Wizard of Oz-studies – whyand how. In Workshop on Intelligent User Interfaces, Orlando, FL, 1993.

[Dey 2000] Dey, A. K., Providing Architectural Support for Building Context-Aware Applications,Thesis of the Georgia Institute of Technology, College of Computing, 2000.

[Ducatel et al. 2001] Ducatel K., Bogdanowicz, M., Scapolo, F., Leijten, J. et Burgelman, J-C.,Scenarios for Ambient Intelligence in 2010, Technical report, ISTAG, February 2001.

[Gaildrat et al. 1993] Gaildrat, V., Caubet, R., Rubio, R., Conception d’un modeleur déclaratif descènes tridimensionnelles pour la synthèse d’images, MICAD’93, Paris, 1993.

[Gu 2004] Gu, T., Wang, X. H., Pung, H. K., Zhang, D. Q., An Ontology–based Context Mo-del in Intelligent Environments, in Proc. of Communication Networks and DistributedSystems Modeling and Simulation Conference, San Diego, California, USA, January2004.

[Hartson et al. 1992] Hartson, H.R., Gray, P.D., Temporal aspects of tasks in the User Action No-tation, Human–computer interaction, Vol. 7, pp.1–45, 1992.

[Henricksen et al. 2005] Henricksen, K., Indulska, J., McFadden, T., Modelling context infor-mation with ORM. In International Workshop on Object-Role Modeling (ORM), vo-lume 3762 of Lecture Notes in Computer Science, pages 626-635. Springer, Springer-Verlag, 2005.

[Henricksen, Wishart et al. 2005] Henricksen, K., Wishart, R., McFadden, T., Indulska, J., Ex-tending context models for privacy in pervasive computing environments. In 2nd In-ternational Workshop on Context Modelling and Reasoning (CoMoRea), PerCom’05Workshop Proceedings, pages 20-24. IEEE Computer Society, March 2005.

[IHM 1992] IHM’92, Compte rendu des ateliers, IHM’92 Quatrièmes Journées sur l’Ingénierie desInterfaces Homme–Machine, 1992.

[Jade] Jade : http ://jade.tilab.com/[Kennedy et al. 1988] Kennedy, A., Wilkes, A., Elder, L., Murray, W., Dialogue with machines,

Cognition 30, pp. 73-105, 1998.[Le Bodic 2005] Le Bodic, L., Approche de l’évaluation des systèmes interactifs multimodaux par

simulation comportementale située, Thèse de doctorat, Université de Bretagne occiden-tale, 2005.

[Martin 1994] Martin, J–C. Cadre d’étude de la multimodalité fondé sur les types et buts de coopé-ration entre modalités, Actes de Montpellier’94, pp.97–106, Février 1994.

[Martin 1999] Martin J–C., Six primitive types of cooperation for observing, evaluating and speci-fying cooperations. Actes de la conférence AAAI Fall 1999 (Cape Cod, USA), pp. 61–68,1999.

BIBLIOGRAPHIE 57

[Martin et al. 2001] Cheyer, A., Julia, L., Martin, J–C., A Unified Framework for ConstructingMultimodal Experiments and Applications, in Cooperative Multimodal Communica-tion, Lecture notes in Artificial intelligence, LNAI 2155, H. Bunt, Beun, R.J., Borghuis,T., Ed. : Springer, pp. 234–242, 2001.

[Nigay 1994] Nigay, L., Conception et modélisation logicielles des systèmes interactifs, Thèse del’Université Joseph Fourier, Grenoble, 1994.

[Nigay 2005] Nigay, L., Cours de conception des systèmes multimodaux, Master 2 3i, Intelligence,Interaction et Information, Université de Grenoble, 2005.

[Nigay et Coutaz 1994] Coutaz J., Nigay L., les proprietes « care » dans les interfaces multimo-dales .Actes de la conférence IHM’94 (Lille, France), pp.7–14, 1994.

[Nigay et Coutaz 1995] Coutaz, J., Nigay, L., Four easy pieces for assessing the usability of multi-modal interaction : the care properties. Arnesen S.A et Gilmore D. Eds., INTERACT’95,Chapman et Hall Publ., pp.115–120, 1995.

[Nigay et Coutaz 1996] Nigay, L., Coutaz, J., Espaces conceptuels pour l’interaction multimé-dia et multimodale, TSI, spécial Multimédia et Collecticiel, AFCET&Hermes Publ., Vol15(9), pp. 1195–1225, 1996.

[OAA] The Open Agent Architecture : http ://www.ai.sri.com/ oaa/main.html.

[Oviatt 1999] Oviatt, S.L, Ten Myths of Multimodal Interaction, Communications of the ACM42(11), pp.74–81, 1999.

[Paternò et al. 1997] Paternò, F., Mancini, C., Meniconi, S., ConcurTaskTrees : A DiagrammaticNotation for Specifying Task Models, in Proceedings of Interact’97, 1997.

[Pierret-Golbreich et al. 1989] Pierret-Goldreich, C., Delouis, I., Scapin, D.L., Un Outil d’Ac-quisition et de Représentation des Tâches Orienté–Objet, rapport de recherche INRIA no1063, Programme 8 : Communication Homme–Machine, août 1989.

[Rouillard 2004] Rouillard, J., VoiceXML, Le langage d’accès à Internet par téléphone, EditionsVuibert, 2004.

[Rousseau 2003] Rousseau, C., Multimodalité en sortie, Etude d’un modèle pour une interactionHomme-Machine dynamique et contextuelle, Mémoire de DEA, Université Paris SudOrsay, septembre 2003.

[Satyanarayanan 2001] Satyanarayanan, M., Pervasive Computing : Vision and Challenges,IEEE Personal Communications, pp.10–17. August 2001.

[Scholtz et al. 1999] Scholtz, J., Muller, M., Novick, D., Olsen, D.R., Schneiderman, B., Whar-ton, C., A Research Agenda for Highly Effective Human-Computer Interaction : Useful,Usable, and Universal, SIGCHI bulletin, ACM/SIGCHI, Volume 31, Number 4, pp.13-16, October 1999.

[Thevenin 1999] Thevenin, D., Coutaz, J., Plasticity of User Interfaces : Framework and ResearchAgenda, In Proceedings of INTERACT’99, pp. 110-117, 1999.

[Thevenin 2001] Thévenin, D., Adaptation en Interaction Homme-Machine : le cas de la plasticité,Thèse de doctorat, Grenoble en informatique. 2001.

[Vanderdonckt 05] Vanderdonckt, J., A MDA–Compliant Environment for Developing User In-terfaces of Information Systems,CAiSE’2005, Porto 2005

[VoiceXML Forum 2004] VoiceXML Forum : XHTML+Voice Profile 1.2.2004,http ://www.voicexml.org/specs/multimodal/x+v/12/, 2004.

[Weiser 1991] Weiser, M., The Computer for the Twenty-First Century, Scientific American, pp.94–104. 1991.

BIBLIOGRAPHIE 58

[Weiser 1993] Weiser, M., Some Computer Science Issues in Ubiquitous Computing, Communica-tions of the ACM, pp.74–84, 1993.

[W3C 03] W3C Multimodal Interaction Framework, http ://www.w3.org/TR/mmi-framework/,W3C Note 3, mai 2003.

Documents

Mémoire de Master Recherche en Informatiquenocremetz.free.fr/DEA/Memoire/RapportLatex.pdf · 2007-06-06 · Mémoire de Master Recherche en Informatique MODÉLISATION DES MÉCANISMES