Critique et limitations

Analyse sémantique. GRASP a été construit à partir de quelques phrases d’exemples choisies arbitrairement et non forcément représentatives des requêtes réelles des utilisateurs, d’où un certain manque de robustesse dans le traitement de celles-ci. Les différents modules le composant étant interdépendants, la prise en compte de nouvelles phrases est d’autant plus difficile. Enfin, la modélisation formelle fournie n’est pas non plus forcément idéale pour l’assistance, et des éléments demeurent peu ou pas traités (comme les références).

Agent rationnel. Une limitation de DAFT 1.0 provient de l’obligation d’associer à une re-quête donnée une unique réaction de nature monolithique. Cela signifie que pour introduire un nouveau comportement particulier, le concepteur de l’agent doit passer en revue toutes les heu-ristiques déjà existantes et éventuellement insérer le code correspondant à ce comportement. Le code inséré est ainsi dupliqué et se retrouve dépendant des heuristiques de comportement

déjà existantes. De plus, tout ajout ultérieur d’heuristique suppose de se poser de nouveau la question de l’insertion de ce comportement dans celle-ci, ce qui rend presque impossible la définition de nouvelles heuristiques par plus d’une seule personne.

Application et modèle. DAFT 1.0 a été conçu pour s’interfacer avec des applications Java, technologie disponible sur de nombreux systèmes, y compris sur le Web par le biais des applets. Or l’évolution d’Internet depuis le début du projet DAFT s’est accompagnée d’une disparition progressive des applets Java, relativement lourdes à cause de la machine virtuelle, rendant partiellement obsolète l’approche choisie si l’on souhaite que le système puisse être exploité par les concepteurs d’applications actuelles. D’autre part, le modèle défini pour chaque application l’est sans prendre en compte la perception réelle qu’en ont ses utilisateurs, ce qui augmente les chances de non résolution des requêtes (puisque l’utilisateur réfère à des éléments qui peuvent ne pas exister du point de vue du modèle) : là aussi, une étude basée sur les retours de DAFT 1.0à ce niveau a permis une amélioration des performances.

Agent animé. Bien que permettant la déictique et l’expression de certaines émotions, les agents LEA sont de type “2D cartoon”, ce qui peut avoir un impact direct sur les perfor-mances de l’utilisateur. Baylor & Kim[2004] ont notamment montré, dans le cadre d’agents pédagogiques, qu’un réalisme visuel accru de l’agent (passage d’une représentation de type “2D cartoon” à une représentation “3D réaliste”3) permettait une amélioration des perfor-mances en termes d’apprentissage, essentiellement chez les utilisateurs masculins. Par ailleurs, le mode de présentation actuel est peu flexible : il contraint à inclure l’application à assister dans l’environnement Java de DAFT 1.0, ce qui a pour effet de réduire l’espace disponible pour l’application et de générer une rupture visuelle avec le style graphique voulu par le concepteur d’application.

2.2.4 DAFT 2.0 (2006–2010)

D’après les critiques faites à la version DAFT 1.0, plusieurs objectifs ont donc été fixés pour établir une nouvelle version du système, ce qui a des conséquences directes sur l’architecture même du système, comme on peut le voir sur la figure 2.5. Nous nous contentons dans cette section de lister ces objectifs et les pistes suivies pour les atteindre, leur mise en application faisant l’objet des chapitres suivants.

2.2.4.1 Objectifs

L’analyseur sémantique GRASP 2.0. À ce niveau, nous avons identifié trois points nécessitant une amélioration par rapport à la version 1.0 :

3Plus exactement “2,5D”, dans la mesure où si un modèle 3D de l’agent a été réalisé, son implémentation

GRASP 2.0 Page ou appli web Requête LN Requête DAFT 2.0 Ressources linguistiques ^Heuristiques Extraction de modèle cognitif Modèle XML de l'application DIG Synchronisation Agent DAFT 2.0 Utilisateur Contrôleur DIVA Déictique Réponse formelle Réponse LN écrite + orale Animation ... Agent DIVA

