L'objectif qui nous guide est en effet l'assistance à l'utilisateur fondée sur l'expérience d'utilisation. Nous présentons en conséquence dans ce chapitre les linéaments d'un cadre général pour l'assistance à la tâche d'un utilisateur exploitant les services d'un système d'information. Nous proposons un modèle de description d'un système d'information en termes de modèle d'utilisation et de modèles de tâches, lesquels permettent d'organiser et par conséquent d'expliquer des cas d'utilisation portant la connaissance d'utilisation. Ces cas pourront ensuite être utilisés pour aider l'utilisateur, et nous présentons quelques pistes de recherche allant dans cette direction.
On se rapproche en fait -- du point de vue de l'organisation des connaissances -- tout à la fois des bases de données semi-structurées (dans lesquelles les tâches ne sont absolument pas prises en compte) et de l'organisation des données en documents XML. Dans ces systèmes, comme dans un système Strates-IA, l'exploitation du système suivant des schémas locaux (on sait qu'à tel endroit la connaissance est organisée ainsi) comme son exploration sont les moyens privilégiés de l'utilisateur dans sa quête d'assistance à sa propre tâche. L'aide que peut lui apporter le système doit se baser sur l'expérience d'utilisation comme matériel premier d'apprentissage et de réutilisation.
Nous présentons tout d'abord dans ce chapitre comment il est possible de représenter la tâche d'un utilisateur, en nous intéressant plus particulièrement à la tâche de description et d'annotation dans les Strates-IA. Nous proposons ensuite de décrire un système informatique en modèle d'utilisation d'une part et en modèles de tâches d'autre part, afin d'être à même de décrire des cas d'utilisation permettant de stocker et d'exploiter l'expérience d'utilisation. Après une généralisation de l'approche proposée, nous fournissons quelques pistes d'exploitation des cas d'utilisation.
Une tâche (humaine) correspond à ce qu'une personne doit réaliser, se propose de faire dans le cadre d'une activité.
Dans le contexte de l'ingénierie des connaissances, la modélisation de la notion de tâche a été proposée [205] et a même fait l'objet de tentative d'ontologie de tâches génériques ( i.e. spécialisable pour toute tâche), comme par exemple dans [49]. Cette approche est alors totalement liée au développement de systèmes à base de connaissances.
La tâche de description et d'annotation de documents audiovisuels est une tâche d'une part non réalisable totalement automatiquement, d'autre part difficile même pour un utilisateur humain. Il y a donc lieu d'assister l'utilisateur effectuant cette tâche, et de considérer celle-ci en tant que telle.
![\includegraphics[width=\linewidth]{fig/exp/tout-en-un2.eps}](img92.gif) |
Pour illustrer comment les principes généraux des Strates-IA peuvent servir de support aux tâches d'un utilisateur, nous choisissons la tâche générique d'annotation de document audiovisuel qui, comme nous l'avons vu, est à la base d'autres tâches comme l'indexation, la recherche d'une séquence, l'analyse d'un document, etc.
Pour présenter les tâches, nous adoptons un formalisme de
diagramme de décomposition (cf. figure 4.1)
permettant de montrer comment les éléments du modèle des
Strates-IA sont exploités. Chaque n
ud d'un diagramme est une
sous-tâche d'un utilisateur, laquelle se décompose
éventuellement en succession (lisible de gauche à droite) de
sous-tâches à effectuer. Certaines sous-tâches peuvent prendre
une forme parmi plusieurs (OU).
La tâche annoter consiste tout d'abord à choisir une dimension d'analyse explicitant un objet d'intérêt. Cette dimension d'analyse peut être construite, ou bien sélectionnée parmi les DA disponibles dans le schéma de description, et il s'agit ensuite d'y choisir un élément d'annotation abstrait, et de poser celui-ci sur le flux. Pour celà, il convient soit de compléter l'annotation d'une unité audiovisuelle pré-existante, soit d'en créer une nouvelle, que l'on annote alors. La création du nouvel élément d'annotation nécessite de valoriser les propriétés de celui-ci : ses attributs (issus par exemple de traitement d'images), mais aussi ses relations élémentaires avec d'autres éléments d'annotation. Pour choisir un autre élément d'annotation EA-cible à mettre en relation Re avec notre EA-source, on peut soit le construire (et donc recommencer une sous-tâche annoter, plus précise puisque l'utilisateur est guidé par l'EA-source qu'il souhaite mettre en relation, et éventuellement par un schéma de description prescriptif), soit aller le choisir dans le contexte de EA-source. Pour explorer ce contexte, on peut par exemple déterminer un graphe potentiel décrivant la portée du contexte, et instancier celui-ci, avant de sélectionner l'EA-cible parmi les candidats activés. Un graphe potentiel contextuel peut être déterminé de plusieurs façons : soit il fait partie des valences de l' EA-source , soit on le construit directement (réservé aux utilisateurs experts) ; soit enfin on réutilise un exemple issu d'un cas d'utilisation similaire, que l'on adapte au cas courant ( cf. 4.4.3). L'adaptation consiste à substituer des éléments du graphe potentiel exemple par de nouveaux éléments corrigeant ainsi les écarts de contexte.
L'assistance à la tâche de l'utilisateur nécessite sa description sous une forme homogène à la représentation générale du système. Nous avons vu qu'une tâche peut se décomposer sous la forme d'un arbre, mais il est également possible de la décrire par ses spécifications précises comme proposé dans les outils implantant Common Kads [145].
Nous excluons ce dernier cas de la recherche d'information semi-structurée telle que nous l'envisageons, car les tâches ne peuvent généralement pas y être décrites de façon précise en terme procédural. La réalisation d'une tâche peut par contre être partiellement décrite sous la forme des éléments manipulés par l'utilisateur pour l'accomplir, ainsi que par les relations qui existent entre ces éléments et qui, d'une certaine façon, l'expliquent. En conséquence, une tâche peut être modélisée par une description des éléments qui doivent ou qui peuvent la caractériser, conduisant à la mise en place de formulaires << expliqués >>. Nous présentons dans la suite quelques définitions précisant ces notions dans le cas général d'un outil informatique, en les illustrant avec le modèle des Strates-IA.
On notera que le travail présenté ici est exploratoire et que les idées qui y sont décrites le sont de façon relativement générale. Nous ne prétendons donc pas donner une définition formelle ou définitive des objets présentés, mais plutôt donner les principes généraux et les intuitions fondamentales de l'approche.
Un outil informatique est un logiciel exploité pour une classe de tâches. Il est caractérisé par les objets de base qu'il fournit à l'utilisateur. Ces objets de base peuvent être décrits par un modèle d'utilisation.
Dans le cadre des Strates-IA, l'outil informatique de base serait par exemple un outil d'annotation manuelle de séquences audiovisuelles, aussi bien pour l'archivage que pour la recherche. Les objets de base sont ceux décrits dans les chapitres 1 et 2.
Un utilisateur est un être humain exploitant les possibilités offertes par un outil informatique dans le cadre d'une tâche. La tâche considérée peut être une sous-tâche d'une tâche beaucoup plus générale. Elle correspond à un sous-but que l'utilisation de l'outil informatique permet d'atteindre plus facilement. Une tâche peut être décrite par un modèle de tâche.
Dans le cadre des Strates-IA, la tâche d'annotation précédemment présentée devrait par exemple être modélisée.
Un modèle d'utilisation est intrinsèquement lié à l'outil exploité. Il décrit les objets de base de l'outil informatique ainsi que les relations qu'ils entretiennent. Un modèle d'utilisation minimal existe par définition (l'utilisation d'un outil sans mode d'emploi explicite minimal est exclue), et on considère qu'il n'existe qu'un seul modèle d'utilisation pour un outil informatique, celui-ci étant défini au moment de la conception de cet outil.
Dans le domaine de la bureautique, les objets de base principaux seraient par exemple le caractère, le mot, la ligne, le paragraphe, le document, le modèle de document, etc.
Le modèle d'utilisation simplifié des Strates-IA est résumé dans la figure 4.2. Les éléments d'annotation sont des inscriptions dans le flux d'éléments d'annotation abstraits et annotent les unités audiovisuelles. Les EAA sont organisés en réseau de relations. Des graphes potentiels, en s'instanciant, permettent de définir des instances qui sont des sous-graphes du graphe général. Des dimensions d'analyse regroupent des EAA désignés par des graphes potentiels. Les valences représentent des possibilités de relation entre EA et s'expriment également sous la forme de graphes potentiels, tandis que les schémas de description organisent des dimensions d'analyse.
![\includegraphics[width=13cm]{fig/exp/ModeleUtilisation.eps}](img93.gif) |
Nous appelons modèle de tâche une description des objets du modèle d'utilisation mobilisés par une tâche particulière avec les relations qu'ils entretiennent dans le cadre de cette tâche. Lorsqu'une tâche se révèle complexe, il peut être nécessaire de décomposer son modèle à l'aide des modèles de ses différentes sous-tâches mises en relation avec les objets du modèle d'utilisation qu'elles permettent d'obtenir. Chaque modèle de sous-tâche se trouve alors dans le contexte du modèle de tâche dont il fait partie, un modèle de tâche se décompose en sous-tâches selon une hiérarchie de décomposition.
Un exemple simple dans le domaine de la bureautique serait constitué par les modèles de document d'un traitement de texte : un modèle de lettre décrit les objets mobilisés dans la tâche d'écriture d'une lettre : expéditeur, destinataire, date, texte etc.
La figure 4.3 illustre comment décrire un modèle de la tâche d'annotation exploitant le modèle d'utilisation des Strates-IA. L'annotation d'une UAV (Modèle Annotation) mobilise :
La sous-tâche choix GP spécifie que le graphe potentiel désignant le contexte peut :
![\includegraphics[width=\linewidth]{fig/exp/ModeleTachePres.eps}](img95.gif) |
On peut à la limite considérer le modèle d'utilisation comme un modèle de la tâche extrêmement générique Utiliser le système Strates-IA, qui ne décrit que les éléments qui peuvent être manipulés et leurs relations.
Un cas d'utilisation3 décrit les instances des objets du modèle d'utilisation utilisés dans le cadre d'une tâche particulière dont un modèle est disponible. Un cas d'utilisation est en quelque sorte une trace de la réalisation de la tâche correspondant au modèle de tâche utilisé. Une instance d'un modèle de tâche se compose donc des instances des éléments qui le constituent, lesquels sont éventuellement d'autres modèles de tâche instanciés.
L'exemple de cas d'utilisation présenté figure 4.4 correspond à une modèle de tâche général de Description, dont un modèle de sous-tâche est le modèle de tâche de la figure 4.3, et un autre correspond à une tâche très générale d'Utilisation des Strates-IA. Le cas d'utilisation se compose alors deux sous-cas d'utilisation correspondant aux deux modèles de sous-tâche utilisés. Le premier sous-cas représente une trace de la réalisation de la tâche d'annotation générale qui a utilisé : la dimension d'analyse DA1, dont est issu l'élément d'annotation abstrait EAA12. L'élément d'annotation EA54 est une inscription dans le flux de EAA12 et annote l'unité audiovisuelle UAV9. EA54 est en relation élémentaire avec EA451, dont la présence n'est pas expliquée (voir plus loin), et avec EA523 qui a lui été désigné par l'instance GPi11 du graphe potentiel GP11, lequel correspond à la valence valence4 (valence de EAA12). Le second sous-cas spécifie qu'un élément d'annotation EA673 a été utilisé et mis en relation avec EA145 et EA451. Un graphe potentiel GP23 a également été utilisé au cours de cet épisode.
![\includegraphics[width=\linewidth]{fig/exp/CasUtilisation.eps}](img96.gif) |
Les éléments d'un cas d'utilisation sont des instances d'objets décrits dans le modèle d'utilisation et éventuellement dans un modèle de tâche (c'est à dire les tâches et sous-tâches).
Les différents éléments du cas d'utilisation profitent des relations existantes (inter- ou intra-modèles) entre les objets de ces modèles, qui fournissent des explications à leur co-occurence. Un cas d'utilisation peut donc toujours s'expliquer par le modèle d'utilisation, et, quand il existe, par le modèle de la tâche courante.
Le cas d'utilisation de la figure 4.4 s'explique ainsi entre autres :
Les relations internes aux cas d'utilisation, par exemple le fait qu'un EA utilisé dans une tâche d'annotation et un EA utilisé dans une tâche générale indeterminée sont en relation participent aux explications internes au cas. Par exemple figure 4.4, la relation entre EA673 et EA451 est une relation interne au cas d'utilisation.
La mémoire du système est composée des informations qu'il doit mémoriser en vue de les restituer dans le cadre des différentes tâches de l'utilisateur (nous n'y incluons pas les modèles d'utilisation et de tâches qui sont a priori fixés).
Les éléments constitutifs de la mémoire sont donc des instances des éléments décrits dans le modèle d'utilisation. Ils s'expliquent << universellement >> selon les relations décrites dans le modèle d'utilisation, selon les relations génériques décrites dans les modèles de tâche et, in fine selon les relations spécifiques décrites dans les cas d'utilisation.
Par exemple dans le cadre de l'utilisation des Strates-IA, la mémoire (cf. figure 4.5) est composée des UAV, des EA et des EAA, des dimensions d'analyse et des graphes potentiels, etc. La mémoire comporte également les cas d'utilisation eux-mêmes. Ceux-ci organisent les connaissances décrites ailleurs (dans le graphe Strates-IA par exemple) en les mettant en relation, c'est à dire :
Tous les éléments de la mémoire s'expliquent mutuellement par les relations directes ou indirectes qu'ils entretiennent.
Les définitions que nous venons de présenter ont un cadre plus large que l'étude des Strates-IA, et la même démarche a été utilisée dans le cadre d'autres projets de recherche tels que présentés dans [69,162] par exemple. C'est cependant dans le cadre de l'étude des Strates-IA qu'elle a été considérée et étudiée comme objectif en soi.
Nous proposons de généraliser l'approche présentée distinguant modèle d'utilisation (universel), des modèles de tâches (génériques) permettant de mémoriser des cas d'utilisation (spécifiques) comme suggéré figure 4.5. La séparation entre éléments concepts et instances est artificielle et correspondrait dans les Strates-IA à celle entre EAA et EA. Plusieurs types d'éléments peuvent faire partie de la mémoire. Par exemple, dans les Strates-IA les graphes potentiels et les dimensions d'analyse y sont conservés.
![\includegraphics[width=\linewidth]{fig/exp/ModelesGeneral.eps}](img97.gif) |
Les éléments du modèle d'utilisation s'expliquent par les relations qu'ils entretiennent les uns avec les autres. Les modèles de tâches s'expliquent par les éléments du modèle d'utilisation qu'ils utilisent et par les relations qu'ils entretiennent les uns avec les autres. Les éléments d'un cas d'utilisation s'expliquent par les éléments du modèle d'utilisation qu'ils utilisent, par les éléments du modèle de tâche qu'ils respectent et enfin par les relations internes au cas d'utilisation non expliquées dans d'autres modèles.
La modélisation proposée d'un système d'information en modèle d'utilisation, modèle de tâche et cas d'utilisation permet de stocker l'expérience d'utilisation du système de telle sorte que celle-ci soit expliquable. En effet, les modèles de tâches permettent de rationaliser les cas d'utilisation, c'est à dire à la fois de diriger le choix des connaissances stockées dans les cas et d'expliquer ces dernières, les rendant ré-utilisables.
Plusieurs directions de recherche sont ouvertes pour exploiter l'expérience sous la forme de cas d'utilisation, nous les présentons rapidement dans la suite de ce chapitre.
Les cas d'utilisation sont des illustrations de l'exploitation des connaissances pour réaliser une tâche. Ces illustrations sont autant d'exemples concrets de l'utilisation de concepts modélisés dans le système, aussi bien les éléments du modèle d'utilisation que les modèles de tâches. A contrario, des concepts non utilisés peuvent être remis en cause par leur non-utilisation.
Dans SESAME par exemple, l'utilisation d'un EAA ou d'une valence s'illustre et s'explique directement par un exemple dans la base, c'est à dire par les cas d'utilisation les mettant en jeu d'une manière ou d'une autre. L'utilisation de la valence valence4 de l'EAA EAA12 est ainsi illustrée par le cas d'utilisation présenté la figure 4.4.
Dans un cadre plus général, le processus de validation d'une << mémoire d'entreprise >> pourrait s'appuyer sur ce type d'approches. Cette façon de procéder revient à valider (ou invalider) les modèles de l'entreprise par leur usage concret.
Les cas d'utilisation peuvent être utilisés comme support concret d'apprentissage de connaissances nouvelles.
Les relations mises en place par l'utilisateur entre éléments d'un cas d'utilisation peuvent être, par répétition, autant d'indications statistiques de relations plus générales intégrables dans la mémoire.
Dans le cadre de SESAME, des relations élémentaires (épisodiques par définition) répétées dans la mémoire entre EA issus d'EAA identiques peuvent pousser à induire des relations entre ces EAA. Il s'agit d'une sorte de data mining validé à l'avance par les différents épisodes d'annotation eux-mêmes (un épisode d'annotation étant un cas d'utilisation dans le cadre d'un système Strates-IA). La relation élémentaire, parce qu'elle autorise toute mise en relation, y compris non prévue, constitue donc un outil puissant d'apprentissage de nouvelles relations.
Un apprentissage sur les modèles de tâches pourrait s'opérer par renforcement des explications utilisées pour assembler les éléments d'un cas d'utilisation.
La figure 4.6 illustre cette idée : un modèle de tâche A est utilisé pour expliquer la sous-tâche st1 d'un cas d'utilisation CU1, et une relation d'explication R, non prévue dans le modèle de tâche est utilisée pour mettre en relation un élément de st1 à un élément de st2. La répétition d'une telle explication dans plusieurs cas d'utilisation peut conduire à la création d'un nouveau modèle de tâche A', spécialisation de A, qui pourra à son tour expliquer de nouveaux cas d'utilisation, tel que CU2, ou contribuer à éclairer retrospectivement CU1.
Par exemple, dans le cadre des Strates-IA, les valences pourraient être acquises à partir des graphes potentiels utilisés pour chercher des contextes permettant la mise en place de relation. Ce processus d'apprentissage serait alors en boucle ouverte sur l'utilisateur expert qui devrait valider les candidatures de valences avant de les ajouter. Si la notion de valence fait bien partie du modèle d'utilisation, les valeurs des valences (instances de graphes potentiels) sont clairement associées à une tâche et peuvent être utilisés en tant que tels.
![\includegraphics[width=400pt]{fig/exp/integrationExplication.eps}](img98.gif) |
Dans une démarche inverse, une différenciation d'explications pourrait être mise en évidence par les explications que l'utilisateur est amené à modifier ou ajouter, conduisant à modifier des modèles de tâche existants.
Les cas d'utilisation peuvent servir directement à l'assistance à la tâche. Ainsi, on peut imaginer un assistant générique -- une sorte de moteur d'assistance -- qui, sollicité par un utilisateur pour l'aider dans une certaine tâche (décrite dans un modèle de tâche) s'y spécialise. L'assistant utiliserait alors la description partielle de la tâche en cours et la base de cas d'utilisation pour proposer des pistes de solutions fondées sur l'expérience de tâches similaires. Cette approche se décline au niveau des sous-tâches, et le paradigme du raisonnement à partir de cas (RàPC) [1] peut être utilisé avec profit pour ce type d'assistance.
On pourrait par exemple imaginer qu'au cours d'une session d'annotation un utilisateur se trouve à court d'idées d'annotation et fasse appel au système. Alors celui-ci (ou plutôt un assistant), analysant la session en cours construirait un cas d'utilisation correspondant à la tâche courante et cherche dans la base de cas d'utilisation un cas similaire, qu'il proposera à l'utilisateur afin de donner des pistes à celui-ci (par exemple << utiliser telle valence >>).
Cette façon de voir les choses pourrait faciliter considérablement la réalisation d'assistants pour des tâches mal définies au départ, mais s'appuyant sur un modèle d'utilisation unique. L'outil, même s'il ne prend pas alors le statut de système à base de connaissance pour autant, doit permettre la manipulation explicite des connaissances qui régissent son fonctionnement, de façon à rendre la notion d'<< assistant intelligent >> possible. A l'instar de [91], nous considérons qu'il s'agit de la seule façon de rendre de véritables services << personnalisés >> aux utilisateurs.
Nous avons dans ce chapitre présenté une manière originale de considérer un système informatique, et plus particulièrement un système d'information en s'intéressant à son rôle de mémoire, non seulement comme permettant de stocker les connaissances de description mises en place (les documents), mais aussi l'expérience d'utilisation rationalisée par des modèles de tâche adaptés.
Nous avons ainsi présenté la tâche de description dans un système fondé sur les Strates-IA, et, sur la constatation de la complexité d'une telle tâche, nous avons proposé un cadre de modélisation permettant de distinguer modèle d'utilisation, modèles de tâches et cas d'utilisation, comme traces de réalisation des tâches. Cette approche est d'abord définie et illustrée dans le cadre de la tâche d'annotation décrite précédemment, puis est généralisée. Nous avons enfin justifié cette manière de décrire les tâches et l'expérience d'utilisation d'un système d'information en présentant des pistes de recherche prometteuses d'utilisation des cas d'utilisation comme prise en compte naturelle de l'expérience comme source d'explication et d'assistance pour l'utilisateur.
Le travail présenté ici ne prétend donc pas fournir des solutions à l'aide à l'utilisateur fondée sur l'expérience, mais n'en est que la première étape conceptuelle. Il s'agit alors de proposer un moyen de stocker l'expérience d'utilisation de telle sorte que celle-ci soit expliquée et rationalisée, donc utilisable comme connaissance.