Chapitre 3 : Les systèmes critiques
Les applications EIAO peuvent être regroupées en trois grandes familles :
· Les présentations de cours. La matière à enseigner est présentée sous forme hypertexte, comme pour SAVANT-1 utilisé entre 1981 et 1989 à Télécom Paris [DES 84], ou plus récemment sous forme multimédia (voir par exemple [CAM 96] pour un cours multimédia sur les mesures électroniques et l’instrumentation, ou [HOM 94] pour un cours sur l’analyse en éléments finis d’une structure de poutre). L’objectif de tels didacticiels est de permettre l’apprentissage d’un domaine par l’exploration de la présentation proposée. De telles présentations peuvent éventuellement intégrer des simulations (comme par exemple [VIL 96], consacré à l’étude de modèles atomiques) ou des exercices, mais leur principal objet est la présentation guidée des connaissances à apprendre.
· Les environnements d’apprentissage, parfois appelés «micromondes». Le premier exemple célèbre d’un tel environnement est le système LOGO, développé par Seymour Papert [PAP 80]. L’objectif de LOGO était d’aider l’enfant à apprendre à apprendre. Comme le note Grumbach [GRU 90], l’enfant qui interagit avec la tortue LOGO construit ses propres théories et peut les tester. Le rôle d’un environnement d’apprentissage est donc de permettre la découverte d’un domaine par la manipulation des objets de ce domaine. Des exemples plus récents de micromondes peuvent êtres trouvés dans [GRA 94], qui présente un logiciel de simulation de la diffusion à travers des membranes, dans [DEJ 96] sur un logiciel de simulation des lignes de transmission ou dans [HOY 97] dédié à la manipulation de symétries axiales. Enfin, les premières expériences d’utilisation de la réalité virtuelle, qui peut-être considérée comme la version la plus aboutie des micromondes, sont en train d’être menées (comme par exemple dans [ANT 98]).
· Les systèmes critiques, parfois appelés «systèmes socratiques» ou «tuteur», dont le premier exemple est le système SCHOLAR [CAR 70] [COL 75], consacré à la géographie de l’Amérique du Sud. Leur rôle est de surveiller l’apprenant engagé dans une tâche de résolution de problème, afin de détecter les erreurs qu’il peut commettre, puis d’émettre des conseils ou des critiques afin d’éviter à l’apprenant des erreurs similaires au cours des résolutions futures. Le modèle que nous développons permettant d’envisager des progrès dans le développement des systèmes critiques, c’est à ce type d’application que nous allons maintenant nous intéresser. Dans la suite de ce chapitre, nous ne nous intéresserons donc qu’à ce dernier type d’application EIAO.
Le système SCHOLAR, bien que basé sur le dialogue avec l’apprenant n’est pas véritablement un système socratique, car il ne fait que discuter des faits. Un système socratique amène par le biais de questions successives l’apprenant à formuler des principes généraux sur la base de cas individuels, à examiner la validité de ces propres hypothèses et à découvrir les contradictions de ces croyances, puis enfin à extraire les inférences correctes des faits qu’il connaît. L’équipe ayant développé SCHOLAR proposa par la suite le système WHY, consacré à la météorologie, et qui peut être considéré comme le premier système socratique [STE 77]. Enfin les systèmes WEST [BUR 76] [BUR 79] (consacré à l’apprentissage du jeu ‘How the WEST was won’), WUSOR-I [STA 76] et WUSOR-II [CAR 77] (consacrés à l’apprentissage du jeu WUMPUS [YOB 75]) constituent des exemples de systèmes critiques : l’apprenant doit ici résoudre un problème, et le système critique ses choix. Nous présenterons au cours du chapitre 4 le système SAVANT-3 [DES 91b] [DES 93] qui est un système critique consacré à l’apprentissage des concepts.
Notre objectif, dans ce chapitre, est d’indiquer quels sont, à notre sens, les principaux manques des systèmes critiques développés jusqu’ici. Afin de pouvoir effectuer cela, nous allons dans un premier temps étudier comment est construit un système critique.
3.1 Architecture des systèmes critiques
Le rôle d’un système critique est de surveiller la résolution de l’apprenant et de mettre en lumière pour celui-ci les erreurs qu’il pourrait commettre. Signaler à l’apprenant qu’une réponse est incorrecte n’est pas suffisant dans ce contexte puisqu’il convient aussi, dans la mesure du possible, de lui signaler pourquoi il s’est trompé.
3.1.1 Un exemple d’architecture
Jean-Marc Labat, dans [LAB 90], présente le tuteur QUIZ, un tuteur intelligent multi-agent développé en coopération avec Michel Futtersack [FUT 90], et consacré à l’enseignement des enchères au bridge. QUIZ est constitué de cinq agents, dont quatre modélisent les activités d’enseignement : un générateur d’exercice, un résolveur de problèmes, un système explicateur et un module pédagogique[1]. Un modèle de l’élève (en overlay, ou expertise partielle) est également présent dans l’application, afin de permettre au module pédagogique de jouer son rôle. Si l’on reprend le découpage classique des systèmes EIAO, [WEN 87] (p. 14, p. 24), le résolveur de problèmes constitue le modèle du domaine et le système explicateur constitue le modèle de l’interaction. Le module pédagogique et le modèle de l’élève sont explicitement présents dans l’application. Enfin, le générateur d’exercice, au service du module pédagogique, peut être vu comme étant au carrefour des modèles du domaine et de l’interaction.
Dans les conclusions que tirent les auteurs de leurs travaux, l’architecture générale du système est validée. Deux composantes semblent avoir atteint un niveau satisfaisant (le résolveur et le système explicateur), alors que les composantes pédagogiques (module pédagogique, générateur d’exercice et modèle de l’élève) semblent moins avancées.
Ces conclusions nous paraissent générales, et toujours d’actualité. Il semble aujourd’hui plus facile de modéliser un domaine, tant au niveau opératoire (résolution de problèmes du domaine) que conceptuel (génération d’explications), que de modéliser des connaissances pédagogiques, censées s’appuyer sur une modélisation différenciée de l’apprenant. La principale difficulté réside selon nous dans la modélisation correcte de l’apprenant. De nombreuses modélisations ont été proposées et aucune ne semblent avoir convaincu la majorité des auteurs. Un des objectifs de notre travail est justement de proposer une modélisation générale des humains en situation de résolution de problème devant permettre à terme de construire une modélisation de chaque individu en situation de résolution d’exercice pédagogique.
Partant des constats que, d’une part, la réalisation d’un module pédagogique n’est possible qu’à partir d’un modèle de l’élève correct et que, d’autre part, la modélisation d’un domaine particulier ne pose pas de difficulté majeure, nous allons ignorer dans la suite de ce travail ces deux modélisations, pour nous consacrer à l’étude du modèle de l’élève, dont une revue peut-être trouvée dans [VAS 90].
3.1.2 Le modèle de l’élève
Avant d’aborder les diverses modélisations de l’élève que l’on peut rencontrer dans la littérature, il nous faut préciser ce que l’on entend généralement par ‘modèle de l’élève’, introduit par Fletcher en 1975 [FLE 75]. Self, en s’appuyant sur une étude des systèmes tuteurs intelligents existants à la fin des années 80, propose six catégories regroupant la vingtaine de fonctions que peut selon lui posséder un modèle de l’élève [SEL 88b] :
· Correction : si la modélisation représente les connaissances erronées de l’élève, il est possible de corriger celles-ci avec précision.
· Proposition : si les connaissances de l’élève sont considérées comme un sous-ensemble des connaissances d’un expert du domaine, le modèle de l’élève permet de choisir dans quel ordre aborder les sujets à étudier.
· Stratégie pédagogique : le modèle de l’élève peut aider à déterminer le niveau d’intervention du système, et le style de celles-ci.
· Evaluation : ces fonctions regroupent l’évaluation de l’élève et celle du système.
· Prédiction : leur rôle est de déterminer les réponses ou les actions les plus probables de l’apprenant à un exercice donné.
· Diagnostic : ces fonctions permettent de préciser ou de faire évoluer le modèle de l’élève.
A notre sens, les fonctions de diagnostic ne font pas partie des fonctionnalités du modèle de l’élève. Le diagnostic du comportement est indispensable pour permettre au modèle de jouer son rôle, mais il ne constitue pas le but de la modélisation. Les fonctions de prédiction et d’évaluation peuvent être à la fois utilisées pour établir le diagnostic et pour guider le système dans ses choix pédagogiques, en proposant par exemple à l’élève un exercice qui mettra ses lacunes en lumière. Malgré l’existence de ces six groupes de fonctionnalités, on peut donc considérer que le rôle du modèle de l’élève est triple, comme le note par exemple Blondel [BLO 96] (p. 80) : comprendre les erreurs de l’apprenant, choisir l’ordre des sujets (et des exercices) à aborder et choisir le niveau et la forme des interventions du tuteur.
Au final, le rôle du modèle de l’élève est de permettre d’adapter l’enseignement proposé par le système EIAO à chacun des apprenants qui l’utilise. Ce qui est représenté dans le modèle de l’élève, ce sont donc les différences inter-élèves. Cette modélisation suppose cependant que l’on dispose d’une modélisation générale des apprenants où il est possible de préciser des caractéristiques particulières de chacun d’entre eux. Le modèle différencié de l’élève peut donc s’appuyer sur une modélisation cognitive générale de l’apprenant, mais ce point n’est pas une obligation. A titre d’exemple, Balacheff [BAL 94] (p. 23) considère que «ce modèle a plutôt une valeur explicative à l’intérieur d’une théorie». Ainsi le modèle en ‘overlay’ (ou modèle d’expertise partielle), que nous allons présenter maintenant, ne constitue pas nécessairement une modélisation cognitive de l’apprenant, mais peut toutefois être vu comme une modélisation des connaissances de l’élève adéquate pour un logiciel d’EIAO.
3.1.2.1 Le modèle en ‘overlay’
Ce modèle représente les connaissances de l’élève de manière statique. Le domaine à apprendre est découpé en unités, et l’estimation de la maîtrise de chacune de ces unités par l’apprenant est stockée dans le modèle. L’élève est donc vu comme un sous-ensemble des connaissances de l’expert ou, ce qui revient au même, du domaine. Cette modélisation présente l’intérêt d’être relativement simple à mettre en œuvre. Il suffit de disposer d’une fonction d’évaluation des résolutions de l’apprenant pour implanter ce modèle. Il permet par ailleurs de guider le modèle pédagogique sur les choix des domaines à aborder et des exercices à traiter. Ce modèle ne peut pas être considéré comme une modélisation cognitive de l’apprenant, puisqu’il ne dit rien des processus d’apprentissage et qu’il ne prévoit pas la possibilité pour l’apprenant de posséder des connaissances erronées. On peut par contre le considérer comme une représentation (au moins partielle) des connaissances de l’apprenant.
Le système GUIDON [CLA 79] [CLA 82] [CLA 87] représente les connaissances de l’élève par un jeu de trois valeurs enchâssées (croyance dans la connaissance de la règle, croyance dans la capacité à l’appliquer et croyance dans l’application effective dans une situation donnée) portant sur chacune des règles du système expert. Cette idée de croyance a été reprise par Self, qui y voit une manière de rendre plus facile le diagnostic de l’élève en cours d’interaction [SEL 88a]. Il n’est pas clair de savoir si la croyance représente le degré de maîtrise de la règle par l’élève ou le degré de croyance de GUIDON dans la maîtrise de la règle par l’élève. Selon Monique Baron, les deux niveaux d’incertitudes sont même confondus [BAR 88].
La modélisation de l’élève dans GUIDON n’est cependant pas entièrement satisfaisante, car le niveau d’abstraction choisi est trop bas. Dans cette modélisation, chaque règle de MYCIN [SHO 76] est considérée comme une connaissance à acquérir par l’apprenant. Il paraît cependant difficile de soutenir que les règles constituant l’expertise de MYCIN sont la seule représentation possible des connaissances sur les maladies infectieuses. Il est même douteux que les règles de MYCIN puissent être une représentation adéquate de connaissances humaines, compte tenu de la présence de facteur de certitude dans la partie conclusion, et de la forme très compilée (experte) des connaissances représentées. Une règle typique de MYCIN est ([CLA 84]) :
Règle 507 :
IF
(1) The infection which require therapy is meningitis,
(2) Organism were not seen in the stain of the culture,
(3) The type of infection is bacterial,
(4) The patient does not have a head injury defect, and
(5) The age of the patient is between 15 years and 55 years
THEN
The organism that might be causing the infection are diplococcus-pneumoniae (.75) and neisseria-meningitidis (.74)
Le système APLUSIX [NIC 87] [NIC 94a] [NIC 94 b] est bien plus satisfaisant en terme de modélisation de l’élève. En effet, le modèle de l’élève n’est plus construit à partir des règles du système de production, mais par l’ensemble des concepts manipulés. Un concept est alors défini à partir de quatre champs (connu, employé, choisi, combiné) qui prennent une des sept valeurs prévues (très faible, faible, médiocre, moyen, assez bien, bien, très bien). La modélisation retenue ici est donc plus acceptable puisque l’on ne considère pas que l’élève fonctionne comme un système expert.
3.1.2.2 Les catalogues de bugs
Un des manques des modèles en ‘overlay’ est qu’il est impossible d’exprimer dans ce formalisme des connaissances erronées de l’apprenant. Afin de rendre compte des erreurs procédurales des apprenants, se développe la notion de bug empruntée à l’informatique. Un bug est une erreur internalisée par l’apprenant qui est représentée de manière implicite dans le modèle de l’élève. Les bugs sont en général des erreurs procédurales, plutôt que des conceptions conceptuelles erronées. L’étude des bugs communément rencontrés dans une population d’étudiants dans un domaine particulier est appelée ‘théorie des bugs’.
Le premier exemple d’une telle modélisation de l’élève est le système BUGGY, développé par Brown et Burton [BRO 78] et consacré aux opérations arithmétiques élémentaires[2]. Le modèle de l’élève est un réseau de procédures (procedural network). Un réseau de procédures pour un savoir-faire donné est une décomposition de ce savoir-faire en procédures qui sont liées entre elles par un treillis de sous-buts. Le réseau contient alors l’ensemble des procédures élémentaires correctes, ainsi que leurs variantes incorrectes (les bugs). Il devient alors possible de comparer le comportement du modèle de l’apprenant à celui de l’apprenant modélisé. Si les résultats donnés par l’apprenant sont compatibles avec ceux produis par un bug du réseau, on considérera que l’apprenant ‘possède’ ce bug.
Le modèle BUGGY était un modèle énumératif : il comportait un nombre fixé de bugs possibles et n’expliquait pas comment pouvait apparaître un tel bug. Dans le but d’expliquer comment pouvaient apparaître de tels bugs, Brown et VanLehn développent par la suite le système REPAIR [BRO 80]. L’hypothèse de base de ce travail est qu’un bug apparaît comme conséquence d’une sortie d’impasse quand la procédure connue ne s’applique pas. L’apprenant utilise alors des heuristiques pour modifier localement la procédure, ce qui va générer le bug. Cette ligne de recherche s’est poursuivie par la théorie STEP [VAN 83a] [VAN 83b] qui couple les principes développés dans REPAIR avec une théorie de l’apprentissage des connaissances procédurales. Ce travail débouche par la suite sur le système SIERRA que nous avons présenté dans le chapitre précédent [VAN 90].
Bien que l’approche de Brown, Burton et VanLehn ait été très riche, puisqu’elle a débouché sur un modèle cognitif de l’apprentissage des connaissances procédurales, elle apparaît trop lourde à mettre en œuvre dans un contexte d’EIAO. En effet, établir un catalogue de bugs pour un domaine donné demande un travail considérable d’analyse de protocoles (plusieurs milliers de soustractions analysées pour la ligne de recherche BUGGY [VAN 88], p. 63). En outre, le catalogue construit est par définition dépendant du domaine enseigné, et un nouveau catalogue de bug devra donc être reconstruit à chaque changement de domaine.
A la difficulté du développement d’un catalogue de bugs s’ajoute le fait que celui-ci peut se révéler inefficace. Ainsi, Zhu et Simon [ZHU 87] montrent que les connaissances procédurales mathématiques peuvent s’apprendre de manière très efficace en utilisant un enseignement constitué quasiment uniquement d’exemples et d’exercices correctement ordonnés. Dans une telle situation, l’approche consistant à redémontrer la procédure correcte après une erreur de l’étudiant semble aussi performante qu’une approche basée sur l’analyse de l’erreur de celui-ci, comme l’indique le travail de Sleeman et al. [SLE 89].
Cependant, ne pas fournir d’information conceptuelle dans certains contextes peut se révéler absurde [OHL 91]. D’autres études (comme [CHI 89]) montrent par exemple que dans des domaines plus complexes comme la programmation ou la cinématique, la manière dont l’apprenant s’explique les exemples à lui-même influe grandement sur l’acquisition et le transfert des procédures de résolution des problèmes du domaine concerné. On voit donc apparaître ici une différence entre des savoir-faire simples (où il existe un algorithme permettant de résoudre le problème) et des savoir-faire complexes (qui nécessitent une expertise afin de résoudre le problème).
Les catalogues de bugs paraissent alors inutiles (et coûteux) dans le premier cas. Dans le second cas (ou il n’existe pas de procédure automatique de résolution), les catalogues de bugs ne sont pas une modélisation cognitive adaptée puisqu’ils servent à représenter des variations erronées de procédures correctes. Ainsi, dans le projet Mentoniezh [NOE 93] [Py 96] consacré à la géométrie, les auteurs cherchent à identifier les erreurs commises au cours d’une démonstration géométrique, en considérant que chaque démonstration est constituée d’étapes élémentaires. Chaque étape est susceptible de donner lieu à des erreurs que les auteurs regroupent en une vingtaine de catégories. Ces catégories sont beaucoup plus vastes que les procédures erronées à la BUGGY, mais elles permettent d’adapter le diagnostic au type d’erreur, ce qui est suffisant pour l’application construite. Les auteurs ne prétendent donc pas modéliser le comportement erroné de l’étudiant, et se contentent de proposer une classification des erreurs possibles.
Comme pour les modèles d’expertise partielle, les modèles en catalogue de bugs peuvent être vus soit comme des modélisations de l’apprenant, mais ils soulèvent alors les problèmes que nous venons d’évoquer, soit comme des modélisations de la tâche (ici, et plus précisément, des erreurs possibles au cours de la résolution de la tâche) qui se révèlent acceptables dans un cadre d’EIAO, bien qu’ils soient insuffisants en tant que modélisations cognitives.
3.1.2.3 Les autres aspects du modèle de l’élève
La représentation des connaissances de l’élève n’est pas nécessairement le seul aspect représenté dans un modèle de l’élève. Pour Self, le modèle de l’élève peut être décrit comme un quadruplet (P, C, T, H) où le couple (P, C) représente les connaissances procédurales (P) et conceptuelles (C) de l’apprenant que nous venons de décrire, où (T) représente ses traits caractéristiques et où (H) représente l’historique des sessions [SEL 88b]. La composante (T) est construite à partir des données fournies par l’apprenant. Elle peut contenir des informations sur son niveau initial, ainsi que des informations sur son caractère (informations sensori-motrices, affectives…). Enfin, la composante (H) regroupe la trace des sessions (éventuellement débarrassée des événements non pertinents, comme dans le projet «Cabri intelligent» [BAL 90] qui est le prolongement de Cabri-géomètre [BAU 90]) ainsi que des informations plus abstraites extraites de la dernière session. La composante (H) n’est généralement pas conservée à l’issue de la session (bien que les informations qu’elle contient puissent être utilisées pour mettre à jour les composantes (P, C) du modèle).
3.2 Questions posées par le modèle de l’élève
La revue de la littérature concernant la modélisation de l’élève montre que les objectifs initiaux du domaine (réaliser une application capable de diagnostiquer les connaissances et le comportement de l’apprenant afin de pouvoir corriger ses conceptions erronées et ses bugs) n’ont pu être atteint. Ce relatif échec amène trois questions :
· Cette approche a-t-elle échoué par le fait d’un manque de connaissances ? Réaliser un modèle des différences inter-élèves nécessite, comme nous l’avons déjà souligné, de possèder un modèle général de l’apprenant. Les modélisations proposées jusqu’alors ne sont peut-être pas suffisantes pour rendre possible les objectifs poursuivis. La séparation entre les connaissances logiques et calculatoires que nous allons défendre au cours de cette thèse est un des points qui n’a jamais été pris en compte dans une telle modélisation. Nous ne prétendons cependant pas que cette seule prise en compte suffira à rendre possible la réalisation d’un modèle de l’élève efficace (cf. chapitre 9). Nous pensons toutefois que cette prise en compte est un prérequis à une telle modélisation.
· Cette approche est-elle réalisable ? Deux élèments peuvent venir jouer contre la réalisation d’un modèle de l’élève. D’une part, il est envisageable que les comportements et les connaissances des élèves comportent trop de variété pour pouvoir être correctement modélisés (cependant, cet argument peut être appliqué à toute tentative de modélisation, et ne saurait en aucun cas interrompre une voie de recherche). D’autre part, l’instantiation du modèle d’un élève demande de réaliser sur lui un diagnostic à partir de son comportement. Mais comme l’élève est en situation d’apprentissage, sa connaissance risque d’évoluer au cours de la phase de diagnostic. Si, de manière constante, le sujet progresse dans un temps inférieur à celui nécessaire pour établir un diagnostic de ses connaissances, ce diagnostic devient impossible à réaliser. Notons cependant que la question de la faisabilité du diagnostic ne peut trouver de réponse que dans le cadre d’un modèle général de l’apprenant, puisque la quantité d’information nécessaire au diagnostic et la vitesse d’évolution des connaissances de l’élève ne peuvent être définit que dans un tel cadre. Là encore, il n’est pas nécessaire de connaître la réponse à cette question pour poursuivre le travail de recherche. Notons enfin que certains auteurs émettent l’idée que la fonction de diagnostic va avoir un rôle sur l’apprentissage des sujets (schématiquement, l’observation va modifier ce qui est observé). Ainsi, comme le note Pierre Dillembourg ([DIL 94], p. 47) : «si le diagnostic est une activité mutuelle et réciproque et, s’il est interactif, il ne correspond plus à une observation neutre des connaissances de l’apprenant, mais il acquiert le statut d’une intervention pédagogique».
· Cette approche est-elle souhaitable et, en tout cas, est-elle nécessaire ? Un des présupposés non dit de la modélisation de l’élève est qu’il est nécessaire de comprendre en quoi les connaissances de l’apprenant sont insuffisantes ou erronées pourr pouvoir réaliser une intervention pédagogique. Mais ce présupposé n’a rien d’évident. Ainsi, VanLehn [VAN 90] indique que l’apprentissage de capacités arithmétiques élémentaires s’effectuent à partir de la présentation d’un grand nombre d’exemples. Dans ces conditions, une analyse de la tâche à apprendre peut s’avérer suffisante pour établir une base d’exemple performante [3] . Jean-Louis Dessalles [DES 90] propose le système SAVANT-3, destiné à l’apprentissage des concepts (et qui sera présenté en détail dans le paragraphe 4.2.1.3), qui ne cherche pas à comprendre le comportement de l’élève mais qui se borne à lui indiquer les contradictions que ce comportement implique.
