Altération du comportement conventionnel de l’utilisateur

comportements de la part des interlocuteurs altérant celui donné dans la section 6.1.1. En effet, celui-ci décrit à l’aide de motifs dialogiques une interaction idéalisée entre un utilisateur ayant un besoin d’information et un expert venant l’aider à répondre à ce besoin d’information. Dans le corpus, certains phénomènes identifiés ne correspondent pas à cette vision idéalisée et nécessitent de la modifier pour les faire apparaître.

Violation d’un engagement en action

Les engagements en action ont un cycle de vie contenant cinq états. Ils peuvent être inactifs (Ina), créés (Crt), complétés (Ful), échoués (Fal) ou violés (Vio). La création d’un engagement en action se fait de manière explicite à l’aide d’un motif dialogique portant sur une action. La complétion d’un engagement en action a lieu lorsque son contenu en action est réalisé par son débiteur. Elle peut être faite explicitement avec l’utilisation d’un jeu de décharge afin de permettre au débiteur de signaler l’exécution de l’action. Ce comportement est cependant très « verbeux », dans le sens où il implique l’exécution d’un jeu pour chaque action réalisée.

Lors de sa conception, nous avons fait l’hypothèse que le système était capable de réaliser les actions instantanément après s’y être engagé, et donc que les engagements en action qu’il contracte sont directement complétés. Ce mécanisme n’est pas applicable pour l’utilisateur, qui peut s’engager à réaliser une action puis ne pas la réaliser. Dans le cadre du scénario de RICM, le seul engagement en action que peut contracter l’utilisateur est le fait de préciser sa verbalisation. La satisfaction de cet engagement en action est réalisée automatiquement lorsque l’utilisateur suit le scénario présenté en figure 6.1. La violation de cet engagement a lieu lorsque l’utilisateur s’engage à préciser sa verbalisation puis qu’il

ré-affirme que celle-ci est terminée sans l’avoir modifiée. Le système doit être capable de détecter cette violation et de continuer à contextualiser correctement ses actions et à y répondre de manière pertinente.

Le diagramme 6.2 présente l’arête que ce type de comportement introduit dans l’auto-mate 6.1, amenant l’utilisateur à ne pas réaliser une partie des comportements attendus de sa part dans l’état de précision de la verbalisation (tous ceux relatifs au sommet PV1 dans l’automate).

Figure6.2 – Illustration de la modification apportée sur l’automate par la violation de l’enga-gement sur la précision de sa verbalisation par l’utilisateur. En gris figure la partie concernée de l’automate et en noir la nouvelle arrête introduite par cette modification.

Modification du besoin d’information

Dans le corpus Cogni-CISMeF, l’utilisateur cherchant des informations médicales pouvait être amené à spécifier, modifier ou reformuler son besoin d’information au cours du dialogue. Le contexte principal dans lequel ce type de phénomène avait lieu le fait sortir de la boucle lancement/évaluation/réparation de la requête suite à un lancement ou à une évaluation peu concluante pour ajouter des informations à la formulation de son besoin d’information initial. Cela traduit le fait que le besoin d’information de l’utilisateur évolue pendant sa recherche, et qu’il peut être nécessaire de le mettre à jour au cours de l’interaction. Cependant, cela n’entraîne pas une reprise de la tâche à partir de cet état passé du scénario, mais plutôt fait faire un « détour » par l’état de précision de la verbalisation du besoin d’information afin d’actualiser les informations qui y avaient été données en premier lieu. Cela implique que cette modification du parcours de l’utilisateur n’est que temporaire et qu’il ne faut pas parcourir à nouveau l’intégralité du scénario pour en revenir à l’état de l’interaction précédant cette discontinuité. Dans le cas d’une mise à jour de la verbalisation par l’utilisateur, une fois celle-ci terminée, l’état suivant dans lequel l’interaction doit se trouver est l’évaluation des résultats.

Le diagramme 6.3 présente les modifications que ce type de comportement introduit dans l’automate 6.1, nécessitant l’introduction d’un état supplémentaire à l’automate pour permettre à l’utilisateur de temporairement retourner dans l’état de précision de la verbalisation.

Figure6.3 – Illustration de la modification apportée sur l’automate par la précision de son besoin d’information par l’utilisateur lors de l’évaluation des résultats d’une requête. En gris figure la partie concernée de l’automate et en noir la nouvelle arrête introduite par cette modification.

Rejet implicite des résultats de la requête

Les participants aux dialogues du corpus Cogni-CISMeF étant co-localisés, ils étaient parfois amenés à ne pas verbaliser l’intégralité de leurs actions, plus particulièrement lorsque ces actions pouvaient être comprises de manière implicite. C’est le cas de l’évalua-tion des résultats de la requête. Certains dialogues du corpus montrent un enchaînement direct entre le lancement de la requête et sa réparation, sans qu’un acte de dialogue d’éva-luation ne soit joué, ni sur les résultats, ni sur la requête elle-même. Cependant, l’utilisateur sait que le fait de modifier la requête rejette implicitement les résultats renvoyés.

L’introduction de ce phénomène dans la simulation du comportement de l’utilisateur si-gnifie qu’il est possible, suite au lancement d’une requête, que celui-ci ne formule aucun des motifs d’Inform attendus dans l’état d’évaluation des résultats et qu’il passe directement à la modification de celle-ci.

Le diagramme 6.4 présente l’arête que ce type de comportement introduit dans l’au-tomate 6.1, permettant à l’utilisateur de passer directement de l’état de lancement de la requête à l’état de réparation de la requête sans passer par les états intermédiaires ER2 et ER3.

Saut en avant

En généralisant l’idée de l’évaluation implicite des résultats, nous introduisons la possibilité que l’utilisateur fasse un « saut en avant » n’importe où dans l’automate. Lorsqu’il lui est possible de prendre une initiative, celui-ci pourra réaliser implicitement son prochain coup et jouer explicitement le coup d’après.

Figure6.4 – Illustration de la modification apportée sur l’automate par le rejet implicite des résultats de la requête par l’utilisateur. En gris figure la partie concernée de l’automate et en noir la nouvelle arrête introduite par cette modification.