Chapitre 3 Les Systèmes à Base de Traces Modélisées
3.2 L’approche M USETTE
L’objectif initial de l’approche MUSETTE (Modéliser les USages et les Tâches pour Tracer
l’Expérience) était de tracer, puis réutiliser l’expérience d’utilisation d’un système informatique. La
notion même d’expérience d’utilisation, issue de travaux antérieurs (Prié 1999 ; Prié et al., 1999), fût
le point de départ du travail de recherche. Il s’agissait de pouvoir décrire l’expérience d’utilisation, de
façon à la matérialiser dans une trace générée par les interactions de l’utilisateur avec son
environne-ment informatique. Entendue comme une réalisation remarquable d’une tâche donnée, l’expérience
d’utilisation matérialisée en une trace, devenait alors réutilisable en tant que telle. Cette réutilisation
pouvait avoir diverses finalités (Prié et Mille, 2000), mais c’est l’idée de réutiliser ces traces
d’utilisation pour l’assistance à l’utilisateur qui fût retenue et constitua le principal axe de
dévelop-pement de l’approche (Champin et al., 2001, 2002). Rapidement après les premières ébauches,
l’approche fût consolidée par une définition plus rigoureuse des concepts utilisés (Champin et
Prié, 2003 ; Champin et al., 2003, 2004), et par sa mise en œuvre concrète (Laflaquière, 2003 ;
Lafla-quière et Prié, 2003 ; LaflaLafla-quière et al., 2005 ; Laflaquière et Ciaccia, 2005). L’approche MUSETTE a ouvert des pistes de réflexion intéressantes quant à l’assistance à l’utilisateur, en s’inspirant
notam-ment du Raisonnement à Partir de Cas (Aamodt et Plaza, 1994; Aamodt, 2001), mais a surtout
préfi-guré l’approche des Systèmes à Base de Traces modélisées.
3.2.1 Les principaux concepts de l’approche MUSETTE
Le principe de base de l’approche est relativement simple. Il s’agit de mettre en place un agent
obser-vateur de l’utilisation d’un système informatique qui génère une trace d’utilisation. Cette trace est définie de telle sorte qu’un analyseur de trace puisse y identifier des épisodes significatifs représentant des expériences d’utilisation, lesquels sont alors réutilisés par des agents assistants pour soutenir l’utilisateur dans sa tâche.
3.2.1.1 Agent observateur, modèle d’utilisation et trace primitive
Afin de décrire l’utilisation dans les termes appropriés à l’identification d’expériences d’utilisation
particulières, l’approche MUSETTE propose de les modéliser explicitement, ce qui revient à déterminer
a priori les éléments constitutifs d’une trace numérique générée par l’utilisation d’un système
informa-tique. Les éléments constitutifs ainsi déterminés sont appelés les Objets d’Intérêt et sont décrits dans
un modèle d’utilisation qui regroupe deux types d’objets – des entités et des évènements – ainsi que
des relations (typées) posées entre ces objets. Les entités sont des objets présents dans l’espace
d’interaction de l’utilisateur81 alors que les évènements sont des changements de l’environnement
opé-rés par le système lui-même ou par une action de l’utilisateur. L’objectif de la trace visée étant sa
ré-utilisation, ces objets d’intérêts, dotés de leurs attributs, doivent impérativement être signifiants pour l’utilisateur aussi bien que pour le système informatique qui les manipule.
Une fois le modèle d’utilisation établi, un agent observateur peut être mis en place et générer
concrè-tement une trace d’utilisation en enregistrant les instances d’objets d’intérêt définis, de façon à ce que
la trace générée respecte le modèle. L’agent observateur repose sur un ensemble de règles
d’observation qui définissent d’une part la manière d’instancier des objets d’intérêt dans la trace à
partir des divers évènements machine82, et d’autre part la manière de structurer la trace elle-même. La
trace ainsi générée est appelée trace primitive, entendue comme la « première trace signifiante », aussi
bien pour le système que pour l’utilisateur lui-même (Figure 3.1).
Figure 3.1 : Génération d’une trace primitives structuration en états et transitions.
La trace primitive générée se compose de deux types de structuresdistinctes : les états et les
transi-tions. Les états qui regroupent des entités, représentent l’état du système observé (différent d’un
« état-machine ») à un instant (ou une période) donné par rapport au modèle d’utilisation. Les
81 Ne correspondant pas nécessairement à un objet du modèle de conception de l’outil manipulé (Laflaquière, 2003).
82 Ces évènements machines peuvent être des événement directement (ou indirectement) accessibles dans le système, ou bien doivent être obtenus par la mise en place d’un code spécifique ou d’une modification de l’environnement lui-même.
tions regroupent quant à elles un ensemble d’évènements qui se produisent entre deux états. La trace primitive est donc in fine une séquence alternée d’états et de transitions, ces derniers structurant un
graphe dont les nœuds sont des entités et des évènements étiquetés par l’ensemble de leurs attributs, et dont les arcs sont des relations.
3.2.1.2 Analyseur de trace, épisodes significatifs et signatures de tâches
La trace primitive ainsi obtenue se prête au traitement d’un analyseur de trace, qui a pour objectif d’en
extraire des épisodes significatifs, i.e. des segments de la trace primitive correspondant à une expérien-ce d’utilisation (liée à la réalisation d’une tâche spécifique), et potentiellement réutilisable en tant que
telle. Ces épisodes sont identifiés grâce à des signatures de tâche. Une signature est un ensemble de
points communs à un type de tâche particulier, impliquant les mêmes entités et/ou évènements, pro-duits à un même moment ou dans un ordre particulier (en fonction des états et transitions) dans la trace primitive. On peut la voir comme un « motif » ou à un « pattern de tâche » (Paternò, 1994) partielle-ment instancié dans la trace. Au final, un segpartielle-ment est repéré et extrait de la trace par l’analyseur en
tant qu’épisode significatif lorsque le segment contient au moins une signature de tâche (Figure 3.2).
Ce processus alimente le système d’un certain nombre d’épisodes significatifs qui peuvent alors être exploités par des agents assistants.
Figure 3.2 : Extraction d'épisodes significatifs, sur la base de signatures de tâches.
3.2.1.3 Agents assistants et réutilisation d’expérience d’utilisation
Plusieurs types d’agents assistants, réutilisant les épisodes significatifs, ont été imaginés. De manière
classique un agent assistant « générique » prenant en charge plusieurs tâches via leurs signatures, peut
explorer la trace courante et suggérer (ou accomplir), au fur et à mesure, des actions qui semblent per-tinentes. On peut également proposer des agents « réactifs », mobilisés uniquement à la demande de l’utilisateur lui-même, et qui lorsqu’ils sont appelés tentent d’identifier la tâche engagée pour trouver dans la trace des épisodes similaires et s’en inspirer pour proposer automatiquement des opérations à effectuer pour prolonger l’action de l’utilisateur.
Ce type d’assistance (similaire à celle fournie par les systèmes conseillers) peut rapidement perdre de sa pertinence lorsque l’utilisateur est engagé dans une tâche complexe dont le succès ne dépend pas uniquement de la « bonne » manipulation de l’outil, mais des décisions et des choix qu’il fait
relative-ment à l’environnerelative-ment numérique dans lequel il est plongé via cet outil. Nous avons détaillé ce
pro-blème (Laflaquière et al., 2005) en prenant comme exemple la veille informationnelle sur le Web,
Pour ce type de tâche, l’agent assistant peut ne pas avoir de suggestion pertinente à fournir relative-ment à la demande de l’utilisateur, ce qui n’empêche pas que la réutilisation des épisodes significatifs peut tout de même apporter de l’aide à l’utilisateur.
Figure 3.3 : Réutilisation(s) des épisodes significatifs par un agent assistant.
En effet, de façon plus pragmatique, l’agent peut simplement proposer à l’utilisateur de consulter
lui-même les épisodes retrouvés. Seul l’utilisateur, en effet, est à même d’identifier clairement les
épiso-des qui correspondent le mieux à sa situation actuelle en tenant compte de critères qui ne sont pas
ac-cessibles au système. Dans ce cas d’assistance médiée ou indirecte, la présentation d’un épisode peut
inspirer une solution à l’utilisateur qu’aucune déduction logique du système ne pourrait fournir sur la seule base de la trace. Notons qu’un des intérêts de l’approche tient au fait que l’interrogation de la base d’expérience est réalisée simplement en utilisant le système (sans faire appel à un langage de requête particulier), et réduisant le risque d’une aide hors de propos. De plus, il est tout à fait possible pour l’utilisateur de définir et rajouter au fur et à mesure de nouvelles signatures de tâches. L’agent peut de façon identique parcourir la trace à la recherche des épisodes contenant cette signature frai-chement définie pour les soumettre à l’utilisateur, ce qui donne une grande flexibilité au système.
3.2.2 Applications de l’approche MUSETTE
Le fonctionnement d’un système d’assistance basé sur des épisodes significatifs se rapproche de celui
des systèmes de Raisonnement à Partir de Cas (Aamodt et Plaza, 1992 ; Aamodt, 2001), que certains
travaux de recherche ont déjà tenté de transposer directement dans un contexte d’assistance à l’activité d’un utilisateur. C’est le cas par exemple des travaux de M. Jackinski et B. Trousse (1997, 1998, 1999) qui proposent d’extraire et de réutiliser de la navigation des internautes des « cas de navigation
mutua-lisables ». Dans le cas de l’approche MUSETTE,la grande différence avec une approche de
Raisonne-ment à Partir de Cas (RàPC) classique83 repose sur le fait de ne plus considérer des cas dans un cycle
de RàPC, mais d’une part des traces, d’autre part des épisodes pouvant – mais pas obligatoirement –
être utilisés en tant que cas. On peut alors imaginer d’autres utilisations que le RàPC stricto sensu, i.e.
comme nous l’avons rapidement évoqué : présentation à l’utilisateur, analyse, assistance indirecte, etc.
Pour marquer cette distinction, l’adaptation des principes du RàPC a d’ailleurs donné lieu à la création du Raisonnement à Partir d’Expérience Tracée proposés dans (Philippon et al., 2005) et (Mille et
al., 2006).
83 Le RàPC se base sur la remémoration et la réutilisation de « cas » concrets d’utilisation de système (sous la forme Problème-Solution). La construction d’un système RàPC suppose donc de définir précisément quelle est la structure des cas, comment ceux-ci sont stockés, remémorés, utilisés, au préalable à la construction du système. Changer le modèle de cas revient à changer le système.
Outre ce développement théorique, divers travaux autour de MUSETTE ont exploité les principes
géné-raux de l’approche et testé ses limites dans différents domaines applicatifs (Arana et al., 2004 ;
Mil-le et Prié, 2006 ; Laflaquière et Prié, 2009), dont celMil-le proposée pour l’assistance à la veilMil-le sur Mil-le Web
avec Human-Links™, dont nous avons fait mention84 (Laflaquière et Prié, 2003). De plus, la
réutilisa-tion des épisodes pour l’assistance a petit à petit été étendue à la facilitation de l’utilisation considérée au sens large (Mille et Prié, 2006) ainsi qu’à l’analyse à base de traces d’utilisation pour laquelle l’utilisateur de la trace n’est plus celui dont l’activité a été tracée. Bien que nous ne soyons pas rentrés
dans tous les détails de l’approche85 nous avons tenu à présenter les concepts importants de l’approche
MUSETTE dans la première partie de ce chapitre car elle préfigurait86 l’actuelle approche des Systèmes à Base de Traces.