Figure 2.5 Architecture du système DAFT 2.0

Amélioration de la robustesse : afin d’améliorer les performances générales du système, il est essentiel de se baser sur des requêtes représentatives des besoins réels des utilisateurs novices afin de diminuer le nombre de mots ou expressions non reconnues en entrée par le système. L’idée-clé est donc de procéder dans un premier temps à un recueil de corpus dont l’analyse doit permettre de réaliser une adaptation des différents outils de la chaîne deTALN, ce qui est particulièrement utile pour les modules ayant recours à la fréquence d’apparition de différents phénomènes linguistiques, comme pour la désambigüisation sémantique.

Possibilité d’améliorations incrémentales : l’augmentation de la robustesse apportée par l’approche corpus est fortement dépendante de la qualité de celui-ci. Dans la mesure où de nouvelles requêtes d’utilisateurs peuvent être recueillies tout au long de l’utili-sation du système, le corpus est amené à croître constamment, tant en quantité qu’en qualité, la seconde découlant de la première. Il est alors essentiel de pouvoir disposer d’un outil d’analyse flexible, c’est-à-dire capable de s’adapter pour que la qualité de l’analyse fournie suive les améliorations successives de la qualité du corpus. Cela requiert donc une séparation stricte entre les données et les processus d’analyse fondés sur celles-ci, soit une externalisation des ressources linguistiques.

Modélisation plus fine des requêtes : à supposer que tous les mots et expressions soient reconnus en entrée, encore faut-il que le système soit capable de capturer les nuances sémantiques entre eux. Cela requiert donc une amélioration sensible du modèle fondé sur les 23 classes d’actes de dialoguedu tableau2.1associés à des références, en définissant un nouveau langage de requêtes formel, DAFT 2.0 , capable de modéliser plus précisément les intentions réelles des utilisateurs et plus adapté aux requêtes émises dans le contexte de l’assistance.

La justification du besoin d’un corpus spécifique pour le système DAFT constitue le sujet du chapitre3tandis que sa prise en compte pour l’amélioration du moduleGRASPsera présentée dans les chapitres4et6, dans lequel on gardera également à l’esprit le besoin d’externalisation des ressources linguistiques. La question de l’amélioration de la précision du langage sera quant à elle discutée dans le chapitre5.

L’agent rationnel DAFT 2.0 : A_R Pour pallier les problèmes mentionnés en 2.2.3.3 et permettre une complexification des comportements potentiels de l’agent tout en facilitant la définition de ceux-ci, nous souhaitons que l’agent rationnel (que nous nommerons AR dans DAFT 2.0) prenne en compte les trois caractéristiques suivantes (illustrées sur la figure2.6) : Factorisation des réactions : afin de simplifier l’écriture d’heuristiques de réaction, nous nous proposons de factoriser leur code en permettant la définition de routines correspon-dant à des situations classiques, auxquels les heuristiques de plus haut niveau peuvent faire appel. En définissant de tels éléments, le concepteur de réactions peut s’abstraire d’une rationalité “de bas niveau” (par exemple la vérification de l’existence d’une réfé-rence) et se concentrer sur des heuristiques plus génériques.

Parallélisation des réactions : si la factorisation permet à une réaction d’être éventuel-lement composée d’un ensemble de sous-réactions, encore faut-il que le concepteur connaisse les sous-réactions existantes. Il faut également que tout ajout d’une nouvelle sous-réaction passe par une analyse des réactions de “haut niveau” existantes pour voir si elle doit y être intégrée. Par conséquent, on peut pousser plus loin la logique en passant à une relation de type “plusieurs à plusieurs” dans laquelle une requête peut être asso-ciée à plusieurs réactions, par exemple en associant les réactions non pas à des requêtes complètes, mais à des sous-parties de la requête formelle.

