Sommaire

Rechercher

• auteur
• année
• titre
• résumé
• abstract
• rubrique

Contact : infos@sticef.org

Environnements interactifs pour la formation professionnelle : une approche fondée sur l’utilisation de cas exemplaires
Du système Simulation à Base de Cas au forum Discussions Interactives à bAse de Cas pour la fOrmation Médicale

Dominique LECLET Laboratoire Savoirs et Socialisations en Education et Formation, Université de Picardie Jules Verne

RÉSUMÉ : Cette communication présente la synthèse de recherches relatives à la prise de décision dans des contextes professionnels variés et la genèse de travaux menés actuellement au sein du laboratoire Sa.So (Savoirs et Socialisations en Education et Formation). Ainsi, trois situations professionnelles ont été étudiées, celle du diagnostic médical, celle du service de restauration et, enfin, celle de la conception multimédia. Un modèle du comportement des experts, commun aux trois domaines a tout d’abord été mis en évidence. Il a été complété par une formalisation didactique. Un modèle conceptuel et informatique définissant le cadre général d’entraînement à la prise de décision : l’environnement interactif fondé sur des cas a ensuite été proposé. Des exemples d’implémentation concrétisent cette approche théorique. MOTS CLÉS : Enseignement professionnel, prise de décision, raisonnement à base de cas, architecture de tuteurs intelligents, modélisation objets, modèles en couches.

ABSTRACT : This communication presents the synthesis of researches about decision making in various job contexts and genesis of work currently undertaken within the laboratory Sa.So (knowledge and socialization in education and training). The objective aims at going up how the introduction of Communication and Information Technologies into the Educational systems comes to enrich distance Education. Three situations have been studied, the medical diagnosis, the catering duty and the multimedia design. A model of the experts behaviour, common to the three domains has been put into evidence. It combines deductive and inductive reasoning. This model definition is followed by a formalisation under the didactic, the conceptual and the logic viewpoints. It enables to set up a general frame for the training to decision making: the case based simulation. Examples implementations are then given in order to make concrete the previous theoretical approach. KEYWORDS : Teaching sale’s profession, decision making, case based reasoning, ITS’ Architecture, objects model, shell model.

• 1. Introduction
• 2. Le contexte
• 3. Le processus de prise de décision
• 4. L’environnement du système SBDC
• 5. Description du modèle générique du module connaissance-expert
• 6. L’implantation du système auteur
• 7. Vers la conception de systèmes supports d’apprentissage pour la formation à distance
• 8. Conclusion
• Références

1. Introduction

Cet article constitue la synthèse d’une série de travaux relatifs à l’apprentissage de différentes formes de prise de décision dans un contexte professionnel : celui du diagnostic en médecine, de l’organisation d’un service de restaurant ou bien encore de la conception d’une application multimédia [LecletWeidenfeld96], [LecletWeidenfeld98a], [Leclet98], [Weidenfeld98]. Ainsi, l’objectif de cette communication vise à décrire le projet SBDC (Simulation à Base De Cas) qui a été financé par le pôle de recherche STEF (Systèmes et Technologies pour l’Education et la Formation) de la région Picardie.

Ce système a également constitué la genèse de travaux menés depuis trois ans, au sein de l’axe TICE (Technologies de l’Information et de la Communication pour l’Enseignement) du laboratoire Sa.So (Savoirs et Socialisations en Education et Formation). Ces recherches concernent le forum DIACOM (Discussions Interactives à bAse de Cas pour la fOrmation Médicale) [Joiron02], mais également le projet SYSMOOSE (SYstèmes Supports de Méthodes pour cOncevoir et Organiser des Services et rEssources pédagogiques en ligne) [LapujadeLeclet03a] et [CravoisierLeclet03].

Ainsi, le système SBDC propose des environnements exploratoires interactifs pour l’apprentissage de la prise de décision dans des contextes professionnels. Ces environnements permettent alors de reproduire (simuler) des situations professionnelles pour lesquelles, il n’existe pas de modèle formel, mais plutôt un modèle conceptuel déduit d’une collection de cas. Le système SBDC offre, alors, à un apprenant, un cadre d’apprentissage proche de son environnement réel d’activité, et basé sur une famille de cas.

En fait, des études scientifiques menées en Sciences Cognitives [Resnick91], [Jonassen92], confirment le sentiment intuitif du bien-fondé d’une “mise en situation” pour les apprentissages envisagés. Ce sentiment repose sur deux mécanismes principaux :

• d’une part, la référence à des cas connus, qui s’effectue en “unifiant” des éléments contextuels des deux situations considérées,

• d’autre part la possibilité d’une découverte par exploration, qui suppose que l’environnement prodigue à l’apprenant les rétroactions nécessaires à l’autoévaluation de la solution qu’il construit.

Ces rétroactions sont fondées sur un modèle de l’évolution des phénomènes étudiés. En sciences physiques, en sciences de la nature et de la vie ou en technologie, une modélisation numérique des phénomènes représentés est généralement possible. Elle permet, après chaque intervention de l’apprenant, de calculer le nouvel état du système et de le visualiser ; c’est le principe de la simulation. L’extension de cette approche modélisée par un système à base de règles [Clancey82], a également été effectuée. Notre approche est cependant différente puisque, nous ne disposons pas, comme nous le verrons dans la section 2, d’un tel modèle qualitatif du phénomène représenté. Nous utilisons plutôt des familles de cas exemplaires pour construire les mécanismes d’interactions évoqués ci-dessus. Pour rendre compte de ceux-ci et fournir à l’apprenant un espace exploratoire interactif, qui le mettra en “situation”, nous avons créé, à partir de ces familles de cas, ce que nous avons appelé des “environnements exploratoires”.

De plus, malgré la variété des professions considérées, nous avons mis en évidence un processus général de prise de décision [LecletWeidenfeld98a],[LecletWeidenfeld98b]. Ce processus fait appel à deux modalités de raisonnement complémentaires, le raisonnement déductif et le raisonnement inductif. Le raisonnement déductif permet lors de la résolution de problème, d’établir la conformité de solutions, mais beaucoup plus rarement leurs optimalités. Le raisonnement inductif permet quant à lui, grâce à des informations spécifiques et/ou particulières, de suggérer à un utilisateur, un rapprochement avec des situations antérieurement connues. Une solution est alors élaborée, par analogie à une situation passée. De ce fait, cette dernière apparaît comme un “cas d’école”, exemplaire, qui exprime sous une forme scénarisée une réelle expertise.

Cette prise de décision se retrouve également dans des systèmes issus d’un courant influent en Intelligence Artificielle, celui du “raisonnement à partir de cas” [ReisbeckSchank89], [Kolodner93], [WatsonMarir94], [AamodtPlaza95]. Cependant, cette prise de décision qui, à ce point, se concrétise par le déroulement d’un récit n’est pas très interactive. Les choix laissés à l’apprenant, se limitent souvent, à de l’exploration hypermédia ou à l’utilisation de quelques logiciels associés au cas présenté.

Ainsi, les environnements exploratoires proposés constituent une structuration particulière des cas dans laquelle l’apprenant évolue et qui lui permet de prendre une décision par analogie à une autre situation qu’il connaît. Ces environnements permettent de transposer à des environnements professionnels en partie modélisés par des cas, les approches fondées sur l’utilisation de bases de connaissances appliquées dans les Systèmes Tutoriels Intelligents [Fieschi84], [AegerterAl91].

La démarche abordée a été la suivante : nous sommes partis de l’étude du diagnostic en médecine, de l’organisation d’un service de restaurant et de la conception d’une application multimédia. Un modèle du comportement des experts, commun aux trois domaines et complété par une formalisation didactique, a alors, été mis en évidence. Un modèle conceptuel a ensuite été élaboré, définissant le cadre général d’entraînement à la prise de décision : l’environnement exploratoire fondé sur des cas.

Dans ce modèle, on retrouve des objets élémentaires, des actions s’appliquant aux objets et le cas échéant, des règles qui déterminent le déclenchement de ces actions. Ces informations ont été ensuite regroupées dans une “scène”, qui apparaît alors comme un agglomérat d’objets élémentaires et qui est structurée par un “décor”. Cette “scène” représente une des étapes des résolutions de problème étudiées. C’est à ce niveau que s’effectueront les interactions de l’apprenant. Le “cas” qui représente des résolutions “exemplaires” est quant à lui, considéré comme une suite de scènes séparées entre-elles par des transitions. Ce cas est complété par des enrichissements pédagogiques, notamment les objectifs assignés aux cas, les commentaires, les évaluations et justifications. Un Système Auteur a été mis en place pour permettre à un enseignant de créer son cas.

Ce Système Auteur permet ensuite à un apprenant de prendre une décision par analogie, qui se traduit concrètement par la possibilité de passer d’un cas à un autre au cours de la session d’apprentissage. Ce choix est rendu possible, grâce à la création, par le système, d’environnements exploratoires. Le Système Auteur propose alors une transition spécifique, appelée un branchement et “relie” une scène d’un cas à une autre scène d’un autre cas.

Ainsi, la section suivante de cet article présente le cadre théorique du système SBDC et les différentes expertises des domaines professionnels considérés. La section 3 s’intéresse, quant à elle, à la formalisation didactique du processus général de prise de décision mis en évidence. Avant d’aborder le modèle du système SBDC, qui fait l’objet de la section 5, la section 4 décrira l’environnement du système. La section 6 s’intéresse quant à elle au Système Auteur. Enfin, la section 7 décrit l’adaptation faite pour concevoir un système support d’apprentissage pour la formation à distance : le forum DIACOM (Discussions Interactives à bAse de Cas pour la fOrmation Médicale). Nous conclurons ensuite, sur les perspectives de recherche envisagées actuellement, ce qui fera l’objet de section 8.

2. Le contexte

Cette section a pour objet de définir le cadre de référence pour des Systèmes Tutoriels Intelligents mettant en jeu des domaines de connaissances dites mixtes. Nous entendons par là, des domaines dans lesquels des connaissances formalisées au moyen de règles quantitatives ou qualitatives, coexistent avec des savoir-faire empiriques principalement justifiables par une pratique professionnelle.

De plus, il nous semble utile de préciser que l’objectif de cette section vise à présenter la pertinence des environnements interactifs dans le contexte de l’acquisition de compétences. Ainsi, diverses situations ont été analysées, celle du “serveur de restaurant”, celle de la “conception multimédia” et celle du “diagnostic médical”. Cependant, ce contexte est bien plus large et peut s’appliquer à d’autres professions.

Ces connaissances dites mixtes sont généralement dispensées dans le cadre d’enseignements professionnels. Ces enseignements récemment encore centrés sur l’apprentissage de procédures doivent intégrer des éléments de prévision, de planification et d’anticipation liés aux règles (quantitatives ou qualitatives), que nous évoquions précédemment. La difficulté “classique” d’associer théorie et pratique dans l’enseignement, a naturellement conduit à rechercher des apports dans les nouvelles technologies et plus particulièrement dans des environnements exploratoires interactifs fondés sur des cas exemplaires.

Ainsi, la section 2.1 présente les principes cognitifs sous-jacents à ces environnements exploratoires interactifs fondés sur des cas exemplaires. La section 2.2 expose les principes de la simulation pédagogique d’activités professionnelles. Les sections 2.3 à 2.5 décrivent les domaines professionnels considérés et la section 2.6 conclut sur la section 2.

2.1. Les principes cognitifs

Dans le cadre de l’apprentissage de pratiques professionnelles, les connaissances formalisées sont importantes mais contrairement aux domaines d’apprentissages tels les mathématiques, ces connaissances ne recouvrent pas la totalité du domaine. Il existe, en effet, dans ces domaines professionnels, d’autres types de connaissances qui peuvent être représentés comme une collection de savoir-faire. Une analyse plus approfondie met alors en évidence une interrelation profonde entre des connaissances formalisables et des habiletés [Richard90].

Dans certains contextes d’apprentissage, notamment ceux qui touchent les enfants ou les publics en difficulté scolaire, les connaissances à formaliser sont abordées à partir de représentations concrètes [Resnick82]. Dans ce cas, le modèle théorique ne suffit pas, pour rendre compte des opérations intellectuelles de haut niveau mises en oeuvre comme l’anticipation, la planification, la recherche de solutions ou encore la prise de décision. Ainsi, la "connaissance avancée se caractérise par la capacité à résoudre des problèmes dans un contexte dans lequel, les procédures ne peuvent s'appliquer directement telles qu'elles ont été apprises" [Jonassen92]. Des capacités de transfert sont alors indispensables. Elles s'acquièrent à travers une représentation flexible du domaine de connaissances. Dans l'action, l'individu qui a atteint ce stade peut composer avec les incertitudes et les contradictions du monde réel. C'est le socle de l'expertise qui n’émerge qu'à travers l'expérience.

