modèle dans une perspective dynamique et temporelle : il peut être enrichi après sa création. Cela implique la nécessité d’une méthodologie de synthèse de modèle robuste et une structuration homogène des informations que l’on peut y intégrer. Un même élément dans le modèle pourra avoir plusieurs incarnations lexicales selon la source de connaissances considérée.
3.2.5 Synthèse
Cette analyse ne suffit pas à donner des indications précises sur le contenu du modèle. Elle permet d’établir quelles sont les forces en présence et sur quoi on peut ensuite compter pour produire un modèle.
Les informations importantes à retenir sont : caractère dynamique et évolutif du modèle, multiplication des sources de connaissances et intégration d’informations permettant de diagnostiquer un cas d’erreur.
Par ailleurs le modèle doit présenter trois types d’information : un contenu structurel, un contenu dynamique et un contenu lexico-sémantique. Si on compare ces exigences avec les précédentes architectures que nous avons développées, on constate que l’exigence de représentation du contenu structurel et fonctionnel existait déjà dans Daft (et InterViews) : il s’agit en quelque sorte des informations minimales que doit exprimer un modèle (et même indépendamment de la problématique d’assistance, comme nous le verrons ultérieurement dans les sections 3.4 et 3.5).
Nous allons maintenant essayer de déterminer plus précisément le contenu des informations qui doivent figurer dans un modèle. Pour ce faire, nous allons exploiter les corpus qui ont été produits dans deux études antérieures à nos projets et au cours de nos propres expérimentations.
3.3 Les corpus d'assistance
Les corpus d’assistance doivent nous donner des indications sur les erreurs qui sont commises par les usagers et sur la façon dont ils les exprimen. Ces informations doivent permettre ensuite de déterminer à quoi doit s’attendre un agent assistant et quelles sont les informations qui lui permettront de répondre (et devront figurer dans le modèle). Les objectifs de cette section sont d’obtenir des principes de modélisation et des contraintes d’assistance sur ceux-ci. Nous pourrons alors nous servir de ces contraintes pour examiner les modèles existants et déterminer s’ils peuvent être utiles à notre entreprise. On prend comme base de départ, un ensemble de corpus retraçant l’interaction entre des usagers et des assistants, ces assistants peuvent être soit des ACA, soit un expert humain. Ces corpus peuvent donc être obtenus de deux façons :
- Usager + système + opérateur humain (expert): l'opérateur humain a la fonction de l'assistant. Il recueille les questions et remarques de l'usager lors de l'interaction
entre celui-ci et le système. Une tâche est proposée à l'usager et les erreurs ainsi que les phrases de l'usager sont enregistrées.
- Usager + système + ACA : dans le cadre d’une expérimentation en magicien d’Oz, un usager a pour consigne d'interagir avec le système et d'entrer ses éventuelles questions grâce à une saisie au clavier. Les compétences d'assistance de l'agent sont désactivées (l'usager est mis au courant) afin de ne pas perturber l'usager qui aurait éventuellement son attention focalisée sur les failles de l'agent plutôt que sur celles du système.
Nous allons synthétiser les informations issues de trois corpus différents : un corpus issu de nos propres expérimentations et deux corpus provenant de deux études différentes réalisées dans le cadre d’assistance avec un expert (premier cas). Nos propres corpus ont été obtenus par la méthode alternative avec une émulation d’Agent Assistant.
3.3.1 Utilisation des corpus
Les corpus sont utilisés comme catalogues de requêtes usagers issus d'une réelle interaction entre un usager et une application. C'est une liste de phrases en plus ou moins bon anglais (traduites en français). On peut ensuite analyser ces différentes requêtes et en extraire des regroupements intéressants.
On peut tout d’abord citer les travaux de l'équipe de Roesler et McLallan (Roesler & McLellan 1995) qui ont permis d’obtenir la classification présentée dans la Table 6 ci-dessous. On peut également citer l'étude de Pilkington (Pilkington 1992), qui a elle aussi permis d’établir des catégories de requêtes, listées dans la table ci-dessous (Table 7). On peut enfin citer le corpus issu des expériences de Daft (Xuetao et al. 2008), qui a aussi permis d'identifier différentes catégories de requêtes listées dans la Table 8. On peut constater que les différentes catégories obtenues par ces différentes études sont quelque peu divergentes : on remarque une certaine convergence dans ces trois taxonomies : les questions en rapport avec une identification (Table 6, item 3 ; Table 7, item 4 ; Table 8, item 1) ; les questions procédurales (Table 6, items 1&4 ; Table 7, item 2&4 ; Table 8, item 2) et les questions appelant un diagnostic – à l’exception du premier corpus (Table 7, item 2 ; Table 8, item 4).
Les autres requêtes citées dans les corpus (par exemple la catégorie 10 de la Table 7) portent sur l’aide sur l’aide ou sur des aspects extérieurs à l’application elle-même. Comme notre objectif est une modélisation de l’application (le reste n’est pas à négliger mais n’est pas l’objet principal), les trois catégories de requêtes explicitées ci-dessus semblent des catégories suffisantes.
De ces corpus, on distingue trois catégories de requêtes différentes : le quoi, le comment et le pourquoi. Ces trois questions renvoient à des situations d'assistance qui sont très différentes et qui amènent des traitements qui seront eux aussi très différents. Même si l'objectif de cette thèse n'est pas d'aborder la problématique proprement dite des résolutions de requêtes, il est important d'avoir une idée des mécanismes qui en découlent pour fournir une base de connaissances dont le contenu est en adéquation
3.3 - Les corpus d'assistance
avec le type de requêtes rencontrées : elles doivent intégrer les informations qui permettront de formuler une réponse utile à l’usager, lui donnant la possibilité de sortir de sa situation de blocage.
Il est intéressant de noter que ces catégories quoi, comment et pourquoi correspondent à peu près aux orientations prises dans le projet InterViews (chronologiquement, l’étude des corpus est arrivée après le projet), à savoir la modélisation de la structure et du fonctionnement. Ces requêtes, également, sont cohérentes avec ce que l’état de l’art nous a appris sur les causes de l’échec des utilisateurs : l’utilisateur transmet dans ses requêtes ses interrogations sur l’échec de ses explorations. Nous soulignons particulièrement l’importance de cette situation et sur le biais cognitif de l’utilisateur : celui-ci s’est construit de fausses représentations des capacités de l’application et cela conduit à des erreurs.
Type de requête
1. « Que dois-je d’abord savoir ? » 2. « Comment faire ? »
3. « Qu’est-ce que cela ? »
4. « Que puis-je faire ensuite ? »
5. Demande portant sur l’utilisation de l’aide (ou demande d’aide sur l’aide)
6. Demande d’explication de la signification d’un terme. 7. Conventions d’utilisation de la souris, du clavier
8. Demande de documentation auxiliaire (sur le système, le domaine d’application etc.)
9. Demande d’assistance externe (expert, ‘Service clients’)
10. Numéro de version.
Type de requête Commentaire
1. « Comment faire pour … ? » Demande d'informations
procédurales précises
2. « Pourquoi ? » Demande d'informations
sémantiques
3. « Est-il possible de … ? » Expression d'une volonté
d'exploration du logiciel 4. « Quel est l'objet/commande … permettant de … ? » Demande de « guidage » global
Table 7 : Taxonomie des demandes d’informations d’aide, d’après Pilkington 1992.
Type de requête Commentaire
1. « quel est le nom du truc dans lequel j’ecris ? » Echec d’identification
2. « peux-t’on mettre une image derrière le nombre
? » Echec d’action
3. « pourqoi ça marche pas si je fais RAZ ? » Perte de contrôle
Table 8 : Taxonomie des demandes d’informations d’aide, d’après Sansonnet 2008.
3.3.2 Mécanisme de traitement des requêtes
Voyons maintenant quels mécanismes de traitement des requêtes on peut mettre en place, et quelles sont les conséquences sur le modèle d’assistance :
- Traitement du quoi : le ‘quoi’ est une référence explicite et directe vers un élément de l'application. Il s'agit d'un élément graphique atomique ou composé. La référence est soit directement nommée (« qu'est ce que le bouton stop ? ») soit donnée en extension (« a quoi sert le bouton rouge »). Le processus de résolution d'une telle requête est axé sur la recherche d'attributs correspondants, un patron formel désignant un élément de l'interface. La difficulté très importante est liée à l'inexactitude du vocabulaire de l'usager. Si a priori une référence donnée en extension ne peut pas être ambiguë (l'usager choisit les termes qui lui permettent de désigner quelque chose de manière évidente), les nominalisations peuvent être imprécises voire fausses. La représentation des éléments de l'application susceptibles d'être référencés par l'usager doit donc intégrer un mécanisme prenant en compte ce phénomène.
3.3 - Les corpus d'assistance
- Traitement du pourquoi : le ‘pourquoi’ est une référence à un évènement passé dans l'expérience de l'utilisateur. L'origine de cet évènement peut être soit une action de l'utilisateur (« pourquoi j'ai fait ça et que ça a fait ça ? ») ou une action du système (« pourquoi telle chose est arrivée ? »). La difficulté évidente est de retrouver l'évènement en question. Ce qui cause cette difficulté est la nature très variable de la granularité de la référence. Si les actions atomiques sont codées sous la forme d'appels de fonctions pour le système, la référence de l'utilisateur peut englober plusieurs actions atomiques. Plus difficile encore, la perception de l'usager peut lui avoir induit une mauvaise représentation du déroulement de l'application : on ne peut exclure la coïncidence de plusieurs actions totalement indépendantes qui soient perçues comme ayant un lien de cause à effet par l'usager par le seul fait qu'il les a vues se produire dans un intervalle de temps très restreint. Dès lors, en plus du mécanisme de référence, il faut introduire un mécanisme de détection de références erronées, ce qui est difficile.
- Traitement du comment : le ‘comment’ se réfère à un but de l'utilisateur. Il doit être interprété comme une requête de demande d'explication ainsi que des étapes que l’utilisateur doit suivre pour atteindre son but. La difficulté réside alors dans la représentation des buts : c'est une notion assez abstraite, et si les programmeurs d'une application définissent (et éventuellement décrivent) un certains nombre de fonctionnalités, ces fonctionnalités peuvent être employées dans des buts très variés qui échappent aux concepteurs initiaux. Il en résulte que les références de l'utilisateur seront vraisemblablement liées au contexte précis de l'utilisation de l'application ce qui s'en ressentira sur le contenu linguistique de la requête de l'utilisateur. Le traitement de la requête requiert donc de trouver le but puis d'établir la séquence d'actions que l'utilisateur doit accomplir.
D'une manière générale, le problème majeur qui se pose est celui de la granularité des éléments référencés par l'usager. Ils peuvent être atomiques ce qui est un cas simple à traiter, mais ils peuvent être aussi composés. Dans ce dernier cas, cette composition est le fruit de la représentation mentale de l'utilisateur. S'il est impossible de connaître les effets de l'expérience passée de l'utilisateur sur ces constructions mentales, il est par contre possible d'avoir accès aux informations strictement perceptuelles qui supportent une telle représentation.
Que peut-on déduire de ces considérations ? D'abord que ces données sont insuffisantes : il faudrait contraster les requêtes en fonction des catégories d'applications et des catégories d'usagers pour avoir une vision fine de ce que s'y passe. Mais, ce qui est important pour notre étude, c’est qu’il existe une régularité dans la forme des requêtes, qui expriment toutes une référence, on peut ainsi proposer un mécanisme de traitement de ces requêtes de manière générique, dans l’objectif de se rapprocher de l’architecture idéale et générique d’Allen.