Externalisation des réactions : l’objectif du système étant d’être utilisé par des concep-teurs d’applications pour les doter d’un agent assistant, la logique de modularisation dans laquelle s’incrivent les deux points précédents peut être prolongée en séparant totalement le moteur de l’agent rationnel des réactions utilisées par celui-ci, de manière à pouvoir les externaliser. L’avantage d’une telle approche est double : d’une part il devient pos-sible de définir des ensembles de réactions qui peuvent ou non être chargées par l’agent (pour étudier par exemple l’impact concret d’une heuristique donnée), d’autre part il est possible pour les concepteurs de “scripter” facilement leurs propres règles sans avoir à éditer le moteur de l’agent. On se dirige ainsi vers une approche collaborative où chaque concepteur d’applications peut (s’il le souhaite) passer du statut de consommateur d’une solution d’assistance clé en main à celui de contributeur.

Le fonctionnement de l’agent rationnel étant clairement affecté par la redéfinition de la structure des requêtes formelles DAFT qu’il reçoit en entrée, présentée dans le chapitre 5, l’évaluation de cette redéfinition de l’architecture d’association requête-réaction de l’agent rationnel pour prendre en compte ces trois objectifs sera abordée au niveau du chapitre 8.

_____ ______ __ ____ _______ ______

___ ______ ____ ____ _________

____ __ ___ ______ ___ _

________ ___ _ __ ______ __ _____ ____

Requêtes en DAFT 2.0 Moteur de l'agent rationnel

________ _________ _______ __________ ____ _______ ___ ______ _____ ________ ____ ______ _________ _____ _ _____ _________ ______ ___ _______ ______ _______ ________ ______ ___ ________ _ _____________ ___ _______ ________ ___ _______ ______ _______ ______ ___________ ________ ________ _________ _ _ ______ ________ ______ _______ _________ ___________ ______ __________ _________ _________ _____ ___ ________ _____ _ Heuristiques de réaction Mapping ______ __________ _____ _____ _____ _______ _________ ____ ____ ___ ___ _________ ___ 1 2 3

Figure 2.6 Agent rationnel AR assurant le lien entre une requête formelle et des heuristiques de réaction, avec factorisation (1), parallélisation (2) et externalisation (3) des réactions, par rapport à la figure2.3

L’application et son modèle. En vue de fournir une assistance plus précise et de rendre le système utilisable par le plus grand nombre de développeurs d’applications, deux points ont retenu notre attention au niveau du modèle d’application :

Extension de la portée des applications : le Web constitue une plate-forme idéale pour toucher un grand nombre d’utilisateurs, notamment novices. De plus, grâce au déve-loppement récent d’applications Web dynamiques basées sur le langage JavaScript en conjonction avec XML pour la représentation des données, l’analyse du code de pages Web permettrait donc de fournir des assistants à la fois pour la navigation et pour l’uti-lisation d’applications. Pour cette raison, DAFT 2.0 a été envisagé comme résolument orienté vers les pages Web et les applications ou services développés en JavaScript. Prise en compte des biais utilisateurs : pour pouvoir apporter une assistance efficace, il

est utile de comprendre la manière dont les utilisateurs perçoivent l’application qu’ils uti-lisent, et notamment la façon dont ils se réfèrent aux éléments qui la compose en termes d’aggrégats perceptifs, qui peut sensiblement différer de l’implémentation effective sous-jacente (cf. figure 2.7). De plus, les études complémentaires menées par Hasson [2007] dans le cadre du projet ont montré que la représentation mentale que les utilisateurs ont de la tâche est au moins tout aussi importante.

L’étude et l’implémentation des améliorations décrites ci-dessus ont été le sujet des travaux de David Leray de 2005 à 2009 [Leray,2009].

Figure 2.7 Exemple de différence entre la perception de l’utilisateur (encadrée

en gras) et l’implémentation réelle (encadrée en pointillés) d’un formulaire sur un site Web permettant la réservation de billets de train [Sansonnet & Leray, 2007] L’agent virtuel animé.