Quelques principes pédagogiques majeurs, visant à développer le stade de la connaissance avancée, découlent de cette théorie. Nous en retiendrons deux. Le premier principe est d’éviter une trop grande simplification dans la présentation notamment de faits ou de concepts. Ainsi, "sur simplifier des connaissances complexes, contribue de façon très significative à faire échouer bien des apprentissages" [JacobsonSpiro93]. Le second principe est de contextualiser l'acquisition des connaissances. D’après J.S Brown, A. Collins et P. Duguid [Brown85], les connaissances seront plus facilement mobilisables si on les acquiert dans des conditions proches de celles dans lesquelles elles seront utilisées. Mais il est aussi nécessaire de faire varier ces contextes. Pour Resnick [Resnick91], proche en cela du courant constructiviste, le contexte dans lequel s'acquièrent les connaissances, détermine fortement leur structure même. Cette dépendance vis-à-vis du contexte d'acquisition est précisément ce qui hypothèque leur utilisation dans des contextes différents. Un contexte d’apprentissage unique rend donc aussi les connaissances “in-transférables” sauf dans des situations identiques à celles de l'apprentissage. Les mécanismes du transfert se construisent donc sur le “fil du rasoir”, entre les deux dangers que sont la “décontextualisation” et la “contextualisation schématique”.

Ces analyses rencontrent une réflexion déjà ancienne [Papert81] sur un des apports essentiels des nouvelles technologies à l’éducation : la flexibilité de représentation qu’elles offrent. Ainsi, de la même façon que l’univers familier de la tortue permet d’aborder la géométrie chez l’enfant, une représentation physique d’un univers professionnel facilitera des apprentissages complexes chez l’adulte ou l’adolescent. L’expérimentation et la mise en situation qui seront ainsi rendues possibles grâce aux représentations visuelles, doivent être accompagnées par des analyses de démarche pour permettre une réelle utilisation didactique.

Nous allons maintenant montrer comment l’idée générale d’environnements interactifs tente de répondre à ces réflexions sur l’acquisition de compétences.

2.2. La simulation pédagogique d’activités professionnelles

L’utilisation de la simulation pour l’enseignement est classique dans des domaines comme des Sciences Physiques, l’électronique, ou encore l’économie. Par extension, on a vu apparaître l’utilisation de tels systèmes pour la formation à des métiers utilisant ces domaines disciplinaires. On retrouve notamment des simulations dans le domaine de la sécurité, du diagnostic de panne [Moustafiades90] ou du contrôle aérien. La simulation est aussi souvent utilisée pour exercer les réflexes de certains opérateurs comme l’entraînement de pilotes [Boy88]. Dans tous ces cas, les deux principes, évoqués dans le paragraphe 2.1 ci-dessus, se traduisent respectivement par :

• La possibilité d’expérimentation offerte à l’apprenant. La représentation physique de l’univers professionnel est utilisée différemment dans les contextes évoqués ci-dessus. Dans nos situations professionnelles, il convient de noter, dès maintenant, que les représentations comporteront toujours des éléments contextuels attachés à l’environnement de travail. Elles différeront ainsi, d’une représentation purement schématique.

• La capacité d’une rétroaction du système de formation. L’objectif est de bien mettre en évidence les éléments contextuels de la démarche afin de faciliter le “transfert”. Cette rétroaction, qui est au moins partiellement automatisée, suppose d’abord le recueil et l’analyse puis l’interprétation des choix de l’apprenant. Ces opérations diffèrent selon les problèmes abordés. Lorsque les modes de raisonnement peuvent être “associés” à un modèle numérique, on s’attache à interpréter la valeur de certains indicateurs selon des relations mathématiques ou physiques. Par contre, lorsque le modèle est plus qualitatif, par exemple basé sur un système de règles, ce sont des inférences logiques qui seront privilégiées. Dans d’autres cas, il faut alors trouver un autre mode de représentation. Par exemple, un raisonnement fondé sur l’utilisation d’expériences passées organisées en ensemble de “cas d’école”.

Dans le cadre du système SBDC, nous avons alors choisi de nous focaliser sur cette dernière approche. Rappelons, que nous nous intéressons principalement, à des systèmes d’apprentissage mettant en jeu des domaines de connaissances dites “mixtes”. Nous entendons par là des domaines dans lesquels, des connaissances bien formalisées au moyen de règles strictes, quantitatives ou qualitatives coexistent avec des savoir-faire empiriques principalement justifiables par une pratique professionnelle. Ces systèmes visent des apprenants expérimentés ayant déjà une formation de base dans le métier considéré. Ainsi, dans la suite de cet article, nous considérons qu’une première formation théorique a été assimilée par l’apprenant. De ce fait, nous nous sommes principalement intéressés aux principes de contextualisation, c’est-à-dire à la capacité à traiter des exceptions ou des écarts par rapport à une certaine “norme”. Cette contextualisation est rendue possible en donnant la possibilité à l’apprenant d’évoluer dans des environnements exploratoires, construits à partir de cas réels et contextuels, liés entre eux par un processus d’analogie.

Voyons maintenant les domaines professionnels expertisés et commençons par le service de restaurant.

2.3. Le service de restaurant

Cette action a été menée à l’initiative et avec le Fond d’Action Formation de l’Industrie Hôtelière, qui a coordonné l’intervention des experts et mis en place des formations expérimentales destinées à tester les hypothèses émises. L’analyse des référentiels de formations des métiers de l’hôtellerie fait apparaître deux types de compétences dans les métiers du service : d’une part, le savoir-faire généralement centré sur la gestuelle et, d’autre part, les aspects stratégiques des métiers qui s’expriment par des prises de décision concernant l’organisation du service et le placement de clients.

Le savoir-faire du serveur de restaurant relève d’un problème combinatoire en apparence classique, mais l’observation des méthodes utilisées par les experts [ThouinWeidenfeld96] montre que, dans certains cas, les stratégies de résolution ne sont pas uniquement de nature déductive. Ainsi, une approche purement combinatoire du placement consisterait à optimiser l’occupation de la salle, à l’instant présent. Dans certaines circonstances, les professionnels confirmés vont mettre en oeuvre des solutions qui vont à l’encontre de cette stratégie. Par exemple, des clients se verront proposer une attente au bar - éventuellement agrémentée d’un apéritif offert - alors que des places sont libres.

Les experts justifient ce comportement, en apparence “irrationnel” par des références à certaines situations (des cas), comme l’arrivée impromptue d’un groupe. Pour être capable de gérer cette éventualité, ils mettent en place des stratégies plus complexes qui reviennent en fait à effectuer une optimisation en moyenne sur un intervalle de temps, plutôt qu’une optimisation instantanée. En fait, cette façon d’agir n’est pas souvent exprimée ou justifiée de cette façon, à cause de la “non familiarité” des apprenants avec les mathématiques.

Cette stratégie complexe n’est utilisée par les experts, que dans certains contextes dans lesquels interviennent des déclencheurs contextuels comme l’heure, le taux de remplissage, ou encore la satisfaction du client. Au contraire, les apprenants tendent à appliquer la procédure systématiquement. La différence provient de la capacité des experts à analyser la situation de départ et à lui appliquer un schéma de résolution éprouvé dans une situation de référence : le cas. Le cas permet alors d’illustrer des analogies mises en évidence par les experts.

La nature de ces cas étudiés est la suivante. Une situation de départ est représentée visuellement par des dessins ou des photos. Des informations (locales) peuvent, alors être déclenchées afin d’appréhender le contexte. Des procédures bien référencées¹ permettent alors de “simuler” l’activité de service et le cas permet d’illustrer des analogies. Voyons maintenant, ce qu’il en est de la conception multimédia.

2.4. La conception multimédia

La réflexion sur les modalités de la conception multimédia a été menée dans le cadre d’un projet de formation à distance au multimédia [WeidenfeldAl97], [WeidenfeldLeclet98]. Ce projet était inscrit dans le contrat d’établissement de l’Université de Picardie Jules Verne et a bénéficié du label Educapôle de la région Picardie. Il s’est effectué en partenariat avec les éditions Masson et le Centre National d’Enseignement à Distance [LecletWeidenfeld97]. En 1998, au démarrage du projet, la formation ouverte et à distance a consisté, en la fourniture de supports de cours interactif, d’un tutorat, de la réalisation d’études d’étudiants via Internet et d’outils coopératifs comme la messagerie, ou le chat. Elle fut à l’origine de la création de la plate-forme INES [INES04], qui est actuellement utilisée par les universités de Bordeaux, de Grenoble, de Toulouse ou encore d’Orléans dans le cadre du projet campus numérique international e-miage [eMIAGE04].

La partie du projet qui nous intéresse ici, est relative aux modalités de conception de produits multimédia. Deux types de contributions alimentent ce contenu. La première concerne une approche méthodique de la conception multimédia et ce de manière générale. Cette approche a été présentée au congrès Society for Information Technology and teacher Education, en mars 1998 [LecletWeidenfeld98c]. Elle fournit un cadre structuré pour cette activité, en offrant des règles générales, un index, ou encore un thesaurus. La seconde concerne un ensemble de “témoignages” émanant de professionnels du multimédia.

Ainsi, un recueil d’expertise de spécialistes et de concepteurs de systèmes documentaires, de CD Rom culturels, ou encore d’application WWW a été réalisé. Leurs pratiques ont été analysées et la description, sous la forme de règles générales, d’index et de thésaurus, a été effectuée. L’analyse des référentiels de formations de ces métiers a fait apparaître, comme dans le cas du service de restaurant, deux types de compétences : d’une part, le savoir-faire généralement centré sur l’expérience, d’autre part, les aspects stratégiques des métiers qui s’expriment par des prises de décision concernant l’appréhension de la conception du multimédia. De plus, un accent tout particulier a été mis sur l’explication et l’illustration des “dérivations”. Par exemple, l’extension du public habituel des encyclopédies par l’intégration d’éléments ludiques ou bien encore l’extension des fonctionnalités de systèmes documentaires voués à la communication.

La nature des cas étudiés a la même structure que, celle décrite dans la section 2.3. Elle en diffère cependant par sa forme. L’application à concevoir est décrite par son “cahier des charges”. Des informations complémentaires sont disponibles et des procédures bien référencées permettent de simuler l’activité de conception. Enfin, l’accès par Internet à un grand nombre d’informations et de projets de conception multimédia, fournit des cas disponibles pour illustrer les analogies mises en évidence par les experts. La dernière situation professionnelle expertisée concerne le diagnostic médical. Elle est décrite dans la section suivante.

2.5. Le diagnostic médical

L’objectif de la formation médicale vise à apprendre aux étudiants à diagnostiquer les pathologies et à les prendre en charge. Pourtant, cette formation aborde l’apprentissage du diagnostic d’une manière assez éloignée de la pratique du médecin. Le découpage du cursus en est en partie responsable [MatteiAl97]. Ainsi, les enseignements théoriques sont pour beaucoup dispensés au travers de cours magistraux, souvent sanctionnés par une évaluation où les questionnaires à choix multiple sont largement utilisés. Certes, cet enseignement favorise une capacité de mémorisation importante chez l’étudiant mais, il ne favorise pas ses capacités d’analyse, de déduction et de croisement d’information, nécessaires à la pratique de la médecine [Cuénoud00].

Ainsi, favoriser l’acquisition de connaissances théoriques de façon contextuelle et permettre l’apprentissage d’une pratique médicale de terrain durant les stages devient primordial. Cet apprentissage en milieu professionnel permet alors aux étudiants de mettre en œuvre, en situation, les différentes connaissances qui leur ont été transmises. Ainsi, pour pallier le manque de contextualisation et faire évoluer les modes d’apprentissage, les facultés de médecine ont mis en place des services pédagogiques où l’apprentissage est davantage personnalisé et centré sur l’apprenant [Farah00]. La pédagogie devient alors active et met l’étudiant en situation d’apprendre et d’agir par lui-même sur sa compétence à traiter un cas clinique donné en se référant à des “cas” déjà connus et résolus par le passé.

