Environnements d`apprentissage basés sur la simulation

Transcription

Environnements d'apprentissage basés
sur la simulation
Propositions d’outils auteur et expérimentations.
V. Guéraud, J-P. Pernin, J-M. Cagnat, G. Cortés
Equipe ARCADE - Laboratoire CLIPS-IMAG
BP 53 - 38041 GRENOBLE Cedex 9, France
Viviane.Gueraud@ima g.fr
RESUME. Cet article présente les travaux de l’équipe ARCADE sur le
thème des simulations à but. Nous discutons les avantages des
simulations dans la formation et diverses approches d’intégration
pédagogiques. Nous analysons différentes solutions de production
existantes. Nous montrons comment des contacts industriels nous ont
conduit à proposer un modèle conceptuel, MARS, puis à développer
deux environnements auteur généralistes, Melisa et OASIS, et un
e n v i r o n n e m e n t a u t e u r s p é c i a l i s é , G e n e S i m u . N o u s ab o r d o n s e n s u i t e
une typologie des contrôles pédagogiques, puis nous décrivons
l’approche mise en œuvre pour une définition facile d'exercices. Nous
présentons finalement plusieurs expérimentations industrielles et
académiques de nos outils, et leurs conclusions.
ABSTRACT. T h i s p a p e r d e s c r i b e s t h e w o r k o f t h e A R C A D E t e a m o n g o a l
oriented simulations. We discuss the advantages of simulations in
training and various pedagogical integration approache. We analyze
various existing production methods. We explain how industrial
contacts led us to propose the conceptual model MARS and to develop
t w o g e n e r a l -p u r p o s e t o o l s , M e l i s a a n d O A S I S , a n d a s p e c i a l i z e d t o o l
GeneSimu. We next give a typology of pedagogical controls and
describe our approach to ease the exercise definition task. We finally
present several industrial and academic experiments with our tools
and their conclusions.
M OTS -CLES :
Environnements
interactifs
d'apprentissage
par
ordinateur,
Simulation
pédagogique,
Environnements
auteurs,
Contrôle pédagogique
2
Sciences et techniques éducatives
KEY WORDS: Interactive computer based learning
Instructional Simulation, Authoring environment,
control.
Sciences et techniques éducatives.
environments,
Instructional
Environnements d'apprentissage basés sur la simulation
3
1 . IN T R O D U C T I O N
Notre équipe ARCADE (Ateliers de Réalisation et de Conception
d ’ A p plications Destinées à l’Education), travaille depuis 1985 dans le
domaine des applications pédagogiques fortement interactives, basées
sur la simulation. La production du logiciel Arcade, dédié à
l'enseignement de l'informatique dans l'enseignement supérieur [CAG
90], nous a confortés dans l'idée que ce type d'application ne doit pas
être vu comme une solution de remplacement mais comme un
complément original et efficace, intégré au processus de formation. Par
la suite, nous avons porté nos efforts sur la définition de méthodes et
d’outils permettant la production de logiciels de même type dans
d’autres domaines scientifiques et techniques, et pour des contextes
aussi bien industriels qu'universitaires.
Depuis de nombreuses années, des recherches menées dans le
secteur de l'EIAH (Environnements Interactifs d'Apprentissage Humain)
visent à proposer des solutions sophistiquées basées sur une approche
cognitive et s'intéressent aux interactions entre système et apprenant
[BAL 97]. Cette approche, qui se base s ur le raisonnement pour
représenter l'expertise du domaine, l'expertise pédagogique et le
comportement de l'élève [NIC 88], pose souvent des problèmes dus à la
complexité des modèles qu'elle met en œuvre et requiert souvent une
étroite et longue collaboration entre spécialistes (pédagogues et
informaticiens). Les recherches actuelles menées dans des instances de
normalisation [IEE 98] visent à harmoniser les différentes approches et à
proposer des environnements informatiques simplifiant la tâche des
a u t e u rs .
Si elles sont prometteuses, ces solutions ne permettent pas encore
aujourd'hui de faire face aux besoins pédagogiques, ni aux contraintes
économiques ou pratiques des entreprises chargées de la formation des
personnels et du monde académique (enseigneme nt secondaire et
universités). Adoptant une approche pragmatique, nous sommes partis
du fait que, pour être réellement intégré dans les nouvelles pratiques
pédagogiques, le recours à la simulation devait être maîtrisé par les
opérateurs de formation eux-mêmes.
Nous avons ainsi abordé depuis 1994 trois types de contextes
complémentaires :
Nous avons mené des travaux de collaboration (1994-1996) avec la
société CORYS, à Grenoble, spécialisée dans la conception de
simulation de systèmes liés aux métiers de l'énergie et du transport.
Notre collaboration a consisté à définir un ensemble de méthodes et
4
d'outils dans le but d'améliorer sensiblement la rentabilité du
développement de logiciels pédagogiques basés sur la simulation.
Nous avons travaillé avec le principal centre européen de formation
interne de l'entreprise Hewlett-Packard, TPEC (Technical Planning and
Education Center, L'Isle d'Abeau, France). Nous avons fourni un
ensemble d'outils permettant aux formateurs de produire eux-mêmes des
simulations pédagogiques destinées aux personnels techniques (projet
MELISA Methodology and Environment for developing Learning,
Instruction and Simulation Applications, 1994-1997).
D'autre part, nous participons aux projets européens ARIADNE
(1996-1998) et ARIADNE II (1998-2000) qui ont pour but principal de
définir une infrastructure permettant l’exploitation rationnelle, par des
enseignants ou formateurs, de ressources disponibles dans un vivier de
connaissances et également de faciliter l’accès et l’utilisation de ces
re ssources par les apprenants. Un second objectif est la fourniture
d’outils permettant aux enseignants la création, la modification ou
l’adaptation de ressources pédagogiques variées. Dans ce cadre, notre
équipe a la charge de réaliser et d'expérimenter un outil auteur
générique permettant la création assistée de simulations pédagogiques.
Des expérimentations se sont déroulées au CAFIM, le Centre d'AutoFormation et d'Innovation Pédagogique de l'Université Joseph Fourier Grenoble 1.
Ces différents contextes avaient en commun un certain nombre de
caractéristiques parmi lesquelles :
La volonté de développer ou de réutiliser des simulations spécifiquement construites dans un but pédagogique, écartant de ce fait la
solution consistant à exploiter des simulateu r s d e t y p e « pleine
échelle » .
La nécessité de développer les simulations dans des délais
courts (quelques mois au plus) et à des coûts raisonnables.
La volonté d'utiliser les compétences existantes dans les
structures, sans avoir à prévoir de lourds développements informatiques
nécessitant le recours à la sous-traitance.
Nos travaux de recherche se sont effectués dans ce cadre et ne
concernent donc ni la production de simulateurs pleine échelle, ni la
mise en œuvre de stratégies sophistiquées de contrôle de simulations
incompatibles avec les contraintes énoncées ci-d e s s u s .
2 . S IMULATION ET PEDAGOGIE
Dans le domaine de l'informatique, le terme de simulation est
employé très fréquemment et recouvre souvent des réalités fort
différentes.
5
2 . 1 . Les objectifs de la si m u l a t i o n
Selon la définition du dictionnaire, la simulation est considérée
comme l'action d'imiter, de copier, de reproduire. Cette définition très
générale ne permet pas de faire d'hypothèses sur la finalité de la
simulation. Dans le domaine informatique, le terme de simulation qui
remonte pratiquement aux origines de la discipline, recouvre aujourd'hui
un panel d'applications de types très variés. Pour des non-spécialistes,
la simulation informatique sera associée par exemple, aux prévisions
météorologiq ues où l'on sait que l'on utilise les calculateurs les plus
puissants du monde, aux simulateurs de vols très répandus dans le
domaine des jeux ou aux simulations d'emprunts dans le domaine
financier. Autant d'exemples où la finalité de la simulation est à c h a q u e
fois différente. Nous proposons donc de répartir les simulations
informatiques en trois catégories selon l'objectif poursuivi : simuler
pour comprendre, simuler pour construire, simuler pour apprendre.
2.1.1. Simuler pour comprendre
Dans les disciplines scientifiques fondamentales telles que les
mathématiques ou la physique, l'ordinateur a d’abord été exploité pour
les capacités de calcul qu'il offrait. On s'est très vite rendu compte que
grâce à cette rapidité, on disposait d'un moyen radicalement nouveau d e
vérifier des hypothèses de travail. En simulant les résultats d'une
théorie proposée, on peut rapidement en vérifier la validité et
progresser beaucoup plus vite dans le processus de mise au point de
cette théorie.
Cette démarche est utilisée aujourd'h ui à grande échelle dans tous
les domaines scientifiques ou techniques tels que l'étude de
phénomènes
météorologiques,
astronomiques,
nucléaires,
épidémiologiques, etc. L'approche consiste ici à progresser dans la
compréhension d'un phénomène réel e n p r o p o sant un modèle (le plus
souvent numérique), et en comparant d'une part, les résultats produits
par une simulation de ce modèle et d'autre part, les phénomènes
constatés dans le monde réel.
2.1.2. Simuler pour construire
Un autre type d'application très courant consiste à utiliser l'outil
informatique pour simuler un nouvel objet avant de le créer
véritablement. Cet usage sert le plus souvent à proposer et valider des
solutions variées pour un problème donné, en évitant de toutes les
réaliser concrètement. On peut citer comme exemples : les logiciels de
simulation de prêts financiers, les logiciels de conception assistée
6
permettant de créer des maquettes d'appareils, de dispositifs techniques
ou de bâtiments.
2.1.3. Simuler pour apprendre
La simulation est aujourd'hui de p lus en plus utilisée dans le
processus d'apprentissage. Elle peut concerner des domaines aussi
variés que :
L'apprentissage de pratiques médicales, avec par exemple, un
certain nombre de projets qui ont pour but l'apprentissage de la
manipulation d'outils chirurgicaux en faisant appel à des techniques de
réalité virtuelle [GEC 94] [FRA 99].
L'apprentissage de la conduite d'engins ou d'avions. On doit
insister ici sur les notions de généricité et de configurabilité, et sur la
nécessité pédagogique du réalis me (utilisation de son, d'images de
synthèse) [GOU 99].
L'apprentissage de matières scientifiques. Par exemple, ARCADE
[CAG 90] permet la simulation des phénomènes dynamiques liés à
l’exécution des programmes pour l’apprentissage de l’algorithmique.
La maîtrise de situations de négociation ou de communication.
Ces exemples montrent bien la variété d'utilisation de la simulation
dans le processus d'apprentissage. On peut remarquer que selon les
contextes, et en fonction des objectifs pédagogiques, il peut être fait
appel à des techniques plus ou moins sophistiquées telles que la réalité
virtuelle, la manipulation directe, le recours au multimédia.
Pourquoi utiliser la simulation dans le processus d'apprentissage ?
De Jong [DEJ 91] énonce un certain nombre de raisons qu'il qualifie
d'affectives : l'attrait de la simulation pour l'apprenant, l'augmentation
de sa motivation, une meilleure compréhension des phénomènes, une
plus grande aptitude à l'adaptation pour des problèmes similaires dans
d'autres contextes, etc. Des raisons p r a t i q u e s sont également citées
[DEJ 91, HER 94] : le travail sur un système réel peut être trop coûteux
ou trop long, dangereux pour l’homme, l’environnement ou le matériel,
source d’angoisse pour le débutant. Dans une simulation, on peut
introduire des situations d'extrême gravité pour entraîner l'apprenant à
réagir, changer l'échelle de temps pour améliorer la compréhension,
simplifier ou altérer une réalité pour mieux l'étudier.
2.1.4. Et les autres simulations ?
Bien évidemment, il existe des applications logicielles basées sur la
simulation qui n'entrent pas de façon claire dans une des catégories
é v o q u é e s c i-dessus. On citera en particulier tous les logiciels de jeux.
Ces applications n'ont, le plus souvent, pas d'autre but avoué que celui
7
d e divertir. Il n'empêche que leur pratique peut entraîner de façon
indirecte une modification de la connaissance, de la capacité de
raisonnement ou du savoir-faire des utilisateurs. Par exemple, des jeux
très répandus comme F l i g h t S i m u l a t o r o u Tetris amélio rent
probablement les capacités d'appréhension de l'espace en 3D ou en 2D.
2 . 2 . Simulations et approches d'apprentissage
Une classification courante consiste à prendre en compte la logique
d'apprentissage proposée par les logiciels pédagogiques, en
distinguant deux approches : l'approche transmission de connaissances
et l'approche d é c o u v e r t e / c o n s t r u c t i o n d e c o n n a i s s a n c e s 1.
2.2.1. Approche transmission de connaissance
Les logiciels issus de l'approche transmission de connaissances
regroupent les tuteurs de l'EAO classique, o u didacticiels, et les
t u t e u r s i n t e l l i g e n t s . Les premiers sont basés sur une décomposition de
la matière en unités élémentaires dont l'enchaînement est préétabli, sur
une évaluation de l'acquisition après la présentation de chaque unité, et
s u r u n e progression conditionnée par la réponse fournie. Les seconds,
les tuteurs intelligents, cherchent à adapter au mieux la transmission de
connaissances aux caractéristiques de l'apprenant. Cette adaptation est
réalisée en intégrant explicitement, dans le logiciel, différentes
expertises concernant respectivement le domaine, les stratégies
pédagogiques, l'apprenant, les interfaces homme -machine [NIC 88].
2.2.2. A p p r o c h e d é c o u v e r t e / c o n s t r u c t i o n d e c o n n a i s s a n c e s
Les
logiciels
issus
de
cette
approche
regroupent
les
h y perdocuments, les environnements d’apprentissage et les micro mondes.
Le concept d'hyperdocument (ou de façon plus précise d'hypertexte
o u hypermédia) permet "l'immersion" dans une mer "d'information" où
le lecteur "navigue" selon un processus associatif. Ce type de logiciel
connaît actuellement un engouement remarquable en particulier grâce à
l'essor du World Wide Web. Un hyperdocument peut être considéré
comme un réseau de nœuds et de liens, où les nœuds représentent les
contenants d'information, et les liens, des relations entre les nœuds ou
portions de nœuds.
1
Le mot "connaissances" est pris ici au sens large, et inclut donc aussi bien, les
connaissances conceptuelles que les connaissances opérationnelles.
8
L'utilisation pédagogique des hyperdocuments induit en général un
a p p r e n t i s s a g e p a r l a d é c o u v e r t e [VIV 91] : l'apprenant a alors la tâche
de donner du sens au chemin qu'il construit à travers la con n a i s s a n c e
proposée.
Quand Papert introduit le concept de micro -monde, il base en
premier lieu son approche sur une démarche d'innovation pédagogique
en reprenant les théories de J.Piaget. Papert propose d'offrir un
environnement ouvert d'apprentissage dans lequel l'apprenant peut
développer ses propres modèles du monde réel afin de les expérimenter
par la simulation. Ces micro -mondes permettent ainsi aux apprenants de
développer et de corriger leurs propres théories.
La notion d'environnement d'apprentissage [HER 94, MEN 95] est
davantage basée sur la simulation d'un modèle que sur sa construction.
L'élève apprend en modifiant les paramètres et en observant les
conséquences de ses actions dans l'environnement simulé. Comme
souligné dans [DEJ 91], la frontière entre micro -mondes et
environnements d'apprentissage basés sur la simulation n'est pas
toujours simple à tracer. Par exemple, le simple fait d'ajouter un
composant dans un circuit électrique relève-t -il de l'un ou de l'autre
c o n c e p t ? Certaines caractéristiques permettent toutefois de distinguer
chaque type d'environnement :
Un micro -monde est un système isolé qui évolue selon ses
propres lois internes, et les possibilités d'apprentissage qu'il propose
évoluent aussi avec le temps.
Dans un micro -monde, l'objectif pédagogique externe peut être
v a r i a b l e e t e s t s o u s -tendu par un objectif ludique interne [GIB 93].
Un environnement d'apprentissage a une finalité explicite
[HER 94].
Soulignons
que
ces
différents
types
d'environnements
(hyperdocuments, environnements d'apprentissage et micro -mondes)
peuvent être proposés de façon conjointe. Les connaissances
proposées dans un hyperdocument peuvent être renforcées par la mise à
disposition de simulations lorsque cela est pertinent. Inversement, un
a p p r e n a n t e n t rain de manipuler une simulation et s'apercevant qu'il ne
maîtrise peut-ê t r e p a s l e s c o n n a i s s a n c e s n é c e s s a i r e s p o u r r a
avantageusement rechercher les connaissances qui lui font défaut à
l'intérieur d'un hypertexte.
Approche
transmission de connaissance
Tuteurs
Classiques
Tuteurs
Intelligents
Approche
découverte-construction de
connaissances
Hyperdocuments
9
Notre
domaine
d'étude
Environnements
d'apprentissage basés
sur la simulation
Micro- mondes
Figure 1. Notre domaine d’étude
2 . 3 . Les environnements d'apprentissage basés sur la simulation
Nous proposons maintenant de définir de façon plus précise le
concept d'environnement d'apprentissage basé sur la simulation, en
l'abordant sous différents angles d'appréciation :
Quelles sont les caractéristiques des connaissances que
l'apprenant doit acquérir grâce à la simulation ?
Quel type de contrôle pédagogique l'ordinateur peut-il assurer ?
Dans quels contextes pédagogiques les simulations peuventelles être utilisées ?
Da ns quelle mesure la simulation pédagogique peut-elle être
exploitée à distance ?
2.3.1. Simulations, connaissances acquises et réalisme des interfaces
Comme nous l'avons vu plus haut, l'utilisation pédagogique de
simulations relève principalement d'une approche d écouverte /
construction de connaissances.
De façon traditionnelle, on fait une différence entre les
connaissances conceptuelles (le savoir), et les connaissances
procédurales (le savoir-faire). Doit -o n p o u r a u t a n t a s s o c i e r l e s
simulations pédagogiques à l'un ou l'autre type de connaissances ?
Dans une acception fréquemment rencontrée, la simulation est
perçue comme la reproduction la plus fidèle possible d'objets du monde
réel. Les simulateurs pleine échelle de pilotage de trains, d'avions, de
bateaux, son t c o n ç u s p o u r p l a c e r l e s a p p r e n a n t s d a n s d e s c o n d i t i o n s
les plus proches possibles de la réalité. Les connaissances construites à
l'aide de ces simulateurs d'entraînement relèvent clairement de
l'acquisition de savoir-faire. On peut remarquer que les besoins
pédagogiques des instructeurs se sont exprimés a posteriori au fur et à
10
mesure de l'utilisation de ce type de simulation [JOA 97] : " les
instructeurs souhaitent à présent compléter un simulateur
d ' e n t r a î n e m e n t p a r u n o u t i l p é d a g o g i q u e c o n s t i t u é , a u m i n imum, d'un
logiciel de création et de supervision d'exercices de simulation et d'un
gestionnaire de cursus de formation". Pour de tels simulateurs, le degré
retenu de réalisme de l'interface (qui peut aller jusqu'à la reproduction
physique exacte de l'environnement réel) se fonde principalement sur
une étude de rentabilité.
Une seconde catégorie concerne le cas où le recours à la simulation
est vu comme une solution complémentaire à d'autres modalités et
l'accent est porté sur l'intégration de l'usage de ces simulations au sein
d'un cursus de formation. Par exemple, dans un contexte que nous
avons étudié, la formation de techniciens au fonctionnement d'un
appareil nouvellement introduit sur le marché est basée sur l'utilisation
conjointe de documents vidéos relatifs au montage et démontage de
l'appareil, et de simulations permettant de se concentrer sur les
stratégies de dépannage liées aux dysfonctionnements de l'appareil.
L'utilisation de ces deux modalités permet à l'apprenant de se concentrer
à divers moments sur différents niveaux d'apprentissage : les documents
vidéos permettent de mémoriser l'emplacement exact des éléments, la
position des vis, l'ordre de montage et de démontage, alors que les
simulations mettent l'accent sur des notions plus conceptuelles telles
que les stratégies de test de l'appareil et de remplacement de
composants éventuellement défectueux. Dans ces simulations, de
nombreux paramètres ont été volontairement altérés (ex : le déroulement
du temps) ou simplifiés (ex : la manipulation physique d'un composant)
afin de faire bénéficier l'apprenant du meilleur apport pédagogique. Il
apparaît donc que, dans ce type de simulations, la réflexion
pédagogique s'effectue a p r i o r i , avant même la conception ou la
réutilisation de simulation et que les connaissances que devra acquérir
l'apprenant pourront être aussi bien conceptuelles que procédurales.
Certains logiciels reposeront davantage sur la démarche de résolution
de problèmes, alors que d'autres s'intéresseront aux aspects purement
opératoire s, voire psychomoteurs.
Pour de tels simulateurs, le degré retenu de réalisme de l'interface se
fonde principalement sur des critères d'efficacité pédagogique et sera
souvent inversement proportionnel au degré d'abstraction des
connaissances à acquérir (Cf. figure 2).
r é épeuvent
m i n e n c e d e pas
l a r é être
f l e x i o ncréés à partir des codes
Erreur ! Des objets Pne
p é d a de
g o g imise
q u e d aen
n s lforme.
a
de champs
conception de la simulation
Figure 2. S i m u l a t i o n s e t d e g r é d ' a b s t r a c t i o n d e s c o n n a i s s a n c e s à
acquérir
Connaissances
purement
conceptuelles
11
2.3.2. Simulations et objectifs de l'apprenant
Un certain consensus émerge pour affirmer que “l a l o g i q u e d e
transmission des connaissances utilisée seule ne fonctionne pas, pas
plus d’ailleurs que la logique de construction personnelle de
connaissances pour un élève largué seul dans un micro -monde”
[VIV 91]. De même Mengelle fait remarquer que "pour être efficace,
l'utilisation d'un micro -monde, d'un e n v i r o n n e m e n t d ' a p p r e n t i s s a g e
o u d ' u n h y p e r t e x t e d o i t ê t r e f i n a l i s é e " [MEN 95]. L'objectif peut
idéalement être un projet personnel de l'apprenant comme dans le cas
des micro -mondes, mais il est le plus souvent fixé par un enseignant ou
un formateur.
Herzo g et Forte [HER 94] évoquent les avantages d’une simulation à
but par rapport à une simulation libre :
Elle place l'apprenant dans une situation donnée et fixe,
éventuellement avec sa participation, l'objectif à atteindre.
Elle offre un défi (un challenge) à l'apprenant et renforce ainsi sa
motivation.
Elle donne un sens aux actions de l'apprenant, une orientation à
son comportement.
Elle évite à l'apprenant de modifier de façon aléatoire ou
incohérente les paramètres de la simulation.
Elle donne à l'apprenant la possibilité d'examiner certains aspects
à côté desquels il serait sans doute passé s'il avait utilisé librement la
simulation.
L'objectif (ou un ensemble d'objectifs) peut être fixé par le formateur
si le logiciel de simulation pédagogique est utili s é p e n d a n t u n e s e s s i o n
pilotée par un enseignant. Il peut également être intégré au logiciel et
proposé à l'apprenant, sous forme de suggestions et de choix
volontaires dans une liste d'objectifs possibles.
Définir des buts pour une simulation pédagogique implique de placer
l'apprenant dans une situation donnée et de fixer alors (éventuellement
avec sa participation) l'objectif à atteindre. Il peut être nécessaire de
préciser un certain nombre de contraintes que l'apprenant devra
respecter durant sa progre ssion vers l'objectif final.
Sur un autre plan, le fait de fournir à l'apprenant un objectif
clairement défini permet d'envisager un suivi de ses activités, une
assistance, un guidage ou une évaluation. Ces différentes activités
peuvent être réalisées soit par l'enseignant dans un contexte
d'utilisation assistée, soit par le système dans un contexte d'utilisation
autonome, voire collaboratif.
12
2.3.3. I n t é g r a t i o n p é d a g o g i q u e d a n s l e p r o c e s s u s d e f o r m a t i o n
De façon générale, dans le domaine de l'Enseignement Assisté par
Ordinateur, il est nécessaire de réaliser une analyse fine des usages
pédagogiques possibles des logiciels produits. Expliciter ces usages, à
savoir la possible présence (physique ou distante) du formateur et de
c o -apprenants, les interactions possib les (maître -élève ou élève-élève)
en fonction des problèmes, des disponibilités de chacun, des niveaux
respectifs des étudiants, etc., peut permettre d'augmenter l'efficacité
pédagogique de ces logiciels. Cette modélisation du contexte
p é d a g o g i q u e p e u t ê t re intégrée dans les logiciels eux-mêmes, en
particulier dans le domaine des tuteurs intelligents [VIV 91].
Les simulations pédagogiques peuvent être utilisées dans plusieurs
contextes :
Simulations intégrées au sein d'un enseignement traditionnel
avec un p é d a g o g u e .
Par exemple, des logiciels de simulation dédiés aux métiers de l'énergie
ont pour objet d'être utilisés pendant des sessions de formation
continue réservées aux personnels techniques de grandes sociétés. Ils
servent d'illustration du cours dispensé de façon traditionnelle, et
peuvent être utilisés en présence du pédagogue dont le rôle consistera
à orienter si nécessaire les apprenants.
Simulations utilisées de façon autonome.
Hewlett-Packard a développé des simulations pour rapprocher la
formation des besoins spécifiques de l'utilisateur. Dans ce cas, l'usage
du logiciel est individuel et autonome et peut couvrir plusieurs types
d'objectifs :
l'a u t o -formation par l'apprenant sur les matériels ou logiciels
dont il doit assurer l'installation ou la maintenance ;
l'a u t o -é v a l u a t i o n qui permet à l'apprenant de vérifier lui-même
les compétences acquises ;
la certification qui recouvre la vérification des aptitudes
techniques à résoudre un problème. Dans ce cas, l'apprenant n'est pas
en situation d'apprentissage, mais d'évaluation.
Simulations utilisées en présence d'autres apprenants.
L'utilisation pédagogique peut également s'appuyer sur la présence de
c o -apprenants, présence effective ou distante par l'intermédiaire d'un
réseau. On parle alors d ' a p p r e n t i s s a g e c o o p é r a t i f. Citons par exemple le
cas des logiciels d'apprentissage basés sur les jeux de rôles [GUE 89]
[ AKK 97] .
13
2.3.4. Simulations et formation à distance
Dans la plupart des contextes que nous avons récemment rencontrés,
la question de l'exploitation distante de simulations est rapidement
devenue centrale. En effet, les simulations, qui permettent un
apprentissage
actif
de
type
« découverte-c o n s t r u c t i o n
de
c o n n a i s s a n c e s » sont compatibles avec un relatif isolement de
l'apprenant. Elles constituent un indispensable complément à des
dispositifs de formation à distance fondés le plus souvent sur la simple
manipulation de documents de type « expositifs » b a s é s s u r u n e l o g i q u e
de transmission de connaissances.
L'essor récent de plates -formes d'intégration de formations à
distance telles que Learning Space [LEA], WebCT [WEB], Ariadne
[FOR 97a, FOR 97b] témoigne de la nécessité actuelle de fournir aux
e n s e i g n a n t s e t f o r m a t e u r s d e s s o l u t i o n s s o u p l e s q u ' i l s p e u v e n t e u xmêmes exploiter, adapter et maintenir. Ces environnements permettent
de mettre en œuvre de véritables cursus de formation, en intégrant la
mise à disposition de ressources pédagogiques variées, la planification
des activités de l'apprenant, la gestion des communications entre
apprenants (travail collaboratif) et avec les enseignants (tutorat). Ces
dispositifs, qui commencent à être déployés à très large échelle dans
certains pays, sont majoritairement associés à une l o g i q u e
d ' e x p l o i t a t i o n a s y n c h r o n e . Ils sont basés sur le fait que les activités
sont réalisées par les apprenants à des temps choisis par chacun (bien
que contraints par des plannings) et que les échanges entre les
différents acteurs s'effectuent à l'aide d'outils de communication
asynchrones (courrier électronique, forums, foires aux questions, etc.).
Cette logique de communication asynchrone apparaît insuffisante
pour une exploitation optimale de la simulation dans un contexte de
formation à distance. L'apprenant est placé dans une situation active où
son comportement a une importance primordiale dans le processus
d'apprentissage ; une mauvaise interprétation ou une incompréhension
des tâches à accomplir peuvent le conduire à graves erreurs ou à un
sentiment d'échec. Des moyens sophistiqués de contrôle de simulations
(guidage, explic ations, etc.) peuvent réduire ces risques sans pour
autant les faire disparaître.
En revanche, les possibilités d'échanger des informations avec un
c o -apprenant, de faire vérifier le travail par l'enseignant, voire de se
faire montrer la solution, permettent de recréer des conditions
différentes d'apprentissage. Plusieurs équipes travaillent sur le domaine
[DER 97] [BAU 98] [LEW 98].
14
3 . LA P R O D U C T I O N D E S I M U LATIONS PEDAGOGIQUES
3 . 1 . Les enjeux et contraintes de la production
Dans deux contextes industriels que nous a v o n s é t u d i é s , n o u s a v o n s
remarqué que la maîtrise de la production représentait un point critique.
La société Hewlett-Packard doit impérativement maîtriser les délais de
d é v e l o p p e m e n t pour être capable de livrer au moment de
l'industrialisation d'un nouveau produit, les supports de formation
correspondants. La société CORYS doit impérativement maîtriser les
c o û t s d e p r o d u c t i o n (délai et ressources) si elle veut proposer des
logiciels de formation à des prix raisonnables.
Ces enjeux, mis en évidence dans des contextes de formation
continue en milieu industriel, se retrouvent également dans le domaine
de la formation initiale. En effet, nous pouvons constater qu'il existe
aujourd'hui des logiciels de grande qualité pédagogique, en général
i s s u s d e t r a v a u x d' e n s e i g n a n t s o u d e c h e r c h e u r s . M a i s n o u s p o u v o n s
également remarquer que ces logiciels sont produits à des coûts
déraisonnables, que ce soit en termes d'effort financier, ou, ce qui est
plus difficilement mesurable, en termes d'investissement personnel des
enseignants. Cette raison, ainsi qu'une reconnaissance très relative du
travail des enseignants impliqués dans l'essor des « Nouvelles
Technologies Éducatives », représente sans aucun doute le frein le plus
important au développement à grande échelle de logiciels pédagogiques
de qualité.
La maîtrise des coûts de production doit permettre de développer
des logiciels de qualité à moindre effort, et de favoriser ainsi
l'apparition sur le marché commercial d'un nombre nettement plus
important de produits intére s s a n t s à d e s c o û t s n e t t e m e n t m o i n s é l e v é s .
Cette augmentation du volume et cette diminution des prix devraient
faciliter l'usage de ce type de logiciels par de nombreux enseignants et
formateurs.
3 . 2 . Processus de développement dans une société spécialisée
En 1994, la société CORYS a désiré diversifier ses activités en
proposant un catalogue de logiciels de simulation pédagogique portant
sur les métiers de l'énergie et du transport (par exemple, simulateurs de
conduite de train, de centrale thermique ou nucléaire) ; et d'autre part,
elle souhaitait réaliser à la demande des logiciels sur mesure. Chaque
logiciel, conçu comme un complément à une formation dispensée de
façon traditionnelle, est consacré à un sujet spécifique (par exemple, les
15
principes de fonctionnement d'un générateur de vapeur) et se présente
sous la forme d'une base de connaissances et d'un ensemble d'exercices
basés sur la simulation. Les logiciels sont prévus pour être utilisés
sous le contrôle de formateurs dans le cadre de sessions de plusieur s
jours.
La nécessité de satisfaire les clients impose un haut niveau de
qualité des logiciels réalisés, tant pour l'expertise du domaine, que pour
la pédagogie ou la présentation interactive, mais avec aussi des
contraintes de prix et de délai de développement (ordre de grandeur :
deux à trois mois).
Le développement des premières maquettes a démontré que la
rentabilité de cette activité ne serait atteinte que par une modification
importante des habitudes de production, en assurant notamment une
coopération efficace entre les différents acteurs (responsable de projet,
expert du domaine, expert pédagogue).
L'apport de notre équipe de recherche a consisté à proposer deux
types de réponses complémentaires aux problèmes soulevés. Le premier
n i v e a u c o n s i s t e à introduire, dans le cadre existant, un ensemble de
méthodes et procédures permettant d'améliorer sensiblement la
rentabilité. Le deuxième consiste à développer des environnements
intégrés de production permettant la mise en œuvre assistée, voire
automatisée, d e c e s m é t h o d e s e t p r o c é d u r e s .
3 . 3 . Les méthodes de génie logiciel appliquées à la production de
simulations pédagogiques
Dans le contexte du développement de simulations pédagogiques
rencontré dans l'entreprise CORYS, nous avons identifié un ensemble
d e s e p t rôles [PER 96a] :
1. La responsabilité du projet de développement ;
2. L'expertise technique du domaine ;
3. L'expertise en pédagogie du domaine ;
4. La conception des aspects externes de l'application ;
5. La conception de l'architecture interne de l'application ;
6. Le d éveloppement informatique des applications ;
7. La médiatisation des applications.
Sur la base de cette décomposition, nous avons proposé un
processus de développement (Cf. figure 3) basé sur la mise en parallèle
de certaines tâches (spécification des modèle s , d e s i n t e r f a c e s e t d e s
scénarios pédagogiques). Amorcée dès la phase de spécification, cette
parallélisation est rendue possible par une forte exigence de
formalisation des informations échangées entre les différents acteurs
16
(sous la forme de formulaires papiers). Elle aboutit à la rédaction de
documents de spécification à partir desquels peut être engagée la phase
s u i v a n t e d e c o n c e p t i o n -réalisation.
17
Cette dernière phase repose :
sur la production parallèle des différents composants
informatiques de l'a pplication (modèle de simulation, interface,
exploitation pédagogique de la simulation) par les personnels
spécialisés,
puis sur l'intégration des différents composants dans
l'application finale.
Cahier
des Charges
PHASE DE
SPECIFICATION
Spécification Globale
LEGENDE
ED : Expert du Domaine
EP : Expert Pédagogue
CI : Concepteur appli. Interactive
CA : Concepteur Architecture
M : Médiatiseur
DH : Développeur Hypermédia
P : Programmeur
Echange entre acteurs
Dossier de
Spécification Globale
ED
EP
CI
Spécif. détaillée
Scénarios
IHM
Spécifications
IHM
PHASE DE
CONCEPTION /
REALISATION
Modèles de simulation
Spécifications
Scénarios
Spécifications
des modèles
CA
Conc. de l'architecture
Dossier d'Architecture
Globale
P
M
Médiatisation
de l'application
Documents Multimédias
(graphimes, sons,
vidéo ,..)
PHASE
D'INTEGRATION
DH
P
Réalisation des
IHM
Réalisation des
Scénarios
Réalis° des modèles
de simulation
Code d'exécution de
l'interface
(testable)
Code d'exécution du
scénario
(testable)
Code
de simulation
(testable)
DH
Intégration
APPLICATION
FINALE
Mise au point de détail
Figure 3 . Modélisation du processus de développement
18
Ce processus a été mis en œuvre dans un cas concret où il s'agissait
de développer en un temps limité (10 semaines) une application
pédagogique consacrée à l'apprentissage des concepts de base du
fonctionnement d'un alternateur. Destinée à un public de techniciens
travaillant dans des entreprises liées aux métiers de l'énergie, cette
application propose à l’apprenant une base de connaissances, ainsi
qu'une série de 15 simulations à buts classées par ordre de difficulté
croissante.
Les méthodes et formalismes introduits dans le processus de
développement nous ont permis d'atteindre notre objectif de production
de l'application "Alternateur" dans le temps imparti. Mais ce résultat n'a
pu être obtenu que grâce à un investissement élevé. En particulier, la
possibilité d'assurer une disponibilité quasi-permanente de certains
intervenants (responsable de projet, informaticiens, expert du domaine,
expert pédagogue) a constitué un élément déterminant, mais non réaliste
dans un contexte de développement visant la rentabilité. Cette
disponibilité a permis notamment la collaboration directe des acteurs
par le biais de réunions de travail.
Les principales leçons à tirer de cette expérience ont été les
suivantes :
Les différentes tâches de spécification peuvent être en partie
réalisées de façon indépendante, avant d'être intégrées dans
l'application finale. Il faut en particulier proposer à chaque type de
concepteur un moyen de tester isolément la validité de ses
spécifications (scénario pédagogique, modèle de simulation, partie
interactive de l'application) ;
La coopération indispensable entre les différents intervenants
nécessite une formalisation précise et non ambiguë des spécifications
de chaque composant et la compatibilité des divers formalismes
retenus ;
Des méthodes basées sur la communication directe entre les
intervenants et la communication par documents formalisés permettent
un gain de temps appréciable. Par contre, ces méthodes entraînent un
surcoût important et une difficulté de mise en place dans un contexte
industriel, dus en particulier à la mobilisation simultanée d'experts de
compétences diverses pendant un laps de temps non négligeable.
Sur la base de ces résultats, nous avons poursuivi nos efforts de
recherche vers la définition d'a teliers de génie logiciel spécialisés
permettant la mise en œuvre automatisée ou assistée des méthodes et
processus proposés.
19
3 . 4 . M A R S : un cadre fédérateur pour la production de simulations
pédagogiques
Les efforts de recherche de notre équipe se sont donc con c e n t r é s
depuis 1995 sur la définition de plates -formes logicielles pour la
production de simulations pédagogiques. En fonction des contextes
rencontrés, les rôles précédemment repérés peuvent soit être tenus par
des acteurs différents, soit reposer sur le s épaules d'un nombre réduit
d'acteurs. Dans ce dernier cas, les environnements de production
devront proposer un degré élevé d'assistance et d'automatisation pour
pallier les carences en spécialistes (notion d’environnement auteur).
Nos travaux s'appuient sur un cadre conceptuel commun, M.A.R.S.
(Modèle, Association, Représentation, Scénario), permettant de
fortement structurer l'approche de production dans toutes ses phases.
MARS repose sur le fait qu'à l'exception des aspects purement
informatiques, les rôles précédemment identifiés relèvent de quatre
types d'activités :
la Modélisation du domaine qui s'intéresse à décrire le système
simulé ;
la Représentation de l'application qui s'intéresse à définir les
interfaces manipulées par l'utilisateur ;
les A s s ociations qui permettent d'intégrer les résultats obtenus
afin d'obtenir l'application de simulation ;
le Scénario qui s'intéresse à l'exploitation pédagogique des
simulations en fixant des objectifs à l'apprenant.
MARS peut servir de guide conceptuel à t rois niveaux :
au niveau supérieur, nous proposons de fournir à l'équipe de
production un ensemble d'espaces de travail spécialisés, permettant à
chaque acteur de manipuler des formalismes adaptés et proposant des
mécanismes de génération assistée, voire automatisée, des composants
logiciels décrits ci-dessus. En fo n ctio n d es caractéristiq u es d es éq u ip es
de production et des domaines d'application, nous pouvons proposer
des degrés de visibilité et de complexité différents. Si, dans le cas
d'équipes rassemb lant toutes les compétences spécialisées, les quatre
espaces de travail peuvent être proposés de façon explicite, la visibilité
pourra être considérablement réduite dans le cas d'un environnement
traitant d'un domaine très spécifique et appelé à être manip ulé par un
auteur isolé ;
au niveau intermédiaire, l'application doit être conçue de façon
explicite comme étant structurée en trois composants indépendants (le
Modèle, le Scénario et la Représentation) pouvant être connectés grâce
à des Associations. Cette approche permet de structurer la conception
mais également de prendre en compte des stratégies de réutilisation
20
concernant aussi bien la réalisation d'un composant, que l'intégration
de plusieurs composants entre eux ;
au niveau le plus interne, le code peut être implémenté sous la
forme d'agents communicants où chaque agent est chargé de participer,
soit à la mise en œuvre d'une activité, soit à l'intégration des différentes
activités.
Environnement 1
Niveau Spécification
Espaces de travail
Visibles par les auteurs
Environnement 2
Mise en
correspondance
génération automatisée
Niveau Conceptuel
Entités de conception
SCENARIO
MODELE
REPRESENTATION
Niveau Implémentation
agents logiciels
Figure 4. Les différents niveaux d'applicatio n d e M A R S
3 . 5 . Les solutions de production de simulations pédagogiques
Nous allons maintenant utiliser le cadre conceptuel MARS pour
évaluer des solutions existantes de production de simulations, et plus
particulièrement de simulations pédagogiques. Nous présen t e r o n s
ensuite les environnements de production basés sur MARS que nous
avons développés.
3.5.1. L e s s o l u t i o n s e x i s t a n t e s d e p r o d u c t i o n d e s i m u l a t i o n s
La simulation est un domaine à part entière de l'informatique. Elle
peut se scinder au moins en deux grandes s o u s -disciplines : la
21
simulation de phénomènes continus et la simulation à événements
d i s c r e t s . C h a c u n e d e c e s s o u s -disciplines propose ses propres règles
d'écriture et ses propres modes de production. Trois types de contexte
peuvent être distingués :
Le d é veloppement « sur mesure » , adapté à la production de
simulateurs complexes de type « pleine échelle » où le code
informatique doit être optimisé. Ce type de logiciel, développé par des
équipes d'informaticiens spécialisés, le plus souvent à l'aide de
langages généraux (C, C++, Ada, voire Fortran), distingue le composant
« moteur de simulation » chargé de décrire le fonctionnement du
système simulé (le Modèle de MARS), et le composant « interface » qui
s'intéresse à définir ce que l’utilisateur peut voir et manipuler. Ces
applications requièrent des solutions logicielles et matérielles
relativement complexes (systèmes multi-tâches, distribution des
applications sur un réseau, recours au calcul parallèle) et s'appuient sur
des mécanismes d'association sophistiqués programmés « à la main » .
Les ateliers de génie logiciel dédiés à la production de
s i m u l a t i o n s pour des classes de problèmes bien spécifiques. Ces outils
spécialisés « préprogrammés » permettent au concepteur de modéliser à
moindre effort. On peut citer, par exemple, SIMFACTORY dédié au
domaine de fabrication discontinue en milieu industriel. Ces outils
simplifient la conception, réduisent les efforts de modélisation,
améliorent la lisibilité et la maintenance, mais ils ne permettent pas une
généralis ation de leur usage hors de contextes très précis [AZZ 95].
Les environnements-auteurs dédiés à la simulation, adaptés à la
production de simulations de moindre complexité et pouvant s'exécuter
sur des plates -formes standard (ordinateur individuel et système monot â c h e ). Leur objectif est de rendre accessible la création de telles
simulations à des non-programmeurs. Ils se basent de façon générale
sur un ensemble d'éditeurs spécialisés permettant de décrire d'une part
la logique fonctionnelle, et d'autre part l'interface de la simulation. Des
techniques de programmation visuelle et de génération automatique de
code rendent effectivement ce type d'outils très attrayant. On peut citer
dans ce domaine LabView de la société National Instruments. Il permet
de
d é finir
sans
programmation
textuelle,
des
systèmes
d'instrumentation, reliés à des équipements réels ou totalement simulés.
L e c o n c e p t e u r d i s p o s e d ' o b j e t s a p p e l é s « Instruments virtuels » qui
proposent un aspect graphique et un aspect logique (basé sur un
e n s emble de connecteurs d'entrée et de sortie). Il peut à partir de ces
objets (qu'il a lui même créés ou qu'il a importés de bibliothèques)
décrire son système grâce à la programmation graphique d'un diagramme
de flots de données reliant les divers instruments virtuels. De la même
façon, Rapid, de la société EMULTEK, a pour objectif la création rapide
de simulations d'instruments, d'appareillage ou de systèmes. Il propose
22
également deux espaces de travail. Le premier permet de définir
l'interface graphique de l'application grâce à des bibliothèques d'objets
au comportement prédéfini. Le second espace permet de définir de façon
graphique (mais aussi souvent textuelle) les relations qui lient ces
objets. Cette fois -ci, la programmation du fonctionnement du système
est basée sur des diagrammes d'états concurrents (formalisme de Harel).
Si l'on évalue ces environnements -auteurs à l'aide du cadre
conceptuel MARS, on peut constater que :
Ces environnements proposent de façon explicite une distinction
entre le modèle fonctionnel et la représentation : l'auteur dispose
d'espaces de travail différents au sein desquels il peut se focaliser soit
sur le fonctionnement du système, soit sur l'interface manipulée par
l'auteur ;
Le mécanisme d'association est implicite. Il re pose en général sur
l'utilisation partagée entre les espaces de travail de noms ou de
références d'objets. Ce type de mécanisme, s'il permet aisément la mise
au point d'applications simples, devient rapidement difficile à maîtriser
pour des applications complexes et se prête mal aux exigences
d'évolutivité et de maintenance du logiciel ;
L'usage de chaque environnement reste en général très lié au
type de formalisme qu'il propose pour modéliser la simulation. LabView,
reposant sur une logique de flux, est principalement utilisé dans des
domaines tels que l'électricité, l'hydraulique, etc., alors que l'usage de
Rapid, basé sur une logique événementielle, concerne plutôt la
simulation d'appareillages ou de machines à états finis.
3.5.2. L e s s o l u t i o n s d e p r o d u c t i o n d e s i m u l a t i o n s p é d a g o g i q u e s
La production de s i m u l a t i o n s p é d a g o g i q u e s est plus complexe que
celle de simples simulations. Elle peut reposer sur deux types de
stratégies : l'approche couplée et l'approche intégrée.
D a n s l'approche couplée, la production de la simulation est
explicitement dissociée de celle de l'application de contrôle
pédagogique. Le problème consiste donc à développer un composant de
contrôle pédagogique et à le lier à la simulation proprement dite. Cette
a p p r o c h e p e u t c o r r e s p o n d r e à c h a c u n de s c o n t e x t e s p r é s e n t é s p l u s
haut :
Dans le cas de développement sur mesure , il faut rendre
observable le code du moteur de simulation afin de pouvoir en assurer
le contrôle pédagogique. Il faut rappeler que, dans ce type de contexte,
ces codes de simulation peuvent être complexes et leurs codes sources
protégés : la solution la plus fréquente consiste à demander au
23
propriétaire du logiciel de développer lui-même une interface d'accès au
logiciel ;
Avec des environnements de production de simulation (atelie r de
génie logiciel ou système -auteur), le problème consiste à rendre
automatiquement la simulation accessible à l'aide de mécanismes de
communication standard. C'est la démarche adoptée par des outils tels
que LabView ou Rapid qui proposent des mécanismes de type DDE
(Dynamic Data Exchange).
SAM [ROS 94] est un exemple d'environnement basé sur une
approche couplée. Il divise une simulation pédagogique en trois types
de composants :
La
simulation
proprement
dite
développée
dans
un
environnement spécialisé comme LabView, ou avec un langage de
programmation,
Un ensemble de ressources pédagogiques développées avec des
outils systèmes -auteurs multimédias comme Hypercard et Authorware.
Ces ressources peuvent être des explications, des illustrations, des
évaluations, des animations, etc.
Un cours basé sur l'agencement d'activités pédagogiques selon
un plan d'instruction. Chaque activité requiert l'usage de la simulation
ou l'exploitation d'une ressource pédagogique.
Parmi les inconvénients de ce type de solution, on peut souligner
d'une part que les interfaces de contrôle proposées par l'outil de
simulation influencent nécessairement le type de contrôle possible de la
part de l'outil pédagogique, et d'autre part, que la tâche du concepteur
est compliquée par le fa it qu’il doit se servir de deux environnements
distincts (manque d'homogénéité entre les interfaces utilisateurs).
L'approche intégrée propose, quant à elle, de fournir au sein d'un
même
environnement
de
production
un
ensemble
d'outils
complémentaires permettant de construire la simulation et d'en assurer
l'exploitation pédagogique. Plusieurs projets, dont le nôtre, ont adopté
en parallèle cette approche, aboutissant à des environnements tels que
SimQuest [DEJ 96], SIM -Best [MAR 97] ou RIDES [MUN 95].
Nous constatons alors que la tâche de réalisation de la partie
pédagogique est toujours bien séparée de la construction de la
simulation proprement dite et que l'éditeur de contrôle pédagogique est
toujours un composant à part entière de ces environnements. No u s
laissons de côté pour l’instant tout ce qui concerne les contrôles
pédagogiques, sur lesquels nous reviendrons dans la partie 4.
Pour la production de la simulation, tous les environnements
permettent naturellement de bâtir une interface et de donner u n
comportement au système. Mais ces deux tâches ne sont pas forcément
dissociées et réalisées dans deux espaces distincts. Ainsi dans RIDES,
24
la simulation est construite comme un modèle graphique du système à
simuler ; ce modèle est composé d'objets graphiq u e s a y a n t c h a c u n u n
comportement défini.
Lorsque les environnements proposent deux espaces distincts, l'un
pour la description abstraite du système à simuler (Modèle), l'autre pour
la définition des interfaces (Représentation), on constate le même
défaut que dans les evironnements LabView et Rapid précédemment
étudiés : ils n'assurent quand même pas une réelle étanchéité entre les
deux. Ainsi, dans SimQuest et SIM -Best, les associations entre les
résultats produits dans les espaces Modèle et Représentation se font
de manière implicite en utilisant les mêmes noms de variables dans les
deux espaces. Un effort d'explicitation est toutefois réalisé dans
SimQuest où l'auteur décrit dans un document les variables du modèle
qui pourront être utilisées par l'interface (et par le contrôle
pédagogique).
Pour la production de l'interface, tous les environnements proposent
des objets prédéfinis. L'auteur peut positionner et personnaliser ces
objets par manipulation directe. Il peut en général créer de nouveaux
o b j e t s et gérer les bibliothèques d'objets. L'intégration de composants
externes comme des objets ActiveX ou JavaBeans n'est en général pas
prévue.
En ce qui concerne la modélisation, les environnements peuvent
privilégier une des deux grandes classes de systèmes ( s y s t è m e s
continus ou systèmes à événements discrets). SimQuest par exemple
vise les systèmes continus et offre à l'auteur un formalisme basé sur les
équations différentielles et algébriques. D'autres environnements
permettent de simuler à la fois les deux classes de systèmes. SimBest
permet de combiner un formalisme (basé sur les équations différentielles
et algébriques) pour les systèmes continus et un autre (basé sur les
files d'attente) pour les systèmes discrets. Dans le même objectif,
RIDES propose u n formalisme unique, combinaison d'objets et de
programmation par contraintes. Dans tous les cas, des éditeurs
spécialisés sont fournis.
Ces différents projets ont été menés en parallèle à nos travaux tout
en poursuivant globalement les mêmes objectifs. Une analyse plus
précise de leurs propositions a été réalisée au sein de notre équipe
[COR 99]. Comparativement, nos propres solutions sont davantage
attachées à la séparation des espaces de travail et proposent un espace
de contrôle pédagogique original. Le paragraphe suivant présente nos
solutions de production de simulation, les aspects concernant le
contrôle pédagogique sont abordés dans la partie 4.
25
3 . 6 . Nos propositions
3.6.1. S o l u t i o n s g é n é r a l i s t e s : Melisa et OASIS
Dans l’organisation de TPEC, la responsabilit é technique et
économique du développement des matériaux pédagogiques est confiée
à un ingénieur possédant à la fois les compétences techniques et
pédagogiques sur le produit. Après étude des systèmes existants, TPEC
a pris l’option de développer un nouvel environnement mieux adapté à
leurs besoins spécifiques : auteur manipulant quotidiennement l'outil
informatique, mais n'ayant aucune expérience en développement
logiciel ; simulations utilisables en formation initiale, en auto-formation
et en certificatio n ; délais de production compatibles avec le rythme de
diffusion des produits (environ 3 mois). Les simulations à réaliser
portaient essentiellement sur le fonctionnement, le réglage, la
maintenance et la réparation des instruments produits par HP. Pendant
la première phase de notre collaboration, nous avons ainsi défini
l’environnement auteur Melisa. (La deuxième phase du travail concerne
GeneSimu et sera décrite dans la section suivante.)
Au sein du projet ARIADNE, nous avons été chargés de fournir un
o u til permettant à un enseignant d'adapter ou de créer lui-même des
simulations. Aucune hypothèse ne pouvait être émise sur le type de
simulation à développer, les domaines concernés, le profil des auteurs
ou le type de contrôle pédagogique à assurer lors de la manipulation de
la simulation par l'apprenant.
Nous avons donc développé un deuxième environnement généraliste
OASIS (Outil Auteur pour la Simulation Interactive avec Scénarios)
dont l’objectif principal est de permettre le développement de
simulations diverses en structurant l'approche de l'auteur et en
l'assistant par des outils visuels de façon à réduire le plus possible le
recours à la programmation.
Pour donner une première idée de ce qu’offre ce type d’outils, nous
présentons maintenant les fonctionnalités essentielles d’OASIS, une
description un peu plus détaillée est fournie en annexe.
OASIS met en évidence le modèle MARS en offrant quatre espaces
de travail, bien distincts, chacun étant consacré à l’une des tâches
suivantes :
Création d'un Modèle abstrait de simulation : le système simulé
est défini de façon abstraite, c’est-à-dire indépendamment de l’interface,
par ses propriétés (ou variables), ses méthodes et son comportement
dynamique (états, événements, diagramme d’états,…).
26
Création de la représentation : l'interface manipulable par
l'apprenant est définie par importation d’objets prédéfinis ou définition
de nouveaux objets, et mise en place d’éléments de décor.
Association du Modèle et de l'interface pour obtenir une
simulation « libre » : on définit ici les liens entre les objets d’interface
et le Modèle ; en précisant par exemple qu’une action de l’apprenant
sur tel objet d’interface doit provoquer l’appel de telle méthode du
Modèle ou l’envoi de tel événement au Modèle ; et inversement que le
changement de valeur de telle variable du Modèle doit être répercutée
sur tel objet afin qu’il modifie son apparence visuelle.
Définition d'exercices pour obtenir une simulation « contrôlée » :
L e s e x e r c i c e s q u e n o u s p r o p o s o n s s o n t b a s é s s u r u n e d é marche
relativement simple de résolution de problème : l'apprenant doit
atteindre un but, en parcourant éventuellement un certain nombre de
s o u s -buts intermédiaires ; des contrôles sont également effectués pour
évaluer si l'apprenant ne s'égare pas dans des v o i e s d a n g e r e u s e s o u
sans issue. (Nous détaillerons l'aspect contrôle pédagogique dans la
troisième partie de cet article.)
Une conséquence de cette structuration est de proposer différents
niveaux d'accès en fonction des compétences des enseignants
[COR 98] :
Le premier niveau, qui requiert les compétences techniques
minimales, concerne la conception d'exercices à partir d'une simulation
libre existante ;
Le second niveau, qui demande à l'auteur une approche
davantage structurée, concerne la création de nouvelles simulations
libres à partir de modèles de simulations existants. L'activité de l'auteur
consiste à créer de nouvelles interfaces de manipulation et de
visualisation adaptées à son public spécifique, puis à assurer la mise en
correspondance entre modèles existants et interfaces créées ;
Enfin, le troisième niveau concerne la conception de modèles
abstraits de simulation. Dans la plupart des cas, cette activité requiert
de solides compétences méthodologiques, voire une réelle expérience
de modélisation informatique.
3.6.2. Un exemple de solution spécifique : GeneSimu
Dans le contexte TPEC, nous avons en particulier travaillé avec la
division MediSchool qui s'occupe de la formation aux appareils
médicaux. Les formations existantes se déroulent en sessions de trois
jours proposant l'utilisation de documents papier, de vidéos et de
manipulation directe des équipements. La volonté de MediSchool était
de remplacer ces manipulations directes par l'utilisation de simulations à
27
l'aide desquelles l'apprenant devrait être capable : (1) de diagnostiquer
un dysfonctionnement de l'appareil, et (2) d'effectuer la réparation en
réglant ou en remplaçant les composants responsables.
Après analyse, nous avons pu établir les points suivants :
La modélisation de la réparation d es différents équipements obéit
à des stratégies similaires, alors que la modélisation du diagnostic est
spécifique à chaque équipement ;
La complexité des systèmes implique la saisie de nombreuses
informations (plusieurs centaines) lors de la modélisation d u s y s t è m e e t
rend très relative la maîtrise de l'application par l'auteur ;
La possibilité offerte à l'auteur de définir lui-même l'interface de
l'apprenant ne garantit pas une homogénéité des applications produites.
Prenant en compte ces remarques, nous avons décidé de développer,
pour la réalisation des applications de dépannage, un environnement
spécifique, nommé GeneSimu, allégeant considérablement le travail des
auteurs.
Pour créer l'application de dépannage avec GeneSimu, l'auteur définit
à l'aide de formulaires les caractéristiques du système : éléments actifs,
conditions de montage/démontage, dépendances fonctionnelles ou
mécaniques des éléments, principaux dysfonctionnements et procédures
de réparation associées.
La simulation de dépannage est ensuite entièrement générée
automatiquement, à partir d'un ensemble de règles préétablies
concernant aussi bien l'interface que les règles de contrôle
pédagogique. L'auteur peut ensuite très aisément personnaliser
l'interface de son application en remplaçant par exemple les symboles
représentant les éléments par des photographies (cf. Figure 5).
Figure 5 . Interface générée automatiquement et interface améliorée
A l'aide de la simulation de dépannage obtenue, l'apprenant peut monter
ou démonter des éléments , effectuer des tests ou des réglages,
28
échanger des composants défectueux. La cohérence entre la simulation
de diagnostic et la simulation de dépannage est assurée et l'apprenant
peut à volonté passer de l'une à l'autre.
Nous allons maintenant aborder ce qui différencie essentiellement les
simulations ordinaires des simulations pédagogiques, c’est-à-dire le
contrôle des activités de l’apprenant.
4 . C ONTROLE PEDAGOGIQUE DE SIMULATIONS
4 . 1 . Définition du contrôle pédagogique
Le terme de contrôle, o u s u i v i , p é d a g o g i q u e recouvre de
nombreuses réalités bien différentes. Essayons tout d'abord de préciser
cette notion.
De façon très générale, un contrôle pédagogique peut être réalisé par
le formateur, par le logiciel pédagogique ou de façon couplée par le
logiciel et le formateur. Nous discutons ici du contrôle fait par le
logiciel et nous évoquerons plus loin l'exploitation des résultats de ce
contrôle par un formateur.
La simulation peut être utilisée à différents moments d'un processus
de formation : découverte, acquisition, évaluation. Selon les cas, le
contrôle pédagogique peut être mis en œuvre pour :
- fournir à l'élève un guidage et une assistance appropriés en cours
d'apprentissage,
- donner à l'élève un bilan de son savoir-faire, avec des
remédiations possibles,
- faciliter le suivi par le formateur en lui donnant un compte-rendu
de l'activité de l'élève,
- obtenir une évaluation synthétique du travail de l'élève.
Les moments pédagogiques conditionnent la nature du contrôle à
effectuer ainsi que sa visibilité par l'élève et par le formateur.
Deux grands types de contrôle sont envisageables, selon que l'on
s'intéresse à la manière dont l'élève enchaîne les activités ou bien à sa
façon d'aborder une activité donnée.
4.1.1. Contrôle sur l'enchaînement des activités
Le suivi de l'enchaînement des activités d'un élève peut se limiter à
une simple historisation de cet enchaînement (consultation de tel
document hypermédia pendant tant de temps, puis travail sur telle
29
simulation,…). C'est par exemple ce que proposent certains outils
d 'intégration pour la formation à distance comme Learning Space. Au vu
de cet historique et après analyse de celui-ci, le formateur pourra
éventuellement conseiller l'élève sur la façon de poursuivre ou de
compléter son parcours.
Le parcours de l'élève peut aussi être analysé automatiquement et au
fur et à mesure de son déroulement. Ceci suppose que des règles
pédagogiques d'orientation soient prédéfinies et embarquées dans le
système de suivi, et qu'elles soient activées pour indiquer à l'élève
quelles activ ités lui sont maintenant suggérées, conseillées, voire
imposées. Ces critères d'orientation peuvent éventuellement prendre en
compte les résultats obtenus par l'élève au cours d'activités proposées
sous forme de tests. Le cheminement de l’élève est ainsi partiellement
guidé au fur et à mesure de sa progression.
De tels contrôles ne sont naturellement pas spécifiques aux
simulations, puisqu'ils concernent l'enchaînement des activités et ne se
préoccupent pas de la nature de ces activités. Néanmoins certains
groupes de recherche ont réfléchi à la constitution de modules
d'enseignement basés sur des simulations ; ils ont défini à la fois des
activités -types sur des simulations et la gestion de leur enchaînement.
Ils offrent alors des outils pour spécifier les règles régissant
l'enchaînement de ces activités, et des outils assurant la mise en œuvre
de ces règles pendant le travail de l'élève afin de guider son
cheminement. Ces outils sont plus ou moins simples d'emploi et donc
plus ou moins accessibles aux formateurs, selon qu'ils permettent de
décrire un enchaînement sous une forme centralisée comme dans RIDES
ou sous une forme beaucoup plus répartie dans les activités comme
dans SimQuest.
I n t é r e s s o n s -nous maintenant à l'autre type de contrôle, "plus fin",
v i s a n t à suivre la progression de l'élève à l'intérieur d'une activité
(exercice) basée sur la simulation.
4.1.2. C o n t r ô l e d e r é s o l u t i o n d ' e x e r c i c e
De nombreux travaux concernent le suivi de l'élève au cours d'une
activité donnée, notamment pendant la résolution de pro blèmes. Un tel
suivi nécessite des connaissances sur le domaine et peut utiliser des
connaissances sur l'élève, ain si q u e d es co n n aissan ces su r les
décisions et le guidage pédagogiques.
Plusieurs approches existent :
Une a p p r o c h e sur mesure : elle consis t e , é t a n t d o n n é u n
domaine et une spécification pédagogique précise, à développer une
30
solution ad hoc, qui peut être plus ou moins sophistiquée mais qui ne
vise aucune généralité.
Une a p p r o c h e verticale : elle consiste, étant donné un domaine
précis d'apprentissage, à donner à la machine un maximum de
connaissances sur ce domaine et à fournir un résolveur de problèmes, si
possible doté de capacités d'explications, de mécanismes de génération
d'aides, et d'un système de génération d'énoncés [BAL 97]. Le système
se chargera ainsi de poser des problèmes à l'élève, de trouver les
solutions, de comparer la solution de l'élève à ses propres solutions, et
d'expliquer sa démarche. Une telle approche permet d'atteindre
davantage de généralité mais elle exige de bien cibler le domaine et
nécessite de gros moyens de développement.
Comme nous ne souhaitions pas nous limiter à un domaine privilégié
d ' e n s e i g n e m e n t , n o u s a v o n s a d o p t é u n e a p p r o c h e horizontale,
indépendante du domaine, nous permettant de :
p r o p o s e r d e s a c t ivités -types sur la simulation,
spécifier la nature des contrôles pédagogiques types associés,
fournir aux formateurs les outils permettant de définir facilement
dans ce cadre le contenu de leurs exercices et contrôles,
et fournir les systèmes opérationnels permettant aux élèves
d'exploiter les exercices et gérant les contrôles pédagogiques.
Cette approche permet d'atteindre un certain degré de généralité
sans devoir inclure dans le système trop d'expertise puisque celle -ci
pourra être spécifiée (à l'intérie ur d'un certain cadre) par l'auteur de
chaque exercice.
4 . 2 . Activités-types sur une simulation et contrôle pédagogique
associé
I n t é r e s s o n s -nous maintenant aux activités -types qu'il est possible
de définir sur des simulations, et au contrôle pédagogique à mettre en
œuvre. Après un bref tour d'horizon des propositions de groupes de
recherche ayant adopté une approche similaire à la nôtre, nous
présenterons les activités d'exercices que nous proposons et le contrôle
pédagogique correspondant.
4.2.1. T y p o l o g i e d e s a c t i v i tés-types sur la simulation
Un éventail varié d’activités -t y p e s p e u t ê t r e p r o p o s é s u r u n e
simulation. Nous pouvons les regrouper de façon synthétique en :
Démonstration : la simulation est utilisée pour informer sur la
composition, la structure et le comportement du système simulé. Elle
31
sert aussi de support pour démontrer des procédures opératoires
(réglage de contrôles, configurations, dépannage,…). Une vérification
des connaissances données par la démonstration peut être proposée
sous forme de QCM utilis ant la représentation du système simulé ou en
demandant à l’élève de reproduire la démonstration. Le contrôle
pédagogique est alors réalisé par comparaison avec la démonstration
elle -même.
Exploration libre, sans contrôle pédagogique
Exploration motivée par un QCM : l'apprenant doit manipuler le
système pour trouver les réponses aux questions. Le contrôle
pédagogique porte uniquement sur les réponses au QCM. L'exploration
peut être guidée par la suggestion d'un ensemble d'états à explorer.
Exercice de prédiction : étant donné l'état initial d'une simulation
ou certaines conditions de fonctionnement, l'apprenant doit prédire les
valeurs qu'auront certaines variables à un moment donné. Le contrôle
peut être automatisé ou bien effectué par l'élève lui-même qui fait
tourner la simulation et compare les résultats avec ses réponses.
Exercice à but : à partir d'un état initial, l'apprenant doit manipuler
la simulation pour atteindre l'état final demandé. L'exercice peut être
plus ou moins complexe selon l'objectif fixé : régler un contrôle, réaliser
une configuration, exécuter une procédure opératoire, réparer le
système … L'auteur peut éventuellement fixer des contraintes que
l'élève devra respecter pendant la manipulation de la simulation (par
exemple, garder une v ariable à l'intérieur d'une certaine plage de
valeurs). Le contrôle pédagogique porte sur l'objectif final (atteint ou
non) et les contraintes (respectées ou non).
Ces activités -t y p e s s ' i n s c r i v e n t d a n s d e s d é m a r c h e s p é d a g o g i q u e s
p l u s g l o b a l e s e t s o n t s o u v ent réparties selon les moments de
l'apprentissage. Notons que certains contrôles nécessitent de surveiller
l'action de l'élève sur la simulation, d'autres non.
4.2.2. Les activités OASIS et leur contrôle pédagogique
Les activités -t y p e s q u e n o u s p r o p o s o n s d a n s O A SIS font partie de
la catégorie Exercice à but. Partant du constat que le contrôle
pédagogique généralement proposé dans ce type d'exercice est
relativement restreint (objectif final atteint ou non, contraintes
respectées ou non), nous avons voulu l'étoffe r en nous intéressant à la
façon dont l'élève progresse vers l'objectif. Nous avons donc essayé de
définir un contrôle pédagogique type pouvant être mis en œuvre sur ce
genre d'exercice.
Rappelons que la démarche suivie nous impose d'être capable de
fournir des outils permettant à un auteur de « remplir le moule » d e c e
contrôle type pour un exercice donné, ainsi que des systèmes
32
permettant d'exploiter les exercices avec les contrôles pédagogiques
ainsi définis. D'autre part, nous souhaitions que le contrôle t y p e
proposé soit pédagogiquement intéressant et nous nous sommes
appuyés pour cela sur une démarche pédagogique concrète : l'activité
de suivi d'un enseignant lors de la réalisation d'une expérimentation (de
type travaux pratiques) par les élèves. En effet, une expérimentation
donne un objectif à atteindre, tout comme un exercice à but.
L'enseignant ne s'intéresse alors de façon continue ni aux intentions, ni
aux comportements des élèves. Sa démarche est de vérifier, le plus
souvent possible, l'état d'avancement de l'expérimentation en cours, et
de réagir en cas de nécessité (donner des indications, stopper des
manipulations dangereuses, faire repartir des élèves arrivés dans une
impasse,…) [PER 96a].
Afin de nous rapprocher de cette démarche pédagogique concrète,
nous demandons à l'auteur de définir à la fois les données de l'exercice
(situation initiale, objectif à atteindre), les étapes de résolution
pertinentes et les situations particulières à observer (erreurs typiques,
dangers, impasses,…). Le contrôle pédagogique consiste alors à vérifier
la réussite de l’élève, à suivre sa progression à l’intérieur des étapes
intermédiaires de résolution et à détecter la survenue de situations
particulières.
Nous définissons ainsi un exercice OASIS par :
Une situation initiale, devant laquelle sera placé l'élève au
démarrage de l'exercice (état initial de la simulation et consigne de
l'exercice).
Une séquence d'étapes à franchir par l'élève ; la dernière étape
correspond à l'objectif final à atteindre par l'élève. Une étape est décrite
par la situation à atteindre, la consigne et la réactivité associée (aide
disponible, retours d'information et actions à réaliser en cas d'échec ou
de réussite).
Un ensemble de situations particulières à surveiller. Ce peut être
le cas d e s i t u a t i o n s o b t e n u e s s u i t e à d e s e r r e u r s t y p i q u e s , d e s
situations d'impasse, des situations de danger ou au contraire des
situations dénotant une approche particulièrement soignée de la
question et que l'on souhaite féliciter… Ces situations (appelées
contrôles) peuvent être à surveiller pendant toute la durée de l'exercice
(contrôle global) ou seulement à l'intérieur d'une étape particulière
(contrôle lié à une étape). Il convient de décrire la situation à surveiller
et la réactivité associée (conduite à tenir lorsque cette situation se
produit).
En fonction du moment pédagogique, ces exercices peuvent être
proposés selon deux modes de travail, le mode apprentissage et le mode
évaluation. Nous décrivons pour chacun de ces modes, le déroulement
de l'exerc ice et du contrôle pédagogique.
33
Le mode apprentissage : on accompagne l'élève dans sa
progression, étape par étape. L'élève reçoit la consigne globale de
l'exercice, puis la consigne de la première étape. Une aide pertinente
pour cette étape est accessible (si elle a été prévue par l'auteur).
Lorsqu'il pense avoir réussi l'étape, l’élève demande la vérification de
son travail et reçoit l’évaluation correspondante. Dès qu'une étape
intermédiaire est réussie, la consigne de l'étape suivante est affichée.
L'élève peut à tout moment recommencer une étape ou passer à la
suivante (le système plaçant alors la simulation comme s’il venait de
réussir l’étape). S'il atteint une situation surveillée, le retour
d'informations et l'action prévus sont alors mis en œuvre.
Le mode évaluation : l'élève résout globalement l'exercice en
temps limité, sans aide ni retour d'information. Seule la consigne
globale de l'exercice est fournie au départ. Pendant que l'élève travaille,
le système de contrôle pédagogique vérifie la progression selon les
étapes attendues, détecte la survenue de situations à surveiller et
établit un rapport sur ces différents points. L’élève ne reçoit aucune
information en cours de route, mais seulement une évaluation globale
lorsqu’il demande la vérification finale de son travail.
Remarquons qu'outre les exercices définis ci-d e s s u s , n o u s
proposons sur toute simulation un mode d'exploration libre, sans
contrôle pédagogique. L'existence de ce mode permet notamment à
l'élève de tester le comportement de la simulation et de se familiariser
avec son interface avant de commencer les exercices proposés.
4 . 3 . Production des exercices à but et de leur contrôle
Nous nous intéressons ici aux environnements prenant en charge la
production et la mise en œuvre des exercices à but et de leur contrôle
pédagogique. Remarquons bien que ces environnements possèdent
forcément deux parties. L'une (environnement auteur) permet la création
de l'exercice et du contrôle pédagogique, l'autre (environnement
apprenant) permet la mise en œuvre de l'exercice et l'exécution des
contrôles pédagogiques précédemment définis par l'auteur.
4.3.1. L e s e n v i r o n n e m e n t s d e c o n t r ô l e p é d a g o g i q u e
Reprenons parmi les environnements évoqués précédemment, ceux
qui permettent de construire des exercices à but sur des simulations :
SAM [ROS 94], RIDES [MUN 95] et SimQuest [DEJ 96].
Dans l'environnement SAM, la construction d'un exercice est faite à
l'aide d'un éditeur graphique de programmes incluant des commandes
agissant sur la simulation : consulter ou changer la valeur d'une
34
variable, activer ou désactiver la surveillance sur une variable,
consulter ou changer l'état de la simulation. La tâche de construction
d'un exercice est donc convertie en une tâche de programmation, dont
on sait toutefois qu'elle est difficile pour les auteurs ciblés (formateurs
non spécialistes en programmation).
L'environnement RIDES est basé sur des interactions élémentaires
(régler un contrôle, afficher un texte, signaler un objet à l'écran,…).
Pour créer un exercice l'auteur peut composer (sous forme d'arbre) ces
interactions élémentaires grâce à un éditeur d'enchaînement. Il peut
également se servir du générateur pour créer un exercice sur un des
types fournis. Les exercices à but proposent des objectifs simples à
l'élève, comme régler tel contrôle, réaliser telle configuration…. La
génération est réalisée à partir des connaissances extraites
automatiquement de la simulation construite, et d'informations
complémentaires données par l'auteur (démonstration d'une séquence
d'actions,…). Le système de contrôle pédagogique est alors capable de
vérifier que les actions de l'élève et leur ordonnancement correspondent
à la démonstration disponible.
Pour créer un exercice en fixant des objectifs plus complexes, l'auteur
doit le décrire comme un enchaînement d'exercices élémentaires et
d'interactions de base.
L'environnement SimQuest permet de définir un exercice à but en
spécifiant la situation initiale, la situation à atteindre, les contraintes à
respecter pendant la manipulation, la consigne et les retours
d'information utiles. La situation initiale est décrite en donnant les
valeurs de chaque variable de la simulation. La situation à atteindre et
les contraintes sont précisées en indiquant pour chaque variable de la
simulation la plage de valeurs acceptable. Le contrôle pédagogique
permet alors d'évaluer la réussite de l'objectif et le respect des
contraintes durant l'exercice.
4.3.2. L ' e n v i r o n n e m e n t O A S I S d e c o n t r ô l e p é d a g o g i q u e
Comme nous l'avons dit plus haut, un exercice OASIS se définit
comme une situation initiale, une séquence d'étapes à franchir et un
ensemble de situations particulières à surveiller (soit pour une étape
particulière, soit pendant toute la durée de l'exercice).
Le processus de développement préconisé permet d'obtenir d'abord
une simu lation dite libre (sans contrôle pédagogique), avant de définir
les exercices. Nous avons saisi cette opportunité pour faciliter la
description des différentes situations caractérisant un exercice. En
effet, l'auteur va pouvoir spécifier une situation simp lement en
manipulant la simulation libre (comme le ferait un élève) jusqu'à
obtention de cette situation et en la "photographiant" (par un simple
35
clic sur un bouton). Le système OASIS mémorise alors automatiquement
les valeurs caractérisant cette situation.
L’auteur peut de plus ensuite expliciter dans quelle mesure une
situation doit être considérée comme correcte lorsqu'elle est proche de
la situation à atteindre (telle que photographiée). Il fait afficher les
valeurs automatiquement mémorisées et peut élargir les réponses
acceptables en précisant par exemple que la valeur d’une certaine
propriété est indifférente, ou que la valeur d’une autre propriété doit
être comprise dans un certain intervalle (alors que la photographie
imposait une valeur précise contenue dans cet intervalle).
Un des intérêts de cette définition par "photographie" est la
simplicité de mise en œuvre par l'auteur de l'exercice (qui n'est pas
forcément l'auteur de la simulation). De plus, cette façon de procéder
permet à l'auteur de réaliser l'exercice (situation initiale, objectif de
l'étape 1,…) comme le ferait l'élève, et donc de garantir sa faisabilité.
L’auteur spécifie également les différentes instructions et retours
d’informations qu'il souhaite donner à l’élève :
- La consigne glo bale, le retour d'information final (en cas d'échec
ou de réussite) et éventuellement le temps limite imposé pour faire
l'exercice (en mode évaluation).
- Pour chaque étape, la consigne, l'aide disponible, les retours
d'informations (en cas d'échec ou de réussite).
- Pour chaque situation à surveiller, le retour d'information à donner
lorsqu'elle est atteinte.
L'auteur dispose d'une vue chronologique des informations qui
pourront être diffusées à l'élève.
Un gestionnaire d'exercices permet de créer, de tester, de modifier et
de supprimer des exercices portant sur une simulation.
L'exécution de ces exercices (test par l'auteur ou exécution par
l'élève) est prise en charge par l'environnement apprenant d'OASIS.
Diverses expérimentations de cet environnement de contrôle
pédagogique ont été réalisées. Nous les décrirons dans la section 5.
4 . 4 . Vers l'indépendance de l'environnement de contrôle pédagogique
Nos expériences nous ont permis de constater que le processus de
définition d'exercices est :
- essentiel pour l'intégration pédagogique des simulations dans
une formation,
- postérieur à la réalisation de la simulation,
- accessible à un formateur sans compétence en programmation.
36
Nous avons donc souhaité rendre l'environnement de contrôle
p é d a g o g i q u e l e p l u s i n d é p e n d a n t p o s sible de la simulation ou plutôt de
la façon dont la simulation est réalisée.
Comme nous l'avons évoqué précédemment, cette indépendance
permet d'utiliser une simulation existante (quel que soit l'environnement
avec lequel elle a été créée) et d'y greffer exercice et contrôle
pédagogique. De plus, puisque l'environnement de contrôle
pédagogique n'est plus lié à l'environnement de réalisation de la
simulation, il devient alors possible de greffer sur une même simulation,
différents types d'exercices et de contrôles parmi ceux que nous avons
précédemment listés. Enfin, cette indépendance pourra favoriser un
contrôle pédagogique distant.
Nous avons donc réfléchi sur la manière d'obtenir cette
indépendance. Nous reprendrons ici la terminologie proposée par le
groupe «Communication Outil/agent» appartenant au comité LTSC
(Learning Technology Standards Committee) [IEE 98]. Ce comité,
sponsorisé par IEEE, a pour objectif général de faciliter le
développement, la diffusion, la maintenance et l'interaction des
s y s t è mes d'apprentissage / enseignement par ordinateur. Pour cela,
différents groupes de travail développent des standards techniques,
des guides et des recommandations pratiques. Le groupe «
Communication Outil/agent » travaille sur l’interaction entre des outils
logiciels (logiciels de bureautique, d’EAO,…) et des agents
d’instruction qui guident l’élève dans l’utilisation de ces outils
(donnent des objectifs, guident, expliquent, …).
D’après leurs premiers résultats, pour qu’un protocole de
communication utile puisse être établi entre un outil et un agent
d’instruction, l’outil doit être :
- i n s p e c t a b l e : il doit pouvoir répondre aux demandes d’information
(état courant, valeurs de propriétés,…) en provenance de l’agent
d'instruction
- observable : il doit être capable de signaler automatiquement des
événements (modifications de valeurs, d’états,…) qui surviennent chez
lui
- scriptable : il doit disposer d’un langage de commande
permettant à l’agent d’instruction de modifier son état (état, valeurs des
propriétés, envoi d’événements…).
Pour poursuivre ce travail dans toute sa généralité, le groupe
« Communication Outil/agent » s'interroge maintenant sur les standards
de référence des objets contenus dans les outils et sur les messages
que doivent pouvoir échanger outil et agent d’instruction. La
problématique est pour nous plus réduite puisque le logiciel de contrôle
pédagogique (notre agent d'instruction) doit communiquer avec une
simulation et non avec n'importe quel outil logiciel. Nous avons donc
37
cherché à expliciter ce que nous devons exiger d'une simulation pour
qu'elle soit inspectable, observable et scriptable par une application de
contrôle pédagogique.
Notre démarche consiste tout d'abord à identifier les services
minimums que doit rendre la simulation puis à proposer une architecture
générale pour le couplage entre une application de contrôle
pédagogique et une simulation.
4.4.1. Identification des services
Il s'agit d'identifier précisément les services que doit obligatoirement
rendre une simulation pour que son utilisation puisse être contrôlée
pédagogiquement. Pour définir ces services, nous avons analysé les
besoins du contrôle pédagogique d'OASIS ainsi que les besoins liés aux
contrôles des différents exercices types proposés sur les simulations.
Les services s ont regroupés sous les quatre rubriques : référence,
inspectabilité, observabilité, scriptabilité.
Concernant les services de référence, la simulation doit au moins
fournir :
un service donnant la liste des variables, des événements, des
états et des obje ts inspectables de la simulation.
Concernant la scriptabilité, nous pensons que la simulation doit
offrir au minimum :
des services autorisant ou non l'accès à la simulation,
des services de mise en marche, pause ou arrêt de la simulation,
un service qui permet de modifier la valeur d’une variable, d'un
état ou de générer un événement,
des services portant sur l'interface de la simulation (mise en
évidence ou non, verrouillage / déverrouillage d'un élément
d'interface,…).
Concernant l'inspectabilité, la s imulation doit offrir au minimum :
un service qui, étant donné le nom d’une variable ou d'un état,
retourne sa valeur.
Concernant l'observabilité, la simulation doit offrir au minimum :
un service permettant la notification des événements.
N o u s p e n s o n s qu'il n'est pas indispensable d'imposer à la simulation
d'offrir des services garantissant l'observabilité des variables et des
états. En effet à partir du moment où les valeurs des variables et des
états sont inspectables, il est possible de reconstruire un service
38
permettant la surveillance (l'observabilité) de ces valeurs. Il suffit en
effet d'interroger régulièrement la simulation sur les valeurs de ses
variables / états significatifs, et de détecter les changements survenus.
4.4.2. P r o p o s i t i o n d ’ u n e a r c h i t e c t ure
Pour le couplage entre une application de contrôle pédagogique et
une simulation, nous proposons une architecture client-serveur où le
serveur est basé sur la simulation, et où le client est l'application de
contrôle pédagogique. La relation client serveur a deux paramètres : le
protocole utilisé par l’application de contrôle pédagogique pour
demander les services à la simulation et le protocole utilisé par la
simulation pour fournir ces services.
Le client, c'est-à-dire l'application de contrôle pédagogique, doit :
expliciter les services demandés à la simulation,
faire connaître le protocole de communication utilisé pour
demander les services,
être capable de réagir lorsqu'elle est informée par le serveur de
changements intervenus sur la simulation.
Le serveur est chargé de fournir les services requis de la simulation
pour l’application de contrôle pédagogique. Ce serveur comprend :
La simulation proprement dite.
Un adaptateur de services, capable d’adapter et d’étendre (si
possible) les services fourn is par la simulation aux services requis par
le contrôle pédagogique. Pour une simulation donnée, les services
attendus par le contrôle pédagogique peuvent en général se répartir en
deux classes ; d’une part, les services fournis tels quels par la
simulation (à la syntaxe près), un fichier (MappingData) permet alors
d'établir la correspondance exacte ; d’autre part, les services qui seront
reconstruits par l'adaptateur à partir de services attendus plus
élémentaires.
Un adapteur de communications et différe n t s c o n n e c t e u r s
capables d'assurer la communication entre l'adaptateur de services et la
simulation, avec le protocole utilisé par celle -ci.
Pour constituer ce serveur, nous fournissons :
l'adaptateur de services. Il s'appuie sur le fichier de
c o r r e s p o n d a nce (MappingData) propre à chaque couple (contrôle
pédagogique, simulation).
l'adaptateur de communications, et les différents connecteurs. Ils
dépendent du protocole utilisé par la simulation.
39
De façon concrète, étant donnée une simulation fournissant le s
services minimums en utilisant un certain protocole, et dans l'objectif
de fournir un contrôle pédagogique sur cette simulation, il sera
nécessaire de :
créer le fichier de correspondance propre au couple (contrôle
pédagogique, simulation).
choisir l'adaptateur de communication et les connecteurs
correspondant au protocole utilisé par la simulation (à condition qu'ils
soient déjà disponibles).
Nous avons mis en œuvre ces propositions pour contrôler
pédagogiquement une simulation écrite en Java et offrant les services
minimums en utilisant les sockets. De plus, cette réalisation nous a
permis de tester l'exploitation à distance de tels contrôles pédagogiques
[COR 99].
5 . EXPERIMENTATIONS DE MARS
Plusieurs expérimentations se sont déroulées dans des contextes
industriels et académiques. Nous commencerons par une brève
description de chacune d'elles. Nous présenterons ensuite une
synthèse des conclusions que nous pouvons en retirer.
5 . 1 . Les expérimentations en milieu académique
Deux expérimentations se sont déroulé es dans le cadre du CAFIM
(Centre d'Auto Formation et d'Innovation Multimédia) qui propose aux
étudiants de l'Université Joseph Fourier un ensemble d'activités
d'autoformation et d'autoévaluation dans des disciplines scientifiques.
D i v e r s e n s e i g n a n t s a p p o rtent leur contribution en prenant sur leur
temps disponible pour travailler à la définition de supports appropriés.
Une première expérimentation [COR 98] a impliqué sept enseignants
de disciplines variées (physique, chimie, géologie, automatique) qui se
s ont portés volontaires pour participer à l'élaboration de simulations
dans leur spécialité. Quatre d'entre eux ne disposait d'aucune
connaissance en programmation, deux avaient une pratique de
développement d'EAO, et le dernier possédait certaines compétenc e s
méthodologiques (approche par objets). Après avoir suivi une
formation de douze heures sur l'environnement, ils ont chacun spécifié
et réalisé (avec plus ou moins d'aide de notre part) une application.
Une deuxième expérimentation a eu lieu dans un mo dule optionnel de
maîtrise d'informatique. Les étudiants ont bénéficié d'une formation à
40
OASIS. Ils se sont ensuite attaqués à une réalisation sur un thème
imposé dans le cadre de séances de travaux pratiques.
Un autre type d'expérimentation fait l'objet d'un travail de DEA en
Sciences Cognitives. Il s'agit cette fois d'une analyse de la façon dont
l'outil OASIS est perçu et utilisé. Quarante-quatre sujets de différentes
origines (étudiants de niveaux variés, chercheurs et enseignants) ont
é t é o b s e r v é s p e n dant diverses tâches avec OASIS.
5 . 2 . Les expérimentations en milieu industriel
Notre collaboration avec la société CORYS ne peut pas vraiment être
considérée comme une expérimentation. L'étude de leur processus de
développement a conduit à notre proposition du modèle MARS et d'une
méthodologie de développement. Une validation a pu être faite dans le
développement d'une simulation d'un alternateur, application qui a reçu
le premier prix de la catégorie Formation des meilleures réalisations
multimédia (ITE'96).
Notre contexte principal a été le TPEC, centre européen de formation
interne de l'entreprise Hewlett-Packard, situé à L'Isle d'Abeau, et plus
particulièrement sa division MediSchool, chargée de la formation sur les
équipements médicaux.
Comme nous l'avons déjà évoqué plus haut, MediSchool voulait
utiliser des simulations à l'aide desquelles l'apprenant devrait être
capable de diagnostiquer un dysfonctionnement de l'appareil, et
d'effectuer la réparation en réglant ou en remplaçant les composants
r e s p o n s a b le s .
Durant l'année 1997, quatre simulations d'équipements médicaux
(défibrillateur, électrocardiographe, etc.) ont été développées par les
formateurs de MediSchool, puis testées en situation réelle. De façon
concrète, les auteurs ont eu à développer deux applications bien
distinctes pour chaque équipement simulé : l'une (la simulation du
diagnostic) s'intéresse à la façon dont doit être diagnostiqué l'état de
l'équipement alors que l'autre (la simulation du dépannage) concerne les
aspects propres à la réparation.
Pour créer la simulation du diagnostic, le formateur utilise
l'environnement Melisa. Il doit (1) modéliser le comportement prévisible
du système en fonction de chaque cas de dysfonctionnement, (2)
spécifier l'interface de l'apprenant et enfin (3) établir les relations entre
le modèle et l'interface.
41
Le développement des simulations de dépannage a été effectué avec
l'outil spécifique GeneSimu. La majeure partie du temps passé par les
auteurs concerne l'analyse précise du problème, la collecte des
informations mais aussi la personnalisation de l'interface produite
automatiquement (ajout de photographies, de vues différentes du même
élément, etc.)
De façon générale, les résultats sont encourageants. Une analyse
plus détaillée est fournie dans [PER 98a]. Selon l'avis de MediSchool,
les développements des simulations auraient été impossibles sans les
outils fournis. Aujourd'hui, un ou deux mois sont nécessaires au
développement d'une simulation pédagogique complète (réparation +
diagnostic), le temps étant réparti entre l'analyse précise du problème
(2/3 du temps total) et la production proprement dite de la simulation
(1/3 du temps total). Les simulations ont été testées durant cinq
sessions différentes auprès d'environ 50 stagiaires en situation réelle
d e formation (personnels techniques, mais également clients de
l'entreprise).
5 . 3 . Bilan des expérimentations
Nous allons essayer de faire une synthèse des résultats obtenus par
nos différentes expérimentations. (Pour simplifier, nous utiliserons le
mot OASIS pour désigner les deux outils généralistes, aussi bien
l'environnement OASIS proprement dit, que l'environnement Melisa.)
Nous commencerons par les aspects qui concernent la réalisation de
simulations.
L'approche fortement structurante de la démarche imposée
(conception séparée du modèle, de l'interface et du contrôle
pédagogique) a été diversement appréciée. Bien acceptée par les
personnes n'ayant pas d'expérience préalable dans le développement
d'applications, elle est en revanche apparue aux autres comme une
contrainte initialement plutôt gênante. Tous ont ensuite cependant
reconnu que la séparation des différents aspects rendait nettement plus
aisées les modifications.
L'activité de conception des modèles abstraits est apparue comme la
plus complexe. Elle requiert une forte capacité de modélisation et
d'abstraction, qui ne peut être réellement acquise que grâce à une
formation spécialisée et une certaine pratique. Dans l'expérience avec
les enseignants, compte tenu de leurs disponibilités réduites en temps
et de leur niveau de pratique, nous avons dû, dans la plupart des cas,
réaliser nous même les modèles abstraits sous leur contrôle. Ce constat
a d'ailleurs été fait aussi par d'autres [VAN 96]. Dans l'expérience TPEC,
la difficulté est venue cette fois plutôt du nombre de paramètres
42
(plusieurs centaines) à prendre en compte pour atteindre le degré de
réalisme souhaité.
Lorsque les applications sont globalement assez semblables, comme
dans le cas de TPEC, l'usage d'un outil très généraliste s'avère alors un
p eu moins aisé. Afin de prévenir un possible découragement des
formateurs, nous avons établi un ensemble de procédures et de règles
pour l'utilisation de l'environnement dans le cas précis de ce type de
simulation. Cette approche, qui a permis le développement effectif des
applications de diagnostic, implique de fait un usage de
l'environnement souvent réduit à une faible partie des fonctionnalités
proposées, et un certain niveau de pratique des auteurs.
Comparativement aux simulations de diagnostic, le développement
des simulations de dépannage a été fortement accéléré par l'utilisation
de l'outil spécifique GeneSimu. Ceci confirme l'avantage d'un outil
spécialisé lorsque le contexte s'y prête. Toutefois, ceci tendra à
restreindre la variété des applications développées et limitera de ce fait
l'intégration pédagogique des simulations. La question est alors de
produire rapidement un outil spécialisé pour une famille de simulations.
Pour cela, nous travaillons actuellement à la conception d’un framework
b a s é s u r MARS [COR 99].
L'existence d'objets prédéfinis bien adaptés s'est avérée être un
facteur important. Lorsqu'un nouveau domaine de spécialité est abordé,
l'auteur manque au début d'objets spécifiques à ce domaine. Nous avons
ainsi été obligés de développer quelques objets complémentaires à la
demande de certains enseignants pour leur permettre de réaliser leur
application en un temps raisonnable. Cet effort diminue avec la
pratique, puisque les nouveaux objets peuvent être facilement intégrés
dans une bibliothèque personnelle.
Passons maintenant à des résultats qui concernent plus
spécifiquement l'environnement OASIS de contrôle pédagogique.
Nous avons relevé une bonne adéquation du type d'exercice et de
contrôle proposé par rapport à l'usage pédagogique att e n d u d e s
simulations, la facilité technique de création des exercices, ainsi que la
bonne acceptation des exercices et du contrôle pédagogique lors de
leur mise en œuvre par les élèves.
Résultat plus étonnant, la définition d'exercices à buts sur la base d e
simulations libres déjà créées ne s'est pas avérée facile pour les
enseignants du CAFIM. Non pour des raisons techniques,
l'environnement permettant aisément la construction d'exercices, mais
p o u r d e s r a i s o n s p é d a g o g i q u e s , l e s e n s e i g n a n t s é p r o u v a n t d e réelles
difficultés à imaginer une exploitation pertinente des simulations : quels
buts fixer aux élèves ? Comment enchaîner les exercices ? etc. A cette
occasion, nous avons pu constater de la part des enseignants une
43
véritable réflexion sur leur pédagogie . Nous avons été de prime abord
surpris par la visible difficulté qu'avaient les enseignants à imaginer des
exercices. Après réflexion, nous pensons que le cadre de
l'expérimentation, basé sur la participation d'enseignants volontaires
pour expérimenter un outil de production, a beaucoup influé sur ce
résultat. En effet, si les enseignants imaginaient facilement des
simulations dans leur domaine, ils ne s'étaient pas encore réellement
posé le problème de leur utilisation pédagogique avec leurs élèves.
Contrairement au cas du TPEC, les simulations n'étaient pas là pour
résoudre des problèmes pédagogiques précis, mais pouvaient pour eux
constituer un plus, qu'il leur fallait encore explorer. Leur idée était
souvent d'introduire la simulation (libre) dans un cours, et d'explorer en
direct avec leurs élèves son utilisation. Notre hypothèse (non vérifiée)
est qu'à l'issue d'une telle démarche exploratoire, ils auraient vu l'intérêt
de proposer des exercices et auraient pu facilement en spécifier.
Lorsque des exerc ices ont été proposés, leur réalisation avec
l'environnement OASIS n'a pas présenté de difficulté technique. Nous
avons également pu vérifier qu'il était possible pour des formateurs
n'ayant aucune compétence en programmation, de créer des exercices
s u r u n e simulation qu'ils n'avaient pas réalisée eux-mêmes. Ceci
constitue l'un des niveaux d'usage (le plus élémentaire) de
l'environnement global OASIS. Cette possibilité nous parait réellement
importante car tout formateur pourra ainsi s'approprier une simula tion
précédemment créée par quelqu'un d'autre avec OASIS, en définissant
les exercices qu'il souhaite proposer à ses élèves sur cette simulation.
Plus globalement, les suppositions que nous avions faites sur
l'existence de différents niveaux de définition d'une simulation
pédagogique se sont révélées exactes. Le premier niveau, la création
d'exercices, ne requiert pas de compétence technique particulière et
permet à l'enseignant de se concentrer sur les aspects purement
pédagogiques. Le second niveau, où l'auteur crée l'interface apprenant,
est plus complexe à manier : cette activité, souvent appréciée par
l'enseignant, peut prendre un temps très important. Enfin, le dernier
niveau, consacré à l'élaboration de modèles de simulation, n'a pu être
correctement manipulé, dans notre expérience avec les enseignants, que
dans un seul cas, par une personne possédant une expérience préalable
de cette activité de modélisation.
6 . P ERSPECTIVES
Les deux contextes que nous venons de présenter semblent a priori
fort différe n t s .
44
Dans le premier cas, celui de TPEC, le recours à la simulation s'est
imposé comme une nécessité pour combler des carences dans le
système de formation existant. Les premières expérimentations,
effectuées dans un milieu homogène (typologie précise des
applications, compétences similaires des auteurs, relative précision des
contextes pédagogiques d’intégration des simulations) ont permis
d'apporter des solutions spécifiques adaptées aux besoins. Les
r é s u l t a t s o b t e n u s s e s o n t a v é r é s t r è s e n c o u r a g e a n t s . Les solutions
relativement simples que nous avons apportées (en particulier au
niveau contrôle pédagogique de la simulation) ont été jugées
satisfaisantes par rapport aux besoins énoncés.
Dans le second cas, celui du développement de simulations dans des
contextes plus académiques, les situations d'exploitation semblent plus
difficiles à évaluer. Nous avons observé à plusieurs reprises que le
problème était abordé dans le mauvais sens : l’auteur réfléchissant
d’abord à la simulation à développer, puis après aux types d’exercices à
proposer sur cette simulation, et enfin aux situations de formation
(autoformation, compléments du cours traditionnel, formation à
distance,…) qui pourraient bénéficier de l’apport de cette simulation.
C e s c o n s t a t s n e f o n t q u e r e n forcer l'idée que l'intégration est le
problème central : le contexte d'utilisation de la simulation est
prééminent par rapport à la nature même de celle -ci. La simulation d'un
phénomène, d'un système matériel ou d'un concept, doit prendre en
compte les objectifs pédagogiques, le niveau de l'apprenant, les
conditions d'utilisation pour être réellement profitable. Certains aspects
des simulations produites dans le cadre de TPEC ont été volontairement
simplifiés, voire ignorés dans certains cas. Les vidéos fournies aux
stagiaires permettent en très peu de temps, et de façon bien plus
réaliste que n'importe quelle simulation informatique, de visualiser le
fonctionnement normal d'une machine ou les conditions pratiques de
montage ou démontage des éléments. Les simulations développées se
sont donc concentrées sur les carences des ressources pédagogiques
déjà utilisées, à savoir les savoir-faire relatifs au diagnostic et à la
réparation.
Les expérimentations que nous avons menées nous ont permis
d'effectuer certains constats sur l'exploitation pédagogique des
simulations. Nous proposons dans notre environnement OASIS, de
greffer le contrôle pédagogique sur des simulations libres, concept
particulièrement apprécié par les auteurs. Nous poursuivons aujourd'hui
d e s t r a v aux dans cette direction : nous désirons pouvoir greffer ces
contrôles sur n'importe quelle application obéissant à un certain nombre
de règles internes, ce qui devrait faciliter la réutilisation, et donc
l’intégration dans les formations [COR 99].
45
Enfin, nous nous intéressons aujourd'hui à de nouveaux contextes
d'utilisation de la simulation, liés en particulier à la formation à distance.
Nous démarrons un nouveau projet visant à offrir la possibilité aux
apprenants dans l'incapacité de participer à une formation traditionnelle
(personnes handicapées, public de formation continue, formation des
techniciens itinérants, etc.), de renforcer leur formation par l'utilisation
de simulations pédagogiques, et en fournissant différentes formes de
travail : tutorat ou travail collaboratif, contrôle asynchrone ou
synchrone, etc.
A l'heure de l'explosion des solutions pédagogiques basées sur les
nouvelles technologies, en particulier sur Internet, nous devons
particulièrement veiller à l'apport pédagogique effectif de c e s s o l u t i o n s
et à la manière dont elles doivent être intégrées dans les processus de
formation existants ou à construire.
A NNEXE : OASIS, UN EXEMPLE D ' ENVIRONNEMENT AUTEUR
Cette présentation très brève met l'accent sur les fonctionnalités
offertes par le logiciel OASIS, mais sans détailler les interfaces.
Nous avons choisi de prendre comme base ToolBook, un logiciel
commercial pour PC de la société Asymetrix, qui permet en particulier de
produire des simulations pédagogiques. Il était en partie utilisé p a r n o s
contacts industriels CORYS et Hewlett-Packard, et par nos divers
contacts académiques, en particulier le CAFIM. Notre contribution a été
de compléter ce logiciel par une surcouche procurant des
fonctionnalités supplémentaires correspondant à une mis e en œuvre du
modèle MARS.
Pour comprendre ce qu'apporte OASIS, il est nécessaire d'avoir
d'abord une idée des possibilités de base de ToolBook.
ToolBook
Une application en ToolBook est un livre, composée de p a g e s . Sur
une page, on peut placer des éléments graphiques classiques : trait,
rectangle, ovale,… ainsi que des composants un peu plus évolués :
bouton, case à cocher, zone de texte, liste déroulante,… Tous ces
éléments sont très facilement disponibles via une palette. Ils peuvent
ê t r e r é u n i s d a n s u n g r o u p e , ce qui les rend solidaires.
Un langage, OpenScript, permet d'écrire des programmes, appelés
scripts. Il fournit les instructions de contrôle usuelles (itérations, choix,
appels de fonction, …), la possibilité de modifier les propriétés des
composants (visibilité, position, taille, couleur,…) et de réagir aux
46
actions de l'utilisateur sur des éléments d'interface (déplacement de la
souris, clic sur un élément graphique, clic sur un bouton, choix d'un
item dans une liste,…).
Un point important est qu'un élément quelqu'il soit (simple élément
graphique, bouton, groupe, page, …) peut comporter une ou plusieurs
méthodes et peut avoir des propriétés (ou variables) supplémentaires
créées par le programmeur.
Problèmes méthodologiques repérés dans l'usage de T o o l B o o k
L'usage "libre" de ToolBook, c'est-à-dire sans s'imposer des règles
méthodologiques strictes, fait apparaître très vite un problème : le code
de l'application se disperse "naturellement" dans les divers objets (ou
groupes) et, facteur aggravant, d ans certains de leurs composants. Ceci
rend la maintenance délicate car il est vraiment difficile de trouver où
est le script qui effectue une certaine action. Toute tentative
d'adaptation d'une simulation existante devient de ce fait plus complexe,
c e q u i réduit les possibilités de réutilisation. Pour le programmeur de
l'application, cette dispersion, qui semble plutôt agréable au début, se
révèle assez vite très gênante pour les mêmes raisons.
Un autre problème vient de la tendance "naturelle" de connecter
directement entre eux des objets d'interface par leurs programmes. Ainsi
par exemple, dans une simulation de la loi d'ohm U=R*I, l'objet
permettant de saisir la valeur de la tension U peut consulter l'objet
Résistance pour obtenir la valeur R, calculer alors la valeur I et
transmettre cette valeur à l'objet chargé de montrer la valeur de
l'intensité par déplacement d'une aiguille. Si ces connexions se font
directement en utilisant les identificateurs uniques des objets et les
détails de leurs propriétés, tout changement ultérieur devient difficile
(par exemple, le remplacement de l'affichage à aiguille par une ampoule
d'aspect différent selon l'intensité). Une fois encore, ceci complique la
maintenance et réduit les possibilités d'adaptation.
Le Modèle (au sens MARS) d'une simulation est par essence un
composant abstrait, qui n'a pas de représentation physique. Comme les
scripts et les variables doivent être liés à un composant ToolBook, le
programmeur va avoir tendance à éclater ce qui constitue en fait le
Modèle en répartissant ses scripts et ses variables dans les objets
d'interface, au détriment de la clarté de la structure de son application.
Des programmeurs expérimentés peuvent réduire ces inconvénients
en se fixant des règles méthodologiques, mais ceci exige une discipline
de tous les instants qui tend à se relâcher avec le temps et avec les
modifications.
47
Fonctionnalités ajoutées par OASIS
Nous pouvons maintenant situer OASIS par rapport à ToolBook. La
totalité des possibilités de ToolBook sont préser v é e s e t r e s t e n t
disponibles normalement. OASIS se présente comme un menu
supplémentaire, qui donne accès aux diverses fonctionnalités
apportées. Rappelons que nous ne chercherons pas ici à décrire les
interfaces de mise en œuvre de ces fonctions.
Le modèle MARS fait référence à quatre aspects : Modèle,
Représentation, Association et Scénario. Une idée de base d'OASIS est
de proposer un espace de travail séparé et bien identifié pour chacun de
ces aspects.
Pour l'espace représentation, on conserve la fenêtre standard de
ToolBook, qui offre déjà des opérations très bien adaptées à la
définition des éléments de l'interface d'une simulation.
Espace Modèle
Un item du menu OASIS conduit à une série de fenêtres dédiées à la
spécification du Modèle de l'applicatio n : on peut y définir des
propriétés (ou variables, dotées si on le souhaite d'une valeur initiale)
et des scripts. C'est OASIS qui prend en charge la création d'un objet
(invisible) qui représente de manière interne ce Modèle. L'auteur se
trouve ainsi conduit à isoler dans son application ce qui ne dépend pas
des éléments d'interface. Ceci nécessite certes un effort de réflexion,
mais s'avère très profitable par la suite car la structure de l'application
devient plus claire.
C e t e s p a c e p r o p o s e d e p l u s u n e fonctionnalité technique très
intéressante et sans équivalent direct en ToolBook. On peut définir un
diagramme d'états pour le Modèle : il suffit de créer des noms d'états,
des noms d'événements, et d'utiliser l'éditeur de graphes fourni pour
p o s i t i o n n e r ces états, et les relier par des transitions correspondant à
l'occurrence de certains événements.
Des scripts peuvent être associés à chaque état pour indiquer des
traitements à effectuer au moment de l'arrivée dans un état, au moment
d u d é p a r t d e c e t é t a t , ou, à intervalles réguliers, pendant la durée du
séjour dans cet état.
Cette fonctionnalité permet de modéliser aisément aussi bien des
systèmes à états discrets, que des systèmes continus. Toute la
mécanique d'exécution de ce diagramme est prise en charg e par OASIS.
48
Bibliothèques d'objets de présentation
Les éléments de base fournis par ToolBook étant d'assez bas niveau
(bouton, liste déroulante,…), on est amené à définir des objets de plus
haut niveau en regroupant des éléments de base et en ajoutant
q u e lques lignes de script pour donner des comportements intéressants.
OASIS comporte une b i b l i o t h è q u e d ' o b j e t s (environ 50), qu'il suffit
d'importer dans la fenêtre standard et de personnaliser en fonction des
besoins de la simulation. Ces objets sont eux-mêmes faits avec
ToolBook, mais en respectant certaines règles d'écriture qui facilitent
leur intégration dans une simulation.
Prenons un exemple d'objet de cette bibliothèque : un curseur
horizontal qui permet de saisir une valeur.
Graphiquement, il comport e plusieurs éléments : une échelle graduée,
deux valeurs limites, un curseur déplaçable le long de cette échelle, une
zone numérique donnant la valeur pour la position courante du curseur,
et une zone de texte permettant de faire apparaître le nom de cet objet
dans l'interface. Un menu local (disponible seulement en mode auteur)
permet de personnaliser l'objet : choix des valeurs minimum et maximum,
choix du pas, présence ou non de la zone numérique, texte affiché,… Il
est même tout à fait possible de changer l'aspect de certains
composants graphiques : forme du curseur,… L'objet est construit en
respectant des conventions (noms des propriétés et des scripts,
emplacement des scripts) qui permettent d'établir ensuite facilement des
liens entre cet objet et le Modèle par le biais d'associations.
Chaque auteur peut définir de nouveaux objets et les placer dans une
bibliothèque personnelle. OASIS fournit un éditeur d'objet qui facilite
le respect des contraintes imposées. On notera aussi que le concept de
diagramme d'états est disponible pour les objets, avec la même interface
que pour le Modèle. Ceci permet de définir des objets au comportement
assez complexes : enchaînements d'états ou répétition de calculs (une
voiture qui se déplace seule par exemple).
Espace A s s o c i a t i o n
Cet espace est méthodologiquement très important. Le Modèle et
l'interface sont, comme on l'a vu, construits indépendamment, et dans
des espaces séparés. C'est dans l'espace Association que l'on va
pouvoir établir les liens entre le Modèle et l'interface. Les
manipulations à faire sont simples : on choisit dans une liste affichée
l'objet que l'on veut lier au Modèle et une fenêtre spéciale permet alors
d'indiquer les modalités précises de cette association.
Certains objets servent à afficher l'é tat interne du système simulé,
c ' e s t-à-dire les valeurs de certaines propriétés du Modèle.
49
On établit alors une association entre une propriété interne du
Modèle et l'objet d'affichage, ou plus précisément entre cette propriété
et une méthode de l'objet ; une telle méthode existe par construction
pour tous les objets d'affichage et doit entraîner un changement dans la
représentation de l'objet..
C'est OASIS qui, pendant l'utilisation de la simulation par l'élève,
prendra automatiquement en charge la surveillance de la propriété et
l'appel de la méthode lors d'un changement de valeur.
L'interface de la simulation propose à l'utilisateur des objets sur
lesquels il peut agir (boutons, curseur, zone de saisie,…). Pour ces
objets, on établit une association entre une de leurs propriétés internes
qui reflète l'action de l'utilisateur et une méthode du Modèle, méthode
qui se chargera alors d'ajuster l'état interne du Modèle. Ici encore, la
gestion pendant l'exécution est entièrement prise en charge par OASIS
qui détecte les actions de l'utilisateur et déclenche les associations
adéquates.
Cette description passe sous silence d'autres aspects : il y aussi des
associations dont l'origine est un événement ou un changement d'état ;
les conditions de déclenchement peuvent être plus précises qu'un
simple changement de valeur : une valeur précise ou un intervalle ; etc.
Le regroupement dans cet espace des liens entre objets et Modèle
clarifie beaucoup la structure d'une application, aussi bien pour l'auteur
initial que pour celui qui chercherait à y faire des modifications
ultérieures.
On remarque également qu'il n'y a jamais de lien direct des objets
entre eux, ce qui facilite les changements d'interface. Un objet
d'affichage n'a pas besoin de savoir si la valeur qu'il affiche a été
obtenue par un calcul, ou saisie soit directement dans une zone
numérique, soit par déplacement du curseur d'un potentiomètre gradué.
Remplacement d'un objet par un autre
Une fonctionnalité secondaire mais commode permet de remplacer
très facilement un objet d'interface par un autre objet du même genre.
Un objet représentant par exemple un potentiomètre linéaire peut être
ainsi remplacé par un potentiomètre circulaire, par une manipulation
triviale. Les associations impliquant l'objet initial s ont automatiquement
reportées sur le nouvel objet.
Ceci permet à un formateur d'adapter facilement une simulation
existante en personnalisant les éléments de l'interface.
Espace scénario
Cet espace constitue un complément très substantiel fourni par
OASIS à ToolBook, en conformité avec le modèle MARS. Nous ne
50
redécrirons pas ici ses principales fonctionnalités qui ont été
présentées dans la section 4.
On rappellera que l'auteur n'a pas à s'occuper du mécanisme
d'exécution ; OASIS prend en charge la gestion des choix d'exercices et
de modes d'exécution faits par l'élève, ainsi que toute la surveillance du
travail de l'élève.
Cet espace scénario n'a aucun équivalent direct en ToolBook. Il
constitue un apport essentiel d'OASIS. Il permet en particulier de
définir avec une grande facilité des exercices différents pour une même
simulation. Nos expériences ont confirmé que des formateurs
réussissaient assez facilement à ajouter de nouveaux exercices à une
simulation qu'ils n'avaient pas développée eux-mêmes, le mé canisme de
définition n'exigeant pas de connaître les détails internes de la
simulation.
51
BIBLIOGRAPHIE
[AKK 97] A KKOUCHE I., PREVOT P., « Cooperative Distance Learning Sessions
Management » IEPM'97, Lyon, France, octobre 1997.
[AZZ 95] A ZZI R., « Environnements de développement de simulateurs pédagogiques
de procédés industriels», Thèse, INSA, Lyon, 1995.
[BAL 97] BALACHEFF N., BARON M., DESMOULIN C., GRANDBASTIEN M., VIVET M.,
« Conception d'environnement interactifs d'apprentissage avec ordinateur,
tendances et perspectives » PRC-GDR IA'97, 1997, p. 315-337.
[BAU 98] BAUDIN V. & ALL , « Conception d’un environnement de téléformation
synchrone : projet TOPASE », Nouvelles Technologies de l'Information et de la
Communication dans les Formations d'ingénieurs et dans l'industrie
(NTICF’98). Rouen, France, 18-20 novembre 1998, p. 53-64.
[CAG 90] CAGNAT J-M., GUÉRAUD V., PEYRIN J-P., «The Arcade Laboratory : an
environment to help teach algorithms », ACM SIGSE Bulletin, vol. 22, n°4, 1990.
[COR 97] CORTÉS G., GUÉRAUD V., « Helping The Teacher to Create Simulation Based
Exercises », 4-th International Conference on Computer Aided Engineering
Education (CAEE 97), Krakow, Pologne, septembre 1997.
[COR 98] CORTÉS G., GUÉRAUD V., « Experimentation of an authoring tool for
pedagogical scenarios », International Conference on Computer Aided Learning
and Instruction in Science and Engineering (CALISCE’98), Göteborg, Suède,
juin 1998
[COR 99] CORTES G., « Simulations et Contrôle Pédagogique », Thèse de doctorat,
Universit é Joseph Fourier-Grenoble 1, octobre 1999 (à paraître).
[DEJ 91] DE JONG T., « Learning and instruction with computer simulations »,
Education & Computing, n° 6, 1991.
[DEJ 96] DE JONG T., Editeur « Designing integrated computer simulation
environments for discovery learning», Servive Project (ET 1020), First project
progress report, décembre 1996.
[DER 97] DERYCKE A., HOOGSTOEL F., VIEVILLE C., « Campus virtuel et apprentissages
coopératifs», 5 es Journées EIAO, Cachan, mai 1997, Éditions Hermès, p. 11-24.
[FOR 97a] FORTE E., W ENTLAND FORTE M., DUVAL E., « The ARIADNE Project (Part I) :
Knowledge Pools for Computer-based and Telematics -supported Classical, Open
and Distance Education », European Journal of Engineering Education, vol 22,
n°1, 1997, p.61-74
52
[FOR 97b] FORTE E., W ENTLAND FORTE M., DUVAL E., « The ARIADNE Project (Part
II) : Knowledge Pools for Computer-based and Telematics -supported Classical,
Open and Distance Education », European Journal of Engineering Education,
vol 22, n°2, 1997, p.153-166
[FRA 99] FRASSON C., « Training Industriel et réalité Virtuelle », Simulation et training
industriel, Bayonne, février 1999.
[GEC 94] GECSEI J., FRASSON C., « SAFARI : an Environment for Creating Tutoring
Systems in Industrial Training », EdMedia, World Conference on Educational
Multimedia and Hypermedia, Vancouver, Canada, juin 1994.
[GIB 93] GIBAUD O., « Contribution au concept de MicroMondes pour l’Enseignement
Assisté par Ordinateur», Thèse, Ecole Centrale de Lyon, 1993.
[GOU 99] GOUARDERES G., « Systèmes Tutoriels et Training Industriel », Simulation et
training industriel, Bayonne, février 1999.
[GUE 89] GUERAUD V., « Un jeu de rôles dans le laboratoire Arcade : une autre façon
d’enseigner la programmation », Thèse de doctorat, Université Joseph Fourie rGrenoble 1, février 1989.
[GUE 94] GUERAUD V., PEYRIN J-P., CAGNAT J-M., DAVID J-P., PERNIN J-P., « Software
environments for Computer Aided Education », SIGCSE Bulletin, vol. 26, n° 2,
ACM Press, juin 1994, p. 19-25.
[GUE 98] GUERAUD V., « Une approche auteur pour le développement de simulations
pédagogiques à partir d’un environnement hypermédia », Quatrième Colloque
Hypermédias et Apprentissages, Poitiers, France, octobre 1998.
[GUE 99] GUÉRAUD V., PERNIN J-P., « Developing pedagogical simulations : Generic
and specific authoring approaches », International Conference on Artificial
Intelligence in Education (AI-ED 99),Le Mans, France, juillet 1999.
[HER 94] HERZOG J.M., FORTE E.N., « A Goal Oriented Simulation in Chemical
Thermodynamics », International Conference on Computer Aided Learning and
Instruction In Science and Engineering (Calisce 94), Paris, France, septembre
1994.
[IEE 98] IEEE, Learning Technology
http://www.manta.ieee.org/P1484
Standards
Committee
working
group,
[JOA 97] JOAB M., A UZENDE O. TRAN J-M., « Extraction automatique de cursus d’une
banque d’exercices », Nouvelles Technologies de l'Information et de la
Communication dans les Formations d'ingénieurs et dans l'industrie
(NTICF’98). Rouen, France, 18-20 novembre 1998, p. 77-83.
[LAB] LABVIEW : //www.natinst.com/labview
53
[LEA] LEARNING SPACE : //www.lotus.xom/home.nsf/welcome/learnspace
[LEW 98] LEWIS R., « Apprendre conjointement : une analyse, quelques expériences
et un cadre de travail», Quatrième Colloque Hypermédias et Apprentissa ges,
Poitiers, France, octobre 1998.
[MAR 97] M ARCELINO M.J., Mendes T.« SimBest : A Set of Integrative Tools to
Support the Development of Computer-Based Educational Programs »,
Proceedings of the 6th IFIP World Conference on Computers in Education,
Chapman and Hall, 1997, p. 945-951.
[MEN 95]
M ENGELLE T., « Etude d’une architecture d’environnements
d’apprentissage basés sur le préceptorat avisé », Thèse, Université P. Sabatier,
Toulouse, 1995.
[MUN 95] M UNRO A., « RIDES Reference manual », Behavioral Technology
Laboratories, University of Southern California, 1995.
[NIC 88] NICAUD J.F., VIVET M., « Les tuteurs intelligents. Réalisations et tendances de
recherche », Technique et Science Informatiques, vol. 7, n° 1, 1988.
[PER 95a] PERNIN J-P., « Assisted design and automatic generation of pedagogical
simulations », 3rd Conference Computer Aided Engineering Education (CAEE
95), Bratislava, Slovakia, septembre 1995.
[PER 95b] PERNIN J-P., GUERAUD V., « MARS, un modèle de conception d'applications
pédagogiques interactives », Conférence IHM 95, Toulouse, octobre 1995.
[PER 96a] PERNIN J-P., « MARS : un modèle opérationnel de conception de
simulations pédagogiques », Thèse de doctorat, Université Joseph FourierGrenoble 1, janvier 1996.
[PER 96b] PERNIN J.P., GUÉRAUD V., COUDRET F., « An experimental environment for the
production of pedagogical simulations », Lecture Notes in Computer Science, vol.
1108, International Conference on Computer Aided Learning and Instruction in
Science and Engineering (CALISCE’96). Donostia -San Sebastian, Espagne,
juillet 1996.
[PER 98a] PERNIN J-P, « Comparing two authoring approaches of instructional
simulations : an industrial experimentation » International Conference on
Computer Aided Learning and Instruction in Science and Engineering
(CALISCE’98), Göteborg, Sweden, juin 1998.
[PER 98b] PERNIN J-P, « L'intégration effective de la simulation dans la formation
technique : un enjeu à ne pas manquer », Nouvelles Technologies de
l'Information et de la Communication dans les Formations d'ingénieurs et dans
l'industrie (NTICF’98). Rouen, France, 18-20 novembre 1998, p. 311-316.
54
[RAP] Rapid, société EMULTEK : http://www.emultek.com
[ROS 94] VAN ROSMALEN P., « SAM Simulation and Multimedia », dans DE JONG & All,
Design and Production of Multimedia and Simulation Based Training, Kluwer
Academic Publishers, juin 1994.
[SIM] SIMFACTORY http://manufacturing.software -directory.com
[TOW 95] T OWNE D., Learning and Instruction in Simulation Environments,
Educational Technology Publications, 1995.
[VAN 96] VAN JOOLIGEN , W OUTER R., DE JONG T., « Supporting the authoring process
for simulation based discovery learning » European Conference on Artificial
Intelligence in Education, Lisboa, Portugal, 1996. p. 73-79.
[VIV 91] VIVET M ., « Expertise pédagogique et usage de tuteurs intelligents » 13èmes
Journées francophones sur l’Informatique, Formation Intelligemment assistée
par Ordinateur, Genève, janvier 1991.
[WEB] environnement W EBCT, http:/ /www.webct.com

Environnements d`apprentissage basés sur la simulation

Transcription

Documents pareils

M.M.T. (Moving Magnet Technologies)

Evaluation, assessment center

Communauté de communes de l`Auxerrois

Programme - ANR LoLitA

Calculette d`emprunt - Tableau d`amortissement - Terre-net

Lycée Mas de Tesse

Le logiciel de simulation, de calcul et de déclaration de l`IR et de l`ISF.

consulter l`article

méthodes de monte-carlo avec r - Nathalie Villa