Réalisme accru : bien que Norman [1994] souligne qu’un agent trop réaliste visuellement génère des attentes plus grandes en termes de performances, et donc un risque de décep-tion plus conséquent si elles ne sont pas à la hauteur de ces attentes, on a vu dans les critiques de DAFT 1.0 qu’il y avait de réels avantages à disposer d’un avatar plus réaliste visuellement, à la fois en termes de représentation (personnages humanoïdes générés en 3D avec des textures plus détaillées) et d’animation (fluidité accrue dans les mouvements avec une interpolation au lieu de passer sans transition d’une animation à l’autre). Intégration Web : pour les raisons invoquées précédemment, il est également nécessaire

d’adapter les agents animés utilisés dans DAFT 1.0 en vue d’un déploiement sur le Web, c’est-à-dire les rendre capables de s’insérer de manière la moins intrusive possible sur une page Web (page classique ou bien contenant une application ou service). Techniquement, deux solutions sont possibles a priori : l’ajout en surimpression de la page ou l’ajout dans une frame4 supplémentaire. Si cette dernière option est plus simple à implémenter, elle a comme inconvénient, outre celui de faire appel à une méthode aujourd’hui peu recommandée, de réduire la zone d’affichage normalement dévolue à l’application. La première option semble donc préférable, mais afin de pouvoir s’adapter à tout type de page sans forcer le développeur d’application à gérer lui-même le positionnement de l’agent sur celle-ci, elle induit que l’agent animé doit pouvoir être déplacé (par glisser-déposer) et réduit (ou masqué) lorsque l’utilisateur ne souhaite pas faire appel à lui. Afin de répondre à ces deux objectifs, un nouveau système d’agents visuellement réalistes et intégrés au Web a été développé, les agents DOM Integrated Virtual Agents (DIVA). Comme leur nom l’indique, ils sont complètement intégrés au Document Object Model

(DOM)de la page Web dans la mesure où ils sont implémentés par le biais d’une imbrication

de balises HTML de type <div> contenant des images correspondant aux différentes parties

4Espace séparé (visuellement et conceptuellement) du reste de la page Web dans laquelle il est inclus et où

du corps de l’agent5. Cette intégration au DOM permet de gérer leur animation par le biais de scripts (écrits ici en JavaScript).

2.2.4.2 Notations

Nous avons vu dans les sections précédentes que l’acronyme DAFT pouvait être utilisé pour faire référence à différents éléments. Pour clarifier les choses, nous distinguerons donc dans les chapitres suivants :

− le “projet DAFT” : cadre de l’ensemble de ces travaux ;

− le système DAFT (majuscules, police romaine à chasse fixe) : ensemble de la chaîne de traitement ;

− le module DAFT (majuscules, police romaine) : correspondant au module de l’agent rationnel au sein du système DAFT ;

− le corpus Daft (minuscules, police italique) : recueilli à l’aide du système DAFT 1.0, utilisé pour la conception de DAFT 2.0 ;

− le langage DAFT (majuscules, police italique) : utilisé pour la représentation formelle des requêtes des utilisateurs. On distinguera la version de DAFT 1.0 (notée DAFT 1.0 ), résumée dans la table2.1, de la version à concevoir pour DAFT 2.0 (notée DAFT 2.0 ).

2.3 Conclusion

Nous avons présenté dans ce chapitre la première version du système DAFT et proposé un certain nombre d’améliorations relatives à l’agent animé utilisé (passage à un mode “3D réaliste” et intégration aux pages Web), à l’accès au modèle de l’application assistée (rendu possible par l’intégration au DOM), à l’agent rationnel (modularisation des heuristiques de réaction) et à la chaîne de traitement des requêtes en langue naturelle (modélisation plus fine et système plus robuste avec possibilité d’améliorations incrémentales). Nous allons dans la partie suivante de cette thèse nous concentrer sur ce dernier point.

5Notons que pour prendre en compte les problèmes de ralentissement qui peuvent apparaître avec une

connection bas débit pour télécharger toutes les animations des agents réalistes DIVA, une version Web des