La réflexion sur l’utilisation d’environnements interactifs basés sur des cas en médecine émane du projet ARIADE (Apprentissage de la Rhumatologie Intelligemment Assisté par orDinatEur), mené en partenariat avec le Service de Médecine Informatique de Rennes [Leclet93]. Le système ariade est un Système Tutoriel Intelligent dont l’objectif était de former des étudiants de 4ème année de médecine au diagnostic médical et ce dans le domaine de la Rhumatologie. Le principe est de leur faire acquérir une démarche cohérente du raisonnement médical et de leur faire suivre un processus de diagnostic, de type hypothético-déductif, qui représente la démarche du clinicien. Le recueil d’expertise mené avec le projet ARIADE a mis en évidence les pratiques des rhumatologues et a permis de se focaliser sur des cas exemplaires, reflétant des stratégies plus complexes que celles habituellement utilisées.

La nature des cas étudiés est identique à celle du service de restaurant et de la conception multimédia. Une situation de départ est représentée visuellement par des photos ou par une vidéo. C’est en fait, la description du cas clinique du patient. Des informations (locales) peuvent alors être déclenchées afin d’appréhender le contexte. Des procédures bien référencées permettent de simuler l’activité de diagnostic. Enfin, des cas cliniques sont disponibles pour illustrer les analogies mises en évidence par les experts rhumatologues. La section suivante conclut sur un bilan des recueils d’expertises menés dans les trois professions considérées.

2.6. Un bilan des recueils d’expertises menés

Pour conclure notre propos, nous pouvons souligner que malgré leurs spécificités, les trois métiers étudiés possèdent des similitudes. En effet, nous avons pu constater que ces trois pratiques professionnelles étaient toutes basées sur un savoir-faire centré sur l’expérience et illustrant des situations proches du réel. De plus, dans les métiers considérés, les pratiques professionnelles illustrent des prises de décision effectives. Enfin, les approches utilisées se réfèrent souvent à des procédures résolues par le passé et se basent sur un raisonnement par analogies.

De plus, dans ces trois domaines professionnels, l’utilisation d’expériences décrites sous forme de cas permet de reconstituer une situation réelle sans la copier exactement. Les différences essentielles découlent, d’une part, de contraintes matérielles (la difficulté de travailler sur la réalité effective) et d’autre part, de choix pédagogiques (possibilité d’extraire de la réalité les éléments les plus significatifs dans la résolution d’un problème). Toutes ces contraintes aboutissent à des environnements de travail de l’apprenant dédiés à l’entraînement à la prise de décision professionnelle.

Ainsi, pour permettre l’apprentissage de ces pratiques professionnelles, un processus commun de prise de décision a été dégagé. Nous avons ensuite élaboré un modèle basé sur des cas, qui rend compte de cette prise de décision. Enfin, un Système Auteur, qui permet à un auteur de créer des cas, a été mis en place. Ce système permet également de constituer les environnements exploratoires destinés à l’apprenant, qui permettent de rendre compte du raisonnement par analogie.

Notre propos est, maintenant de caractériser de façon intrinsèque le processus de prise de décision qui a été dégagé.

3. Le processus de prise de décision

Trois recueils d’expertise ont été menés en parallèle, en utilisant l’observation des pratiques par enquêtes exploratoires et de terrains. Ces enquêtes ont permis de mettre à jour une conceptualisation du processus de prise de décision. Des entretiens de vérifications ont ensuite été menés pour valider les concepts proposés.

Le processus commun de prise de décision a pu donc être dégagé, suite à cette démarche de recueil d’expertise. Ainsi, partant de problèmes à résoudre comme un cas clinique, un client à placer, ou une interface multimédia à décrire, une stratégie de résolution commune, a été identifiée. Cette section présente la formalisation de ce processus commun de prise de décision.

3.1. Un processus commun de prise de décision

Le processus de prise de décision a été décomposé en une situation de départ et une stratégie de résolution à appliquer. La situation de départ a été définie comme permettant de poser le problème à résoudre. On retrouve dans cette situation un ensemble d’entités (dont la connaissance est généralement explicite) et un ensemble de propositions. Ces propositions permettent de faire évoluer la situation de départ et/ou la connaissance des entités disponibles. Par exemple dans le domaine de la médecine, la situation de départ peut être la connaissance des entités signes élémentaires et antécédents médicaux. L’objectif visé est la maladie à diagnostiquer.

La stratégie de résolution a, quant à elle, été définie comme permettant, de fixer les objectifs visés pour la prise de décision. Plusieurs stratégies distinctes peuvent alors être associées à une même situation de départ et peuvent conduire à des solutions différentes. Généralement, ces stratégies sont liées à des critères indépendants de l’objectif visé proprement dit. Ces critères dépendent essentiellement de l’environnement dans lequel évolue la prise de décision. Cette situation, assez fréquente dans la vie professionnelle, a dans notre approche été simplifiée, à des fins pédagogiques, en établissant une priorité entre les critères. En effet, d’une façon générale, les problèmes à résoudre sont des cas d’écoles où les situations de départ sont inspirées du réel mais “lissées” de façon à en simplifier l’utilisation didactique.

Dans le domaine de la médecine, une stratégie de résolution permettra de privilégier le critère de rapidité des examens complémentaires, une autre de favoriser le critère de prescription de médicaments génériques. Ces critères restent indépendants de l’objectif visé qui est de diagnostiquer une maladie. Ils sont par contre fortement liés à l’environnement dans lequel évolue la prise de décision : médecine d’urgence, économie hospitalière du coût de prescription, etc.

Ainsi, avant de dérouler le processus de prise de décision, un premier niveau d’informations est renseigné par l’auteur, qui doit notamment préciser l’objectif visé, la stratégie de résolution, l’environnement dans lequel l’apprenant va évoluer. Il renseigne également les indicateurs pertinents choisis en fonction de la stratégie de résolution. Enfin, il choisit et classe les critères. Voyons sur un exemple du serveur de restaurant, quelles sont ces informations :

• Objectif visé = {Apprendre à placer les clients}

• Stratégie de résolution = {Privilégier la rentabilité}.

• Environnement Apprenant = {Restauration de luxe}

• Critères = { Rentabilité, Accueil, Hygiène, Sécurité}

• Indicateurs pertinents = {Table 3 appelle souvent, Table 5 donne pourboire, Chiffre d’affaires}.

Puis, un deuxième niveau d’information est renseigné par l’auteur, qui choisit alors le problème à résoudre, une situation de départ et les actions proposées. Sur l’exemple, du serveur de restaurant, on trouve alors :

• Problème à résoudre = {Placer les clients qui arrivent}

• La situation de départ = {Description des tables libres, Description des tables occupées, Etat d’avancement des repas, Liste des clients à placer, Etat du cahier de réservation, Présence d’un salon d’attente}.

• Actions proposées = {Placer les clients à la table 5, Placer les clients à la table 7, Faire attendre les clients au salon avec apéritif, Offrir un digestif à la table 3, Desservir la table 5}.

Voyons donc maintenant quelle est la formalisation du processus de prise de décision, validée par nos experts.

3.2. La formalisation du processus de prise de décision

Le processus de décision a été divisé en deux phases. La première phase, qui se déroule en cinq étapes (étape 1 à 5 dans la figure 1 ci-après), vise à analyser la situation de départ et à déterminer les actions admissibles. Pour cela, un ensemble pertinent d’entités qui permet d’établir une orientation est considéré. Une hypothèse d’orientation est ensuite émise. L’évaluation des conséquences immédiates de cette hypothèse est effectuée. La prise en compte d’entités conduisant à l’élimination de certaines hypothèses est ensuite effectuée. L’ensemble restant correspond aux actions admissibles.

La seconde phase, qui se déroule quant à elle, en trois étapes (étape 6 à 8 dans la figure 1 ci-après), procède au classement des actions admissibles. Pour cela, nous nous sommes inspirés du formalisme de la théorie de la décision pour associer à chaque stratégie et à chaque solution admissible un coût.

Ce coût est une fonction vectorielle dont les axes sont les critères qualitatifs utiles (évoqués dans la section 3.1) pour apprécier les conséquences d’une action. Pour tenter d’établir une norme commune, les experts ont choisi de ne pas exprimer ces critères sous une forme numérique, car cela était souvent complexe et réducteur et de surcroît les écarts de coût n’avaient pas la même signification. La méthode dégagée par les experts est la suivante. Des indicateurs pertinents sont proposés en fonction de la stratégie de résolution choisie. Le coût de chaque action admissible est exprimé en fonction de ces indicateurs. Le classement des actions admissibles s’effectue selon ce coût. Prendre la décision revient à proposer l’action admissible prioritaire. Ce processus commun de prise de décision est représenté par la figure 1, ci-dessous :

>

Figure 1 : Processus général de prise de décision

La figure 2 ci-dessous traduit un exemple de ce processus général de prise de décision dans le cadre du serveur de restaurant.

Figure 2 : Exemple du déroulement du processus pour le serveur de restaurant

Ainsi, un processus commun de prise de décision a pu être dégagé et ce malgré la variété des domaines professionnels étudiés. Ce processus nous a alors conduit à envisager un cadre général pour l’entraînement à la prise de décision : l’environnement exploratoire basés sur des cas.

3.3. Vers un modèle d’environnements exploratoires ...

Le processus fait appel à deux modalités de raisonnement complémentaires, le raisonnement déductif et le raisonnement inductif. Rappelons que le raisonnement déductif permet lors de la résolution de problème, d’établir la conformité de solutions par rapport à la solution finale. Le raisonnement inductif permet quant à lui, grâce à des informations spécifiques et/ou particulières, de suggérer un rapprochement avec des situations antérieurement connues. Une solution est alors élaborée, par analogie à une situation passée. Cette dernière apparaît alors comme un “cas d’école”, exemplaire, qui exprime sous une forme scénarisée une réelle expertise.

De plus, notons que le processus de prise de décision qui vient de vous être présenté met en jeu des connaissances issues de savoir-faire empiriques justifiables par une pratique professionnelle. Ces connaissances ont été modélisées grâce au modèle conceptuel que nous avons élaboré et qui définit le cadre général d’entraînement à la prise de décision du système SBDC.

Ainsi, nous avons constaté que, les experts utilisaient des concepts du domaine à enseigner. Nous avons alors défini, afin de représenter ces concepts, des objets élémentaires et des actions s’appliquant aux objets. De plus, nous avons également constaté, que les experts avaient besoin de représenter une des étapes de la résolution de problème étudié. Nous avons alors proposé la notion de “scène”. Ainsi, une “scène” est considérée comme un agglomérat d’objets élémentaires. Enfin, nous avons défini et élaboré la modélisation d’un “cas” qui constitue une résolution “exemplaire”. Un cas est alors considéré comme une suite de scènes séparées entre-elles par des actions “transitions”.

Enfin, pour fournir à l’apprenant un espace exploratoire “fortement” interactif, le système SBDC se propose de définir des environnements interactifs, créés à partir d’une collection de cas recueillis dans la base de cas. Un tel environnement permet au système de prendre en compte l’apprentissage du raisonnement par analogie. Concrètement cette action se traduit par la possibilité de passer d’un cas à un autre au cours d’une session d’apprentissage. Une transition spécifique permet alors de passer d’une scène à une autre scène d’un autre cas. Cette transition est appelée un branchement.

Une des difficultés principales est la construction de ces familles de cas exemplaires ayant assez peu de solutions pour ne pas risquer une explosion combinatoire. La piste retenue consiste, à partir d’une scène, à ne considérer que les transitions vers d’autres scènes qui sont significatives par rapport à un objectif pédagogique donné. Ce filtrage, au moyen d’objectifs pédagogiques, permet effectivement de limiter le nombre de transitions entre cas.

Ainsi, avant d’aborder dans le détail le modèle du système SBDC, qui fera l’objet de la section 5, nous allons voir dans la section suivante quel est l’environnement proprement dit du système et les différents éléments qui le composent.

4. L’environnement du système SBDC

Dans un premier temps, nous allons décrire l’architecture globale du système SBDC. Puis dans un deuxième temps, nous nous focaliserons sur l’architecture du Système Auteur. Nous aborderons alors brièvement les modules qui le composent, puis nous présenterons son fonctionnement. Afin de permettre une meilleure compréhension du fonctionnement global du système SBDC, nous présenterons le fonctionnement du Système Elève.

4.1. L’architecture globale du système SBDC

Le système SBDC se compose de deux systèmes principaux : le Système Auteur et le Système Elève. Le système Auteur permet à un auteur de caractériser les connaissances relatives aux cas. Le Système Elève permet à un apprenant de s’entraîner à la prise de décision professionnelle.

