Sciences
et Technologies de l´Information et de la Communication pour l´Éducation et la Formation |
Volume 10, 2003 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Vers un modèle générique d’assistance
|
Apprentissage individualisé par ordinateur |
Téléapprentissage en réseau |
---|---|
Apprentissage individualisé : un étudiant, un ordinateur |
Apprentissage individuel et collectif, plusieurs apprenants en réseau |
Le didacticiel ou le tuteur intelligent est le principal matériel pédagogique sinon le seul |
Multiplicité de matériels et de ressources éducatives en ligne et sur le Web |
Assistance fournie par un module tutoriel |
Formes multiples d’assistance humaine et informatisée |
Ensemble limité et fixe de stratégies tutorielles |
Ensemble flexible et ouvert de stratégies pédagogiques |
Guidage serré de l’apprentissage |
Autogestion de l’apprentissage |
Connaissances spécialisées et buts précis de la formation |
Buts plus larges, plus génériques, plus adaptables |
Données d’observation continues et liées étroitement aux connaissances et aux habiletés visées |
Données d’observation partielles et liées de façon floue à un ensemble de compétences visées |
Tableau 1 : Comparaison de l’enseignement assisté par ordinateur et du téléapprentissage en réseau [Paquette02]
Pour élaborer le modèle générique d’un système d’assistance pour le téléapprentissage (figure 2), nous avons utilisé le logiciel MOT développé au Centre de recherche LICEF. Ce logiciel permet de représenter sous forme graphique un ensemble de connaissances, dans notre cas les attributs et les composantes d’un système d’assistance, à l’aide de la technique de modélisation par objet typé [Paquette96], [Paquette02b]. Cette technique propose de distinguer, au moyen d’un certain formalisme graphique, à la fois les types d’objets de connaissances et les types de liens entre ces objets de connaissances. Deux types de connaissances suffisent à élaborer un modèle conceptuel générique (une ontologie), soit des concepts (représentés par des rectangles) et des principes (représentés par des hexagones). Par ailleurs, trois types de liens, représentés par des flèches traversées d’une lettre indiquant le type de lien, se sont avérés nécessaires pour définir le modèle générique, soit le lien de composition (C) sur lequel est basée la hiérarchie principale des concepts, le lien de spécialisation (S) entre concepts et le lien de régulation (R) entre un principe et le concept qu’il régit.
Par ailleurs, le lien d’instanciation (I) peut être utilisé pour indiquer la relation entre le modèle générique d’assistance et un modèle spécifique dans un contexte d’application, comme celui du système hôte ADISA. Les connaissances factuelles (représentées par des rectangles aux coints coupés) résultant de cette instanciation du modèle générique sont les composantes d’un modèle spécifique d’assistance comme celui que nous visons à définir pour ADISA.
L’équipe de chercheurs s’est réunie à de nombreuses reprises afin de construire collectivement le modèle à l’aide du logiciel MOT projeté sur écran. L’équipe était composée de chercheurs expérimentés dans la construction de plusieurs systèmes conseillers intelligents ou d’interfaces adaptatives, ainsi que d’experts en ingénierie pédagogique connaissant bien le système hôte sur lequel le système d’assistance doit se greffer. De plus, l’un des membres de l’équipe donne régulièrement des formations à de futurs utilisateurs du système hôte et s’est donc appuyé sur son expérience de dispensateur de soutien humain pour instancier le modèle et aider l’équipe à valider le modèle générique. L’élaboration d’un modèle spécifique pour ADISA construit en parallèle, et pour lequel l’équipe disposait de plusieurs exemples d’interventions d’assistance déjà implantées dans ADISA, a servi à élaborer le modèle générique, par un va-et-vient constant entre la formulation générique et la formulation instanciée de chaque élément du modèle.
La première version du modèle spécifique d’assistance a subi une validation préliminaire, en la confrontant à des données recueillies lors d’une observation d’une séance d’utilisation d’ADISA par trois usagers travaillant en équipe autour d’un même poste de travail et dont deux des membres étaient déjà très familiers à MISA mais peu à ADISA et le troisième peu familier tant avec MISA qu’avec ADISA. Au cours de cette séance d’une journée, qui a eu lieu au LORIT (Laboratoire Observatoire de Recherche sur l’Ingénierie du Téléapprentissage) du Centre de recherche LICEF, une assistance humaine était accessible à distance sur demande. Afin de simuler une situation d’assistance à distance, l’assistance était fournie verbalement par une personne qui n’était pas présente dans la salle mais qui pouvait suivre le travail accompli par les usagers par le truchement d’une caméra vidéo filmant les usagers et d’un système de captation de tous les événements se produisant au poste de travail des usagers. Un enregistrement synchronisé des actions et du discours des usagers et de la personne ressource a été effectué. L’analyse de cet enregistrement a permis de répertorier un certain nombre d’interventions d’assistance qui furent analysées en fonction des éléments du modèle générique préliminaire (voir l’exemple dans la section 6). L’équipe a ensuite procédé à la révision du modèle à partir des résultats de l’analyse des observations.
Notre modèle générique d’un système d’assistance est présenté à la figure 2. Cette figure illustre le modèle principal (ou de premier niveau) du modèle. Certains éléments de ce modèle sont décomposés dans des "sous-modèles" qui, pour des raisons de contrainte d’espace, sont décrits brièvement sous forme textuelle dans les paragraphes qui suivent. Par ailleurs, nous fournissons différents exemples illustrant comment les éléments du modèle peuvent être instanciés dans le contexte de l’utilisation d’ADISA.
La figure 1 fait bien voir qu’un système d’assistance épiphyte se greffe à un système hôte (dans notre cas, ADISA). Le système hôte est composé notamment d’un ensemble d’objets sur lesquels peuvent porter l’assistance (ce que nous appelons des objets d’assistance) et que nous spécifions un peu plus loin. Le système d’assistance est extérieur et donc en partie épiphyte, néanmoins il communique avec le système hôte, qui doit l’informer des évènements qui surviennent et peut parfois être commandé par le système d’assistance, dans le cas des interfaces adaptatives.
Un système hôte peut être défini comme un environnement proposant à un usager ou à un groupe d’usagers un ensemble de procédures et de ressources visant à leur permettre de réaliser une tâche relativement complexe. En ce sens, on retrouve dans le système hôte les éléments essentiels permettant de réaliser le modèle de la tâche. Le modèle de la tâche n’est toutefois pas une composante du système hôte même s’il suppose l’utilisation de toutes ou de certaines fonctionnalités de celui-ci. Le concepteur du système d’assistance peut décider de soutenir uniquement certaines tâches et à partir d’un certain point de vue qu’il définit. Par exemple, un système d’assistance pour la fabrication d’un budget à l’aide d’un tableur ou pour la planification de travaux avec tableur comportera deux modèles de tâches très différents, même s’il s’agit du même système hôte, ici le tableur.
En plus d’une liste hiérarchique de tâches et de sous-tâches que permet de réaliser le système hôte (que nous appelons modèle de composition de la tâche), le modèle de la tâche peut aussi contenir :
un modèle de progression dans la tâche : la progression peut être séquentielle (les sous-tâches doivent être exécutées dans un ordre prédéterminé), parallèle (les sous-tâches peuvent être exécutées parallèlement), modulaire (les sous-tâches d’une activité doivent toutes être réalisées avant de passer à une autre activité) ou optionnelle (toutes les sous-tâches peuvent être réalisées dans un ordre choisi par l’usager) ;
un modèle de pondération de la tâche : ce modèle permet de déterminer, le cas échéant, l’importance relative des sous-tâches à l’intérieur du modèle de la tâche. Ceci peut conduire, par exemple, à attribuer un pourcentage à une sous-tâche ;
un modèle temporel de progression dans la tâche, qui spécifie, lorsque c’est pertinent, la durée ou les dates de chaque sous-tâche ainsi qu’un échéancier de réalisation de la tâche. Ces aspects du modèle de la tâche sont utiles pour permettre au système d’assistance d’offrir à l’usager de l’assistance adaptée à sa progression dans la tâche.
Figure 2 : Le modèle générique d’un système d’assistance (modèle principal)
Pour qu’il soit adaptatif, un système d’assistance doit également comporter un modèle de l’usager, qui se construit dynamiquement par la collecte des traces laissées par l’usager lors de l’utilisation du système hôte et du système d’assistance. Le modèle usager est en grande partie une comparaison entre ce que l’usager fait et le modèle de la tâche ou les prescriptions sur l’utilisation du système hôte (overlay model). Le modèle de l’usager est ainsi extrait des traces d’utilisation, mais il peut être aussi modifié directement par l’usager lui-même, lorsqu’il spécifie des préférences ou s’il corrige son modèle usager.
Nous pouvons distinguer le modèle statique de l’usager et le modèle dynamique de l’usager. Le modèle statique fait référence à des traits généraux de l’usager (compétence dans le domaine, familiarité avec le système hôte), à des préférences déclarées par l’usager lui-même dans le système d’assistance (style d’expression et mode d’accès souhaités pour l’assistance) ou encore au rôle de l’usager dans la tâche. Le modèle dynamique fait référence à toutes les traces dynamiques que le système d’assistance se doit de colliger au cours de l’utilisation du système hôte ou du système d’assistance par l’usager. Le fait de lancer, débuter ou de compléter une ressource du système hôte, le nombre de fois que l’usager a accédé à une ressource, le temps passé à un élément du système hôte, la quantité d’activité dans un élément de la tâche, etc., constituent autant d’exemples de traces pouvant être colligées sur l’activité de l’usager dans la tâche. Le nombre de fois que l’usager a consulté ou reçu un message d’aide ou encore sa réaction à un message d’assistance constituent des exemples de traces pouvant être colligées sur l’utilisation du système d’assistance par l’usager.
Outre le modèle de la tâche et le modèle de l’usager, un troisième type de modèle peut être intégré au système d’assistance ; il s’agit du modèle de groupe. En effet, tel que déjà mentionné, l’une des caractéristiques des environnements de téléapprentissage est qu’ils permettent les échanges et le travail collaboratif. Le système d’assistance peut ainsi conserver un modèle de groupe qui peut être une représentation moyenne des modèles des individus du groupe, une représentation des propriétés du groupe tel qu’identifiées au départ, ou encore une trace des activités du groupe et des interactions entre les membres du groupe. Le modèle de groupe vise à offrir à chaque usager un portrait de la progression du groupe ainsi que de l’assistance fondée sur une comparaison entre sa propre progression dans la tâche et la progression du groupe. Tout comme le modèle de l’usager, le modèle du groupe comporte une dimension statique et une dimension dynamique. La dimension statique fait référence aux compétences et préférences du groupe dans le domaine, au style de communication et au mode de fonctionnement souhaités par le groupe, à la répartition des tâches dans le groupe, à l’échéancier du groupe, etc. La dimension dynamique fait référence aux traces laissées par le groupe que ce soit dans le système hôte (début ou fin du travail sur un élément de la tâche, etc.) ou dans le système d’assistance (assistance déjà fournie à l’ensemble du groupe, etc.).
Enfin, un système d’assistance est constitué d’un ensemble d’interventions d’assistance1. Les prochains paragraphes sont consacrés à la définition des principales composantes d’une intervention d’assistance.
Les principales composantes d’une intervention d’assistance sont l’identification de l’assistance (son nom), l’objet d’assistance, le thème d’assistance, le mode d’accès à l’assistance, les buts de l’assistance et les différentes règles d’assistance permettant de réaliser l’intervention.
Il est intéressant de spécifier le thème de chaque intervention d’assistance, de manière à permettre éventuellement le regroupement des interventions par thématique dans une aide indexée mais également la constitution de modules d’assistance spécialisés.
Une intervention d’assistance peut porter sur différents thèmes :
le fonctionnement du système hôte, spécifiquement qui comprend :
les fonctions des éléments du système hôte (à quoi sert tel ou tel élément du système hôte), par exemple, à quoi sert la fonction d’annotation ;
la sémantique des éléments du système hôte (lexique, menus, icônes, placement des éléments, etc.) ; par exemple, la signification de la numérotation employée pour nommer les "éléments de documentation" (ÉD) dans ADISA ;
les procédures du système hôte (comment procéder pour faire une opération) ; par exemple, la procédure pour créer un nouveau projet ou l’enregistrer ; la procédure d’utilisation des éléments de base pour créer un modèle MOT du scénario pédagogique ;
les stratégies d’utilisation du système hôte ; par exemple, une méthode de travail pour éviter les erreurs (e.g. enregistrement périodique), une méthode pour nommer les composantes produites, etc. ;
l’exécution de la tâche, par exemple l’explication du déroulement d’une activité, l’ordre à respecter ;
l’adaptation de la tâche, par exemple réduction du nombre d’ÉD à produire lorsque l’environnement de téléapprentissage à développer est relativement simple ;
la qualité des productions, soit les critères attendus pour les productions : cohérence, complétude, pertinence, clarté, validation externe, etc., par exemple cohérence entre les différentes parties d’un ÉD (cohérence endogène) et cohérence entre différents ÉD (cohérence exogène) (l’évaluation qualitative doit en général être assurée par un acteur humain, mais l’information une fois connue peut devenir un paramètre considéré par le système d’assistance) ;
la collaboration au sein du processus de travail lorsque le système hôte le permet, soit la coordination entre les membres d’une équipe ou entre des équipes de gestion (appariement des participants, répartition et synchronisation du travail, séquence des tâches, etc.), l’engagement des participants et la communication des idées entre les participants (par exemple, entente sur l’utilisation de la fonction d’annotation dans ADISA) ;
l’autogestion, qui comporte la planification de son propre processus de travail avec le système hôte, la supervision de sa propre compréhension des éléments du système hôte et l’évaluation de son efficacité à exécuter les procédures du système hôte.
De façon plus spécifique, une intervention d’assistance est toujours faite en fonction d’un objet ou d’un ensemble d’objets, qu’il soit partie du système hôte, de la tâche ou du modèle usager ou de groupe. Il peut s’agir :
d’un concept utilisé dans le système hôte (e.g. le concept d’"unité d’apprentissage" utilisé dans ADISA, ceux d’activité optionnelle ou de cohérence dans les critères de qualité) ;
d’une ressource disponible dans le système hôte (e.g. un ÉD d’ADISA, une rubrique spécifique d’un ÉD ou une valeur dans cette rubrique) ;
d’une procédure ou d’un ensemble de procédures supportées par le système hôte (e.g. procédure de création d’un nouveau projet, procédure de production d’un rapport) ;
d’un principe ou d’un ensemble de principes utilisés dans le système hôte (e.g. principes de sélection d’une stratégie pédagogique, principes de collaboration entre les membres d’un projet) ;
d’un lien entre ces divers objets (e.g. le lien entre deux tâches).
Chaque intervention se fait selon l’un ou l’autre des modes d’accès suivants (tableau 2) :
assistance indexée - l’intervention est fournie en fonction d’une liste statique et indexée, que l’usager peut consulter en tout temps (e.g. un conseil apparaît à la suite d'une recherche ou d'une sélection dans la liste des interventions d'assistance classifiées en fonction des thématiques) ;
assistance contextuelle - l’intervention est fournie dynamiquement en fonction du contexte, c’est-à-dire par rapport à un objet d’assistance spécifique ; l’intervention ne tient pas compte du modèle usager, elle est la même pour tous les usagers (e.g. la signification d’un terme utilisé dans un ÉD apparaît en pop-up lorsque l’usager pointe le terme) ;
assistance adaptative globale - l’intervention est fournie en fonction du modèle statique de l’usager (e.g. des conseils supplémentaires s’adressant aux novices dans la tâche sont fournis dans un module pouvant être consulté en tout temps) ;
assistance adaptative contextuelle - l’intervention est fournie en fonction du contexte et en fonction du modèle dynamique de l’usager (e.g. une explication est donnée à l'usager à sa première visite dans un ÉD).
Assistance en contexte |
Assistance non associée au contexte |
|
---|---|---|
Assistance non fondée |
Assistance contextuelle |
Assistance indexée |
Assistance fondée |
Assistance adaptative contextuelle |
Assistance adaptative globale |
Tableau 2 : Les modes d’accès à l’assistance
Une intervention d’assistance comporte un ou plusieurs buts. Nous en avons identifié sept :
présentation - il s’agit de décrire un objet d’assistance, tel que par exemple un ÉD spécifique ;
explication - il s’agit d’offrir à l’usager des explications supplémentaires à propos d’un objet d’assistance (e.g. spécifier l’utilisation qui est faite dans un autre ÉD d’une donnée entrée par l’usager) ;
rappel - il s’agit de rappeler à l’usager certaines procédures ou principes, notamment lorsqu’il contrevient à ceux-ci (e.g. vous ne pouvez effectuer telle action avant telle autre.) ;
guidage - il s’agit de montrer à l’usager comment exécuter une tâche, par des moyens graphiques (mise en relief, sélection, flèche, clignotement, etc.), par un contrôle adaptatif du système visant à inciter (ouverture d’un formulaire) ou à démontrer de manière dynamique, à l’usager les étapes d’une manœuvre qu’il souhaite faire (animation explicative) ;
motivation - il s’agit de fournir à l’usager des informations ayant un impact sur son état affectif (encouragement, indication qu’une étape est terminée, etc.) ;
vérification - il s’agit de poser une question à l’usager afin de vérifier un aspect relié à la tâche ou à l’usager, de manière à lui offrir par la suite un conseil adapté (e.g. s’agit-il de la première fois que vous utilisez ce système ?) ;
rétroaction - il s’agit d’offrir à l’usager des informations sur les activités du système (propagation des données, nouvelle ressource accessible) ou l’état d’avancement de son travail (e.g. barre de progression sur une activité).
La règle d’assistance constitue le cœur de l’intervention d’assistance ; elle décrit de façon opérationnelle les conditions requises et les actions d’assistance qui seront exécutées.
Chaque intervention d’assistance est définie par une règle d’assistance. Chaque règle est composée, d’une part, d’une ou plusieurs conditions d’assistance (SI...) et, d’autre part, d’une action d’assistance ou d’une séquence d’actions d’assistance (ALORS...). Voyons les différents types de conditions et les différents types d’actions qu’il est possible de retrouver dans une intervention.
Nous distinguons les conditions de déclenchement et les conditions de clôture de l’assistance.
Pour qu’une action (ou une séquence d’actions) d’assistance soit déclenchée, il faut que toutes les conditions d’assistance soient vérifiées. L’événement déclencheur est un type de condition qui lance un appel au système conseiller et la recherche d’une règle qui possède cette condition et dont toutes les autres conditions sont vraies (par exemple, l’ouverture d’une ressource).
Parmi les conditions de déclenchement, on retrouve les conditions suivantes :
les conditions relatives au modèle de la tâche - par exemple, telle intervention d’assistance sera fournie à une date spécifiée dans le modèle temporel de progression dans la tâche ;
les conditions relatives au modèle de l’usager : ces conditions peuvent s’appuyer sur le modèle statique de l’usager, sur le modèle dynamique de l’usager ou encore sur des comparaisons entre le modèle de l’usager, d’une part, et le modèle de la tâche ou le modèle de groupe, d’autre part ;
conditions relatives au modèle statique de l’usager (assistance adaptative globale) - ces conditions s’appuient sur des caractéristiques générales de l’usager, telles que définies dans le modèle statique de l’usager (e.g. Si l’usager préfère tel mode d’accès à l’assistance...) ;
conditions relatives au modèle dynamique de l’usager (assistance contextuelle et adaptative) - il s’agit de conditions qui s’appuient soit sur les actions de l’usager au cours de la réalisation de la tâche à l’aide du système hôte, soit sur les actions de l’usager en rapport avec le système d’assistance (par exemple, pour ce qui concerne le premier cas, une action d’assistance peut être déclenchée lorsque l’usager sélectionne, débute ou complète un élément de la tâche, lorsqu’il déclare que telle sous-tâche est importante pour lui, lorsqu’il passe une certaine période de temps à travailler à l’un des éléments de la tâche, lorsqu’il effectue successivement plusieurs fois une action déterminée démontrant possiblement qu’il se trouve dans une impasse (ouvrir-fermer un ÉD, par exemple), lorsqu’il annote un élément de la tâche, etc., l’univers des possibilités est très étendu ; dans le deuxième cas par exemple, une action d’assistance sera déclenchée si l’usager a déjà reçu un message dans la même situation ou s’il a réagi à telle ou telle intervention d’assistance) ;
les conditions relatives au modèle de l’usager en relation avec le modèle de la tâche - il s’agit de conditions qui s’appuient sur l’évaluation par le système de l’écart entre le modèle de l’usager et le modèle de la tâche. Par exemple, une intervention est fournie si l’usager est en retard sur l’échéancier de la tâche ou encore s’il tente de compléter un ÉD avant tel autre, alors que ces ÉD doivent suivre une progression séquentielle ;
les conditions relatives au modèle du groupe - ces conditions sont semblables aux conditions relatives au modèle de l’usager, sauf qu’ici, elles prennent leur origines dans les modèles agglomérés des individus d’un groupe et éventuellement dans les propriétés et actions du groupe :
conditions relatives au modèle statique du groupe - par exemple, une assistance supplémentaire est rendue disponible aux usagers qui font partie d’un groupe dont tous les membres sont considérés novices dans le domaine de la tâche ;
conditions relatives au modèle dynamique du groupe - par exemple, une intervention est fournie lorsqu’au moins deux membres du groupe sont intervenus dans telle activité, ou si la participation est jugée insuffisante ;
les conditions relatives au modèle de groupe en relation avec le modèle de la tâche - par exemple, une intervention est fournie lorsque l’ensemble du groupe prend du retard par rapport au modèle temporel de progression de la tâche ;
les conditions relatives au modèle de l’usager en relation avec le modèle de groupe - il s’agit de conditions qui s’appuient sur l’évaluation par le système de l’écart entre le modèle de l’usager et le modèle de groupe - par exemple, une intervention est fournie lorsque l’usager prend du retard par rapport à la progression de l’ensemble du groupe ou encore s’il intervient peu dans la tâche par rapport à l’intensité du travail accompli par les autres membres du groupe.
Par ailleurs, lorsqu’une intervention d’assistance est fournie, il est souvent nécessaire d’indiquer au système d’assistance des conditions de clôture de l’intervention : nombre de répétition de l’intervention, durée de celle-ci.
Nous pouvons distinguer les actions d’assistance déclenchées et les actions de clôture de l’assistance.
Les actions d’assistance pouvant être déclenchées sont de l’un ou l’autre des quatre types suivants :
adaptation du système hôte ou du système d’assistance : cette adaptation peut venir modifier
l’interface du système hôte - par exemple, la couleur d’un bouton est modifiée suite à une action de l’usager ou encore le nombre de choix est réduit dans un menu en fonction du contexte ;
le modèle de l’usager - par exemple, un compteur enregistre le nombre de fois qu’un usager accède à un élément du système hôte ;
le modèle du groupe - par exemple, un graphique montre la moyenne de groupe des résultats à un test ;
l’interface du système d’assistance - par exemple, les préférences de l’assistance sont modifiées ;
affichage d’un message du système d’assistance : le message est textuel ou audiovisuel et peut prendre différentes formes fondées sur les buts de l’assistance : conseil positif, négatif ou de type avertissement [Tchounikine98], constat, question.
lancement/affichage d’un élément du système hôte : dans ADISA, il s’agit, par exemple, d’ouvrir un formulaire d’ÉD.
lancement/affichage d’une ressource externe : il peut s’agir soit de lancer une application, soit d’afficher un document externe ou de communiquer avec des participants du projet en envoyant, par exemple, un courriel à tous les participants une fois qu’un ÉD est complété.
Tel que déjà mentionné, ces différentes actions peuvent se combiner afin de former une séquence d’actions d’assistance.
Quant aux actions de clôture de l’assistance, elles dépendent du type d’action d’assistance fournie : par exemples, pour un message affiché faire disparaître le conseil après un certain délai ; pour le lancement ou l’affichage d’un élément du système hôte (par exemple, lancement d’une démonstration), alors fermer ou faire disparaître cet élément. Il en est de même pour le lancement ou l’affichage d’une ressource externe. Quant aux actions d’adaptation de l’interface du système hôte ou du système d’assistance (e.g. sélection par le système d’une rubrique dans ADISA, mise en relief d’une activité suggérée), la clôture supposera de de retourner à l’interface originale.
Lorsque aucune action de clôture de l’assistance n’est spécifiée, alors l’intervention d’assistance demeure disponible tout au long de la session d’utilisation du système hôte. Par exemple, le bouton d’une activité change de couleur lorsque celle-ci est complétée, et aucune condition de clôture n’est définie.
Les conditions et les actions de clôture peuvent également être laissées sous le contrôle de l’usager : arrêt d’une animation, introduction de préférences sur les modalités, le rythme de l’assistance, le type de rétroaction (graphique, textuelle ou verbale).
Afin de développer un modèle d’assistance qui soit adapté à la réalité des activités des concepteurs d’environnements de téléapprentissage, nous avons cherché à instancier le modèle en développement sur des cas concrets d’utilisation de l’environnement ADISA. Nous reprenons ici quelques exemples de cas d’assistance qui ont été observés lors de l’étape de validation du modèle présentée plus haut, et qui correspondent à du soutien reçu par les utilisateurs, qu’il soit fourni par ADISA, par les collaborateurs ou par un expert de l’utilisation de l’outil et de la tâche. Ces exemples visent à illustrer, de façon plus concrète, comment s’articule le modèle pour représenter des règles d’assistance dans le contexte de l’utilisation d’ ADISA.
Le tableau 3 présente, pour chaque situation-exemple, l’assistance qui a été apportée spontanément par le conseiller humain ou qui a été demandée par les utilisateurs d’ ADISA. Il montre ensuite comment le modèle générique permet de représenter, pour chacune des interventions d’assistance, le type d’assistance (thème, objet, mode, but), les conditions de déclenchement et les actions d’assistance fournies.
Les observations présentées portent sur le début de l’interaction avec le système, aussi plusieurs des interventions d’assistance portent sur le fonctionnement du système hôte. Nous présentons cependant certaines interventions d’assistance portant sur la tâche.
Par exemple dans la première situation, lors de l’observation, l’usager voulait nuancer un choix, ce qui ne peut se faire, dans ADISA, que par l’ajout d’un commentaire en utilisant le système d’annotation. Il n’est pas vraiment possible pour le système d’intervenir pour l’aider au moment précis où l’usager en a besoin, mais le système peut, après un certain temps, proposer une fonctionnalité qui n’est pas utilisée, surtout, comme dans ce cas, lorsque l’usager hésite.
La seconde situation montre que parfois la meilleure façon d’aider est de fournir de l’aide contextuelle et indexée en répertoriant systématiquement les termes et les besoins d’assistance des usagers. L’aide contextuelle doit être planifiée durant la conception d’un système hôte, puis validée et complétée suite à des observations des usagers en activité.
La troisième situation illustre deux choses. D’abord il semble y avoir ici un problème d’interface du système hôte : pourquoi afficher un nouveau formulaire ED104, si l’usager veut passer à l’ED106 et que le public cible est bien enregistré ? Mieux vaut dans ce cas corriger l’interface du système hôte. En développant le système d’assistance, nous avons ainsi trouvé et corrigé certaines situations qui étaient problématiques pour les usagers du système hôte. Deuxièmement, elle démontre que le système d’assistance peut, dans certains cas, utiliser la répétition d’une action ou une action non complétée pour fournir une explication.
La quatrième situation représente un cas classique de soutien à la tâche dans un environnement où l’usager navigue librement et tente de faire une activité sans avoir fait les préalables. Dans ce cas, le système utilise un message de rappel et peut lancer l’élément permettant de procéder aux tâches préalables.
Enfin dans le dernier cas, il s’agit de supporter la progression dans la tâche en fournissant de la rétroaction sur ce qui est fait et en suggérant visuellement l’étape suivante, tout en laissant l’usager libre de poursuivre ses activités.
Il ne s’agit ici que de quelques exemples de l’application du modèle. Nous avons ainsi répertorié près de 300 interventions possibles, qui ont été définies selon les termes du modèle dans une base de données relationnelles. Nous sommes actuellement à formaliser les règles d’assistance de ces interventions, en traduisant leurs conditions et actions en termes pouvant être traitées par un système d’assistance informatisé.
Le Conseiller générique [Dufresne03], un système expert fonctionnant de façon épiphyte en interaction avec un système hôte, utilisera ces règles définies par les concepteurs du système d’assistance, pour décider des interventions d’assistance les plus appropriées qui seront offertes à l’usager au sein de l’application ADISA. Le conseiller générique communique avec le système hôte et est informé des évènements de l’interaction, il maintient les modèles individuels et de groupes et dirige de l’extérieur les actions d’assistance qui sont possibles dans l’environnement.
Nous avons présenté un modèle générique d’un système d’assistance qui peut servir de cadre de référence pour concevoir des systèmes d’assistance pouvant se greffer aux divers systèmes hôtes utilisés par différents acteurs du téléapprentissage. Cet exercice nous a permis d’apprécier la diversité des types d’interventions d’assistance pouvant être offerts à ces acteurs, ce qui nous permettra de décrire les règles d’assistance de façon standardisée.
Nous devons maintenant valider et compléter le modèle en développant des gabarits de règles génériques pour différentes situations d’assistance. Ceux-ci nous apparaissent essentiels pour faciliter la définition d’un ensemble de règles d’assistance qui apparaîtront cohérentes aux utilisateurs [DufresneSchlienger02], tel que le suggèrent Arroyo et al. [ArroyoAl01]. Ces gabarits devront être élaborés et validés pour les différents thèmes et buts de l’assistance, pour différents profils d’usagers (novice et expert du système hôte et de la tâche d’utilisation d’ ADISA). Dans un premier temps, le modèle générique d’assistance sera donc utilisé pour développer le modèle du soutien au concepteur pédagogique dans ADISA, mais éventuellement il sera appliqué pour modéliser le soutien à l’apprenant et au tuteur.
Par ailleurs, nous entreprenons d’actualiser un modèle procédural de la tâche du concepteur de l’assistance définie dans Paquette, Pachet, Giroux et Girard [PaquetteAl96]. Ce modèle consiste à définir comment (dans quel ordre, selon quels principes) les différentes composantes d’un système d’assistance comme celui d’ADISA peuvent être construites. Le but ici est de faire évoluer les interfaces des outils de conception de l’assistance déjà contenues dans EXPLOR@ et EXPLORAGRAPH, lesquelles seront utilisées pour construire le système conseiller d’ ADISA.
Finalement, nous produirons, au cours des prochaines années, différentes composantes du système d’assistance d’ ADISA, en commençant par l’intégration de principes de progression entre les tâches de la méthode MISA et de principes d’adaptation de la méthode à un projet donnée. En parallèle, un ensemble de principes visant la cohérence et la qualité des décisions de conception feront l’objet de recherches en sciences de l’éducation et seront par la suite intégrés au système d’assistance.
Assistance observée |
ÉD 104 :
l’usager veut ajouter un choix non prévu à
la rubrique " Niveaux de compétence en technologies
de l’information ". |
ÉD 104 :
l’usager demande ce que signifie la rubrique " Écart
à combler selon les domaines de compétence ".
|
ÉD 104 :
lorsqu’il a fini de définir le 3e public cible,
l’usager veut ouvrir l’ÉD 106 mais l’ÉD104
vierge revient toujours à l’écran :
il s’inquiète d’avoir perdu les données
relatives au dernier public cible. |
L’usager n’a
pas défini une rubrique (" unité d’apprentissage "
) à l’ÉD 222 et il ouvre l’ÉD
310. |
L'usager ajoute des
instruments à la liste des instruments d’apprentissage
dans le " modèle médiatique " à
l’ÉD 320. |
---|---|---|---|---|---|
Assistance observée :
expert, collègues ou système |
L’expert propose d’utiliser
la fonction d’annotation (cocher Imprimer pour
que ce soit imprimé avec le rapport) ou d’ajouter
un tableau. |
L’expert propose
de consulter le glossaire fourni dans ADISA. |
L’expert suggère
de sélectionner le "nom" du public cible entré
dans le menu déroulant pour voir s’il est là,
si oui, il explique que cela signifie qu’il a été
sauvegardé |
Un message lui apparaît
" Pour travailler avec 310, vous devez déclarer
des UA dans 222. Dans 222, une UA est un nœud terminal
de type procédure. " |
À l’ÉD
430, le bouton COMPOSITION devient rouge pour indiquer qu'il
y a de nouveaux instruments à tenir compte. |
Interventions
d’assistance |
|||||
Thème |
Fonctionnement du
système hôte |
Fonctionnement du
système hôte |
Fonctionnement du
système hôte |
Exécution
de la tâche |
Exécution
de la tâche |
Objet |
Procédure
d'annotation |
Concept |
Procédure
de vérification de données |
Procédure
du formulaire 222 |
Procédure
de modification de la composition des instruments |
Mode d'accès |
Adaptative contextuelle
|
Indexée et
contextuelle |
Adaptative contextuelle |
Adaptative contextuelle |
Adaptative contextuelle |
But |
Présentation |
Présentation |
Explication |
Explication |
Guidage |
Conditions |
Modèle dynamique
de l’usager :
- durée de l’utilisation assez longue
- pas d’utilisation des annotations |
Modèle dynamique
de l’usager :
l’usager sélectionne la rubrique et demande
de l’assistance. |
Modèle dynamique
de l’usager :
l’usager ouvre plusieurs fois l’ÉD 104
vide. |
Comparaison entre
le modèle de la tâche et le modèle de
l'usager (activité séquentielle) :
- ouverture de l’ÉD 310 ;
- ÉD 222 non complété. |
Comparaison entre
le modèle de la tâche et celui de l'usager (interdépendance
entre activités) : ajout dans la rubrique " Instrument "
de l’ÉD 320. Ouverture de l’ÉD 430.
Condition de clôture : ajout d’un nouvel
instrument au scénario d’apprentissage. |
Actions |
Message : suggérer
d’utiliser la fonction d’annotation. Lancer un
élément du système hôte. |
Message : définir
le terme. |
Message : expliquer
la procédure de vérification des données
enregistrées. |
Message : rappeler
la séquence. Message :Expliquer la logique de
la séquence. |
Adaptation de l'interface :
coloration d’un bouton. |
Implications pour
le système d’assistance |
Si la fonction d’annotation
n'a pas été utilisée : afficher
un message et ouvrir le système d’annotation
pour ajouter des nuances lors de la conception. |
Fournir une aide
contextuelle pour chaque formulaire expliquant le vocabulaire,
etc., et rendre cette aide accessible dans l’index |
Prévoir des
messages pour des actions incohérentes et expliquer
les procédures. Donner des explications favorisant
l’élaboration d'un modèle mental des activités
d'enregistrement et de sauvegarde. |
Fournir un message
générique lorsqu'une séquence de tâches
n'est pas respectée. |
Suggérer visuellement
les activités requises reliées à l'interdépendance
entre les activités d'une tâche. |
Tableau 3 : Exemples de situations d’assistance et instanciation du modèle pour proposer des interventions d’assistance
Les auteurs tiennent à remercier le Fonds québécois de recherche sur la société et la culture (FQRSC) pour son soutien financier.
Arroyo, Y., Beck, J. E., Beal, C. R., Wing, R., Woolf, B. P. (2001). Analyzing students’ response to help provision in an elementary mathematics intelligent tutoring system. Dans R. Luckin (éd.), AIED'2001 Workshop Proceedings: Help Provision and Help Seeking in Interactive Learning Environments, May 19-23, San Antonio, Texas. http://www.cogs.susx.ac.uk/users/bend/aied2001/arroyo.pdf [consulté le 20 novembre 2003].
Brusilovsky, P. (1996). Methods and techniques of adaptive hypermedia. User Modeling and User-Adapted Interaction, 6, 87-129.
De La Passardière, B., Dufresne, A. (1992). Adaptative Navigational Tools for Educational Hypermedia. Dans I. Tomek (Ed.), Computer Assisted Learning, Proceedings of the 4th International Conference, ICCAL ’92, Wolfville, Canada (pp. 555-567). Berlin : Springer-Verlag.
Denis, B. (2003). Quels rôles et quelle formation pour les tuteurs intervenants dans des dispositifs de formation à distance? Distances et savoirs, 1(1), 19-46.
Du Boulay, B., Luckin, R. (2001). Modelling Human Teaching Tactics and Strategies for Tutoring Systems. International Journal of Artificial Intelligence in Education, 12, 235-256.
Dufresne, A. (1997). Conception d’interfaces pour l’apprentissage à distance. Revue de l'Éducation à Distance, XII(1/2), 177-200.
Dufresne, A. (2000). Model of an adaptive support interface for distance learning, Dans G. Gauthier, C. Frasson et K. VanLehn (éds), Intelligent Tutoring Systems, Proceedings of the 5th International Conference, ITS 2000, Montréal, Canada, June 19-23, 2000, (pp. 334-343). Berlin : Springer-Verlag
Dufresne, A. (2001a). Modèles et outils pour définir le soutien dans les environnements hypermédias d'apprentissage. Dans E. de Vries, J.-P. Pernin et J.-P. Peyrin (éds.), Hypermédias et Apprentissages 5, Actes du cinquième colloque, Grenoble, 9, 10 et 11 avril 2001 (pp. 13-24). Paris : EPI/INRP.
Dufresne, A. (2001b). ExploraGraph : Improving interfaces to improve adaptive support. Dans J. D. Moore, C. L. Redfields et W. L. Johnson (éds), Proceedings of AI in Education, AIED'2001, San Antonio (pp. 306-313). Amsterdam : IOS Press.
Dufresne, A. (2001c). Conception d'une interface
adaptée aux activités de l’éducation à
distance - ExploraGraph. Sciences et Techniques Éducatives, 8(3),
301-320.
[Dufresne02]
Dufresne, A. (2002). The ExploraGraph advising system : an ergonomical evaluation of the editor., TICE'2002, Lyon, France, (pp. 299-306).
Dufresne, A., Paquette, G., Bergeron, F., Castellain, B., Lapalme, J., Rouatbi, M. (2003). Intégration d’un conseiller générique à divers environnements de télé-apprentissage. Communication au Congrès de l’Association canadienne française pour l’avancement des sciences, (ACFAS 2003), Rimouski, Québec.
George, S. (2001). Apprentissage collectif à distance, SPLACH : un environnement informatique support d'une pédagogie de projet. Thèse de doctorat. Le Mans, Université du Maine. http://www-ic2.univ-lemans.fr/~george/recherche.html
Girard, J., Paquette, G., Miara, A., Lundgren, K. (1999). Intelligent assistance for web-based telelearning. Dans S. Lajoie et M. Vivet (éds), Open learning environment, Proceedings of AI in Education, AIED '99, Le Mans, France (pp. 561-569). Amsterdam : IOS Press.
Giroux, S., Pachet, F., Paquette, G., Girard, J. (1995). Des systèmes conseillers épiphytes. Revue d'intelligence artificielle, 9(2), 165-190.
Hammerton, L., & Luckin, R. (2001). How to help? Investigating children’s opinions on help. AIED'2001 Workshop on Help Provision and Help Seeking in Interactive Learning Environments, San Antonio.http://www.cogs.susx.ac.uk/users/bend/aied2001/helpworkshopnode7.htm
Hotte, R. (1993). Encadrement assisté par ordinateur et formation à distance. Revue de l'éducation à distance, VIII(2), 37-53.
Jermann, P., Soller, A., Muehlenbrock, M. (2002). From Mirroring to Guiding : A Review of State of the Art Technology for Supporting Learning. Proceedings of CSCL'2002, Boulder Colorado (pp. 324-331). Boulder, Colorado : Erlbaum.
Kinshuk, Patel, A., Russell, D. (2002). Intelligent and Adaptive Systems. Dans H. H. Adelsverger, B. Collis et J. M. Pawlowski (éds), Handbook on Information Technologies for Education and Training (pp. 79-92). Berlin : Springer-Verlag.
Kumar, V. McCalla, G.I., Greer J.E (1999). Helping the peer helper. Dans S. Lajoie et M. Vivet (éds), Open learning environment, Proceedings of AI in Education, AIED '99, Le Mans, France (pp. 325-332). Amsterdam : IOS Press.
Maina, M. (1999). Analyse de l’interface du Campus Virtuel par rapport aux activités du tuteur. Mémoire de maîtrise non publiée, Université de Montréal, Montréal.
Merrill, M. D., Twitchell, D. (1994). Instructional design theory. Englewood Cliffs, NJ.: Educational Technology Publications.
Paquette, G. (1996). La modélisation par objets typés : Une méthode de représentation pour les systèmes d'apprentissage et d'aide à la tâche. Sciences et techniques éducatives, 3(1), 9-42.
Paquette, G. (2002a). L'ingénierie pédagogique : Pour construire l’apprentissage en réseau. Sainte-Foy (Québec) : Presses de l'Université du Québec.
Paquette, G. (2002b). Modélisation des connaissances et des compétences : Un langage graphique pour concevoir et apprendre. Sainte-Foy (Québec) : Presses de l'Université du Québec.
Paquette, G., Aubin, C., Crevier, F. (1994). An intelligent support system for course design. Educational Technology, 31(9), 50-57.
Paquette, G., Brisebois, A., Ruelland, D. (2002). Combining cognitive, affective, social and metacognitive learner attributes for assistance in distributed learning environments. Proceedings of the E-Learn Conference 2002, Montréal, Canada (pp. 759-766). Norfolk, VA: AACE.
Paquette, G., Crevier, F., Aubin, C. (1997). Méthode d'ingénierie d'un système d'apprentissage. In Cognito, 8, 37-52.
Paquette, G., Pachet, F., Giroux, S., Girard, J. (1996). EpiTalk, a generic tool for the development of advisor systems. International Journal of Artificial Intelligence in Education, 7, 349-370.
Paquette, G., Ricciardi-Rigault, C., de la Teja, I., Paquin, C. (1997). Le Campus virtuel : Un réseau d'acteurs et de ressources. Revue de l'éducation à distance, XII(1/2), 85-101.
Paquette G., Rosca I. (2003). Modeling the Delivery Physiology of Distributed Learning Systems. Technology, Instruction, Cognition and Learning, 1(2), 183-209.
Paquette, G., Tchounikine, P. (2002). Contribution à l'ingénierie des systèmes conseillers : une approche méthodologique fondée sur l'analyse du modèle de la tâche. Sciences et Techniques Éducatives, 9, 405-435.
Rich, E. (1989). Stereotypes and User Modeling, Dans A. Kobsa et W. Wahlster (éds), User models in dialog systems (pp. 35-51). Berlin: Springer-Verlag.
Richey, R. C., Fields, D. C., Foxon, M. (2001). Instructional design competencies : The standards. Syracuse, NY : ERIC Clearinghouse on Information & Technology.
Ruelland, D. (2000). Vers un modèle d'autogestion en situation de télé-apprentissage. Thèse de doctorat non publiée, Université de Montréal, Montréal.
Saba, F. (1999). Helping students learn online : Learning how to learn. Distance Education Report, 3(2), 1.
Spector, M. J., Polson, M. C., Muraida, D. J. (éds) (1993). Automating instructional design - Concepts and issues. New York : Educational Technologies Publications.
Tchounikine, P. (1998). Des outils d'analyse d'un modèle MOT et une méthode d'ingénierie de systèmes conseillers. Notes de recherche. Montréal : Centre de recherche LICEF, Télé-université.
Tennyson, R. D., Barron, A. E. (éds). (1995). Automating instructional design: computer-based development and delivery tools. Berlin : Springer.
Vassileva, J., Greer, J, McCalla, G., Deters, R., Zapata, D., Mudgal, C., Grant, S. (1999) A Multi-Agent Approach to the Design of Peer-Help Environments. Dans S. Lajoie et M. Vivet (éds), Open learning environment, Proceedings of AI in Education, AIED '99, Le Mans, France, (pp. 38-45). Berlin : Springer-Verlag.
Winkels, R. (1992). Explorations in intelligent tutoring and help. Amsterdam : IOS Press.
Zhang, J., Gibbons, A. S., Merrill, M. D. (1997). Automating the design of adaptive and self-improving instruction. Dans C. R. Dills et A. J. Romiszowski (éds), Instructional development paradigms (pp. 613-632). Englewood Cliffs, N.J. : Educational Technology Publications.
Aude DUFRESNE détient un Ph.D. en psychologie
informatique. Elle est professeure agrégée au Département
de communication de l’Université de Montréal, où
elle dirige le Laboratoire de Recherche sur la Communication Multimédia.
Ses recherches portent sur l’ergonomie cognitive des systèmes
informatisés et en particulier sur les interfaces et le conseil
dans les environnements d’apprentissage à distance.
Josianne BASQUE détient un doctorat en psychologie. Elle
est professeure à la Télé-université en technologies
appliquées à l'éducation. Elle est également
chercheure au Centre de recherche LICEF ainsi qu’au Centre interuniversitaire
de recherche sur le téléapprentissage (CIRTA). Dans ses
recherches, elle s'intéresse à l'ingénierie pédagogique,
à la co-construction de connaissance et d’habiletés
métacognitives à l'aide des TIC, à l’usage
des cartes de connaissances à des fins d’apprentissage ainsi
qu’à la recherche et au traitement de l’information
dans des environnements d’apprentissage informatisés.
Gilbert PAQUETTE détient un Ph.D en intelligence artificielle
appliquée à l’éducation. Il est professeur
à la Télé-université, détenteur d’une
chaire de recherche du Canada en ingénierie cognitive du téléapprentissage
et directeur du Centre de recherche CIRTA. Il est à l’origine
de plusieurs projets de recherche-développement stratégiques
dans les domaines de la gestion des connaissances, de l’ingénierie
pédagogique et de la formation à distance.
Karin LUNDGREN-CAYROL détient un Ph.D. en technologie de
l'éducation de l'Université Concordia. Depuis six ans, elle
travaille comme chercheure associée au Centre de recherche LICEF.
Ses intérêts de recherche portent sur les stratégies
et les outils informatiques pour faciliter l'apprentissage virtuel.
Michel Léonard détient une Maîtrise en Éducation.
Depuis plus de huit ans, il travaille comme professionnel de recherche
au centre de recherche LICEF. Au sein de ce centre, il a contribué
au développement et à la validation de méthodes d’ingénierie
pédagogique (TFMM et MISA), et de systèmes d'ingénierie
pédagogique (AGD, MOT et ADISA).
Sandrine PROM TEP est actuellement étudiante au Ph.D. en
informatique cognitive à la Télé-université.
Adresse : 4750, Avenue Henri-Julien, Montréal, (QC) H2T 3E4
Courriel : dufresne@com.umontreal.ca;
jbasque@teluq.uquebec.ca;
{gpaquett, mleonard, klundgre, spromtep}@licef.teluq.uquebec.ca
[1] L’astérisque associé au lien signifie que le lien de composition est multiple.
Aude DUFRESNE, Josianne BASQUE, Gilbert PAQUETTE, Michel LÉONARD, Karin LUNDGREN-CAYROL, Sandrine PROM TEP, Vers un modèle générique d’assistance aux acteurs du téléapprentissage, Revue STICEF, Volume 10, 2003, mis en ligne le 5-01-2004, http://sticef.org, ISSN : 1764-7223
© Revue Sciences et Technologies de l´Information et de laCommunication pour l´Éducation et la Formation, 2003