Pour constituer le système Auteur, et modéliser les connaissances de nos experts, nous nous sommes inspiré des méthodes qui conduisent à l’élaboration de Systèmes à Base de Connaissances (SBC) et plus précisément de la méthode KADS [WielingaAl92]. En effet, le modèle d’expertise de KADS comporte des connaissances provenant du savoir-faire et de l’expérience des experts des domaines modélisés. Un tel modèle se veut alors indépendant de toute contrainte d’implantation informatique et facilite le dialogue entre le concepteur du système et l’expert. Rappelons que notre expertise était issue de trois domaines différents et que nous souhaitions proposer un formalisme commun de représentation aux trois experts. Le principe du modèle d’expertise de KADS consiste donc, à séparer dans des représentations différentes, les connaissances relatives aux concepts du domaine et les connaissances relatives aux processus de mise en œuvre de ces connaissances. Nous avons alors repris ce principe, pour modéliser les connaissances des experts.

Voyons donc maintenant, dans le détail l’architecture du Système Auteur.

4.2. L’architecture du Système Auteur

Comme le montre la figure 3 ci-dessous, le Système Auteur est composé de trois modules : un module Interface Auteur, qui se charge de l’interaction avec l’auteur, un module connaissance-expert qui permet à l’auteur de stocker les connaissances relatives aux cas et un module appariement qui se charge de créer les environnements exploratoires qui seront proposés à l’apprenant. Le module connaissance-expert comprend le modèle spécifique qui vise à stocker les connaissances relatives aux cas et à leurs appariements. L’architecture du Système Auteur peut être résumée par la figure 3 ci-dessous :

Figure 3 : Architecture du Système Auteur

Sur cette figure, nous remarquons que le modèle générique se divise en deux couches : la couche domaine et la couche environnements. La couche domaine contient trois niveaux : le niveau des concepts, le niveau des scènes et le niveau des cas. La couche des environnements contient, quant à elle, le niveau des environnements, qui sont créés automatiquement, lorsque la base de cas contient suffisamment de cas, par le module appariement. Ces différents niveaux visent à différencier les types de connaissances existants au sein du système.

Enfin, nous pouvons également remarquer que la couche problème correspond à une instanciation du modèle générique. Focalisons-nous dans la section suivante, sur le module connaissance-expert et voyons les différentes couches qui le composent.

4.3. Le module connaissance-expert du Système Auteur

Le module connaissance-expert qui comprend le modèle générique peut être schématisé par la figure 4, ci-dessous :

Figure 4 : Modèle générique du module connaissance-expert

Comme on peut le remarquer sur la figure 4, la couche problème contient les quatre niveaux différenciés du modèle générique. Commençons par le niveau des cas. Celui-ci permet de recueillir les cas décrits par l’expert. Notons qu’un cas est composé de scènes dans lesquelles l’expert décrit des concepts particuliers : des entités et des actions. Ainsi, pour pouvoir décrire un cas, l’expert place donc dans chaque scène des concepts qu’il décrit à partir d’un ensemble de concepts proposés par le système.

Par exemple, “placer le client” est un exemple d’action du domaine de restauration et “Table 5 libre” est un exemple d’entité de ce domaine. Ainsi, pour qu’un expert puisse placer une action de type “Placer” ou bien “Table 5 libre ” dans une scène d’un cas, il existe au sein de la couche problème, un niveau contenant le type d’action “Placer” ou le type d’entité “Table” et ses caractéristiques. Ce niveau se nomme le niveau des concepts. Ainsi, à partir de ces deux concepts, les experts peuvent créer autant de concepts que possibles dans les cas qu’ils décrivent. Il leur suffit de choisir le concept dont ils ont besoin, puis d'en paramétrer les caractéristiques, selon la situation à laquelle il souhaite le voir s’adapter. On dira qu’un concept est “issu” d’un type de concept². Les concepts sont ensuite regroupés dans le niveau des scènes. Le dernier niveau de cette couche problème est le niveau des environnements qui permet de stocker les environnements exploratoires constitués par le système.

On peut également remarquer sur la figure 4, que le modèle générique vise à représenter le modèle relatif aux connaissances stockées dans les quatre niveaux de la couche problème. La couche domaine comprend trois niveaux. Le niveau des concepts représente la manière dont un concept peut être décrit au sein du système. Le niveau des scènes permet de regrouper tous les concepts (entités et actions) au sein d’une structure. Le niveau des cas vise à décrire la structure d’un cas. La couche environnement qui contient le niveau des environnements permet de décrire la structure d’un environnement exploratoire, c’est-à-dire deux cas ayant des similitudes de type “analogie”. Nous avons choisi le terme de modèle générique, car celui-ci regroupe des niveaux indépendants du domaine d’apprentissage.

Après avoir détaillé l’architecture du système SBDC, nous pouvons maintenant aborder le fonctionnement du Système Auteur.

4.4. Le fonctionnement du Système Auteur

La figure 5, ci-dessous, schématise le fonctionnement du Système Auteur, sous une forme scénarisée. L’objectif de ce diagramme vise à représenter les interactions entre l’auteur et le système. Cette “scénarisation” de fonctionnement est composé de plusieurs étapes s’enchaînant, depuis la création d’un nouveau cas jusqu’à la constitution d’un environnement interactif mis en évidence grâce à la proximité de deux cas. Ces interactions sont matérialisées par des flèches. Un étiquetage et une numérotation de ces flèches permettent de faire apparaître le séquencement dans le temps, de ces interactions.

Figure 5 : Fonctionnement du Système Auteur

Ainsi, un auteur commence par décrire un nouveau cas à travers l’interface auteur. Le premier niveau de la couche problème intervenant dans le scénario de fonctionnement est donc le niveau des concepts. L’interface auteur commence, en effet, par “interroger” ce niveau et les concepts nécessaires à l’auteur pour décrire son cas. Les flèches 1 et 2 lui sont retournées.

Le système guide ensuite l’auteur, pour décrire son cas. Ce guidage sera décrit précisément dans la section 7. Une fois le cas décrit, il est envoyé dans la couche problème (flèche 3). Si de nouveaux concepts ont été décrits par l’auteur, à travers le cas, le niveau des concepts est mis à jour (flèche 4). Le cas est, lui-même, stocké dans le niveau des cas et les scènes dans le niveau des scènes (flèche 5).

Enfin, lorsque la base de cas contient suffisamment de cas, le module appariement intervient en déclenchant son algorithme général (flèche 6), qui cherche les proximités entre deux cas, afin de constituer des environnements exploratoires. Une fois un environnement pertinent mis en évidence, l’algorithme le sauvegarde dans le niveau des environnements (flèche 7 et 8), le niveau des cas est mis à jour et l’environnement exploratoire est renvoyé à l’auteur (flèche 9). L’auteur peut alors valider l’environnement exploratoire proposé.

Une fois les environnements exploratoires constitués, ceux-ci peuvent être choisis, et proposés à l’apprenant pour que ce dernier puisse s’entraîner à la prise de décision dans sa pratique professionnelle.

Avant d’aborder la section 5, où le modèle générique du module connaissance-expert est détaillé, nous allons décrire le fonctionnement du Système Elève. Notons, que le Système Elève se compose de deux modules : un module Interface Elève qui se charge de l’interaction entre l’apprenant et le système et un module Exploration qui permet à l’apprenant d’explorer son environnement d’exploration en le guidant dans la résolution de son problème.

4.5. Le fonctionnement du Système Elève

Afin de constituer les interactions du Système Elève, nous avons analysé avec les experts quelle pouvait être, la visualisation de l’environnement à proposer à l’apprenant. Il s’est alors avéré que cette visualisation pouvait prendre des formes variables.

Pour des activités professionnelles, comme celles du serveur, où prédominent une communication et une activité verbale et gestuelle, nous avons souhaité privilégier des représentations concrètes et l’utilisation de l’image, voire de la vidéo. Dans d’autres activités, en apparence semblables, comme l’agencement de surfaces [LecletWeidenfeld96], c’est au contraire une représentation plus abstraite qui s’impose afin de rendre compte des conditions réelles de l’activité. Pour d’autres activités mentionnées, comme la médecine, c’est l’information disponible à un instant donné qui est l’élément déterminant de l’environnement. Cette information n’est généralement pas visualisable au premier plan, mais est rattachée à des zones sensibles de l’écran, icônes ou boutons, et elle peut être obtenue, au moyen d’un mécanisme hypertexte.

Enfin, la visualisation adaptée à la conception multimédia synthétise ces deux approches. D’une part, les informations disponibles sont essentielles et leur représentation est similaire, à celle évoquée pour la médecine. D’autre part, les décisions du concepteur peuvent aussi se concrétiser de façon “visuelle”, par exemple en décrivant l’interface du produit en conception à l’aide d’un langage graphique de spécification [Coutaz90].

Ainsi, nous avons décidé qu’il serait proposé à l’apprenant un ensemble “d’opérations/actions” qui permettraient d’agir sur la représentation métaphorique de l’environnement de travail. Le déclenchement de ces “opérations/actions”, schématisées par des icônes ou des menus, permet alors d’avoir un effet sur l’environnement de travail. On retrouve deux catégories “d’opérations/actions” :

• Leur exécution peut éventuellement modifier la représentation visuelle. Un cas particulier intéressant est une représentation de l’environnement réaliste (par exemple à base de vidéo), pour laquelle la représentation physique de l’action peut également être rendue par une séquence vidéo. Cette représentation est particulièrement intéressante lorsque les modalités d’exécution de “l’opération/action” peut affecter la prise de décision.

• Leur exécution peut modifier le niveau d’information. Dans ce cas, l’exécution de “l’opération/action” ne modifie généralement pas la visualisation de l’environnement, mais comporte en elle même différentes étapes significatives. Dans ce cas, l’activation “correcte” de “l’opération/action” constitue un sous problème du problème initial, qui peut d’ailleurs être déterminant dans la solution générale.

Ainsi, la figure 6 ci-dessous, schématise le fonctionnement du Système Elève, sous une forme scénarisée, représentant les interactions entre l’élève et le système. Cette “scénarisation” de fonctionnement permet à l’apprenant de parcourir un environnement exploratoire qui lui est proposé et d’être guidé durant son exploration. Dans son parcours, l’apprenant pourra alors choisir des “opérations/actions” , qui lui permettront soit d’avancer dans son environnement exploratoire, soit de découvrir ses erreurs, soit de résoudre un sous problème avant de continuer dans l’exploration de son environnement ou bien encore de se brancher sur un autre cas.

Ces interactions sont matérialisées par des flèches. Un étiquetage et une numérotation de ces flèches permettent de faire apparaître le séquencement dans le temps de ces interactions.

Figure 6 : Fonctionnement du Système Élève

Ainsi, l’interface élève extrait un environnement exploratoire à présenter à l’élève (flèches 1 et 2). L’interface élève déclenche alors le processus de prise de décision et explore l’environnement exploratoire (flèche 3). Durant ce parcours, et lorsque l’apprenant a besoin d’être guidé ou aidé, une procédure d’aide est déclenchée (flèche 4) et l’aide est proposée à l’apprenant (flèche 5). Puis le parcours de l’environnement est re-itéré (flèche 6).

Après avoir présenté l’environnement du système SBDC et le fonctionnement des Systèmes Auteur et Elève, nous allons maintenant décrire précisément, le modèle générique du module connaissance-expert . La section suivante vise à présenter ce modèle.

5. Description du modèle générique du module connaissance-expert

Dans cette section, nous décrivons chacune des deux couches interdépendantes  du modèle générique : la couche domaine et la couche des environnements.

Dans la couche domaine, nous retrouvons les trois niveaux décrits brièvement dans la section 4.3. Le premier niveau se nomme le niveau des cas et constitue la modélisation de la structure des cas. Ainsi, un cas décrit par un auteur, est un séquencement d’étapes, appelées les scènes, chacune décrivant des données sur le problème à résoudre, appelées les entités. D’autre part, dans chaque scène est spécifiée la décision prise par l’auteur qui lui permet de passer à l’étape suivante de son cas. Cette décision se nomme une action. Les actions matérialisent la décision de l’auteur face à la scène décrite et permettent de passer à la scène suivante, autrement dit de continuer le récit du cas. Ainsi, les scènes sont regroupées dans le niveau des scènes, les entités et les actions sont regroupés dans le niveau des concepts.

La création d’un cas permet alors, à l’expert d’illustrer un (des) objectif(s) pédagogique(s) global(baux). Cependant, le cas n’est pas fondé sur une interaction très riche et n’autorise pas une exploration très poussée de la situation par l’apprenant. Le cas prend plutôt une forme démonstrative qui permet à l’apprenant d’étudier un cas de façon linéaire tout comme l’aurait décrite préalablement l’expert. Afin de permettre à l’apprenant d’être mis dans une situation telle que le système l’autorise à effectuer des analogies entre des situations déjà vécues et connues (“autre cas”) et donc de combiner ses prises de décisions, le système va alors constituer ce que nous avons appelé des environnements exploratoires. Ces environnements sont regroupés dans le niveau des environnements de la couche environnement.

Nous commençons dans la section suivante à présenter le niveau des cas de la couche domaine, puis nous aborderons ensuite le niveau des scènes et enfin le niveau des concepts. Enfin, le niveau des environnements de la couche environnement sera décrit.

5.1. Le niveau des cas de la couche domaine

Le niveau des cas décrit la structure des cas dans le système SBDC. Ces cas constituent des exemples de résolution de problème. Ainsi, un cas est composé d’une suite de scènes et de transitions entre celles-ci. De plus, il est important de souligner qu’un cas illustre un ou plusieurs objectifs pédagogiques. Un objectif pédagogique représente une stratégie que l’on souhaite privilégier dans le cas, en vue de l’enseigner. Il permet également de préciser l’objectif d’apprentissage sous-jacent à l’étude de ce cas. Par exemple, un objectif pédagogique pourrait être “apprendre à placer les clients, en privilégiant la rentabilité”. Ici, l’objectif d’apprentissage sous-jacent est “apprendre à placer ses clients” et la stratégie est “privilégier la rentabilité”. La figure 7 ci-dessous représente la structure d’un cas dans le niveau des cas.

Figure 7 : Structure d’un cas dans le niveau des cas

Sur cette figure 7, on peut voir qu’un cas comporte tout d’abord un nom, un auteur, et des commentaires. Le nom du cas peut être donné par l’auteur. Les commentaires visent à recueillir une chaîne de caractères permettant à l’auteur de décrire librement la thématique principale du cas. Un cas est donc constitué d’un séquencement de scènes, représentant chacune une étape du cas. Décrire un cas revient à décrire l’une après l’autre chacune des étapes du déroulement du cas, c’est-à-dire chacune de ses scènes. Voyons donc maintenant, la description du niveau des scènes de la couche domaine.

5.2. Le niveau des scènes de la couche domaine

La couche des scènes, comme son nom l’indique, est composée de concepts appelés scènes. Une scène vise à représenter, à un instant donné, l’ensemble des informations proposées à l’apprenant. Ces informations lui sont fournies sous la forme d’entités et d’actions. L’idée de départ consistait à définir la sémantique d’une représentation visuelle de la “scène”, telle qu’elle apparaîtra à l’écran. Cette visualisation, qui peut avoir l’aspect d’un décor sous forme de photographies, de schémas, ou d’animation vidéo, peut être annotée en utilisant des approches classiques en hypermédia (une zone de l’écran faisant références aux entités de la couche domaine). Par exemple, sur la photo de la salle de restaurant, le marquage d’un rectangle et sa désignation comme étant une entité “table ronde”, signifie que le rectangle est défini comme zone sensible et a toutes les caractéristiques des entités tables rondes modélisées dans le niveau des concepts de la couche domaine.

Des propriétés plus spécifiques à la scène peuvent également être attachées aux entités de cette scène. Par exemple, la scène peut souligner visuellement, l’importance d’une entité de type “signe clinique”, définissant “un genou épanché”, en l’attachant à une zone sensible montrant précisément un genou épanché. Une scène peut alors être représentée “visuellement” par une vidéo de l’interrogatoire d’un patient où des zones d’information sont identifiées et attachées aux entités issues de la couche domaine. Les scènes reliées entre-elles par des actions constituent alors un cas, regroupé dans la couche des cas. La figure 8, ci-dessous, visualise la structure des scènes dans le niveau des scènes.

Figure 8 : Structure des scènes dans le niveau des scènes

Ainsi, un cas est composé d'un ensemble de scènes, chaque scène représentant une étape dans le déroulement du cas. Le cas apparaît alors comme une “histoire exemplaire”, constituée d’une suite de scènes, liées entre-elles par des actions transitions regroupées dans le niveau des concepts de la couche domaine. La section suivante présente ce niveau.

5.3. Le niveau des concepts de la couche domaine

Le niveau des concepts permet de représenter les concepts, éléments atomiques divisés en entités et en actions. Les entités représentent des objets, des personnages ou des évènements attachés à la situation professionnelle décrite dans la section 2. Celles-ci, au-delà de leur description “physique”, peuvent être source d’information et peuvent enrichir de ce fait, le niveau d’information du système. On retrouve en particulier des entités requêtes, activées par l’apprenant et qui ont pour effet de révéler une information et entités auto-actives qui se déclenchent automatiquement, en présence d’un déclencheur, pour fournir une information additionnelle.

Les actions portent sur des groupes d’entités et ont pour effet d'informer ou de passer à une autre scène. Une action est définie par ses pré-requis (évènements indispensables pour son activation), par ses déclencheurs (évènements qui conduisent à choisir l’action), par une description de ses effets (modification ou information d’une ou de plusieurs entités) et enfin, par ses paramètres. De plus, une action permet de passer d’une scène à une autre scène. Nous avons ainsi, défini deux types d'action: les actions terminales (qui font suite à un choix erroné ou qui clôturent un cas) et les actions de transition (qui permettent de passer à une autre scène d'un cas).

Ainsi, lorsque les connaissances de la couche domaine sont fournies au système et lorsque celui-ci possède suffisamment de cas intéressant, il peut alors constituer un environnement exploratoire. En effet, un cas étudié par un apprenant reflète comme nous venons de le souligner un “cas d’école” isolé, et n’autorise pas à lui seul, une exploration complète de la situation étudiée. Notamment, il ne permet pas de prendre en compte le raisonnement par analogie à des situations connues. La section suivante présente ce niveau.

5.4. La couche des environnements exploratoires

Le schéma de gauche, de la figure 9 ci-dessous, représente une collection de trois cas, comportant un nombre inégal de scènes (identifiées par des ronds). Le schéma de droite illustre un exemple d’environnement de simulation créé à partir de cette collection. Les ronds matérialisent des scènes décrites dans la section 5.2, et les flèches horizontales représentent les actions transitions applicables à ces scènes. Les flèches obliques représentent des actions spécifiques, qualifiées de branchements permettant de passer d’une scène d’un cas à une autre scène d’un autre cas.

Figure 9 : Cas et environnements exploratoires

Ces environnements exploratoires permettent de représenter au mieux les choix possibles de la réalité. Ils permettent ainsi à l’étudiant un entraînement dans des conditions “proches” de cette réalité. Cependant, la figure 11 n’illustre qu’imparfaitement cette réalité qui est beaucoup plus complexe. Ainsi, si plusieurs transitions sont systématiquement envisagées à partir de chaque scène et si la profondeur de la résolution est de 5 ou 6, il faudrait, a priori, disposer de plusieurs centaines de scènes, reliées entre elles pour décrire toutes les configurations. Une telle situation est exceptionnelle, certes, mais possible, dans la “réalité”.

On peut ainsi, trouver quelques résultats mathématiques qui admettent une démonstration où dans plusieurs étapes successives, il y a un véritable choix de méthodes (par exemple le théorème de d’Alembert Gauss ou Zorn) ou encore des diagnostics de panne particulièrement complexes. Ces exemples fournissent des types de situations réelles, qui dans le cadre d’un environnement didactique ne pourront être utilisés. En effet, dans ces situations complexes les difficultés ne sont pas sériées, isolées, décomposées comme dans une “bonne” pratique pédagogique. Le choix d’une résolution de problèmes adaptée pour illustrer un ou quelques objectifs pédagogiques va s’accompagner d’une simplification des situations concomitantes à une réduction du graphe des parcours possibles. On peut alors remarquer que la constitution des environnements exploratoires consiste à identifier, les possibilités de branchements entre ces cas. La figure 10, ci-dessous, visualise la structure des environnements exploratoires dans le niveau des environnements.

Figure 10 : Structure des environnements exploratoires dans le niveau des modèles environnements

Ainsi, nous avons décrit dans cette section le modèle générique du module connaissance-expert. Il nous paraît important de souligner que la phase de conception nous a conduit, à élaborer un modèle indépendant de tout domaine d’application : le modèle générique. Cette généricité vise à permettre la modélisation de connaissances sur un domaine (les concepts) et le recueil d’exemples scénarisés d’utilisation de ces connaissances (les cas).

De plus, afin de valider la généricité de notre modèle, nous avons élaboré un Système Auteur. L’objectif de ce système était aussi de faciliter le travail individuel des experts et de permettre d’assurer une cohérence entre les expertises émanant d’individus différents. La section suivante décrit donc le Système Auteur et la démarche suivie.

6. L’implantation du système auteur

Dans cette section, nous allons, dans un premier temps, aborder la démarche commune qui a été retenue afin d’élaborer notre Système Auteur, puis dans un deuxième temps nous focaliserons sur la création d’une entité et d’une action. Enfin, nous aborderons la constitution de l’environnement de simulation et nous conclurons sur notre première expérimentation.

6.1. Une démarche commune du système auteur

La première étape a été de valider une démarche commune du Système Auteur, permettant de guider l’expert dans la constitution de ses cas. Un cahier des charges a alors été réalisé et validé. Un environnement multi fenêtré et enrichi de barres d'outils spécifiques pour la description des concepts a été choisi. Ainsi, au départ, le système propose à l’auteur de :

• Choisir, une situation de départ, un objectif visé, une stratégie de résolution et l’environnement apprenant (environnement dans lequel l’apprenant va évoluer).

• Choisir, parmi une liste d’indicateurs affichée, les indicateurs qu’il juge pertinents en fonction de la stratégie de résolution choisie.

• Choisir et classer, parmi une liste de critères affichée, les critères judicieux.

Le système va ensuite guider l’auteur, scène par scène et va proposer pour une action donnée, les actions associées aux entités correspondantes. Il effectue alors deux filtres sur les actions. Le premier filtrage s’effectue par rapport à la scène : les actions dont tous les pré-requis ne figurent pas dans la scène sont éliminées et les actions dont les déclencheurs figurent dans la scène sont conservées. Le second filtrage s’effectue en référence aux objectifs pédagogiques, parmi celles qui subsistent. Parmi toutes ces actions applicables, les transitions sont celles qui aboutissent à une scène répertoriée. La démarche adoptée est la suivante :

1. L’auteur commence par décrire les entités de la scène en cours de construction.
2. Le système propose ensuite :

   • Les actions dont les pré-requis sont déjà vérifiés dans la scène ou celles qui agissent sur les entités.

   • Les critères suivants sont destinés à expliciter les choix de groupes d’actions proposés par les experts, dans un contexte pédagogique préalablement défini et permettant également de limiter l’explosion combinatoire :

     • Situation 1/ L’action correspond à une règle stricte, elle a alors un caractère obligatoire.

     • Situation 2/ L’action correspond à la violation d’une règle stricte.

     • Situation 3/ L’action correspond à une pratique reconnue et directement justifiable dans le contexte. Elle correspond à une règle contextuelle.

     • Situation 4/ L’action correspond à une erreur fréquemment commise et directement explicable. Elle correspond également à une règle contextuelle (erronée).

     • Situation 5/ L’action choisie constitue une transition entre deux scènes d’un “cas interactif” déjà référencé.

     • Situation 6/ Il existe une scène “similaire” à la scène courante et pour laquelle l’action choisie a l’une des caractéristiques énoncées.

3. Le système choisit les actions qu’il considère comme admissibles dans la situation décrite et choisit l’action “transition”.

Ce processus est ainsi, réitéré jusqu’à la description finale du cas traité. L’auteur décrit alors pour chaque scène, des entités et des actions, dont certaines sont des actions transition, qui permettent de relier une scène à une autre scène, afin de constituer un cas.

Dans la situation 2, l’affichage d’un message d’erreur préétabli, ou comportant des paramètres instanciables (situation 4) permet de résoudre le problème, sans modification de situation. La situation 5 permet quant à elle de ramener à une situation connue.

Les situations 1 et 3 renvoient à des situations classiques des Systèmes Tutoriel Intelligent : la nouvelle “scène” est dérivée de l’ancienne par application d’une règle (stricte ou contextuelle). La description logique de la nouvelle scène est aisée si les objets intervenants dans les règles sont identiques à ceux figurant dans les scènes considérées, ce qui semble être aussi une évidence pédagogique. Si nous adoptons cette contrainte pour la définition des règles, il est possible de rendre compte physiquement de l’évolution du système de deux façons :

• Modifier automatiquement les représentations visuelles des attributs modifiés par application de la règle. Ceci est réalisable lorsque la scène est visualisée sous forme d’une image vectorielle 2D ou 3D résultant de la “superposition” d’objets plus élémentaires. L’infographie en général, des langages tels VRML et les “avatars” sont des technologies permettant cette réalisation.

• Par contre, la définition des rétroactions d’un système à base vidéo n’est pas évidente. On se contentera dans une première phase de disposer d’une description sémantique associée à la description visuelle, et d’effectuer les modifications à ce niveau sémantique .

En fait la principale difficulté correspond à la situation 6, et plus précisément dans la définition de la “similarité” entre deux scènes. Les situations 5 et 6 renvoient donc, à la création les environnements exploratoires.

Voyons maintenant dans le détail, le processus de description d’une entité et celui d’une action.

6.2. La description d’une entité

Lors de la description d'une entité, le problème réside dans le fait que l'auteur décrit sa connaissance de manière “implicite”. En effet, selon la description de la scène dans laquelle il se trouve, il peut vouloir créer une nouvelle entité à partir d'une nouvelle classe, créer une nouvelle entité à partir d'une classe déjà existante ou bien encore créer une nouvelle entité à partir d'une nouvelle classe, elle-même créée à partir d’une classe déjà existante.

Néanmoins, l'auteur ne possède généralement pas de notions de formalisme objet, lui permettant de savoir précisément dans laquelle de ces situations, il se trouve. Ainsi, le système doit être capable d'identifier ces éventualités en fonction des informations données par l'auteur. L'auteur est guidé dans sa description grâce à une succession de boîtes de dialogue. Une typologie des boîtes de dialogue a été élaborée et nous verrons dans la section suivante, un exemple concernant la création d’une action. Ainsi, la notion d'action “apprenant” est décrite par l'auteur lors de la création d'une scène. La description de cette action fait l’objet de la section suivante.

6.3. La description d’une action

Le système auteur permet à l’auteur de décrire de façon formelle, pour une scène donnée, l’action qu'il a été amené à réaliser dans la scène durant son “expérience”. Le système vise alors à obtenir une collection de classes d'actions possibles dans le domaine considéré. Pour cela, l’auteur définit l’action par son nom et fournit un ensemble de pré-requis. Ainsi, l'auteur peut : créer une nouvelle action et donner les particularités de son application dans la situation présente ; utiliser une action déjà définie et donner les particularités de son application dans la situation présente.

Le système guide l'auteur dans sa collection d'actions. Ainsi, une succession de boîtes de dialogues permet d'assurer ce guidage, en fournissant notamment l'accès à la liste des actions applicables, dans une situation donnée. Une typologie des boîtes de dialogues a été définie et la figure 11 ci-dessous, décrit les différents choix proposés à l'auteur durant sa description. La figure 12 présente la boite de dialogue correspondante.

Figure 11 : Processus de description d’une action

Figure 12 : Ecran correspondant

En tout premier lieu, le système procède à la comparaison des pré-requis de chaque action répertoriée avec les entités décrites par l'auteur depuis le début du cas. Cette phase a ainsi pour objectif d'extraire l'ensemble des actions applicables dans la scène que l'auteur a décrit. Deux situations ont alors été identifiées (branches 1 et 2 sur la figure 11) :

• Il existe un ensemble non vide d'actions applicables : le système propose alors à l'auteur la liste de ces actions (boîte de dialogue n° 1). Si celui-ci sélectionne l'une de ces actions, il a alors la possibilité de créer directement une nouvelle instance de cette action en entrant directement dans la boîte de dialogue n° 4 prévue à cet effet.

• l'auteur a la possibilité de choisir l'option “nouvelle”, dans la liste des actions applicables. Dans ce cas, il entre dans une boîte de dialogue intermédiaire, lui permettant de spécifier le nom et l'ensemble des pré-requis de cette action. Une fois la description réalisée, il peut alors créer l’instance issue de la nouvelle action.

• Il n'existe aucune action applicable : le système propose alors à l'auteur, soit de stopper sa description, soit de décrire une nouvelle action (boîte de dialogue n° 5). Dans ce dernier cas, le procédé est le même que précédemment, lorsqu'il sélectionne l'option “nouvelle” dans la liste des actions applicables.

L’expert décrit ainsi son cas, guidé par le Système Auteur. Puis, lorsque suffisamment de cas sont rentrés, le module appariement du Système Auteur intervient en déclenchant son algorithme général, qui cherche les proximités entre deux cas, afin de constituer des environnements exploratoires. La section suivante présente le module appariement.

6.4. Le module appariement du Système Auteur

Comme il a été précisé dans la section 5, les environnements exploratoires visent à représenter au mieux les choix possibles de la réalité. Ils permettent ainsi, à un apprenant, un entraînement dans des conditions “proches” de cette réalité. La constitution de ces environnements exploratoires consiste à identifier, les possibilités de branchements entre deux cas. La signification des proximités entre les cas d’une même base a alors été réalisée. Cette étude a fait l’objet d’un mémoire de DEA [Joiron98].

Afin de constituer les environnements exploratoires, un algorithme d’appariement est déclenché par le module appariement. Tout d’abord, la proximité entre les cas est évaluée globalement, relativement aux objectifs pédagogiques assignés aux cas. Ceci vient du fait qu’il est difficile de considérer que deux cas, illustrant des objectifs pédagogiques complètement différents, peuvent s’avérer proches. Il faut également se placer dans la situation de l’apprenant qui, dans une scène donnée, fait le choix d’une action de type branchement. Son choix se traduit alors par le passage de cette scène, vers une autre scène d’un autre cas. Ce passage doit nécessairement conserver une cohérence dans les objectifs pédagogiques qu’il suit. Ainsi, les objectifs pédagogiques des deux cas, sources et cibles du branchement, doivent être similaires.

Par ailleurs, la proximité a également été notifiée selon une dimension locale, en tenant compte du contexte spécifique de la scène à partir de laquelle un branchement est possible. En effet, lorsque l’apprenant se trouve dans une scène donnée et qu’il choisit une action correspondant à un branchement, il est nécessaire que le contexte de la scène d’arrivée soit relativement proche de celui de la scène de départ. Ainsi, pour constituer les branchements possibles à partir d’un cas donné, l’expert lors de la création de son cas, précise les scènes, à partir desquelles il juge qu’un branchement par analogie est possible. En effet, celui-ci sait par expérience, dans quelles situations une analogie de raisonnement dans la prise de décision est envisageable. Ces scènes constituent alors les scènes de départ. L’algorithme déclenche ensuite, un premier filtrage de la base de cas afin de collecter les cas ayant des objectifs pédagogiques similaires au cas de départ.

Enfin, parmi tous les cas issus du premier filtrage, il est déterminé quelle est la scène la plus similaire à la scène de départ. Le cas comportant cette scène similaire est appelé le cas d’arrivée. Puisque ces deux scènes sont semblables, un branchement est alors placé entre la scène départ et la scène qui suit la scène similaire dans le cas d’arrivée.

Afin de tester notre Système Auteur, nous avons ensuite été amenés à choisir un champ d’expérimentation. Nous avons alors décidé de travailler dans un premier temps sur le domaine professionnel du serveur de restaurant. Puis, nous avons continué avec le domaine de la Rhumatologie. La section suivante présente un premier bilan de cette expérimentation.

6.5. Un bilan d’une première expérimentation

Suite à cette première expérimentation, nous avons entamé une réflexion sur le contexte d’utilisation du Système Auteur. En effet, cette expérimentation nous a permis d’effectuer plusieurs constats.

Il semblait délicat pour les auteurs d’appréhender la constitution même d’un cas et de le décomposer en scènes, en actions et en entités, sans une “explicitation” précise du cas. En particulier, nous avons rencontré une certaine difficulté chez nos experts à créer de nouveaux type d’entités (manque de temps, trop de contraintes, trop de travail). Par exemple, les signes d’anamnèse font partie du vocabulaire couramment utilisé chez un médecin, cependant, la description de ces signes en terme “d’attributs” n’est pas innée. C’est pourquoi, toute l’étape de formalisation des types de concepts a été réalisée avec notre participation active, notre expert intervenant surtout pour la validation. En contrepartie, le modèle conceptuel était suffisamment riche et générique pour constituer des environnements exploratoires.

Différentes possibilités s’offraient alors à nous. La première nous orientait vers la création d’un noyau minimal de concepts qui pourrait être basé sur une ontologie. Avec ce noyau initial, les médecins pourraient avoir l’aide d’un guidage ontologique et l’instanciation de concepts, de scènes et de cas, à partir de types de pré-définis serait un mécanisme plus facile à acquérir. La seconde possibilité nous orientait plutôt vers la confrontation de la notion de cas, à d’autres contextes pédagogiques. Le fait de tester d’autres environnements d’apprentissage en réutilisant la notion de cas nous permettrait alors de confronter aussi le processus de prise de décision.

Ainsi au début de l’année 2000, de nouvelles directions ont été proposées au système SBDC. Nous nous sommes alors dirigés vers la conception de systèmes supports d’apprentissage à distance. En effet, à cette époque, l’élargissement du réseau Internet bouleversait les modes d’enseignement et l’utilisation des Technologies de l’Information et de la Communication dans les systèmes d’Enseignement (TICE) passait par l’intégration de la notion de distance.

De plus, les possibilités d’échange offertes par Internet, notamment via des forums de discussions favorisaient les interactions entre tous les acteurs d’une formation à distance. Ces possibilités d’échanges permettaient la confrontation de points de vue et d’expériences, notamment dans les formations professionnelles pour lesquelles l’apprentissage se fondait principalement sur l’étude d’expériences exemplaires. Nous nous sommes alors intéressés aux interactions entre apprenants et à la confrontation du processus de prise de décision, dans un cadre distanciel et bien sûr à la généricité des cas. C’est ainsi que, nous avons souhaité explorer et expérimenter une autre forme d’apprentissage : l’apprentissage entre pairs. Nous allons donc maintenant aborder cette problématique.

7. Vers la conception de systèmes supports d’apprentissage pour la formation à distance

Le système support d’apprentissage présenté ici est partiellement fondé sur une adaptation du système SDBC. En effet, l’idée générique de nos recherches visait à étudier les possibilités de mise en place d’un système support d’apprentissage entre pairs pour la FMC (Formation Médicale Continue). Ce travail a fait l’objet de la thèse de Céline Joiron [Joiron02].

Ainsi, l’objectif du forum DIACOM (Discussions Interactives à bAse de Cas pour la fOrmation Médicale) vise un apprentissage de la prise en charge de la douleur chez l’enfant. Nous souhaitions alors appliquer nos travaux antérieurs et exploiter l’utilisation de cas dans d’autres contextes pédagogiques. Nous souhaitions également confronter le processus de prise de décision à distance et apporter une dimension collective : inciter les discussions entre praticiens à propos de cas cliniques médicaux, et ce de façon asynchrone, sur Internet. Ces questionnements ont fait l’objet de communications antérieures [JoironLeclet01b], [Joiron02].

Le choix de la FMC comme terrain d’expérimentation nous permettait également de proposer un environnement interactif pour une formation professionnelle à distance. En effet, la plupart des offres de formation continue, basées sur l’apprentissage entre pairs, étaient à l’époque périodiques et présentielles. Or, les médecins n’avaient pas toujours la possibilité de participer régulièrement à ce type de réunions. Proposer un système informatique permettant une mise en place, à distance, de ce type d’apprentissage entre pairs, sans imposer la moindre contrainte de temps et de lieux à ces praticiens, prenait alors un certain intérêt. L’idée d’un forum de discussion dit “interactif” a alors été présentée dans [Joiron99].

De plus, la prise en charge de la douleur chez l’enfant est apparue comme un domaine d’expérimentation intéressant à cause de l’absence de protocoles définis dans les établissements de santé français. En effet, selon Fournier-Charrière, dans les services de pédiatrie "la douleur n’est pas encore prise en compte de façon systématique dans la démarche thérapeutique" [FournierCharrière99]. En fait, il s’agit d’un domaine auquel le corps médical accorde de plus en plus d’importance et de nombreux ouvrages témoignent de l’intérêt porté par la communauté des pédiatres au sujet [EcoffeyMurat99].

Cette démarche a été délibérée, car nous souhaitions, avoir une démarche de conception participative et confronter notre modèle conceptuel à un autre domaine d’application afin de commencer à confirmer nos hypothèses de généricité. Enfin, notre principale motivation résidait dans le contenu même des cas cliniques du domaine. Prendre en charge la douleur nécessitait tout d’abord de l’évaluer et de la traiter. Or, les stratégies et les modes d’évaluation de la douleur sont généralement compliqués par le jeune âge des patients. Ainsi, les cas pouvant être décrits, présentent des stratégies de résolution de problèmes originales totalement basées sur l’expérience des praticiens.

Nous avons donc travaillé avec un expert privilégié, le Docteur François Marie Caron, Pédiatre libéral et praticien hospitalier au Centre Hospitalier Régional Universitaire d’Amiens. Ce pédiatre travaillait également sur un champ disciplinaire autre que celui de la Rhumatologie, la douleur chez l’enfant.

Ainsi, l’objectif de cette section est de présenter quelle adaptation a été faite du système SBDC pour concevoir le forum DIACOM. Dans un premier temps et ce afin de permettre une meilleure appréhension des adaptations qui ont été faites, nous décrivons l’architecture du forum. Dans un deuxième temps, nous aborderons le fonctionnement de celui-ci.

7.1. L’architecture du forum DIACOM

L’architecture du forum DIACOM se compose de trois modules : le module interface, le module appariement et le module connaissances. Le module interface se charge de l’interaction entre l’utilisateur et le système. Ce module est composé de deux interfaces : DIACOM-IA (DIACOM Interface Auteur) et DIACOM-ID (DIACOM Interface de Discussion). L’interface auteur permet à un médecin de décrire un nouveau cas clinique sur le forum. L’interface de discussion donne, quant à elle, accès aux discussions ouvertes sur le forum DIACOM. Par le biais de cette dernière, un médecin a la possibilité de savoir à quel cas son propre cas a été apparié, et selon quels critères. Il peut encore consulter l’ensemble des cas stockés sur le forum. Cette architecture modulaire a été présentée dans [JoironLeclet01a] et [JoironLeclet01b].

Le module appariement vise à prendre en charge l’appariement dans le forum. Cet appariement est géré par un algorithme qui extrait de chaque cas entré dans le système, les critères nécessaires à son appariement. Ensuite, un algorithme d’appariement effectue une comparaison entre les critères de ce nouveau cas et les critères appartenant à chaque cas stocké antérieurement. Cette comparaison aboutit à extraire un cas, pertinent par rapport au nouveau cas, dont l’auteur présente des centres d’intérêts communs.

Le module connaissances se compose de deux couches : la couche domaine et la couche modèle. La couche domaine contient les “connaissances” manipulées par le système. Ces connaissances sont les cas, les concepts utilisés pour décrire les cas, ainsi que toutes les informations relatives à l’appariement de ces cas. La couche modèle est composée des modèles relatifs aux connaissances stockées dans la couche domaine. La couche domaine correspond alors à l’instance de la couche modèle.

Figure 13 : Architecture du forum DIACOM

Chacune de ces deux couches est composée de quatre niveaux. Ces niveaux visent à différencier les types de données existant au sein du forum. Ainsi, le niveau des concepts représente les concepts (entités et actions) du domaine. Le niveau des cas permet de représenter les connaissances relatives aux cas. Enfin le niveau des critères et des appariements permet de représenter les connaissances nécessaires pour effecteur un appariement entre deux cas. La section suivante présente le scénario de fonctionnement du forum DIACOM.

7.2. Le scénario de fonctionnement du forum DIACOM

La figure 14 ci-dessous, schématise le fonctionnement du forum DIACOM, sous une forme scénarisée. L’objectif de ce diagramme est de représenter les interactions effectives entre les différents éléments du forum, tout au long du “scénario”. Ces interactions matérialisées par des flèches. Un étiquetage et une numérotation de ces flèches permettent de faire apparaître le séquencement dans le temps de ces interactions.

Un apprenant médecin commence par décrire un nouveau cas à travers l’interface DIACOM-IA. Le premier niveau de la couche domaine, intervenant dans le scénario de fonctionnement, est donc le niveau des types de concepts. DIACOM-IA commence, en effet, par interroger ce niveau et les types de concepts nécessaires à l’apprenant pour décrire son cas lui sont retournés (flèches 1 et 2). Une fois le cas décrit, il est envoyé dans la couche domaine du forum DIACOM (flèche 3). Si de nouveaux types de concepts ont été décrits par l’apprenant, à travers le cas, le niveau des types de concepts est mis à jour (flèche 4). Le cas est, lui-même, stocké dans le niveau des cas (flèche 5).

Le module appariement est ensuite mis en œuvre grâce au déclenchement de son algorithme général (flèche 6). Ce dernier lance l’algorithme d’extraction de critères (flèche 7) qui extrait du nouveau cas, les critères utilisés pour son appariement (la pathologie, les objectifs et la stratégie). Ces critères sont alors sauvegardés dans le niveau des critères (flèche 8).

Figure 14 : Fonctionnement du forum DIACOM

Une fois l’extraction de critères terminée, l’algorithme d’appariement proprement dit est déclenché (flèche 9). Cet algorithme compare les critères du nouveau cas avec ceux des cas stockés au préalable, en se référant au niveau des critères de la couche domaine (flèches 10 et 11). Une fois un appariement pertinent mis en évidence, l’algorithme d’appariement sauvegarde les informations relatives à cet appariement dans le dernier niveau de la couche domaine : le niveau des appariements (flèche 12).

Chaque nouvel appariement inscrit dans ce niveau engendre enfin la mise à jour de l’interface de discussion par l’ouverture d’une nouvelle discussion sur le forum (flèches 13 et 14). Les discussions peuvent alors avoir lieu dans l’interface de discussion et ces discussions sont enregistrées dans la couche des discussions (flèche 15).

Après avoir abordé le fonctionnement du forum, voyons donc maintenant quelle a été l’adaptation faite du système SBDC.

7.3. Du modèle SBDC au modèle DIACOM

Le dispositif envisagé dans DIACOM est partiellement fondé sur une adaptation du système SBDC. En effet, une contribution d'un apprenant dans ce forum est un cas que cet apprenant peut structurer à travers une interface adaptée. Cette phase de description permet de fournir à l’apprenant l’opportunité de formaliser son opinion. Suite à cette phase descriptive, le système effectue un appariement des cas en les comparant à la fois sur leurs similitudes et leurs différences. Cet appariement concerne les nouveaux cas et les cas stockés antérieurement dans la base. Une fois un appariement satisfaisant mis en évidence, le système peut procéder à la mise en relation des apprenants aux centres d'intérêt communs. Cette mise en relation est en fait une incitation des auteurs des cas appariés à venir interagir sur le forum et ce de façon asynchrone. L’objectif est alors un apprentissage par la discussion.

Ainsi, une partie du modèle conceptuel SBDC a été reprise, en particulier l’idée de structurer les cas selon une suite de scènes séparées par des actions-transitions. Cependant, la notion de scène a été adaptée. En effet, tout d’abord les cas sont décrits par des médecins pairs, pour des médecins expérimentés. Il n’est donc pas nécessaire de proposer dans chaque scène plusieurs actions possibles, aboutissant certaines fois à des erreurs identifiées. Par ailleurs, les cas ne sont plus destinés à être explorés par les praticiens, mais à être comparés et confrontés. Ainsi, le principe des environnements interactifs et des branchements n’est plus nécessaire. La couche des environnements et la couche des scènes ont donc été supprimées.

De plus, l’idée d’apparier des cas a également été reprise. Cependant, l’appariement dans le forum de discussions interactives est radicalement différent de l’approche proposée dans le projet SBDC. En effet, il s’agit ici de comparer les stratégies de résolution de problèmes, décrites par les praticiens à travers leurs cas et non plus d’étudier les possibilités de branchement entre des cas d’experts. Le module appariement permet donc un appariement fondé sur des critères identifiés (la pathologie, les objectifs et les stratégies). Cet appariement utilise alors des distances locales pour comparer les critères et des distances globales pour apparier des cas. Ainsi, deux couches ont donc été ajoutées pour gérer les appariements : la couche des critères qui comporte les critères d’appariement et la couche des appariements qui maintient la “mémoire” de ces appariements.

Pour conclure notre propos sur le forum DIACOM, nous pouvons dire que celui-ci permet à des praticiens de décrire à distance des cas cliniques issus de leur propre expérience. Le modèle générique permet de représenter cette expertise. Le module appariement effectue des rapprochements entre les cas, en se basant sur leurs différences. Ce module s’appuie alors sur un modèle spécifique dépendant du domaine. Les auteurs dont les cas ont été appariés sont ensuite incités par le système à interagir, à travers une interface de discussion asynchrone.

La réalisation d’un prototype a permis de valider l’expérimentation du domaine de la prise en charge de la douleur chez l’enfant, de valider également le modèle et enfin, d’effectuer une première validation du module appariement sur le corpus.

Ainsi, après avoir abordé l’adaptation faite du système SBDC pour créer le dispositif DIACOM, nous pouvons maintenant conclure sur cette communication en présentant dans la section suivante, un bilan de ces travaux de recherche, concernant les réalisations et apports scientifiques. En second lieu nous exposerons, nos recherches actuelles et nos perspectives.

8. Conclusion

Cet article a présenté la synthèse de recherches relatives à la prise de décision dans des contextes professionnels variés. Ainsi, l’objectif de cette communication visait à décrire le système SBDC qui a constitué la genèse de travaux menés depuis trois ans, au sein de l’axe TICE du laboratoire Sa.So.

Le système SBDC permet, en fait, de concevoir des environnements exploratoires interactifs pour l’apprentissage de la prise de décision dans des contextes professionnels. Ces environnements permettent alors de reproduire (simuler) des situations professionnelles pour lesquelles, il n’existe pas de modèle formel, mais plutôt un modèle déduit d’une collection de cas. Le système “Simulation à Base de Cas” offre, alors, à un apprenant, un cadre d’apprentissage proche de son environnement réel d’activité.

Dans un premier temps, nous avons dégagé un modèle du comportement des experts combinant raisonnement déductif et inductif, puis une formalisation didactique permettant de définir un cadre général d’entraînement à la prise de décision. Nous avons ensuite proposé une architecture du système SBDC. Nous avons alors choisi une architecture modulaire, se basant sur des modèles en couches. Cet ensemble de travaux s’est concrétisé par l’implantation d’un logiciel auteur qui a été testé sur un domaine médical d’expérimentation.

Cette première expérimentation nous a alors permis de dresser un premier bilan. Il semblait délicat pour un médecin d’appréhender la constitution même d’un cas et de le décomposer en scènes, en actions et en entités, sans une “explicitation” précise du cas. En contrepartie, le modèle conceptuel était suffisamment riche et générique pour constituer des environnements exploratoires. Ainsi, de nouvelles orientations ont été envisagées. En effet, nous nous sommes alors intéressés aux interactions entre apprenants et à la confrontation du processus de prise de décision, dans un cadre distanciel et bien sûr à la généricité des cas. Nous avons également souhaité explorer et expérimenter une autre forme d’apprentissage : l’apprentissage entre pairs. Ces nouvelles orientations nous ont conduit à étudier, concevoir et expérimenter un système support d’apprentissage entre pairs, dans le cadre de la Formation Médicale Continue et à distance : le forum DIACOM.

Ainsi, l’apport scientifique concernant la conception de ces systèmes supports d’apprentissage de pratiques professionnelles relatives à l’utilisation de cas est de proposer des modèles génériques en couches. En effet, les modélisations en couche sont généralement utilisées dans le cadre de recueil d’expertises et de Systèmes à Bases de Connaissances. Ainsi, peu de systèmes éducatifs utilisent ce type de modélisation. En fait, le principal avantage de modéliser des connaissances à enseigner sous la forme de couches est que l’on peut ré-utiliser une partie (couche) du modèle pour d’autres contextes d’apprentissage. C’est ce qui a été fait dans le cadre de DIACOM.

A l’heure actuelle, nous envisageons d’exploiter l’approche distancielle et collective des recherches menées à partir du système SBDC. En premier lieu, rappelons que la réflexion menée sur les modalités de la conception fut à l’origine de la création de la plate-forme INES, qui est actuellement utilisée dans le cadre du projet campus numérique international e-miage.

Ainsi, notre recherche actuelle s’oriente vers la création d’outils d’aide à l’enseignant, intégrables dans des plates-formes d’enseignement à distance. Cette recherche a démarré en 2001 avec le projet SYSMOOSE³ qui vise la création de systèmes supports de méthodes, pour concevoir et organiser des services et ressources pédagogiques en ligne, s’intégrant dans une infrastructure de type “plate-forme”. Ce travail de recherche a fait l’objet de communications récentes [LapujadeLeclet03a], [LapujadeLeclet03b] et [CravoisierLeclet03].

De plus, la particularité de cette recherche est de se baser sur une typologie de scénarios d’apprentissage induits par les “Technologies Educatives Distantes”, en adéquation avec les objectifs d'apprentissage de la formation et les caractéristiques des apprenants. Dans ce cadre, l’objectif est de ré-utiliser le modèle SBDC et de l’adapter pour modéliser des scénarii pédagogiques en vue de concevoir un outil d’aide à la création de services pédagogiques en ligne, de type parcours personnalisés et adaptatifs, mais aussi d’aide à la création de ressources pédagogiques en ligne, de type Activités Pédagogiques Collectives.

Références

Références bibliographiques

[AamodtPlaza95]

Aamodt A., Plaza J. (1995). CBR : foundational issues, methodological variations and system approaches, AICOM, International Conference of Artificial Intelligence Communications, vol 7 n° 1, 39-59.

[AegerterAl91]

Aegerter P., Auvert B., Gilbos V., Andrianiriana F., Benillouche E., Landre M.F., Bos D. (1991). CONSULT-EAO : un tuteur pour l’apprentissage du diagnostic médical destiné aux travailleurs de santé des pays en développement, In Quéré M., Systèmes experts et enseignement assisté par ordinateur, Ophrys (Eds), 101-122.

[Boy88]

Boy G., (1988). Assistance à l’opérateur : une approche de l’intelligence artificielle, Conférence Teknéa, 1988.

[Brown85]

Brown J.S., (1985). Process versus product : a perspective on tools for communal and informal electronic learning, Computing Research Journal (Ed.), n°1.

[Clancey82]

Clancey W., (1982). Tutoring rules for guiding a case method dialog, in Intelligent Tutoring Systems, Brown J.S. et Sleeman D., Academic Press, Londres.

[Cuénoud00]

Cuénoud F., (2000). L’apprentissage par problèmes, chercher pour se comprendre, LEP Loisirs et Pédagogie, Lausanne.

[Coutaz90]

Coutaz J., (1990). Interfaces homme-ordinateur, conception et réalisation, Dunod Informatique (Ed.), Paris.

[CravoisierLeclet03]

Cravoisier E., Leclet D., (2003). Towards a method of design of course for distance learning : a method based on the personalized course of learner, ALCAA 2003, Actes de la conférences « Agents Logiciels, Coopération, Apprentissage, Activité humaine », p 6-16, Bayonne.

[EcoffeyMurat99]

Ecoffey C., Murat I., (1999). La douleur chez l’enfant, Paris, Flammarion Médecine (Ed.).

[Farah00]

Farah P., (2000). Pédagogie médicale : un facteur de rassemblement de solidarité dans la francophonie médicale, Editorial, Pédagogie Médicale, volume 1, N°1.

[Fieschi84]

Fieschi D., (1984). Contribution au système expert Sphinx : application à l’enseignement médical, Thèse de doctorat, Université de Paris VI.

[FournierCharrière99]

Fournier-Charrière E., (1999). La douleur en service de pédiatrie, Paris, Flammarion Médecine (Ed.), chapitre 12, p 109-126.

[JacobsonSpiro93]

Jacobson M., Spiro R., (1993). Hypertext learning environments, cognitive flexibility, and the transfer of complex knowledge. An empirical investigation, Center for the study of reading, Technical report. College of Education, University of Illinois, US.

[Joiron98]

Joiron C., (1998). Similarité dans un système de Simulation à Base De Cas (SBDC), Mémoire de DEA, Université de Picardie Jules Verne.

[Joiron99]

Joiron C., (1999). An Interactive Forum for Distance Education, AIED 99, Young Researcher Track, Le Mans, France.

[JoironLeclet01a]

Joiron C., Leclet D., (2001). A case base model for a case based forum : experimentation on pediatric pain management, Proceedings of Artificial Intelligence in Education AIED2001, San Antonio Texas, mai, US, (IOPress J.D. Moore, C.L. Redfiled, W.L. Johnson Ed.), p 111-121.

[JoironLeclet01b]

Joiron C., Leclet D., (2001b). Partage de cas pour la formation médicale : modélisation et expérimentation du forum DIACOM, Sciences et Techniques Educatives – Volume 8, n°1-2/2001, Actes de la conference EIAO’01, Paris, Hermes (Ed.), p 149-154.

[Joiron02]

Joiron C., (2002). Une contribution aux systèmes supports de Formation Médicale Continue à distance et d’apprentissage entre pairs : conception et expérimentation du forum DIACOM (Discussions Interactives à bAse de Cas pour la fOrmation Médicale), Thèse de doctorat, Université de Picardie Jules Verne.

[Jonassen92]

Jonassen D.H., (1992). Cognitive flexibility theory and its implications for designing CBI, in Instructional models in C.B.L environments, Springer-Verlag (Ed.).

[Kolodner93]

Kolodner.J.L., (1993). Case Based Reasoning, Morgan Kaufmann (Ed.).

[LapujadeLeclet03a]

Lapujade A., Leclet D., (2003). Vers une méthode de conception d’activités pédagogiques collectives distantes. Un domaine d’expérimentation : la programmation C++, ALCAA 2003, Actes de la conférences « Agents Logiciels, Coopération, Apprentissage, Activité humaine », p 69-79, Bayonne,.

[LapujadeLeclet03b]

Lapujade A., Leclet D., (2003b). Design and Implantation of Distant Collective Educational Activities An Application Domain : the Learning of Programming, ICOOL 2003, Proceedings of the International Conference on Open and Online Learning, University of Mauritius Press, p7-13, Ile Maurice.

[Leclet93]

Leclet D, (1993). Une approche par plans et par modélisation du domaine appliquée à l’enseignement de la rhumatologie : le système ARIADE , Thèse de doctorat, UTC.

[Leclet98]

Leclet D., (1998). A  learning  system  for  rheumatology on  internet, ED-MEDIA 98, Proceedings of World Conference on Educational Multimedia and Hypermedia & World Conference on Educational Telecommunications, Freiburg, Juin, Allemagne, AACE/Springer-Verlag (Ed.), ISBN 1-880094-30-4, p 56 – 61.

[LecletWeidenfeld96]

Leclet D, Weidenfeld G., (1996). Un modèle de simulation basé sur une représentation de type “objets - règles” pour l’enseignement des métiers de vente, ITS 96, Intelligent Tutoring Systems, Proceedings of the 3rd International conference, Montréal, Juin, Canada, Lecture Notes in Computer Sciences, Springer (Ed.), p 502-511.

[LecletWeidenfeld97]

Leclet D, Weidenfeld G., (1997). Co-operation process between university and company based on New Technology in information and communication, RUFIS 97, Proceedings of Role of Universities in the Future Information Society, Prague, septembre, République Tchèque, Czech and Slovak part. Praha (Ed.), p 227-234.

[LecletWeidenfeld98a]

Leclet D, Weidenfeld G., (1998). Case Based Simulation Applied to Medical Training, ICCE 98, Proceedings of Sixth International Conference on Computers in Eduaction, Pekin, Octobre, China, AACE/Springer-Verlag (Ed.), p 74 – 80.

[LecletWeidenfeld98b]

Leclet D, Weidenfeld G., (1998b). Training to strategical decisions in professional context : a bridge from case based to simulation based approach, Journal of Computer Assisted Learning, Ed Backwell Science Ltd, Juin, volume 14, p 140-147.

[LecletWeidenfeld98c]

Leclet D, Weidenfeld G., (1998c). Training trainers to the use of Internet, SITE 98, Proceedings of Society for Information Technology and Teacher Education, 9th International Conference, Washington, Mars, US, Volume 1, AACE/Springer-Verlag (Ed.), p 117 – 183.

[MatteiAl97]

Mattei J.F., Etienne J.C., Chabot J.M., (1997). De la médecine à la santé, pour une réforme des études médicales et la création d’universités de la santé, Flammarion (Ed.).

[Moustafiades90]

Moustafiades J., (1990). Formation au diagnostic technique, Masson (Ed.).

[Papert81]

Papert S., (1981). Jaillissement de l’esprit, Champs – Flammarion (Ed.).

[ReisbeckSchank89]

Reisbeck C.K., Schank R.C., (1989). Inside Case Based Reasoning, Lawrence Erlbaume Associates Ed, Hillsdale, NJ, US.

[Resnick82]

Resnick L.B., (1982). Syntax and semantics in learning to substract, T. Carpenter et al. (Ed.), Laurence Erlbaum Associates, Hillsdale, New Jersey.

[Resnick91]

Resnick L.B., (1991). Award for distinguish contributions to educational research, recipient adress, American Educational Research Association (Ed.), Washington, US.

[Richard90]

Richard J.F., (1990). Les activités mentales: comprendre, raisonner, trouver des solutions, Armand Colin (Ed.).

[ThouinWeidenfeld96]

Thouin C., Weidenfeld G., (1996). Impact des NTE sur l’acquisition d’habiletés stratégiques nécessaires à l’exercice du métier de serveur de restaurant, Biennale de l’Education, Paris.

[WatsonMarir94]

Watson I., Marir F., (1994). Case-Based Reasoning: A Review, the Knowledge Enginering Review, Vol 9. No.4.

[Weidenfeld98]

Weidenfeld G., (1998). The role of the context for designing hypermedia training applications, ED-MEDIA 98, Proceedings of World Conference on Educational Multimedia and Hypermedia & World Conference on Educational Telecommunications, Freiburg, Juin, Allemagne, AACE/Springer-Verlag (Ed.), ISBN 1-880094-30-4, p 100 – 106.

[WeidenfeldLeclet98]

Weidenfeld G., Leclet D., (1998). An open and distance training towards the creation of courseware with multimédia, SITE 98, Proceedings of Society for Information Technology and Teacher Education, 9th International Conference, Washington, Mars, US, AACE/Springer-Verlag (Ed.), Volume1, p 105 – 113.

[WeidenfeldAl97]

Weidenfeld G. et alii, (1997). Techniques de base pour le multimédia, Masson (Ed.), Paris.

[WielingaAl92]

Wielinga B., Schreiber G., Breuker J., (1992). KADS : a modelling approach to knowledge engeneering, Knowledge Acquisition, volume 4, pp 5-53.

Références à des sites Internet

[INES04]

http://www.dep.u-picardie.fr(consulté en avril 2004).

[eMIAGE04]

http://www.u-picardie.fr/~cochard/IEM/ (consulté en avril 2004).

A propos des auteurs

Dominique LECLET est Maître de Conférences et habilitée à diriger des recherches en informatique à l'université de Picardie Jules Verne et chercheur au laboratoire Sa.So. Ses activités de recherche concernent les environnements informatiques pour l'apprentissage humain (EIAH) et plus particulièrement les systèmes supports d'apprentissage à distance dans des contextes professionnels.
Son projet de recherche porte sur deux points, d'une part la continuation des travaux sur les EIAH, d'autre part la  création d'outils d'aide à l'enseignant pour la création de services pédagogiques personnalisés et adaptatifs et pour la création de ressources pédagogiques en lignes. L'originalité de l'approche est d'utiliser la simulation à base de cas pour modéliser des scénarios pédagogiques.

Adresse : Laboratoire Sa.So, Université de Picardie Jules Verne, IUP Miage, Pôle Saint Leu, 33 rue St Leu, 80039 Amiens Cedex 1

Courriel : dominique.leclet@u-picardie.fr

^[1] Une vingtaine de procédures distinctes semblent suffisantes, en première approximation, pour représenter l’ensemble des actions possibles.

^[2] Notons que la relation “ISSU_DE”, entre concepts et types de concepts, s’apparente à la relation d’instanciation existant entre objets et classes, dans une modélisation objet.

^[3] SYstèmes Support de Méthodes, pour cOncevoir et Organiser des Services et rEssources pédagogiques en ligne.

Référence de l'article :

Dominique LECLET , Du système Simulation à Base de Cas au forum Discussions Interactives à bAse de Cas pour la fOrmation Médicale, Revue STICEF, Volume 11, 2004, ISSN : 1764-7223, mis en ligne le 15/09/2004, http://sticef.org