pascal lando progetto : une m´ethode de … sciences et technologies de l’universit´e de...
Post on 24-Jul-2019
217 Views
Preview:
TRANSCRIPT
DEA Sciences et technologiesde l’universite de technologie de Compiegne
majeureTechnologies de l’information et des systemes
presente par
Pascal Lando
Progetto : une methode de conceptionde gabarits de scenarios pour activitespedagogiques collectives distantes a
base de projets
Stage effectue du 1er fevrier au 31 juillet 2004au sein du laboratoire Sa.So, axe NTE de
l’universite de Picardie Jules Verne
Soutenu le 6 septembre 2004 dans le jury compose de :
M. Philippe Trigano Professeur, UTC CompiegneMme Dominique Leclet Maıtre de conferences HDR, UPJV AmiensMme Anne Lapujade Maıtre de conferences, UPJV AmiensM. Dominique Lenne Maıtre de conferences, UTC Compiegne
On ne peut rien apprendre aux gens. On peut seulement les aider adecouvrir qu’ils possedent deja en eux tout ce qui est a apprendre.
Galilee
Table des matieres
Remerciements 9
Introduction 11
Partie I – Contexte et situation initiale 15
1 L’apprentissage collectif mediatise par ordinateur et les projets 17
1.1 L’apprentissage collectif . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 L’apprentissage par projet . . . . . . . . . . . . . . . . . . . . . . 20
1.3 L’apprentissage collectif par projet . . . . . . . . . . . . . . . . . 22
1.4 La notion de scenario pedagogique . . . . . . . . . . . . . . . . . . 22
2 Etat de l’art 25
2.1 Gabarits de scenarios pedagogiques . . . . . . . . . . . . . . . . . 26
2.2 Autres travaux relatifs aux APCD de projets . . . . . . . . . . . . 35
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3 Vers une typologie de scenarios pour les APCD de projets 45
3.1 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Criteres de discrimination . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Proposition d’une typologie . . . . . . . . . . . . . . . . . . . . . 48
Partie II – Modelisation et analyse des scenarios 51
4 Notre demarche de modelisation 53
4.1 La modelisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Le formalisme MOT . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 UML : Unified Modeling Language . . . . . . . . . . . . . . . . . 56
4.4 Resume de notre demarche de modelisation . . . . . . . . . . . . . 57
6 Table des matieres
5 Modelisation des gabarits de scenarios 59
5.1 SPLACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 APC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 NetPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 SYMBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 iPedagogique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.6 Conclusions et hypothese fondatrice . . . . . . . . . . . . . . . . . 68
Partie III – Progetto : une methode de conception 73
6 Rappel sur les methodes de conception 75
6.1 Les systemes d’information . . . . . . . . . . . . . . . . . . . . . . 76
6.2 Qu’est-ce qu’une methode de conception ? . . . . . . . . . . . . . 77
6.3 Vers une methode de conception. . . . . . . . . . . . . . . . . . . . 77
7 Le modele generique 79
7.1 Presentation des concepts de modelisation . . . . . . . . . . . . . 80
7.2 Le modele generique . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.3 Parametrage du modele generique : regles d’integrite . . . . . . . 93
8 Demarche de conception 103
8.1 Etape 1 : definition des acteurs et de leurs actions . . . . . . . . . 104
8.2 Etape 2 : precision des concepts manipules . . . . . . . . . . . . . 105
8.3 Etape 3 : structuration des etapes . . . . . . . . . . . . . . . . . . 106
8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9 Formalismes proposes 109
9.1 Formalisme de definition des acteurs et actions . . . . . . . . . . . 110
9.2 Formalisme dedie a la structuration des etapes . . . . . . . . . . . 111
10 Le logiciel Progetto : un outil d’aide a la conception d’APCD 115
10.1 Etude prealable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.2 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.3 Fonctionnement du logiciel . . . . . . . . . . . . . . . . . . . . . . 117
11 Positionnement par rapport a la normalisation 127
11.1 Presentation succincte de IMS Learning Design . . . . . . . . . . 128
11.2 IMS-LD pour la description de gabarits de scenarios ? . . . . . . . 129
11.3 Solution proposee . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Conclusion 133
Table des matieres 7
Annexes 137A Exemple de fichier XML genere par Progetto . . . . . . . . . . . . 137
Remerciements
Je souhaite remercier Dominique Leclet, responsable de l’axe NTE du labora-toire Sa.So d’Amiens, pour m’avoir accueilli et donne tous les moyens d’integrerson equipe dans les meilleures conditions.
Je remercie Anne Lapujade, qui m’a initie a la recherche, guide, encourage etrassure tout au long de ce stage. J’espere que notre cooperation nous menera aaccomplir des choses interessantes dans les annees a venir. . .
Je remercie Philippe Trigano, pour avoir accepte de diriger ce stage cote UTC,et pour la confiance et la liberte qu’il m’a accorde dans mon travail.
Je remercie egalement Dominique Lenne pour avoir accepte de participer aujury de ce DEA.
Mes remerciements vont aussi a Monique Grandbastien, qui m’a fait l’honneurde porter attention a mes recherches. Ses quelques remarques m’ont encouragedans mon travail.
Enfin, merci a l’ensemble de l’axe NTE, notamment Brigitte, Celine, Em-manuelle, Helene et Mohamed pour leur gentillesse et pour m’avoir integre tresrapidement dans leur equipe.
Introduction
Les environnements informatiques pour l’apprentissage humain (EIAH) font al’heure actuelle l’objet d’un interet sans cesse grandissant. Alors que bon nombrede formations s’ouvrent a la distance, s’appuyant de plus en plus frequemmentsur des plateformes informatisees d’apprentissage, les methodes et techniquesd’enseignement distant se diversifient. Cette diversification est rendue possiblegrace a une collaboration entre plusieurs disciplines : informatique, sciences del’education, didactique, psychologie, sociologie. Nos travaux s’inscrivent dans ladiscipline informatique, et ont donc pour but de produire des abstractions for-malisees de situations reelles, et de fournir des outils et methodes pour travaillersur ces abstractions. L’objectif premier de nos recherches est de proposer desdispositifs permettant d’aider les concepteurs d’activites pedagogiques collectivesdistantes (APCD) dans leur demarche.
Le travail presente dans ce document a ete effectue dans le cadre d’un stagede DEA d’informatique, debute en fevrier 2004 au sein du laboratoire Sa.So1 (axeNTE : Nouvelles technologies educatives) de l’universite de Picardie Jules Verne.
Ce chapitre introductif se propose, dans un premier temps, de situer nostravaux dans leur contexte general. Nous presentons ensuite nos objectifs de re-cherche, et definissons notre problematique. Enfin, nous precisons la methodologieemployee, et annoncons le plan de ce document.
Contexte general
L’axe NTE du laboratoire Sa.So mene depuis quelques annees un projetnomme SYSMOOSE (Systemes supports de methodes pour concevoir et orga-niser des services et ressources pedagogiques en ligne, s’integrant dans une infra-structure type « plate-forme »), visant a pallier l’isolement des apprenants dansles formations a distance. Un des axes de ce projet est consacre a la conceptiond’activites pedagogiques collectives dans le cadre de la pedagogie a base de pro-jets. Nos travaux naissent de ces recherches.
1Savoirs et socialisations en education et formation, EA 3303.
12 Introduction
Le contexte general dans lequel s’inscrivent nos recherches est donc celui duCSCL (Computer-Supported Collaborative Learning), traduit en francais par ap-prentissage collaboratif assiste par ordinateur (ACAO). Dans ce contexte desACAO, nos travaux s’inscrivent plus particulierement dans le champ de recherchesur les ACAO distantes : les activites collectives proposees sont effectuees dans cecas par des apprenants geographiquement repartis, et communiquant par le biaisdes reseaux informatiques. Nous parlerons donc, dans la suite de ce document,d’activites pedagogiques collectives distantes (APCD).
La conception et l’implantation d’APCD fait intervenir deux types d’ac-teurs : le concepteur, qui a en charge la creation d’un gabarit (∼ moule) descenario pedagogique (partie structurelle), et l’auteur, qui implante ce scenariopour generer une activite pedagogique particuliere (partie operationnelle). Cesdeux acteurs peuvent etre (et sont frequemment) une unique personne, conce-vant un type de scenario adapte a un enjeu pedagogique donne, et l’instanciantpour creer le scenario souhaite. Notre contexte de travail est celui de la conceptiond’APCD de projets : nos travaux s’adressent donc aux concepteurs de gabarits descenarios pedagogiques pour APCD de projets. Ce contexte pose, nous enonconsci-apres nos objectifs de recherche.
Objectifs de recherche
Dans ce contexte de travail, nos recherches se proposent de remedier a l’insuf-fisance existant actuellement au sein des plateformes d’apprentissage a distanceau niveau de l’aide aux concepteurs d’APCD a base de projets. Notre objectifpremier est donc de participer a la creation de methodes et d’outils destines aaider les concepteurs d’APCD de projet dans leur demarche.
Le probleme fondamental motivant nos travaux reside dans le fait que leconcepteur de scenarios pedagogiques n’a pas necessairement de competencesparticulieres en informatique. L’enjeu essentiel est donc de proposer une methodedestinee a guider le concepteur dans sa tache en lui permettant de manipuler desconcepts qui lui sont familiers, (tache a realiser, groupe d’apprenants, ressourcepedagogique, etc.), et a extraire de ses intensions pedagogiques, de maniere auto-matique, des structures informatiques pouvant etre implantees dans le cadre deplateformes ou autres outils pedagogiques. La problematique sous-jacente a cesobjectifs de recherche est presentee dans la section suivante.
Problematique
Notre problematique reside en la proposition d’une modelisation capable derepresenter une abstraction de, si ce n’est tous, un nombre important de gaba-
Introduction 13
rits de scenarios pedagogiques pour les APCD de projets, qui sera la base denotre methode de conception. En effet, nous sommes conscients de l’etendue despossibilites pedagogiques conferees par la mise en oeuvre d’APCD de projets,et n’affichons donc pas la volonte de creer des modeles supportant toute cettediversite. Cependant, nous voyons en la proposition de modeles que nous quali-fierons de generiques (meme si nous n’ignorons pas qu’en termes de pedagogie,un modele informatique est tres difficilement completement generique) une aideprecieuse a la conception de scenarios pedagogiques.
Autour de cette modelisation, nous avons construit une methode de conceptionde gabarits de scenarios pedagogiques pour APCD de projets, Progetto, compre-nant une demarche de conception, des formalismes et un outil support de cettemethode. L’originalite de nos travaux est caracterisee par le fait qu’il n’existeaucune methode de ce type a l’heure actuelle.
De plus, nos recherches visant a aider le concepteur, nous nous appuyons surune typologie d’APCD de projets afin de guider ce dernier dans le choix d’untype de gabarit en fonction de ses objectifs pedagogiques. Ce guidage fait l’objetd’un assistant dans notre outil de conception.
Methodologie
Notre demarche a consiste a etudier les gabarits de scenarios pedagogiquesproposes dans la litterature (etude bibliographique), en relever les caracteristiquesessentielles, synthetiser et analyser ces caracteristiques. Cette synthese, compre-nant la proposition d’une typologie d’APCD de projets, une uniformisation desconcepts employes ainsi que le degagement des modeles de donnees sous-jacentsa chaque type de scenario, a pour objectif de permettre la comparaison et la miseen evidence des similarites et des divergences entre les differents modeles.
Cette demarche nous a permis de batir un modele generique de gabaritsde scenarios pedagogiques pour les APCD de projets, ainsi qu’une methode deconception fondee sur ce modele.
Plan du document
Dans une premiere partie, nous presentons le contexte de nos travaux ainsi quela situation initiale (etat de l’art) relevee dans la bibliographie en ce qui concerneles ACPD de projet. Nous proposons egalement, dans cette partie, une typologiede ces APCD de projets existantes, en fonction des objectifs pedagogiques pour-suivis.
14 Introduction
La deuxieme partie du document est consacree a la modelisation informatiquedes gabarits de scenarios etudies. Apres avoir introduit et justifie notre demarchede modelisation, nous presentons les modeles de gabarits concus.
Enfin, dans une troisieme partie, nous presentons notre methode de conceptionde gabarits de scenarios. A la suite d’un bref rappel sur les methodes de concep-tion de systemes d’information, nous presentons toutes les composantes de notremethode (modele, demarche, formalismes, outil). Nous precisons egalement notrepositionnement par rapport a la normalisation emergente en matiere de descrip-tion de contenus pedagogiques.
Nous concluons ce document en annoncant les perspectives de recherche ou-vertes par les travaux effectues.
Premiere partie
Contexte et situation initiale
Chapitre 1
L’apprentissage collectif mediatisepar ordinateur et les projets
Nos travaux s’inscrivant dans une volonte de creation de dispositifsinformatiques supports a la creation d’activites pedagogiques, nousjugeons interessant, prealablement a la presentation de notre methodede conception, de rappeler le contexte pedagogique et les theories surlesquelles elle s’appuie. C’est la raison pour laquelle nous presentonssuccinctement, dans ce chapitre, les bases theoriques pedagogiquessur lesquelles reposent nos recherches. Nous situons egalement plusprecisement notre contexte de recherche au sein des APCD de projets,en clarifiant la notion de scenario pedagogique pour ce type d’APCD.
Table des matieres1.1 L’apprentissage collectif . . . . . . . . . . . . . . . . . 18
1.1.1 Apprentissage cooperatif . . . . . . . . . . . . . . . . . 181.1.2 Apprentissage collaboratif . . . . . . . . . . . . . . . . 191.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 L’apprentissage par projet . . . . . . . . . . . . . . . . 201.2.1 Definition et contexte . . . . . . . . . . . . . . . . . . 201.2.2 Histoire . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.3 Fondements . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 L’apprentissage collectif par projet . . . . . . . . . . . 221.4 La notion de scenario pedagogique . . . . . . . . . . . 22
18 L’apprentissage collectif mediatise par ordinateur et les projets
1.1 L’apprentissage collectif
L’apprentissage collectif vise l’acquisition de savoirs et de savoir-faire par lebiais du travail en groupe (de taille variant de deux personnes a une promo-tion entiere), ou les apprenants doivent atteindre un objectif commun. Cetteforme d’apprentissage mise essentiellement sur la qualite des interactions entreles differents membres du groupe. Plusieurs theories ont influence ce conceptd’apprentissage collectif, il convient donc d’en rappeler brievement les objets res-pectifs :
– Le constructivisme, trouvant son origine essentiellement dans les travauxde Piaget, postule que l’apprentissage naıt de l’action (« on apprend enfaisant ») ;
– Le behaviorisme postule que l’apprentissage passe par une modification du-rable du comportement (∼ donner une nouvelle reponse a un stimulus quine la provoquait pas auparavant) ;
– Le cognitivisme, s’opposant au behaviorisme, postule que l’apprentissageconsiste en la comprehension et l’acquisition d’informations et de schemesnouveaux ;
– l’approche socio-culturelle, s’appuyant sur les theories de Vygotsky, affirmeque l’apprentissage est en grande partie influence par les interactions so-ciales entre les individus.
Remarque 1 Meme si nos travaux se situent dans le domaine de l’apprentissagepar projet (apprentissage par l’action), et relevent donc prioritairement du cou-rant constructiviste, il paraıt abusif de « classer » ce type d’apprentissage commese fondant uniquement sur les theories constructivistes. Plus particulierementdans le cas de projets collectifs, il semble que les interactions sociales jouent unrole important dans l’acquisition des savoirs et savoir-faire, ce qui releve plutotdes theories socio-culturelles. Il est donc de rigueur de considerer ces differentestheories dans leur ensemble et non d’en isoler telle ou telle caracteristique pourcaracteriser nos travaux.
Au sein de l’apprentissage collectif, il est possible de distinguer deux sous-categories : apprentissage cooperatif et apprentissage collaboratif. La confusionentre ces deux termes est frequente, et certains auteurs les considerent memedeliberement comme similaires [Cohen, 2001]. Cependant, de nombreux auteursdistinguent cooperation et collaboration (ex. : [Roschelle et al., 1995]) ; nous nousrallions a cette consideration.
1.1.1 Apprentissage cooperatif
Le travail cooperatif est un mode de travail collectif, dans lequel les individusse partagent un travail en fonction de leurs competences respectives.
1.1 L’apprentissage collectif 19
L’apprentissage cooperatif est une donc un apprentissage en groupe, orga-nisee et structuree de facon a ce que l’apprentissage soit dependant de l’echanged’informations entre les apprenants du groupe. D’apres [Slavin, 1995], le fait decooperer en groupe permet d’accroıtre l’efficacite du travail, ceci etant justifie pardeux theories : la theorie motivationnelle et la theorie de cohesion sociale.
Dans la pratique, de nombreuses situations de travail cooperatif sont ob-servees, aussi bien dans le monde du travail que dans le milieu pedagogique.Parmi ces situations, nous pouvons citer a titre d’exemple d’activites cooperativesla methode Jigsaw, consistant a confier a chaque apprenant (ou groupe d’appre-nants) une « piece de puzzle » (un travail complementaire), puis a assembler cespieces afin de valoriser le travail de chacun.
1.1.2 Apprentissage collaboratif
Le travail collaboratif se caracterise par le fait que les individus travaillentconjointement a l’atteinte d’un but commun (une œuvre commune).
L’apprentissage collaboratif est une demarche active par laquelle l’apprenanttravaille a la construction de ses connaissances. Le formateur y joue le role defacilitateur des apprentissages alors que le groupe y participe comme source d’in-formation, comme agent de motivation, comme moyen d’entraide et de soutienmutuel et comme lieu privilegie d’interaction pour la construction collective desconnaissances [Henri et al., 2001]. Ce mode d’apprentissage est donc significati-vement different du precedent, et l’amalgame frequemment constate entre appren-tissage collectif et apprentissage collaboratif paraıt injustifie dans notre contexte(par exemple, dans le cas d’apprentissage collaboratif, il n’y a generalement pasde repartition a priori des roles au sein des groupes, ce qui est parfois le cas dansle cadre d’apprentissage cooperatif). De ces differences cooperation/collaborationdecoulent des besoins en outils (informatiques et organisationnels) relativementdistincts.
1.1.3 Conclusion
Ces differents mode d’apprentissage (travail individuel, cooperatif et collabo-ratif) sont, dans la majorite des cas, utilises en synergie dans les activites deprojets. Un projet pedagogique collectif est donc generalement fonde sur uneforme d’apprentissage que l’on peut qualifier d’« hybride », melant apprentissageindividuel et apprentissage collectif (cooperatif et/ou collaboratif).
20 L’apprentissage collectif mediatise par ordinateur et les projets
1.2 L’apprentissage par projet
1.2.1 Definition et contexte
Dans la suite de ce document, nous nommerons pedagogie de projet1 la miseen place de toute activite pedagogique ayant comme noyau central la realisationd’un projet par les apprenants. Le concept pedagogique fondamental de cettemethode est donc l’activite des apprenants, et la supposition que leur implicationdans la realisation de taches dotees d’une credibilite depassant le cadre scolaireest un declencheur de l’acquisition de savoirs et de savoir-faire.
De plus, ils nous semble important d’etablir une distinction entre les objec-tifs pedagogiques de l’apprentissage a base de projets. En effet, la richesse et ladiversite des situations pedagogiques pouvant etre mises en place dans le cadrede pedagogie de projet semble pouvoir repondre a des objectifs tres varies. A cetitre, [Lemaıtre, 2000] propose une typologie des situations de mise en place depedagogie de projet, en distinguant cinq objectifs federateurs :
– former avec des projets : l’apprentissage est disciplinaire, et le projet estun outil pedagogique ;
– former aux projets : l’apprentissage est centre sur la mise en œuvre deprojets, il est moins lie a une discipline particuliere ;
– former par le projet : l’objectif est ici de cibler l’acquisition de savoirs etde competences interdisciplinaires, parfois appelees meta-competences oucompetences de haut niveau [Betbeder, 2003] ;
– former pour le projet : l’objectif est de developper une culture du projet,pour donner aux eleves l’envie d’apprendre ;
– former le projet (des apprenants) : la formation est alors de nature « psycho-sociologique », et vise le developpement personnel, l’autonomie et l’adap-tation au monde.
D’autres auteurs, notamment [Mabardi, 1996] distinguent egalement la for-mation par le projet de la formation au projet. Cependant, tous les projets misen place visent des objectifs souvent multiples, les rapprochant plus ou moins deplusieurs des situations exprimees ci-dessus. Il est toutefois generalement possiblede distinguer une ligne conductrice repondant a l’un des points cites.
1.2.2 Histoire
La strategie pedagogique consistant a faire travailler des eleves sur des projetsest relativement ancienne. En effet, le philosophe et pedagogue John Dewey (1859-1952) a experimente la pedagogie de projet des la fin du XIXe siecle, au sein del’ecole-laboratoire rattachee a l’universite de Chicago [Gregoire et al., 1999]. Plus
1Le terme anglophone Project-Based Learning (PBL, a ne pas confondre avec Problem-BasedLearning, voisin mais non equivalent) est frequemment employe.
1.2 L’apprentissage par projet 21
recemment, un ouvrage federateur sur la pedagogie de projet est l’article intituleThe Project Method, du psychologue William Kilpatrick (1871-1965). Cet articlea contribue a instaurer la pedagogie de projet comme une veritable strategiepedagogique dans les ecoles, et a eu un retentissement considerable, comme lesouligne [Gregoire et al., 1999].
De plus, l’activite professionnelle des salaries d’aujourd’hui est profondementdifferente de celle observee dans les generations precedentes. Ainsi, les entreprisesen quete d’efficacite recherchent a l’heure actuelle des competences naguere moinsplebiscitees (ou uniquement pour des postes a responsabilite), a savoir les capa-cites d’analyse et de synthese d’un probleme, la faculte de s’inserer pleinementdans une equipe et de s’y epanouir, la prise d’initiatives par rapport a un problemedonne, etc. Force est de constater que ces competences sont tres difficilementfaconnees par les systemes classiques d’apprentissage (avec ou sans ordinateur :cours magistraux, exercices individuels, etc.), ou l’unique enseignement retire parl’apprenant est un savoir theorique. Il se trouve que la pedagogie de projet semontre efficace pour pallier ces manques, puisqu’elle suscite un mode d’organi-sation du travail de plus en plus repandu dans les entreprises [Lemaıtre, 2000].Cette pedagogie centree sur l’apprenant connaıt donc un essor non negligeabledepuis quelques decennies.
1.2.3 Fondements
Kilpatrick definit un projet pedagogique comme etant une activite possedantles caracteristiques suivantes [Gregoire et al., 1999] :
– un but precis ;– l’engagement dans sa totalite de la personne qui l’accomplit ;– le deroulement dans un environnement social.
On constate que ces caracteristiques se rapprochent des conditions de travaildans lesquelles sont amenes a etre plonges les apprenants de formations profes-sionnelles, de types ecoles d’ingenieurs, IUP, IUT, etc. [Lemaıtre, 2000] evoquele fait que le projet tel que le concoit notre modernite occidentale semble ainsihistoriquement lie a l’apparition du metier d’ingenieur. Ce constat prend touteson importance dans notre contexte de formation professionnelle.
De plus, la pedagogie de projet implique un bouleversement du role de l’ensei-gnant : celui-ci ne joue pas le role habituel de « dispenseur » de savoirs, mais defacilitateur de l’apprentissage [George, 2001]. D’apres [Vassileff, 1997], le role desenseignants consiste alors a gerer pedagogiquement la dynamique d’apprentissagenee de la situation de projet.
22 L’apprentissage collectif mediatise par ordinateur et les projets
1.3 L’apprentissage collectif par projet
L’apprentissage par projet est tres souvent utilise par le pedagogue dans uncontexte de travail collectif. Ainsi, les apprenants sont amenes a travailler par pe-tits groupes afin de mener a bien un projet pedagogique, selon un scenario plus oumoins directif propose par le concepteur de l’activite. Nous interessant a des ac-tivites collectives distantes, les projets sont realises par des groupes d’apprenantsrepartis geographiquement, et communiquant grace aux reseaux informatiques.
Cette approche combine donc les differents types de travail collectif evoquesplus tot, a savoir le travail cooperatif et le travail collaboratif, mais egalementdes taches individuelles, le tout dans un contexte de realisation d’un projetpedagogique. Le fait de « marier » la pedagogie de projet a l’apprentissage col-lectif permet a nos yeux d’ajouter une dimension de realisme a cet apprentis-sage. Ainsi, les apprenants confrontes a une situation de travail les impliquantde maniere realiste dans un projet collectif sont plus disposes a s’investir dans larealisation des taches qui leur sont proposees.
En resume, d’apres [Dirckinck-Holmfeld, 1994] la pedagogie de projet peutetre decrite a l’aide de cinq mots-cles : orientee probleme, interdisciplinarite,collaboration, travail dans les conditions de projet et controle par les participants.
1.4 La notion de scenario pedagogique pour les APCD de
projets
De maniere generale, un scenario pedagogique peut etre defini, dans le cadred’apprentissage par projet, comme etant la presentation du projet avec en plus,des informations relatives aux participants, aux taches qui leur sont confiees ouencore au mode de realisation de ces taches [Lapujade et al., 2003]. En d’autrestermes, le scenario prevoit le deroulement d’une activite d’apprentissage (en lieuxet temps) et comprend une definition des objectifs, une planification plus oumoins detaillee des activites, une description des taches des apprenants et desmodalites d’evaluation [Daele et al., 2002]. Il est donc possible de decomposer unscenario pedagogique en deux parties distinctes, a savoir :
– une partie structurelle, precisant l’agencement temporel des taches confieesaux apprenants, les types d’acteurs en presence (apprenants, tuteurs, etc.),et les types de services et ressources a disposition ;
– une partie operationnelle, fruit d’un travail pedagogique destine a repartirles savoirs et savoir-faire a transmettre ainsi que les acteurs reels dans le« moule » qu’est la partie structurelle.
La conception et l’implantation d’APCD fait donc intervenir deux types d’ac-teurs : le concepteur, qui a en charge la creation d’un gabarit (∼ moule) de
1.4 La notion de scenario pedagogique 23
scenario pedagogique (partie structurelle), et l’auteur, qui implante ce scenariopour generer une activite pedagogique particuliere (partie operationnelle) (cesdeux acteurs peuvent etre une unique personne).
La figure suivante illustre les processus de conception et d’implementation descenarios pedagogiques pour APCD de projets.
Définition d'un gabarit de scénario
Description d'un scénario
Exécution du scénario
Concepteur
Auteur
Apprenant
Fig. 1.1 – Mise en place d’un scenario pedagogique pour APCD
Chapitre 2
Etat de l’art
Ce chapitre se propose de repertorier et d’expliciter les differentstravaux proposant des gabarits de scenarios (de maniere explicite ouimplicite) destines aux APCD a base de projets rencontres dans lalitterature. Plus generalement, nous aborderons tous les travaux ayantabouti a la proposition de scenarios pedagogiques mais egalement ceuxdont la vocation fut de realiser des outils supportant l’execution detels scenarios. Nous presentons tout d’abord les gabarits de scenariospedagogiques pour APCD de projets rencontres dans la litterature.Puis, nous listons quelques exemples d’implementations de scenarioset d’outils informatiques destines a supporter ces scenarios. Enfin,nous concluons en proposant un tableau recapitulatif des travauxetudies.
Table des matieres2.1 Gabarits de scenarios pedagogiques . . . . . . . . . . 26
2.1.1 SPLACH . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.2 Le projet NetPro . . . . . . . . . . . . . . . . . . . . . 272.1.3 APC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.4 SYMBA . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.5 iPedagogique . . . . . . . . . . . . . . . . . . . . . . . 302.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2 Autres travaux relatifs aux APCD de projets . . . . 352.2.1 Exemples de scenarios . . . . . . . . . . . . . . . . . . 352.2.2 Outils supportant les APCD de projets . . . . . . . . 40
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 43
26 Etat de l’art
2.1 Gabarits de scenarios pedagogiques pour les APCD a
base de projets
2.1.1 SPLACH
2.1.1.1 Presentation
SPLACH (Support d’une pedagogie de projet pour l’apprentissage collectif hu-main a distance) est le fruit des travaux de these de Sebastien George, au sein dulaboratoire d’informatique de l’universite du Maine [George, 2001]. Ces travauxse situent dans un contexte de passage des environnements interactifs d’appren-tissage avec ordinateur (EIAO) aux environnements interactifs d’apprentissage adistance (EIAD).
SPLACH propose un environnement apprenant comportant des outils de plan-ning, reunion, courrier, forum, documentation, et des outils specifiques au do-maine. Un environnement « chef de projet », relativement voisin de l’environne-ment apprenant, est egalement disponible, ainsi qu’un environnement « profes-seur », permettant la definition et la mise en place des scenarios de projets. En-fin, SPLACH propose un outil d’analyse automatique des comportements sociauxlors des conversations synchrones mediatisees, fonde sur des actes de langage, etpermettant la determination de profils de comportements sociaux (animateur,verificateur, queteur, independant).
Sebastien George fonde ses travaux sur l’hypothese selon laquelle la mise adisposition d’outils informatiques de collaboration ou de cooperation n’est passuffisante a l’installation d’une dynamique collective au sein des groupes de projet,mais que cet apport technique doit etre accompagne d’un scenario pedagogiqueconcu de maniere a creer des interdependances fortes entre apprenants. Le gabaritde scenario pedagogique propose dans SPLACH (il s’agit bien d’un gabarit car ilpeut etre utilise dans differents domaines) est presente dans la section suivante.
2.1.1.2 Scenario pedagogique
Dans SPLACH, un projet se decompose en etapes (∼ sous-projets) lineaires(les etapes se suivent sequentiellement). Les apprenants sont organises en groupes,et suivis par un tuteur appele chef de projet. Chaque etape est constituee d’unephase de travail individuel asynchrone puis d’une phase de travail collectif syn-chrone, comme le montre la figure 2.1.
Phase asynchrone Dans une phase asynchrone, chaque apprenant de l’equipetravaille a une tache individuelle, a partir d’un document d’equipe en entree(cahier des charges ou document provenant de l’etape precedente).
2.1 Gabarits de scenarios pedagogiques 27
Cahierdes
chargesdu projet
Tâchedu sujet
1
Documentd'analysedu sujet 1
Tâched'équipe
Documentd'analyse
del'équipe
Phase asynchrone Phase synchrone
Sujetapprenant
1
Sujetapprenant
2
Sujetapprenant
3
Tâchedu sujet
2
Tâchedu sujet
3
Documentd'analysedu sujet 2
Documentd'analysedu sujet 3
Fig. 2.1 – Une etape de projet dans SPLACH (d’apres [George, 2001])
Phase synchrone Dans une phase synchrone, l’equipe travaille collectivement apartir des documents crees lors de la phase asynchrone, et produit un documentd’equipe en sortie.
Les apprenants ont a leur disposition un certain nombre d’outils (forum, chat,planning, etc.) integres a l’environnement SPLACH pour realiser les taches indi-viduelles et collectives. La validation d’une etape (et donc la possibilite de passera l’etape suivante) est decidee par le chef de projet.
2.1.2 Le projet NetPro
2.1.2.1 Presentation
NetPro est un projet pilote europeen, qui a ete initie en 1997 et acheve en2003 [Markkanen et al., 2001], avec le support de la commission de la Commu-naute Europeenne au sein du projet Leonard de Vinci. Son objectif principalest la creation d’outils informatiques destines a faciliter la pedagogie par projet.Dans le cadre de ce projet a ete developpe un systeme informatique de gestion del’apprentissage oriente par projet, qui porte le nom de NetPro Learning System.Ce systeme est dote d’une interface nommee Project Deliverable Center (PDC),comprenant un espace d’administration permettant aux concepteurs d’activitespedagogiques d’administrer leurs projets, ainsi qu’un espace apprenant permet-tant aux etudiants de gerer leurs projets ou encore de consulter les travaux deleurs pairs.
2.1.2.2 Scenario pedagogique
Dans l’approche retenue par NetPro, un projet est considere comme un coursa part entiere. Le projet est divise en taches. Les apprenants sont amenes a
28 Etat de l’art
planifier leur travail, puis a realiser ces taches. La realisation des taches donnelieu a la production de « deliverables » (∼ contributions : documents, programmesinformatiques, etc.), qui sont partages avec les autres groupes. Ainsi, les groupesde projet sont invites a consulter les travaux des autres groupes travaillant surdes sujets voisins, a apporter un feedback aux auteurs des travaux (grace a desquestionnaires preetablis par les enseignants) et, eventuellement, a s’en inspirer.
2.1.3 APC
2.1.3.1 Presentation
L’APC (Activite pedagogique collective) est une recherche initiee par AnneLapujade au debut de l’annee 2003, dans le cadre du projet SYSMOOSE1 du poleregional picard STEF2. Cette recherche, actuellement menee au sein du labora-toire Savoirs et Socialisations de l’UPJV, consiste en la modelisation d’activitespedagogiques a base de projets [Lapujade et al., 2003]. Ce travail a donne lieu audeveloppement d’un outil support d’activites collectives distantes inserable dansune plateforme d’enseignement a distance et fonde sur une architecture quatretiers. Un modele UML de gabarit de scenario pedagogique adapte a la pedagogiede projet a ete propose, et une APC d’apprentissage du langage C++ a eterealisee par instanciation de ce modele.
2.1.3.2 Scenario pedagogique
Un projet APC est compose d’etapes (qui peuvent elles-memes etre composeesde sous-etapes), permettant chacune d’atteindre un objectif pedagogique associea un ou plusieurs grains de cours, et dont la duree moyenne est fixee par l’au-teur. Les etapes peuvent regrouper des activites individuelles (travail cooperatif)ou collectives (travail collaboratif), certaines etapes individuelles pouvant etrerealisees simultanement par chaque membre du groupe : dans ce cas, la valida-tion de toutes les etapes (par les membres du groupe et le tuteur) entraıne lepassage a l’etape suivante. La realisation de ces etapes pourra etre effectuee enligne ou hors-ligne selon la nature de la tache a accomplir. Enfin, certaines etapespeuvent etre abstraites : elles ne donnent pas lieu a un travail mais doivent tou-jours etre decomposees en sous etapes (ce qui permet de structurer le scenariopedagogique). La figure 2.2 presente un exemple d’instanciation de ce modele descenario pedagogique en une activite d’apprentissage du langage C++.
1Systemes supports de methodes pour concevoir et organiser des services et ressourcespedagogiques en ligne, s’integrant dans une infrastructure de type « plate-forme ».
2Systemes et technologies en education et formation.
2.1 Gabarits de scenarios pedagogiques 29
Gérer une université
Programmation declasses simples
Compositionmonovaluée d'objets
Héritageentre classes
Compositionmultivaluée
Associationentre classes
Finalisation del'application
Programmationde la
classe Chaîne
Programmationde la
classe Date
Programmationde la
classe Adresse
Programmationde la
classe Personne
Programmationde la
classe Étudiant
Programmationde la
classe Enseignant
Écriture d'uneliste chaînée
générique
Écriture d'uneliste
d'objets
Programmationde la
classe Université
Proposerune
solution
Programmerla
solution
Programmation de la
classe Élément
Programmationde la
classe Liste
Programmationde la classe
ListeEnseignants
Programmationde la classe
ListeUV
Synchro Synchro Synchro Séquence Séquence
Séquence Synchro
Séquence
Étape individuellecoopérativeapprenant 1
Étape individuellecoopérativeapprenant 2
Étapecollaborative
Légende
Fig. 2.2 – Scenario pedagogique de l’activite d’apprentissage du C++
2.1.4 SYMBA
2.1.4.1 Presentation
SYMBA est le fruit des travaux de Marie-Laure Betbeder, dans le cadre d’unethese de doctorat d’informatique du laboratoire d’informatique de l’universite duMaine [Betbeder, 2003]. Ces travaux ont abouti a la creation d’un environnementmalleable3 support d’activites collectives en contexte d’apprentissage. L’objectifpedagogique du projet4 confie aux apprenants est d’inciter ces derniers a menerune reflexion de fond concernant l’organisation de leur travail collectif, et de favo-riser la creation d’une communaute d’apprenants. L’approche a pour fondementla theorie de l’activite, cadre general d’analyse de differentes formes d’activiteshumaines.
2.1.4.2 Scenario pedagogique
Les etudiants, organises en groupes de 6 a 7 personnes, doivent fournir untravail de recherche d’information et de synthese. Le scenario est decrit par unealternance de phases synchrones et asynchrones, individuelles et collectives. L’ori-ginalite de la demarche consiste en la consideration de la planification du travail(et donc la definition des taches) comme une tache a part entiere. Ainsi, les appre-nants de chaque groupe sont amenes a s’interroger sur leur organisation, et a for-maliser leur demarche au sein d’un environnement informatique nomme SYMBA.Cette reflexion de planification est consideree comme une veritable tache, et s’ef-fectue grace a un outil de planification des etapes et un outil de definition destaches au sein de ces etapes.
3Un systeme informatique est dit malleable s’il permet a ses utilisateurs de l’adapter a leursbesoins, et que cette action d’adaptation constitue l’une des fonctionnalites du systeme.
4[Betbeder, 2003] ne parle pas de projet ni de pedagogie de projet en ces termes, mais plutotd’activite collective mediatisee. Cependant, nous jugeons ces travaux pertinents dans le cadrede nos recherches, puisqu’ils rentrent dans le cadre d’etude defini precedemment.
30 Etat de l’art
2.1.5 iPedagogique
2.1.5.1 Presentation
iPedagogique est une plate-forme auteur pour l’enseignement en presentielet a distance d’unites de valeur scientifiques et techniques dont la pedagogie estorientee projet [Fougeres et al., 2002]. Cette plateforme a ete developpee par Phi-lippe Canalda, Alain-Jerome Fougere et Pascal Chatonnay au sein de l’universitede technologie de Belfort-Montbelliard, suite a un appel a projet interne « Innova-tions pedagogiques ». iPedagogique propose un gabarit de scenario pedagogiquedestine aux APCD de projets dans le domaine de l’apprentissage de l’informa-tique.
2.1.5.2 Scenario pedagogique
La demarche adoptee ici est fondee sur une approche de modelisation de lapedagogie de projet s’inspirant des procedes observes dans le secteur automobile.Les acteurs sont de quatres types :
– les apprenants, qui realisent le projet ;– l’enseignant « commanditaire » du projet (∼ l’auteur) ;– le tuteur, qui encadre les groupes d’apprenants ;– l’evaluateur, charge de noter les travaux realises.
En debut d’activite, les apprenants constituent eux-meme leurs groupes deprojets, puis choisissent un sujet de projet (le tuteur peut alors emettre des com-mentaires ou oppositions). Le projet est constitue de six phases distinctes (consti-tution des groupes et choix du sujet, redaction du cahier des charges, conception,realisation, tests, redaction de la documentation). La validation des etapes de pro-jet depend quant a elle de certaines contraintes (envoi d’un document, reunion depersonnes ou encore validation par le responsable). Le diagramme d’interactiondans les projets est presente par la figure 2.3 page 31.
2.1 Gabarits de scenarios pedagogiques 31
Étudiant Mener le projetRôle :membre du projet
EnseignantSuivre le projetRôle :expert et tuteur
Paramétrage du site
Définition des projetset du planning
Attente
Choix du sujet Choix du groupe
Administration groupesRépartition par tuteur
Phase 0
Rédactioncahier descharges
Spécificationsfonctionnelles
Rapportd'avancement
Lecture
Phase 1
Phase 2
Co-conception dusystème logiciel
Définition du plan, testsDéfinition du plan, tests
Codage
Prise RDV
Assisté par lesystème
Phase 4
Phase 3
Test, intégration, validation du système
Phase 5
Rédaction de la documentation
[ Fonctions sélectionnées ]
Soutenance
Évaluation/Décision
Sujet, groupeInscription
OppositionOpptionnel
CdC, rapport d'avancementValidation
RéponseObligatoire
Lecture
Compte renduValidation
RéponseOpptionnel
Vérifiation
HoraireRdV
CommentaireOpptionnel
Lecture
Livraison, rapport de testsInformation
CommentairesOpptionnel
Lecture
DocumentInformation
CommentairesOpptionnel
Tâches parallèles
Mise à dispositionde documents
Suivi de projetau cas par cas
Édition de l'agenda(PRV), affichage
Fig. 2.3 – Diagramme d’interaction dans les projets (d’apres [Fougeres et al.,2002])
32 Etat de l’art
2.1.6 Conclusion
Nous avons dresse, dans cette section, une liste des gabarits de scenariospedagogiques pour APCD de projets rencontres dans la litterature. Ces gabaritsont tous des caracteristiques communes et quelques differences. Nous presentonsci-apres un tableau recapitulatif mettant en exergue l’ensemble de ces differentescaracteristiques.
Tableau recapitulatif
Notre comparaison des gabarits de scenarios s’articule autour de six criteresprincipaux :
– le role de l’activite pedagogique ;– l’objectif pedagogique poursuivi ;– la taille des groupes ;– la planification du travail ;– la nature des flux de communication inter-groupes ;– le degre de liberte d’organisation.
Nous detaillons ces criteres dans les paragraphes qui suivent.
Role de l’activite Le role de l’APCD de projets peut etre :– principal : le projet se substitue au cours (apprentissage guide par le projet) ;– complementaire : l’activite de projet complete le cours.
Objectif pedagogique principal de l’activite Marie-Laure Betbeder propose uneclassification des objectifs pedagogiques d’une activite collective d’apprentissageen quatre categories [Betbeder, 2003] :
– l’objectif est un apprentissage lie au domaine ;– l’objectif est le developpement de competences de haut niveau (analyse,
synthese, evaluation) ;– l’objectif est l’apprentissage du travail collectif ;– l’objectif est de structurer un public cible en une communaute d’apprenants
(ou groupe d’apprentissage), c’est-a-dire de creer des liens sociaux entreindividus.
Planification du travail La planification du travail correspond a l’ordonnancementdes taches a accomplir par les groupes d’apprentissage. Cette planification peutetre effectuee :
– par l’auteur de l’activite ;– par les apprenants eux-memes ;– par l’auteur et les apprenants en partie.
2.1 Gabarits de scenarios pedagogiques 33
Flux intergroupes Les groupes sont tres rarement isoles, et generalement l’APCDprevoit des echanges entre les differents groupes. Ces echanges peuvent prendredifferentes formes :
– feedback ou commentaires : les apprenants consultent les travaux de leurspairs et leur apportent des commentaires et/ou suggestions ;
– travaux intergroupes : l’activite prevoit des taches d’apprentissage devantetre effectuees par l’ensemble des apprenants ou par des rassemblements degroupes ;
– communications simples (ex. : chats, forums, etc.) : l’activite ne prevoitpas de tache specifique mettant en jeu plusieurs groupes, mais permet auxdifferents groupes de communiquer afin d’accroıtre leur efficacite.
34 Etat de l’art
SP
LA
CH
Net
Pro
AP
CSY
MB
AiP
edag
ogiq
ue
Rol
ede
l’act
ivit
eC
ompl
emen
tair
eP
rinc
ipal
Com
plem
enta
ire
Com
plem
enta
ire
Com
plem
enta
ire
Obje
ctif
peda
gogi
que
prin
cipa
lD
omai
neD
omai
neD
omai
neSt
ruct
urer
unpu
-bl
icci
ble
enun
eco
mm
unau
ted’
ap-
pren
ants
Dom
aine
Tai
llede
sgr
oupe
s2–
33
26–
72
Pla
nific
atio
ndu
trav
ail
Aut
eur
Aut
eur
etap
pre-
nant
sA
uteu
rA
uteu
ret
appr
e-na
nts
Aut
eur
Flu
xin
terg
roup
esC
omm
unic
atio
nssi
mpl
esFe
edba
ck(a
ppre
ciat
ion
des
trav
aux
des
autr
esgr
oupe
sgr
ace
aure
mpl
issa
gede
ques
tion
nair
es)
Com
mun
icat
ions
sim
ples
Tra
vaux
inte
r-gr
oupe
sC
omm
unic
atio
nssi
mpl
es
Deg
rede
liber
ted’
or-
gani
sati
onM
oyen
Moy
enFa
ible
Fort
Faib
le
Tab.2.
1–
Rec
apitula
tifde
spr
inci
pale
sca
ract
eris
tiqu
esde
sga
bari
tsde
scen
ario
set
udi
es
2.2 Autres travaux relatifs aux APCD de projets 35
2.2 Autres travaux relatifs aux APCD de projets
De nombreux travaux et ouvrages traitent de la pedagogie de projet, et plusparticulierement des APCD a base de projets. Bien que toutes ne proposent pasde gabarit de scenario, nombre d’entre-elles apportent des elements interessants etpouvant servir notre problematique. C’est la raison pour laquelle nous avons choiside presenter, dans cette section, quelques travaux particulierement representatifs,apportant un eclairage supplementaire sur notre problematique. Cette sections’articule en deux parties :
– quelques exemples de scenarios relatifs aux APCD de projets ;– quelques outils permettant de mettre en œuvre de tels scenarios.
2.2.1 Exemples de scenarios
Nous presentons ici quelques scenarios issus de la litterature. Il ne s’agit pasde gabarits de scenarios, dans le sens ou leur but n’est pas de fournir une struc-ture receptacle a divers scenarios en fonction d’un but pedagogique donne : ils’agit soit d’organisations tres generales (meta-scenarios), soit de scenarios tresprecis desquels il est difficile d’isoler un veritable gabarit reutilisable. Cepen-dant, nous souhaitions presenter ces scenarios afin d’eclairer le lecteur sur lanuance scenario/gabarit de scenario. De plus, notre modelisation devra prendreen compte les pistes fournies par ces exemples d’implementations.
2.2.1.1 La proposition de Berger et Rieben au CNAM
Berger et Rieben ([Berger et al., 2000]), formateurs d’ingenieurs du Conser-vatoire national des arts et metiers, ont mis en place un scenario d’activite deprojet mediatisee par le web (environnement d’apprentissage interactif). Dans cescenario, au fur et a mesure que l’apprenant avance dans le projet, il remplitdes fiches de reperage, afin de temoigner de son avancement et de formaliser lesquestions qu’il se pose. Ces fiches d’avancement a remplir definissent en fait unestructuration du projet (figure 2.4).
Le fonctionnement de l’outil (technologie Web PHP) est fonde sur des forumsde discussion ou les apprenants et les enseignants peuvent poster des fichiers cor-respondant a leur avancement. Quand une fiche est postee par un apprenant,c’est une production qui devient aussi une publication [Berger et al., 2000] (doncqui est consultable par les autres apprenants).
Le cote collectif du travail passe essentiellement par une mediatisation par lesforums de discussions, et le mail. Cependant, aucune sequence de phases collec-tives et/ou individuelles n’est precisee par les auteurs.
36 Etat de l’art
Contextualisation du projet
Analyse préalable
Mise en oeuvre
Prise de reculn˚7 - Analyse de la stratégie développée
n˚1 - Une première idée de projet
n˚2 - Repérage du problème
n˚3 - Plan d'étude
n˚4 - Plan de travail
n˚5 - Stratégie du projet
n˚6 - Travail avec les acteurs du projet
n˚8 - Présentation synthétique du projet
Fig. 2.4 – Schema de structuration de l’accompagnement de projet (d’apres [Ber-ger et al., 2000])
Cet exemple de scenario (il s’agit bien d’un scenario en plus d’un outil, puis-qu’il structure les travaux des apprenants) nous est utile dans le cadre de notremodelisation generique, dans le sens ou il apporte un element nouveau (i.e. nonrencontre dans les autres scenarios ou gabarits de scenarios) : le caractere pu-blic des commentaires des enseignants sur un travail. Autrement dit, tous lesapprenants doivent pouvoir consulter, selon [Berger et al., 2000], les retours desenseignants concernant les travaux de leurs pairs (par le biais d’un forum). Cetelement est a integrer dans notre modele, afin de pouvoir gerer ce cas de figure.
2.2.1.2 « La pedagogie de projet comme fondement pour l’ACAO »
Lone Dirckinck-Holmfeld propose, dans « Project Pedagogy as the Foundationfor Computer Supported Collaborative Learning » ([Dirckinck-Holmfeld, 1994]),une organisation type de projet a des fins pedagogiques. Un projet y est planifiepour une duree d’un semestre, et l’auteur precise que la majorite des projetssuivent une organisation relativement similaire. Cette organisation est decrite ensept etapes :
1. Creation des groupes de projets, en fonction d’une part de l’interet desapprenants pour les sujets proposes, d’autre part des preferences sociales ;
2. Chaque groupe analyse le probleme pose, afin de transformer toutes lesidees en une representation formelle ;
3. Le travail est planifie, et une division du travail au sein du groupe estetablie ;
4. La phase de recherche, consistant en la realisation du travail est effectueeen suivant l’organisation pre-etablie, tout en devant gerer des evenementsimprevus (dans les conditions d’un projet-reel) ;
2.2 Autres travaux relatifs aux APCD de projets 37
5. Sur la base de la phase precedente, le groupe tire des conclusions judicieusesen fonction de la problematique fixee en debut de projet (ce qui le menegeneralement a s’apercevoir qu’une autre formulation de la problematiqueet/ou de la methodologie aurait ete plus judicieuse) ;
6. Les resultats du projet sont explicites dans un rapport, qui doit, en plusdes considerations techniques en lien avec la problematique initiale, rendrecompte des lecons tirees sur le plan du travail collectif ;
7. Le rapport est evalue et complete par une soutenance orale, dans laquellele groupe presente son travail a l’enseignant et un evaluateur exterieur.
Ce schema d’organisation est tres general, et n’entre pas dans les details del’ordonnancement des taches individuelles et collectives, etc. Il donne neanmoinsun apercu du decoupage d’un projet en phases, et caracterise le fait qu’en reglegenerale, la derniere phase d’un projet pedagogique consiste en une evaluation.Cette etude est egalement tres interessante dans le sens ou elle relate d’une pra-tique ecologique : tous les cours de l’universite d’Aalborg (Danemark) ont eteconcus sur la base de cette methodologie nommee « pedagogie de projet orientee-probleme ».
2.2.1.3 « Un cadre methodologique pour l’apprentissage collaboratif a base de pro-jets en reseau »
Ce travail de recherche a ete initie par Thanasis Daradoumis, Fatos Xhafaet Joan Manuel Marques, dans un projet de l’Open University of Catalonia[Daradoumis et al., 2000]. L’objectif est de proposer un scenario pedagogique abase de travail collaboratif, dans le domaine de l’informatique, et plus parti-culierement dans le cadre de projets de developpement de logiciels. Il n’y a pasde proposition d’outil destine a supporter le scenario presente : ce dernier estsuppose constituer une approche originale pour utiliser les technologies existantes(logiciels de CSCW) afin de mettre en place une pedagogie de projet.
Le scenario debute par une etape collective de discussion asynchrone, destineea permettre aux apprenants de se familiariser avec l’activite et a preparer l’etapesuivante de formation des groupes. Cette seconde etape, consideree comme tresimportante, permet aux apprenants d’engager des discussions afin de definir desgroupes de projet efficaces, notamment en fonction de donnees pratiques (horairesde disponibilite de chacun pour le travail collaboratif, buts individuels, etc.). Al’issu de cette deuxieme etape, les groupes nouvellement formes choisissent untype d’organisation, a savoir :
– « democratique » : tous les membres sont au meme niveau et assurent lesmemes responsabilites ;
– « democratique avec coordinateur » : idem, mais dans ce cas un coordina-teur (un membre du groupe) est nomme pour chaque phase du projet afin
38 Etat de l’art
de guider le groupe dans la phase en question ;– « leader » : un membre du groupe assure le role de coordinateur durant
tout le projet.
Lorsque les groupes sont crees et structures, l’execution du projet commence,et se deroule en une suite d’etapes collectives et individuelles :
1. Etude du probleme : etape collaborative (groupe complet) ;
2. Planification du travail : etape collaborative (sous-groupes) ;
3. Realisation : etape individuelle puis collaborative ;
4. Tests ;
5. Redaction d’un rapport : etape collaborative.
L’evaluation s’effectue en deux parties, la note finale en etant la moyenne :– une evaluation individuelle (pour chaque membre du groupe), prenant en
compte la qualite des contributions de chaque apprenant ;– une evaluation collective (note de groupe), s’interessant au resultat produit
par le groupe (rapport terminal de groupe, etc.).
Ce scenario est original dans le sens ou il introduit le concept de role au seindes groupes (coordinateur, leader. . .). Cette caracteristique est a integrer dansnotre modele.
2.2.1.4 Learn-Nett
Learn-Nett [Charlier et al., 2000] definit un scenario impliquant des groupesd’apprenants dans des projets collectifs. Un projet est constitue d’etapes (chaqueetape definissant une serie de taches a realiser), et faisant appel a un certainnombre d’outils suggeres (forum, chat, visioconference. . .).
Un projet Learn-Nett se decompose en 5 etapes :
1. Composition des groupes, prise de contact ;
2. Decision a propos du theme de travail, redaction d’un premier plan detravail ;
3. Action, realisation du travail ;
4. Finalisation du travail ;
5. Evaluations.
2.2.1.5 « Favoriser la construction des connaissances dans la pedagogique de projeten reseau »
Veli-Pekka Liflander propose, dans l’article « Expansive Knowledge Construc-tion in Network-Based Project Learning » [Liflander, 1999], un scenario de cours
2.2 Autres travaux relatifs aux APCD de projets 39
fonde sur une APCD de projets. Le scenario est prioritairement destine a favori-ser l’acquisition de savoirs et savoir-faire lies a un domaine precis, mais egalementl’apprentissage du travail collectif.
Les apprenants, reunis au sein de groupes, travaillent a l’elaboration de solu-tions informatiques a un probleme donne, produisant des rapports intermediairesde groupe, des prototypes et un rapport terminal. Toutes ces productions fontl’objet d’une notation collective.
Ce scenario possede plusieurs particularites interessantes dans le cadre denotre etude.
Premierement, la constitution des groupes est effectuee librement par des« chefs de groupes » designes par l’enseignant (le tuteur de l’activite). Les groupesne sont donc pas crees a priori par le tuteur, mais leur constitution fait partiedes taches conferees aux apprenants.
De plus, le scenario mele roles hierarchiques (« chef de groupe ») et rolesdisciplinaires : expert multimedia, expert IHM, secretaire, etc.
Enfin, il existe dans ce scenario des flux inter-groupe : en particulier, un desgroupes est dit superviseur des autres groupes. Cette caracteristique importante,consistant a permettre au concepteur d’instaurer des etapes mettant en jeu plu-sieurs groupes pour leur realisation, est a integrer a notre modelisation.
2.2.1.6 « Une experience d’implantation d’activites organisees a distance au niveauuniversitaire »
Le scenario propose par Bruno De Lievre, Jean-Jacques Quintin et ChristianDepover [De Lievre et al., 2002] apporte un angle de vue complementaire dansle cadre de nos travaux, puisqu’il s’agit d’une experience menee dans le domainede la psychologie. Les activites proposees aux etudiants sont mediatisees par laplate-forme de formation a distance developpee par l’Unite de technologie del’education (UTE) de l’universite de Mons-Hainaut.
Il s’agit de scenarios pour travaux pratiques (que nous considereront commedes « mini-projets », donc entrant dans le cadre de notre etude), destines a fa-voriser le travail collaboratif. Une typologie d’activites a distance favorisant letravail collaboratif est proposee. Cette typologie distingue les scenarios utilisantune premiere etape individuelle, ou une premiere etape collective, puis prend encompte les suites possibles a partir de chaque cas (enrichissement, creation d’unnouveau document. . .). Les possibilites de creation de groupes par les apprenantseux-meme ou par le tuteur sont egalement envisagees.
Cet article definit donc les bases pedagogiques permettant d’informer (et nond’orienter) un concepteur d’activites pedagogiques collectives, en mettant a saconnaissance les differentes options possibles pour la mise en place d’APCD.
40 Etat de l’art
L’interet de cet article pour nos travaux est d’apporter un ensemble de scenariospertinents au niveau pedagogique que notre methode de conception devra per-mettre de creer.
2.2.2 Outils supportant les APCD de projets
Les outils informatiques presentes dans cette section n’embarquent pas de ga-barit de scenarios pedagogiques destine a supporter les APCD de projets. Il s’agituniquement de supports techniques, proposant des moyens de communication etde partage (chat, forum, FTP, etc.) specialement concus pour les APCD.
2.2.2.1 Zebu
Zebu [Ward et al., 1997] est un groupware educatif destine a supporter lesAPCD de projets. Zebu est fonde sur la technologie Web, et est en fait constitued’un ensemble de pages hypertextes. Un outil de communication asynchrone (fo-rum) est propose, ainsi que des espaces de partage de documents (les apprenantsont acces aux travaux de leurs pairs tout au long de la duree du projet) et desgaleries (ressources a la disposition des apprenants). L’outil permet egalement desupporter les taches de l’enseignant (creation des groupes de projet, repartitiondes apprenants dans les groupes, etc.).
Le travail des apprenants consiste en la construction collaborative de pages« multimedia » incluant du texte, des illustrations, du son, de la video et desliens hypertextes. Les enseignants peuvent proposer des gabarits de pages afin deguider les apprenants dans leur travail.
2.2.2.2 « Outils telematiques pour le support de projets en groupes dans l’enseigne-ment superieur »
L’article Telematic Tools to Support Group Projects in Higher Education pro-pose un certain nombre d’outils telematiques (outils et services associant lestelecommunications et l’informatique) mis en œuvre a l’universite de Twente(Pays-Bas), et destines a supporter la pedagogie de projet en groupe. Ici encore,la solution proposee est fondee sur une technologie Web [Collis, 1997a].
Le projet a permis d’identifier quelques problemes recurrents lors de la miseen place d’APCD de projets, et de proposer des reponses « telematiques » a cesproblemes. Le tableau 2.2 presente ces propositions. Au niveau technique, l’en-vironnement propose notamment une page de planning permettant de consulterles taches a realiser, une page recensant les differents groupes et leurs membres,ou encore une page de definition d’etapes de projet destinee a l’enseignant.
2.2 Autres travaux relatifs aux APCD de projets 41
Problemes recurrentsdans les APCD deprojets
Propositions du « Tele-project »
Preservation de lacohesion et du rythme ducours a mesure que lesapprenants s’immergentdans leurs projetsrespectifs
Un site WWW de cours integrant des materiels pedagogiques,un support au travail de projet et des outils de communication.A travers ce site, le planning et la progression de chaque groupepeut etre visible de tous.
Motivation et structura-tion de la collaboration
Choix d’une tache (developpement d’un produit commun) etd’une strategie pedagogique, la methode « Jigsaw » par la-quelle chaque membre du groupe a des contributions claire-ment definies et independantes de celle du groupe. Choix d’unestrategie de combinaison de membres locaux et distants au seinde chaque groupe.
Motivation et structura-tion de la communication
Un rapporteur dans chaque groupe est responsable des contactsavec le professeur durant les activites « on-line » hebdoma-daires, structurees par le professeur. Utilisation d’une formed’archivage de mails inspiree des newsgroup et integree au site.
Maintenir une « memoirede groupe »
Utilisation d’un espace de travail partage integre au site decours WWW (en particulier, l’outil « BSCW » concu par GMD,Darmstadt, Allemagne).
Charge de travail de l’en-seignant
Utilisation d’un outil graphique pour la production des pagesWWW, et developpement de la « Milestone Suite » (decritedans [?]), facilitant la preparation des plannings de cours etdonnant automatiquement des informations sur la situation ac-tuelle.
Organisation et executionde l’evaluation indivi-duelle et inter-groupe
Utilisation du site WWW aussi bien en tant que produit qu’entant qu’environnement de travail. Ceci permet les comparaisonsinter-groupes ainsi que les evaluations fondees sur les resultatscollaboratifs d’ensemble. Utilisation d’un outil d’evaluationintegre au site WWW. Ceci permet un enregistrement efficacedes feedbacks, une comparaison directe entre les sous-groupesd’etudiants, et la visualisation par les apprenants des simili-tudes et differences entre leurs impressions sur les cours et cellesde leurs pairs.
Tab. 2.2 – Ameliorer l’efficacite de l’apprentissage par projet en groupe :problemes et reponses proposees par le Tele-project a l’universite de Twente (tra-duction personnelle depuis [Collis, 1997a])
42 Etat de l’art
2.2.2.3 ePBL
ePBL est un outil developpe dans le cadre de la these de Vivian ParaskeviSynteta [Synteta, 2002], destine a gerer les projets en ligne. Les trois fonctionsde base de ePBL sont les suivantes :
– systeme de gestion de fichiers permettant de deposer et de consulter descontributions (redigees selon une grammaire XML predefinie, apportantune structuration sous certaines contraintes) ;
– outils d’evaluation, d’audit et d’annotation a destination de l’apprenant(lies aux fichiers XML) ;
– outil de redaction de documents avec une grammaire assez peu contrai-gnante, et permettant de publier les resultats sous la forme d’un « livre » ho-mogene.
L’outil est fourni sous la forme d’un module PostNuke5.
2.2.2.4 Coler
Coler (Collaborative Learning Environment for Entity-Relationship Mode-ling) [Suthers, 2002] est un environnement Web d’apprentissage collaboratif danslequel des apprenants, repartis geographiquement, sont amenes a resoudre desproblemes de modelisation de donnees (elaboration de modeles entite-association,etc.). La resolution s’effectue en petits groupes, et de maniere synchrone. Les ap-prenants resolvent dans une premiere phase le probleme individuellement puisde maniere collective au sein de l’environnement. Coler propose egalement unsysteme d’assistance automatique au travail collectif sous forme de conseils emisaux apprenants.
2.2.2.5 Argue & Graph
Argue & Graph [Jermann et al., 1999] est un environnement support d’ap-prentissage collectif, dont le but est de declencher l’apprentissage de chaque par-ticipant par le biais de discussions. Ces discussions s’effectuent via des question-naires.
Le scenario pedagogique peut s’exprimer de la maniere suivante :
1. Les apprenants remplissent un questionnaire, dont le contenu depend del’activite, chaque reponse devant etre argumentee (argue) ; le logiciel pro-duit alors une synthese des reponses donnees, sous la forme de graphiques(graph), ce qui permet a l’enseignant de former des groupes heterogenes(i.e. composes d’apprenants ayant des visions tres differentes) ;
5PostNuke est un systeme collaboratif de gestion de contenus et de communautes. Il s’agitd’un ensemble d’outils permettant de construire un site Web genere dynamiquement.
2.3 Conclusion 43
2. Les apprenants travaillent en groupes afin de proposer une nouvelle version(collective) du travail (remplissage du questionnaire) ;
3. Le logiciel produit une deuxieme synthese des reponses donnees, toujourssous forme de graphiques ;
4. Les apprenants redigent enfin une synthese individuelle, qui est ensuitepubliee sur le web.
Les auteurs precisent que le dispositif permet d’engager les etudiants dans unprojet collaboratif qui permet a chacun de developper une reflexion personnelle,et que le fait de voir leurs reponses reifiees sur le Web (ainsi que celles desautres), de se confronter, ou encore de devoir chercher des solutions communessont benefiques pour la reflexion et la formation de concepts.
2.3 Conclusion
Nous avons presente, dans ce chapitre, les principales contributions de re-cherches concernant les APCD de projets mediatisees par ordinateur. Parmi cescontributions, nous avons releve des gabarits de scenarios pedagogiques et lesavons compares selon des criteres que nous avons proposes. L’ensemble de cesgabarits, ainsi que tous les autres travaux presentes dans ce chapitre, vont nouspermettre, dans le chapitre suivant, de degager une typologie d’activites collec-tives distantes a base de projets.
Chapitre 3
Vers une typologie de scenariospedagogiques pour les APCD
a base de projets
Le but de nos travaux etant de disposer de moyens d’aider leconcepteur d’APCD de projets dans sa demarche, nous devons pro-poser des criteres permettant a ce dernier de se diriger vers le typede scenario adapte a ses objectifs pedagogiques. C’est la raison pourlaquelle, apres avoir repertorie les differents gabarits de scenariospresents dans la litterature, nous proposons d’etablir une typologiede scenarios pour les APCD de projets.
Table des matieres3.1 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . 463.2 Criteres de discrimination . . . . . . . . . . . . . . . . 46
3.2.1 Taille des groupes . . . . . . . . . . . . . . . . . . . . 463.2.2 Strategie d’evaluation . . . . . . . . . . . . . . . . . . 473.2.3 Degre de liberte d’organisation . . . . . . . . . . . . . 473.2.4 Roles au sein des groupes . . . . . . . . . . . . . . . . 47
3.3 Proposition d’une typologie . . . . . . . . . . . . . . . 48
46 Vers une typologie de scenarios pour les APCD de projets
3.1 Etat de l’art
Les APCD de projets s’inserent dans le cadre plus general des activites col-lectives, et en heritent donc certaines proprietes. Parmi ces dernieres, la notiond’objectif est centrale. En effet, le concepteur d’APCD de projets, comme toutconcepteur d’activite pedagogique collective, produit un scenario en fonction d’unbut precis quand a l’apprentissage attendu.
Ainsi, comme nous le precisions dans le chapitre 2, Marie-Laure Betbeder pro-pose une typologie des activites collectives mediatisees en fonction de leurs objec-tifs [Betbeder, 2003]. Nous proposons d’adapter cette typologie a la pedagogie deprojet et de la completer par des criteres de discrimination permettant d’orienterle concepteur vers un type de scenario adapte a ses besoins pedagogiques.
Remarque 2 La typologie que nous proposons est uniquement fondee sur l’ob-servation et l’analyse des travaux presentes dans le chapitre precedant. Ainsi, ellen’a pas de valeur theorique pedagogique, mais constitue uniquement un moyen deguider le concepteur d’APCD de projets vers un gabarit de scenario approprie ases besoins.
3.2 Criteres de discrimination
3.2.1 Taille des groupes
La taille des groupes est un critere cle lors de la conception d’une APCD deprojets. D’apres les travaux etudies, et d’apres [Betbeder, 2003], des groupes detaille restreinte (typiquement 2–3 apprenants) sont particulierement adaptes a unapprentissage lie a un domaine precis (ex. : apprentissage de la programmation),tandis que des groupes plus importants ont plutot vocation a favoriser les aspectscommunication et structuration d’une communaute d’apprenants.
Vayer et Roncin [Vayer et al., 1987] postulent que l’organisation d’un groupedepend de sa taille. Cette taille est elle-meme fonction de la nature des activitesqui y sont mises en œuvre et des objectifs pedagogiques. Ils distinguent alors troiscategories de groupes :
– le groupe de base, constitue de 4 ou 5 personnes, reunies a partir de choixpersonnels : c’est le groupe ideal pour creer, resoudre des problemes ;
– le groupe restreint, de 8 a 12 personnes, ideal pour une activite collectivede type discussion ;
– le groupe secondaire, ou organisation, correspond a la classe entiere.
Nous retrouvons dans cette proposition de Vayer et Roncin (qui s’adresse ades classes d’enfants) des proportions equivalentes a notre proposition : groupes
3.2 Criteres de discrimination 47
restreints pour la resolution de problemes, groupes plus importants pour le travailcollectif.
3.2.2 Strategie d’evaluation
Les strategies d’evaluation peuvent etre tres diversifiees. Alors que de nom-breux scenarios pedagogiques prevoient une evaluation de groupe en fin de projet(ex. : [Lapujade et al., 2003], [Dirckinck-Holmfeld, 1994]), d’autres introduisentegalement une evaluation individuelle (ex. : [Daradoumis et al., 2000]). Il sembleque l’evaluation individuelle mette l’accent sur le travail lie au domaine et auxsavoirs et savoir-faire acquis par les apprenants, tandis que l’evaluation collec-tive juge plutot des efforts fournis par les equipiers pour s’organiser et travaillerefficacement en groupe.
3.2.3 Degre de liberte d’organisation
Comme le montre le tableau 2.1, certains scenarios prevoient tres precisementles taches a realiser par les apprenants en repartissant ces taches avec une gra-nularite tres fine (ex. : [Lapujade et al., 2003], [Fougeres et al., 2002]), alors qued’autres laissent les apprenants s’organiser et planifier leur travail avec un degrede liberte plus ou moins prononce (ex. : [Betbeder, 2003], [Markkanen et al., 2001].Les scenarios considerant la planification des taches comme une tache a partentiere sont plutot de nature a developper des capacites organisationnelles et detravail collectif, tandis que les scenarios n’autorisant qu’un faible degre d’auto-organisation aux apprenants semblent plus adaptes a un apprentissage lie audomaine.
3.2.4 Roles au sein des groupes
Dans les projets reels, les differents acteurs n’ont que tres rarement le memerole et les memes types de taches a effectuer. La diversite des roles peut se ma-nifester de deux manieres :
– roles hierarchiques (chef de projet, etc.) ;– roles disciplinaires (expert multimedia, en communication, etc.).
Les projets pedagogiques peuvent s’inspirer de cette attribution de role ob-servee dans les projets reels. Par exemple, dans [Daradoumis et al., 2000] ou en-core dans [Collis, 1997a], les apprenants se voient attribuer (ou s’attribuent eux-memes par conciliation en debut de projet) de tels roles.
Nous emettons l’hypothese, au regard des scenarios precites, que les roleshierarchiques sont particulierement adaptes pour l’apprentissage de l’organisationcollective et de la gestion de projet, tandis que les roles disciplinaires permettent
48 Vers une typologie de scenarios pour les APCD de projets
de specialiser les apprenants, donc tendent a favoriser un apprentissage lie a undomaine.
3.3 Proposition d’une typologie
Sur la base des criteres de discrimination enonces precedemment et des typesd’objectifs etablis par M.-L. Betbeder, nous proposons la typologie d’ACPD deprojets presentee par le tableau 3.1 page 49.
3.3 Proposition d’une typologie 49
Tai
lle
des
grou
pes
Str
ateg
ied’e
valu
atio
nD
egre
de
liber
ted’o
rgan
isat
ion
Rol
esau
sein
des
grou
pes
Exem
ple
s
App
rent
issa
gelie
audo
mai
neM
oder
ee(<
4)In
divi
duel
leet
/ou
colle
ctiv
eFa
ible
Non
AP
C,SP
LA
CH
Dev
elop
pem
ent
deco
mpe
tenc
esde
haut
nive
auIn
dete
rmin
eeIn
divi
duel
leM
oyen
Non
Arg
ue&
Gra
ph
App
rent
issa
gedu
trav
ailc
olle
ctif
Moy
enne
Col
lect
ive
Non
Fort
Zeb
u,Lea
rn-
Net
tC
reat
ion
d’un
eco
mm
unau
ted’
appr
enan
tIm
port
ante
(>5)
Col
lect
ive
Fort
Non
SYM
BA
Tab.3.
1–
Pro
posi
tion
d’une
typo
logi
ed’
APC
Dde
proj
ets
Synthese de la premiere partie
Nous avons pose, dans cette premiere partie, le contexte pedagogique de nos re-cherches. Apres avoir rappele brievement en quoi consiste l’apprentissage collectifet par projets, et precise notre vision du concept de scenario pedagogique, nousavons effectue un tour d’horizon des differentes implementations de scenariospedagogiques pour les APCD de projets, incluant des gabarits de scenarios, maisegalement des outils supports de pedagogie de projet. En nous appuyant sur lestravaux ainsi etudies, nous avons pu proposer une typologie permettant de gui-der, dans les grandes lignes, le concepteur de scenarios pour APCD de projetsvers le type d’activite approprie a ses besoins.
Deuxieme partie
Modelisation et analyse desscenarios etudies
Chapitre 4
Notre demarche de modelisation
Notre objectif etant de proposer une methode de conception degabarits de scenarios pour APCD de projets, nous avons, dans lapremiere partie de ce memoire, presente une etude bibliographiquedes travaux relatifs aux APCD de projets, et propose une typologiede scenarios pour ces activites. Le noyau central de notre methodede conception residant en une modelisation des gabarits etudies, nousdevons parvenir a modeliser de maniere judicieuse des differents gaba-rits. Ce chapitre propose une description et une justification de notredemarche de modelisation. Ainsi, apres une presentation generale de lademarche, nous presentons le formalisme MOT, puis la modelisationpar diagrammes de classes UML avant d’expliciter formellement notredemarche de modelisation des types de scenarios rencontres dans lalitterature.
Table des matieres4.1 La modelisation . . . . . . . . . . . . . . . . . . . . . . 544.2 Le formalisme MOT . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . 544.2.2 Concepts manipules . . . . . . . . . . . . . . . . . . . 54
4.3 UML : Unified Modeling Language . . . . . . . . . . . 564.3.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . 564.3.2 Diagrammes . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Resume de notre demarche de modelisation . . . . . 57
54 Notre demarche de modelisation
4.1 La modelisation
Nous entendons par modelisation l’action de creer une abstraction d’une si-tuation reelle a partir de donnees exploitables. Le modele produit par l’action demodelisation est compose de concepts et de regles [Rolland et al., 1988].
En ce qui concerne le produit de la demarche de modelisation, [Walliser, 1977]
distingue deux types de modeles :– le modele theorique ;– le modele empirique.
De toute evidence, nos travaux se situent dans le champ des modeles em-piriques, dans le sens ou ils ne sont pas fondes sur une axiomatisation de faitstheoriques mais sur des observations concretes. Les modeles que nous proposonsdans ce document sont donc des representations de situations reelles dans desformalismes de niveaux d’abstraction plus ou moins eleves.
Dans les sections suivantes, nous presentons les formalismes que nous utili-serons pour modeliser les differents gabarits de scenarios etudies, ainsi que lademarche globale de modelisation employee.
4.2 Le formalisme MOT
4.2.1 Presentation
MOT (Modelisation par objets types) est un formalisme propose par l’equipede Gilbert Paquette [Paquette, 1996] au laboratoire LICEF (Laboratoire d’infor-matique cognitive et environnements de formation), permettant la representationdes connaissances, et axe sur la conception pedagogique. Ce formalisme permetde presenter des processus, les acteurs qui realisent ces processus ainsi que lesequipements et outils necessaires a l’execution des processus. MOT permet doncde modeliser des processus pedagogiques varies dans leurs ensembles.
La particularite dominante de MOT est sa capacite de traitement de deuxniveaux d’abstraction en meme temps : les faits et les connaissances abstraites,ces dernieres etant a leur tour subdivisees en trois categories : les concepts, lesprocedures et les principes (habituellement, ces types de connaissances font l’objetde techniques de modelisation complementaires mais differentes) [Paquette, 1996].
4.2.2 Concepts manipules
Les concepts manipules par MOT sont les suivants :– les procedures, representees graphiquement par des cercles (ex. : Calculersurface) ;
4.2 Le formalisme MOT 55
– les concepts, representes par des rectangles (ex. : Document papier) ;– les principes (causaux ou de controle), representes par des hexagones (ex. :Si x>2, ou encore Client) ;
– les faits, representes par des dodecagones1 (ex. : Anne).
De plus, ces concepts sont relies entre eux par des liens types :– lien de composition (C), reliant une connaissance a l’une de ses composantes
(ex. : « un memoire est compose de chapitres ») ;– lien de regulation (R), qui s’utilise d’un principe vers une autre connaissance
abstraite, pouvant etre un concept, une procedure ou un autre principe (ex. :« un ordinateur regule (∼ realise) une procedure de tri ») ;
– lien intrant-produit (I/P), qui relie un concept a une procedure (ex. : « undocument imprime est un produit de la procedure d’impression ») ;
– lien de precedence (P), qui indique une contrainte temporelle entre deuxprocedures ou principes (ex. : « la conception precede la realisation ») ;
– lien de specialisation (S), qui est la representation d’une sorte de (ex. : « unchercheur en informatique est une sorte de chercheur ») ;
– lien d’instanciation (I), qui relie une connaissance abstraite a un fait (ex. :« Pascal est une instance d’apprenti chercheur »).
La figure 4.1 presente un exemple de modelisation MOT relativement simple,et faisant intervenir la plupart des concepts et des liens disponibles.
Étudiant de DEA
Étudiant
Obtenir DEA
Valider la partiethéorique
Valider le stage
Obtenir unemoyenne d'au moins
10/20Écrire un rapport Rapport
Pascal
I
S
R
C C
P
C C
I/P
Fig. 4.1 – Exemple simple de modelisation MOT : obtention du diplome de DEA
1Polygone a 12 cotes.
56 Notre demarche de modelisation
Nous voyons en la propriete de double niveau d’abstraction proposee parMOT une maniere interessante d’aborder la complexite des systemes etudies (desscenarios pedagogiques), permettant de representer simplement des faits et desconcepts, et tout en gardant un bon niveau de semantique. Cependant, en depit deses avantages, MOT est, par son haut niveau d’abstraction, relativement distantdes preoccupations d’implementation informatique de structures de donnees. Ornotre souhait est d’aider le concepteur dans sa demarche de creation de scenariospedagogiques a des fins d’utilisation de ces derniers via des machines informa-tiques, d’ou un besoin crucial d’exprimer les scenarios crees dans des structuresde donnees reconnues par les langages informatiques. Nous avons donc choisi decompleter notre demarche de modelisation par l’elaboration de diagrammes declasses UML.
4.3 UML : Unified Modeling Language
4.3.1 Presentation
Unified Modeling Language (Langage unifie pour la modelisation) est un lan-gage de modelisation objet, ne de la fusion des trois methodes de modelisationobjet : OMT2, OOD3 et OOSE4, et peut a ce titre s’y substituer sans perte d’in-formation. UML n’est pas une methode : il fournit simplement les elements pourrepresenter et visualiser les artefacts d’un systeme.
4.3.2 Diagrammes
UML definit neuf types de diagrammes :
Vues statiques
– diagramme de classes : representation de la structure statique (classes etrelations) ;
– diagramme d’objets : representation des objets et de leurs liens ;– diagramme de cas d’utilisation : representation des fonctions du systeme du
point de vue de l’utilisateur ;– diagramme de composants : representation des composants physiques de
l’application ;– diagramme de deploiement : representation du deploiement des composants
sur les dispositifs materiels.
2Object Modeling Technique.3Object-Oriented Design : methode proposee par Grady Booch, parfois appelee Booch, ou
encore Object-Oriented Analysis and Design (OOAD).4Object Oriented Software Engineering, egalement appelee Objectory.
4.4 Resume de notre demarche de modelisation 57
Vues dynamiques
– diagramme de sequence : representation temporelle des objets et de leursinteractions ;
– diagramme de collaboration : representation des interactions entre les ob-jets ;
– diagramme d’etats-transition : description des changements d’etats d’unobjet ou d’un composant, en reponse aux interactions avec d’autres objetsou avec des acteurs ;
– diagramme d’activites : representation du comportement d’une methode oud’un cas d’utilisation.
Dans le cadre de notre modelisation, nous nous interessons particulierementaux diagrammes de classes. Le diagramme de classes permet de representer deselements de modelisation statiques (les classes) ainsi que les liens les unissant, afinde montrer la structuration du modele, tout en faisant abstraction des aspectsdynamiques.
Remarque 3 Considerant qu’UML est aujourd’hui tres repandu et bien connude la communaute informatique, nous ne detaillons pas davantage cette section etne proposons pas une presentation complete des differents types de diagrammes.Nous renvoyons le lecteur a [OMG http, 2004] pour une presentation complete.
4.4 Resume de notre demarche de modelisation
Nous pensons les deux approches precitees largement complementaires dans lecadre de nos travaux de modelisation de scenarios pedagogiques. L’operation demodelisation UML de scenarios existants (demarche de retro-conception5) est unetache relativement complexe. Ainsi, MOT convient tout a fait pour une utilisationen tant qu’interface de comprehension et de conceptualisation entre la realite etsa representation informatique, et aide alors a reduire les temps de modelisationen permettant de proposer une premiere modelisation moins formelle, mais plusaisement convertible en UML.
Notre demarche de modelisation s’articule donc en deux parties :– une partie dite dynamique, consistant en la production de modeles MOT
presentant le scenario dans toute sa complexite pedagogique, avec un hautniveau d’abstraction ;
– une partie dite statique, ou l’on propose les diagrammes de classes UML as-socies aux scenarios etudies, diagrammes aisement transposables en struc-
5Chikofsky et Cross [Chikofsky et al., 1990] definissent la retro-conception (reverse-engineering) comme etant un processus d’analyse d’un systeme logiciel, ayant comme objectifsprincipaux l’identification des composantes du systeme et de leurs interrelations, et la creationde representations du systeme sous d’autres formes ou a des niveaux d’abstraction plus eleves.
58 Notre demarche de modelisation
tures de donnees informatiques.
La figure 4.2 resume notre demarche globale de modelisation6.
P
CC
Modélisation MOT
P
Modélisation des gabaritsde scénarios étudiés
Étude bibliographique
Modélisation UML
Fig. 4.2 – Notre demarche de modelisation des gabarits de scenarios etudies
6Les etapes post-analyse des modeles produits n’apparaissent pas ici, et feront l’objet deschapitres suivants.
Chapitre 5
Modelisation des gabarits descenarios
Ce chapitre presente les premieres briques de nos apports per-sonnels de recherche, en proposant une modelisation uniforme desgabarits de scenarios releves et decrits precedemment. Comme nousl’exposions dans le chapitre precedant, chaque scenario sera modeliseen deux temps : une modelisation MOT puis une modelisation UML.Les modeles sont presentes dans le meme ordre que celui dans lequelleurs scenarios respectifs ont ete introduits au chapitre 2.
Table des matieres5.1 SPLACH . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.1 Modele MOT . . . . . . . . . . . . . . . . . . . . . . . 605.1.2 Diagramme de classes UML . . . . . . . . . . . . . . . 60
5.2 APC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.1 Modele MOT . . . . . . . . . . . . . . . . . . . . . . . 625.2.2 Diagramme de classes UML . . . . . . . . . . . . . . . 62
5.3 NetPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.1 Modele MOT . . . . . . . . . . . . . . . . . . . . . . . 635.3.2 Diagramme de classes UML . . . . . . . . . . . . . . . 64
5.4 SYMBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.4.1 Modele MOT . . . . . . . . . . . . . . . . . . . . . . . 655.4.2 Diagramme de classes UML . . . . . . . . . . . . . . . 66
5.5 iPedagogique . . . . . . . . . . . . . . . . . . . . . . . . 675.5.1 Modele MOT . . . . . . . . . . . . . . . . . . . . . . . 675.5.2 Diagramme de classes UML . . . . . . . . . . . . . . . 68
5.6 Conclusions et hypothese fondatrice . . . . . . . . . . 685.6.1 Analyse des modeles produits . . . . . . . . . . . . . . 685.6.2 Hypothese fondatrice . . . . . . . . . . . . . . . . . . . 70
60 Modelisation des gabarits de scenarios
5.1 SPLACH
5.1.1 Modele MOT
Sebastien George lui meme [George, 2001] a propose une representation MOTde l’organisation d’un projet dans SPLACH (figure 5.1). Ce modele explicite lefait que, dans SPLACH, une etape est constituee d’une phase de travail individuelpuis d’une phase de travail collectif, chacune de ces phases donnant lieu a laproduction de certains documents.
IPC
CC
C
IPIP
RRR
R
IP
IP
IP
IP
IP
CC
C*
ÉquipeSujet
apprenant 1
Tâche
Tâchecollective
Tâcheindividuelle
Documentd'équipeen sortiede l'étapecourante
Documentd'équipe en
entrée(cahier descharges oudocumentde l'étape
précédente)
Documentsujet
apprenant 1
Étape de projet
Projet
SujetApppprenant 2
SujetApppprenant 3
Documentsujet
apprenant 2
Documentsujet
apprenant 3
C
C
Tâche Tâche
Fig. 5.1 – Modele MOT d’un projet dans SPLACH (d’apres [George, 2001])
Dans un souci d’uniformisation de modelisation par rapport aux autres typesde scenarios, nous apportons quelques precisions a ce modele MOT. Ces precisionssont evoquees textuellement dans [George, 2001], mais n’apparaissent pas au seindu modele initial propose par S. George. Nous introduisons donc, dans la fi-gure 5.2, la notion de chef de projet [George, 2001].
5.1.2 Diagramme de classes UML
La figure 5.3 presente le diagramme de classes du gabarit de scenarios deSPLACH. Ce diagramme a ete obtenu a partir du diagramme MOT presente parla figure 5.2.
5.1 SPLACH 61
IPC
CC
C
IPIP
RRR
R
IP
IP
IP
IP
IP
CC
C*
ÉquipeSujet
apprenant 1
Tâchecollective
Tâcheindividuelle
Documentd'équipeen sortiede l'étapecourante
Documentd'équipe en
entrée(cahier descharges oudocumentde l'étape
précédente)
Documentsujet
apprenant 1
Étape de projet
Projet
SujetApppprenant 2
SujetApppprenant 3
Documentsujet
apprenant 2
Documentsujet
apprenant 3
C
C
Encadrer
Chef de projet
R
TâcheTâche Tâche
Fig. 5.2 – Modele MOT complete d’un projet dans SPLACH
Personne
- Nom : String- Prénom : String
PlanningProjet
- Nom : String
Chef de projet
Équipe
Apprenant
Production
Document
- Nom : String- Public : boolean
Étape
- Nom : String
Tâche
- Nom : String- Collective : boolean- Synchrone : boolean
1 1
1..*
*
Précède >
0..1
0..1
Précède >1..* 1
Réalise >1..* 1..*
Intrant >
1..*
1..*
Encadre >1
*
Tâche individuelle Tâche collective
Fig. 5.3 – Diagramme de classes du scenario pedagogique de SPLACH
62 Modelisation des gabarits de scenarios
5.2 APC
5.2.1 Modele MOT
La figure suivante presente le diagramme MOT de l’APC d’Anne Lapujade.Une etape peut etre decomposee en sous-etapes, ce qui apparaıt sur le modele.De plus, une synchronisation peut etre mise en place entre les etapes (certainesetapes individuelles peuvent etre realisees simultanement par chaque membre dugroupe), tandis que d’autres etapes doivent s’executer sequentiellement.
Encadre
IP
Contribution
Étapecoopérative
Étapecollaborative
Sujet du projetActivité
pédagogique
Étape
Résultatterminal
Classe C++
Apprenant
IP IP
C*
IP
C*
SS
C*
R
Groupe
R
R
Groupe
Document
I
I
C*
Fig. 5.4 – Modele MOT du scenario pedagogique de l’APC
5.2.2 Diagramme de classes UML
Le diagramme de classes UML de l’APC (extrait de [Lapujade et al., 2003]),est presente par la figure 5.5. Les classes grisees sont des classes communes al’activite pedagogique et a la plate-forme dans laquelle cette derniere est deployee.Leur nombre et leur nature expliquent la necessite d’une normalisation de laplate-forme [Lapujade et al., 2003].
5.3 NetPro 63
Cours
Activité pédagogique
+ Intitulé : String
Apprenant virtuel
+ Nom : String
Contenu
Objectif pédagogique
Grain de cours
Apprenant Tuteur
État
+ HeureDébut : Date/Time+ HeureFin : Date/Time+ État : String
+ Intitulé : String+ NombreParticipants : int+ Durée : Time+ Concrète : Boolean+ Connectée : Boolean+ Collaborative : Boolean+ Synchrone : Boolean
Étape
Groupe
+ Nom : String+ NombreParticipants : int
1..1
1..1
1..1
0..* 1..1
*
*
*
* *
*
*
*
1..1 *
*
*
* * * 0..1 0..1
*
0..*
0..*
1..1
1..*
1..*
*
1..1
Conception générale de l'activitépour tous les groupes
Définition des groupes réels
Synchronisée avec Précédente
Fig. 5.5 – Diagramme de classes du scenario pedagogique de l’APC (d’apres[Lapujade et al., 2003])
5.3 NetPro
5.3.1 Modele MOT
La figure 5.6 page 64 presente le diagramme MOT du gabarit de scenariosde NetPro. Ce modele rend compte du fait que les groupes peuvent planifier leurtravail, mais egalement apporter un feedback aux travaux de leurs pairs.
64 Modelisation des gabarits de scenarios
Assesment
Peer assesment
Self assesment
Project
Task
Plan work Individual task Group task
ReviewTeacher Student
Manager
Group
Deliverable
Group deliverable
Providefeedback
Project plan
IP
IP
S
IP
IP
S S
R
R
S
IP
IP
C
C*
R
R
R
C*
IP
IP
IP
RR
Fig. 5.6 – Modele MOT du scenario pedagogique de NetPro
5.3.2 Diagramme de classes UML
La figure 5.7 page 65 presente le diagramme de classes du gabarit de scenariosde NetPro.
5.4 SYMBA 65
Projet
- Nom : String- Objectif : String
Tâche
- Nom : String- Durée : Time
Apprenant
- Nom : String- Prénom : String
Groupe
- Nom : String
Manager
- Nom : String- Prénom : String
Deliverable
- Nom : String- Chemin : String
Tuteur
- Nom : String- Prénom : String
Planning
Feedback
- Remarques : String
1..* 1..*
1..*
1
1
11
1
1
*
*
*
1..*
*
1
*
*
Réalise >
Consulte >
< Évalue
Propose > Ordonne >
{ordonné}
< Concerne
Fig. 5.7 – Diagramme de classes du scenario pedagogique de NetPro
5.4 SYMBA
5.4.1 Modele MOT
La figure 5.8 presente le diagramme MOT du gabarit de scenarios de SYMBA.
66 Modelisation des gabarits de scenarios
IP
IP
C*
Met en jeu Répartition du travail
IP
Nature(individuelle/collective)
C*
C*
P
C
Exécution desétapes planifiées
C*
R
IP Descriptifde tâcheÉlaboration
R
SSS
Acteur
IPProduction
IPRessource
IPOutil
IP
IP
R
Plan d'étapeordonnancement
des tâches
Planification
C*
C*
Sous-groupeApprenantGroupe
C*
Tâche
C*
Étape
Activité collectivemédiatisée
S
C*
C*
C*
Fig. 5.8 – Modele MOT du scenario pedagogique de SYMBA
5.4.2 Diagramme de classes UML
La figure 5.9 presente le diagramme de classes du gabarit de scenarios deSYMBA.
5.5 iPedagogique 67
Tuteur
- Nom : String- Prénom : String
Groupe
- Nom : String
Apprenant
- Nom : String- Prénom : String
Tâche
- Intitule : String- Objectif : String- DuréePrévue : Time- NbrParticipants : int
Activité médiatisée
- Nom : String
Étape
- Nom : String
Plan
Fichier
- Chemin : String
Ressource
- Nom : String- Publique : String
Outil
- Nom : String
Réalisation
- DateDébut : Date- DateFin : Date
Encadre >
Encadre >
Utilise >
Produit >
Utilise >
Concerne >
Planifie >
Précède >Relative à >
*
1..*
1..*
6..7
*
1
*
**
1
*
0..*
0..*
1
0..*10..*
0..*
0..*
0..*
*
{ordonné}
1..*
*
1
Fig. 5.9 – Diagramme de classes du scenario pedagogique de SYMBA
5.5 iPedagogique
5.5.1 Modele MOT
La figure 5.10 presente le diagramme MOT du gabarit de scenarios adoptedans iPedagogique.
S
S
REncadre
Tests Rédactiondocumentation
IP
P
C
IP
IP
Évaluation
IP RProduction
R
C*
Projet
S
S
S
S
P
Étape deprojet
RéalisationConceptionRédactioncahier descharges
Choix duprojet
R
IP
Ressource
Gérer
Expert
C*
R
Évaluateur
Tuteur
GroupeApprenant
Constitutiondes groupes
P P P P
Fig. 5.10 – Modele MOT du scenario pedagogique de iPedagogique
68 Modelisation des gabarits de scenarios
5.5.2 Diagramme de classes UML
La figure 5.11 presente le diagramme de classes du gabarit de scenarios deiPedagogique.
Personne
- Nom : String- Prénom : String
Projet
- Nom : StringTuteur
Groupe
Apprenant
Ressource
- Nom : String
Étape de projet
- Nom : String- Collective : boolean- Synchrone : boolean
1..*
Précède >
0..1
0..1Réalise >1..* 1..*
Intrant >
1..*
1..*Encadre >1
*
Production
- Nom : StringÉvaluateur
Réalise >
*0..1
Expert
Gère >
*
*
Fig. 5.11 – Diagramme de classes du scenario pedagogique de iPedagogique
5.6 Conclusions et hypothese fondatrice
La section precedente a consiste en la presentation des modeles MOT et dia-grammes de classes UML des differents types de scenarios etudies (SPLACH,APC, etc.). L’etude de ces modeles nous a mene a des constats en termes deconception de gabarits de scenarios pedagogiques pour les APCD de projets,et a permis de degager certaines caracteristiques communes a tous les types descenarios etudies.
5.6.1 Analyse des modeles produits
Dans tous les modeles presentes au chapitre 5, nous pouvons observer cer-taines caracteristiques communes, ainsi que quelques divergences. Cette sectionse propose d’analyser ces similitudes et ces divergences.
5.6 Conclusions et hypothese fondatrice 69
5.6.1.1 Similitudes
Au regard des differents modeles, nous constatons d’emblee de fortes simili-tudes structurelles quand a la representation des gabarits de scenarios etudies. Eneffet, tous les scenarios etudies se rejoignent pour considerer un projet (au senspedagogique) comme etant une entite abstraite decomposee en unites de travailconcretes et sequentielles. Cette unite de decomposition, generalement appeleeetape ou sous-projet (bien que certains scenarios la nomme differemment, mais laquestion terminologique n’est pas notre propos dans ce chapitre, cf. chapitre 7),constitue donc un noyau dur autour duquel gravitent un certain nombre de no-tions (nous ne parlons pas encore de concept a ce stade). Parmi ces notions, nouspouvons citer (liste non exhaustive) :
– les acteurs ;– les objectifs du projet ;– les outils qu’il mene a utiliser ;– les documents produits et/ou utilises ;– l’evaluation.
Il se trouve que ces notions apparaissent frequemment dans les differents tra-vaux etudies, sous des formes relativement voisines (cf. tableau 5.1).
5.6.1.2 Divergences
Au dela des similitudes observees, la richesse du processus de conceptionpedagogique confere a certains des types de scenarios etudies quelques singu-larites. Ainsi, nous relevons ca et la des caracteristiques propres a tel ou tel typede scenario. Par exemple, iPedagogique fait intervenir des acteurs non rencontresdans les autres scenarios : l’expert et l’evaluateur.
Cependant, ces particularites ne bouleversent pas la structure de base evoqueeplus tot (le scenario est toujours structure en etapes, execute par certains ac-teurs, etc.). En d’autres termes, ces contraintes de modelisation sur les types descenarios semblent pouvoir s’integrer a un noyau minimal constitue des notionscommunes a tous les types de scenarios, qui ont ete evoquees dans le paragrapheprecedant.
5.6.1.3 Tableau recapitulatif
Le tableau 5.1 presente une comparaison de quelques notions manipulees parles differents gabarits de scenario etudies.
70 Modelisation des gabarits de scenarios
SPLACH APC NetPro SYMBA iPedagogiqueStructuration sequentielledes etapes
X X X X X
Utilisation d’outils X X X X XUtilisation de documents X X X X XStrategie d’evaluation X X X X XAuto-planification par lesapprenants
X X
Gestion de contributions X X X X XRoles X
Tab. 5.1 – Notions manipulees par les types de scenarios etudies
5.6.2 Hypothese fondatrice
Nous presentons dans cette section l’hypothese sur laquelle sera fondee lasuite de notre demarche de recherche, concernant la modelisation de gabarits descenarios pedagogiques.
5.6.2.1 Rappel sur la methodologie
Comme nous le precisions au chapitre , notre objectif de recherche est departiciper a l’elaboration de methodes et d’outils destines a aider le concepteurde scenarios pedagogiques pour APCD dans sa demarche. A ce titre, nous avonsetudie les differents gabarits de scenarios rencontres dans la litterature afin demettre en exergue les similitudes et divergences entre ces derniers.
La figure 5.12 rappelle quels etaient les tenants et les aboutissants des cha-pitres precedants, ainsi que les choix qu’il nous incombe d’effectuer a cet etatd’avancee de nos recherches (les etapes effectuees apparaissent grisees).
5.6.2.2 Hypothese
En nous appuyant sur les constats effectues dans ce chapitre, nous posonsl’hypothese suivante :
Les modeles de gabarits de scenarios pedagogiques pour lesAPCD de projets rencontres dans la litterature sont suffi-samment similaires pour envisager que leur generation soitsupportee par le parametrage d’un modele dit generique.
5.6.2.3 Consequences sur notre demarche scientifique
L’hypothese formulee ci-dessus engendre un certain nombre de directives derecherche, listees ci-apres.
5.6 Conclusions et hypothese fondatrice 71
PP
Construction d'unmodèle générique
PP
Si modèles suffisammentsimilaires
P
Analyse des modèles
P
CC
Modélisation MOT
P
Modélisation des gabaritsde scénarios étudiés
Étude bibliographique
Modélisation UML
Si modèles trèséloignés
Construction d'unméta-modèle
Fig. 5.12 – Notre demarche de recherche
Tout d’abord, nous orientons nos recherches vers la constitution d’un modelegenerique. Le terme generique signifie que le modele en question possede en sonsein toutes les entites (et les relations les nouant) pouvant etre utilisees dans lesgabarits de scenarios etudies. Il est important de preciser une nouvelle foisque nous ne pretendons absolument pas, par le biais d’un tel modele generique,couvrir toute l’etendue de l’imagination des concepteurs pedagogiques, et quenous sommes conscients de l’extreme diversite des possibilites de scenarios pou-vant etre mis en œuvre, meme au sein du domaine relativement restraint qu’estla pedagogie de projet en groupe, a distance, et mediatisee par ordinateur. Auniveau de la demarche de conception, l’hypothese sus-citee signifie donc que laconception d’un type de scenario ne s’effectuera pas par instanciation d’un meta-modele, mais par le parametrage d’un modele generique. Ce parametrage serarealise par adjonction de fonctionnalites a un noyau minimal (cf. chapitre 7), etfera l’objet de notre demarche de conception.
Synthese de la deuxieme partie
Apres avoir indique et justifie notre demarche de modelisation, nous avons pro-pose une presentation, dans cette deuxieme partie, de l’ensemble des modelesMOT et UML des gabarits de scenarios etudies. L’analyse de ces modeles a revelede fortes similitudes entre tous les gabarits etudies, et nous a permis de poserl’hypothese fondatrice selon laquelle il est possible de fonder notre methode deconception de gabarits de scenarios pedagogiques pour les APCD de projets surun modele dit generique.
Troisieme partie
Progetto : une methode deconception de gabarits de scenariospedagogiques pour APCD a base de
projets
Chapitre 6
Rappel sur les methodes deconception de systemes
d’information
Nous nous interessons a l’elaboration d’une methode de concep-tion de gabarits de scenarios pedagogiques pour les APCD a base deprojets. A l’heure actuelle, aucune methode de ce type n’existe, or ilsemble interessant de proposer aux auteurs de scenarios pedagogiquesles outils necessaires pour definir et implanter des scenarios originauxde maniere simplifiee. Ce chapitre apporte quelques rappels quant auxmethodes de conception de systemes d’information au sens large, afinde situer clairement nos travaux.
Table des matieres6.1 Les systemes d’information . . . . . . . . . . . . . . . 766.2 Qu’est-ce qu’une methode de conception ? . . . . . . 77
6.2.1 Les modeles . . . . . . . . . . . . . . . . . . . . . . . . 776.2.2 Les formalismes . . . . . . . . . . . . . . . . . . . . . . 776.2.3 Les outils . . . . . . . . . . . . . . . . . . . . . . . . . 776.2.4 La demarche . . . . . . . . . . . . . . . . . . . . . . . 77
6.3 Vers une methode de conception. . . . . . . . . . . . . 77
76 Rappel sur les methodes de conception
6.1 Les systemes d’information
Un systeme d’information1 (SI) peut etre defini comme etant la partie dureel constituee d’informations organisees, d’evenements ayant un effet sur cesinformations, et d’acteurs qui agissent sur ces informations ou a partir de cesinformations, selon des processus visant une finalite de gestion et utilisant lestechnologies de l’information [Morley et al., 2000]. Le SI integre les dimensionsorganisationnelles, humaines et technologiques de la gestion de l’information ausein d’une organisation (cf. figure 6.1).
Système d'information
Système opérant Système informatique
Acteurs Informations Processus Matériels Logiciels Applicatifs
C C
C* C* C* C* C* C*
Fig. 6.1 – Representation MOT des composantes d’un systeme d’information
Toute organisation possede un SI, qui en est une representation. Ce SI peutintegrer un systeme informatique, afin d’en ameliorer la gestion. Un tel systemeinformatique peut, quant a lui, etre defini comme un ensemble organise d’objetstechniques (materiels, logiciels, applicatifs) dont la mise en œuvre realise l’infra-structure d’un systeme d’information [Morley et al., 2000].
Dans le cadre de nos travaux, nous proposons de caracteriser les scenariospedagogiques executes dans des environnements informatiques par des systemesd’information, composes
– d’informations ;– d’acteurs ;– de processus ;– d’un systeme informatique assistant ces processus.
1Une information peut etre definie comme etant une donnee dotee d’un sens. Une donnee, parexemple informatique, n’est donc pas a elle seule une information si elle n’est pas accompagneed’un modele d’interpretation permettant de lui attribuer un sens.
6.2 Qu’est-ce qu’une methode de conception ? 77
6.2 Qu’est-ce qu’une methode de conception ?
Une methode de conception de systemes d’information doit etre constituee,d’apres [Rolland et al., 1988], de quatre composantes : des modeles, des forma-lismes, des outils et une demarche.
6.2.1 Les modeles
Comme nous l’exprimions dans la section 4.1, un modele est defini par unensemble de concepts et de regles regissant ces concepts. Plus succinctement,un modele est une simplification de la realite [Booch et al., 2000]. La methodede conception peut disposer de plusieurs modeles. Dans notre cas, la methodes’appuiera sur le modele generique presente au chapitre 7.
6.2.2 Les formalismes
Un formalisme est un ensemble de constructions qui permet de decrire for-mellement les specifications du SI [Lapujade, 1997]. Les formalismes permettentdonc une representation abstraite des concepts presents dans les modeles.
6.2.3 Les outils
Les outils sont destines a aider et guider les utilisateurs de la methode dansleur demarche. A ce titre, ils s’appuient, notamment, sur les formalismes pourpermettre a l’utilisateur d’effectuer sa tache de conception le plus simplementpossible.
6.2.4 La demarche
La demarche de conception specifie au concepteur du systeme d’informationde quelle maniere il doit proceder pour utiliser les composantes de la methode.Cette demarche est formulee en etapes sequentielles.
6.3 Vers une methode de conception de gabarits de scenarios
pedagogiques. . .
Nous avons formule dans ce chapitre l’hypothese selon laquelle l’elaborationd’un scenario pedagogique peut etre consideree comme la conception d’une formede systeme d’information, mettant en jeu des acteurs, des informations, des pro-cessus. Cette hypothese est fondee sur la these selon laquelle un systeme de for-mation peut etre considere comme un systeme d’information [Lapujade, 1997].
78 Rappel sur les methodes de conception
Nous proposons donc une methode de conception de scenarios pedagogiques(et plus particulierement de gabarits de scenarios) pour les APCD a base deprojets. Conformement aux specifications de [Rolland et al., 1988], notre methodes’articulera autour de 4 composantes :
– un modele : notre modele generique de gabarits de scenarios, comprenantdes concepts et des regles d’integrite definis au chapitre 7 ;
– des formalismes de representation, notamment un diagramme de descriptiondes types d’acteurs et de leurs actions, ainsi qu’un diagramme de structu-ration des etapes de projets ;
– un outil : le logiciel Progetto, permettant aux concepteurs de gabarits descenarios de mettre en œuvre la methode du meme nom ;
– une demarche, specifiant comment utiliser les formalismes et les regles pourcreer un gabarit de scenario (cette demarche est reprise dans le logicielProgetto, cf. chapitre 10).
Chapitre 7
Le modele generique
Ce chapitre a pour but la presentation de notre modele generiquede gabarits de scenarios pedagogiques pour APCD de projets. Il secompose de trois sections, abordant respectivement :
– les concepts de modelisation retenus ;– une presentation du modele generique ;– les possibilites de parametrage du modele generique, dependant
de certaines regles d’integrite.
Table des matieres7.1 Presentation des concepts de modelisation . . . . . . 80
7.1.1 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . 807.1.2 La structure du scenario . . . . . . . . . . . . . . . . . 837.1.3 Les realisations et leur evaluation . . . . . . . . . . . . 867.1.4 Les ressources et outils . . . . . . . . . . . . . . . . . . 90
7.2 Le modele generique . . . . . . . . . . . . . . . . . . . 917.3 Parametrage du modele generique : regles d’integrite 93
7.3.1 Noyau minimal . . . . . . . . . . . . . . . . . . . . . . 937.3.2 Parametrage de la structuration du scenario . . . . . . 937.3.3 Parametrage des taches . . . . . . . . . . . . . . . . . 957.3.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . 967.3.5 Utilisation d’outils et ressources . . . . . . . . . . . . 967.3.6 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 977.3.7 Tutorat . . . . . . . . . . . . . . . . . . . . . . . . . . 987.3.8 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 997.3.9 Planification . . . . . . . . . . . . . . . . . . . . . . . 1007.3.10 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 1007.3.11 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 101
80 Le modele generique
7.1 Presentation des concepts de modelisation
Nous presentons dans cette section l’ensemble des concepts integres a notremodele generique. Notre approche, inspiree de l’approche « systemes d’informa-tion », nous mene a modeliser ces concepts par le biais de classes d’un modeleobjet (une autre approche aurait pu consister en la creation d’une ontologie).C’est l’« assemblage » de ces classes, ainsi que leur parametrage (notamment deleurs attributs) qui permettra de construire les gabarits de scenarios souhaites.Nous ne decrivons ici que les concepts retenus : les regles d’integrite s’appliquantau parametrage des liens entre ces concepts feront l’objet de la section 7.3. Pourchaque concept, nous proposons une definition, soit personnelle, soit inspiree detravaux mentionnes (IMS-LD par exemple).
7.1.1 Les acteurs
Definition 1 Les acteurs d’un scenario sont des personnes qui interagissententre-elles ou avec le systeme afin de participer au deroulement du scenario.
De notre analyse bibliographique ressort la mise en scene de cinq types d’ac-teurs potentiels1 :
– l’apprenant, membre d’un groupe ;– le tuteur ;– l’evaluateur ;– l’expert.
Remarque 4 D’autres acteurs interviennent dans le cycle de vie du scenariopedagogique, notamment le concepteur et l’auteur. Cependant, leur presentationn’apparaıt pas ici, car ils interviennent en amont de l’execution du scenario aproprement dit (phases de parametrage et d’instanciation du modele generique).
L’ensemble de ces acteurs est reconnu par le systeme comme etant des per-sonnes (classe Personne, figure 7.1). Cette classe est une classe abstraite : onn’instancie jamais une personne, mais toujours un des acteurs qu’elle engendre.
- Nom : String- Prénom : String
Personne
Fig. 7.1 – La classe Personne
La norme IMS-LD (cf. chapitre 11) definit deux types de roles joues par lespersonnes intervenant dans la realisation d’un scenario pedagogique : les appre-nants (learners) et le personnel assistant l’apprentissage (staff ).
1Tous les types acteurs ne sont pas forcement implementes lors du parametrage du modelegenerique.
7.1 Presentation des concepts de modelisation 81
7.1.1.1 L’apprenant
Definition 2 L’apprenant est l’acteur qui, au sein d’un groupe, realise les tachesd’apprentissage definies dans le scenario pedagogique.
Remarque 5 Ce concept d’apprenant est analogue a celui de learner definit dansIMS-LD.
La figure 7.2 presente la classe Apprenant, qui herite de la classe Personne.
Remarque 6 Dans la suite de ce chapitre, les classes deja introduites serontrepresentees en fond gris, avec les attributs caches.
Apprenant
Personne
Fig. 7.2 – La classe Apprenant
Nous travaillons dans un contexte de travail collectif (cf. chapitre 1). A cetitre, nous nous devons de proposer explicitement des concepts destines a sup-porter les activites collectives. Nous introduisons donc le concept de groupe d’ap-prenants (figure 7.3). D’apres [Anzieu et al., 1982], le terme groupe doit etrereserve, dans un usage scientifique, a la designation d’un ensemble de personnesreunies ou qui peuvent et veulent se reunir. Cette definition simple corresponda notre situation : un groupe d’apprenants est, dans le cadre d’un scenariopedagogique pour APCD de projets, une entite immaterielle regroupant des per-sonnes (les apprenants), reunies au debut de l’activite par l’auteur ou le tuteur,voir sous leur propre volonte (auto-formation des groupe, comme par exempledans iPedagogique [Fougeres et al., 2002]). La figure 7.3 presente la classe Groupe,et precise qu’un groupe est compose de un ou plusieurs apprenants.
Apprenant
Groupe
1..*
- Nom : String
Fig. 7.3 – La classe Groupe
82 Le modele generique
7.1.1.2 Personnel assistant l’apprentissage
Cette partie aborde les concepts representant tous les acteurs n’etant pas detype apprenant. Il s’agit notamment de la classe staff definie dans IMS-LD.
Le tuteur [Paquette, 1997] caracterise un role de Formateur au sein des cam-pus virtuels. Ce formateur a en charge de faciliter l’apprentissage, et est a la foismoniteur (« coach »), conseiller, evaluateur des travaux de l’apprenant, aide al’utilisation de l’environement, animateur des equipes ou du groupe, realisateurdu diagnostic.
Nous reprenons cette definition, mais en l’associant au terme francais tuteur(le terme formateur evoquant plutot quand a lui le « dispenseur » de savoirs, etsemblant etre moins utilise en formation a distance).
Definition 3 Le concept de tuteur (figure 7.4) represente la personne ayant encharge l’assistance des apprenants (monitorat ou encore « coatching ») concer-nant les problematiques abordees dans le scenario, l’animation des groupes eteventuellement l’evaluation et la facilitation du travail au sein de l’environne-ment.
Tuteur
Personne
Fig. 7.4 – La classe Tuteur
De plus nous constatons que dans les scenarios etudies, il n’est pas toujoursdu role du tuteur d’evaluer les travaux : certains scenarios (ex. : iPedagogique)confient ce travail a un evaluateur specifique.
L’evaluateur
Definition 4 L’evaluateur est la personne ayant en charge l’evaluation des tra-vaux des apprenants.
Tous les gabarits de scenarios ne prevoient pas necessairement de faire in-tervenir un evaluateur, et confient parfois cette tache au tuteur. Les evaluationspeuvent etre de differents ordres et intervenir a des moments cles definis parl’auteur du scenario. La figure 7.5 presente la classe Evaluateur representant ceconcept.
7.1 Presentation des concepts de modelisation 83
Évaluateur
Personne
Fig. 7.5 – La classe Evaluateur
L’expert Le concept d’expert est parfois introduit dans la litterature (notammentdans [Fougeres et al., 2002]) afin de designer la personne responsable de « gererles ressources ».
Definition 5 L’expert est l’acteur qui a en charge la maintenance de la perti-nence et de la validite des contenus (documents, etc.) destines a etre utilises dansle scenario.
La figure 7.6 presente la classe Expert representant ce concept.
Expert
Personne
Fig. 7.6 – La classe Expert
7.1.2 La structure du scenario
Nous presentons dans cette section les concepts permettant de representerla structure du scenario. Notre approche nous amene a identifier trois conceptsde base : le scenario, constitue d’etapes, lesquelles donnent lieu a l’execution detaches.
7.1.2.1 L’etape
Les gabarits de scenarios et autres scenarios particuliers etudies prevoienttous (explicitement ou implicitement) un ordonnancement du travail a effectuerdans le temps en etapes sequentielles. Nous introduisons donc le concept d’etape(figure 7.7).
Definition 6 Une etape de projet est une entite abstraite representant une partiede celui-ci (sous-projet) selon un objectif pedagogique determine.
84 Le modele generique
- Intitulé : String- Durée_Prévue : Time
Étape
Fig. 7.7 – La classe Etape
7.1.2.2 Le scenario
Le concept d’etape defini, nous introduisons celui de scenario (figure 7.8 :classe Scenario APCD). Ce concept de scenario permet d’identifier un scenariopedagogique pour activite collective distante a base de projet, comme etant unesuite d’etapes.
Definition 7 Un scenario est la specification d’une suite d’etapes sequentiellesagencees selon un objectif pedagogique.
Scénario APCD
- Nom : String- Objectif : String- Auteur : String
Étape1..*
Fig. 7.8 – La classe Scenario APCD
7.1.2.3 La tache
Definition 8 Une tache est une unite de travail programmee, constituant toutou partie d’une etape de projet.
On retrouve ce concept dans [George, 2001], [Lapujade et al., 2003] ou encoredans [Betbeder, 2003]. Par exemple, au sein d’un scenario d’apprentissage duC++, dans une etape dont l’objectif serait d’apprehender la programmation declasses simples, une des taches prescrites pourrait etre la programmation d’uneclasse Chaıne destinee a permettre la gestion simplifiee des chaınes de caracteresen C++.
La figure 7.9 presente la classe Tache representant ce concept.
Tache individuelle Une tache realisee par un seul des apprenants du groupe estdite individuelle.
7.1 Presentation des concepts de modelisation 85
Tâche
- Intitulé : String- Objectif : String- Durée_Prévue : String- Connectée : boolean- Point_Validation : boolean
Étape1
Relative à0..*
Fig. 7.9 – La classe Tache
Tâche individuelle
Tâche
Fig. 7.10 – La classe Tache individuelle
Tache collective Une tache realisee par au moins deux apprenants est dite col-lective.
Tâche
Tâche collective
- Nombre_Participants : int- Collaborative : boolean- Synchrone : boolean
Fig. 7.11 – La classe Tache collective
7.1.2.4 Le plan
Nous abordons dans cette section le probleme du degre de liberte d’organisa-tion d’un scenario pedagogique. Ainsi, selon les objectifs pedagogiques, le scenariopeut etre plus ou moins directif. Dans le cas d’un scenario directif, nous pouvonsimaginer une planification des etapes et des taches definie par le concepteur,tandis qu’un scenario moins directif permettrait aux apprenants de planifier euxmeme leur travail (comme par exemple dans [Betbeder, 2003]).
86 Le modele generique
Definition 9 Un plan d’etape est la definition d’une liste de taches la consti-tuant, incluant leur agencement temporel (synchronisme, sequencement).
Remarque 7 Le plan d’etape etant la specification d’une liste de taches (doncd’instances de la classe Tache, cf. 7.1.2.3), il decrit implicitement l’organisationde ces taches, a savoir les apprenants censes realiser chaque tache ainsi que lesressources et outils eventuellement utilises ces taches.
Tâche
PlanGroupe
Étape1
Relative à0..*
Concerne >
Décrit >
1
1..*1
*Propose >
1 1
Fig. 7.12 – La classe Plan
7.1.2.5 Les roles
Dans certains scenarios (par exemple [Collis, 1997a]), au sein d’un grouped’apprenants, il est prevu d’assigner des roles differents a chaque apprenant. Parexemple, un groupe peut etre compose d’un « expert multimedia », d’un « experten programmation » et d’un « chef de projet ». Ceci nous amene a la definitionsuivante, illustree par la figure 7.13 :
Definition 10 Un role est l’attribution d’une specificite (hierarchique ou disci-plinaire) a un apprenant quant aux actions qu’il doit mener.
- Nom : String- Description : String
Rôle
Fig. 7.13 – La classe Role
7.1.3 Les realisations et leur evaluation
7.1.3.1 Les travaux
Nous introduisons ici un concept non present dans les gabarits de scenariosetudies. Un scenario pedagogique, d’apres la definition annoncee au chapitre 1definit un certain nombre de consignes, et de planifications definies a priori par leconcepteur. De plus il definit, generalement, la forme des produits devant decouler
7.1 Presentation des concepts de modelisation 87
de l’execution du scenario (notamment les contributions des apprenants, cf. sec-tion 7.1.3.2). Pour relier cette planification des taches aux produits devant endecouler, nous introduisons un concept de travail :
Definition 11 Un travail represente l’activite d’un apprenant, d’un groupe d’ap-prenants voire d’un sous-groupe d’apprenants a l’occasion de l’execution d’unetache.
La figure 7.14 presente ce concept de travail.
- Date_Début : Date- Date_Fin : Date
Travail
Apprenant*1..*
TâcheRéalise >
Fig. 7.14 – La classe Travail
7.1.3.2 Les contributions
Le travail realise par un ou plusieurs apprenants executant une tache peutdonner lieu a la production d’une ou plusieurs contribution. Nous proposons doncla definition suivante :
Definition 12 Une contribution est une entite materielle representant le fruit dutravail d’un ou de plusieurs apprenants dans le cadre de l’execution d’une tache.
Publique : boolean Une contribution est dite publique si elle est consultablepar les apprenants appartenant a d’autres groupes. Cette propriete est no-tamment utilisee dans des strategies de peer-reviewing, retenues dans Net-Pro [Markkanen et al., 2001].
Type : char Une contribution peut etre de differents types. Nous avons releve2 types : document (D) ou fichier informatique (F).
7.1.3.3 La validation
Dans certaines activites (par exemple dans l’APC [Lapujade et al., 2003]), lepassage a une etape ulterieure est conditionnee par la validation des travaux detous les membres du groupe par leurs equipiers (les autres membres du groupe)et par le tuteur.
88 Le modele generique
Ressource
Contribution
- Type : char
Fig. 7.15 – La classe Contribution
Definition 13 La validation est un acte d’approbation commis par un membresd’un groupe concernant le travail d’un de ses equipiers. Il s’agit d’un phenomenediscret (validation ou non-validation).
7.1.3.4 L’evaluation
Un projet pedagogique donne lieu, dans une tres grande majorite des cas,a une forme d’evaluation des travaux effectuees (ou de la maniere dont ils ontete effectuees, selon la strategie adoptee par le concepteur : distinction entrel’evaluation du projet et l’evaluation des objectifs d’apprentissage [George, 2001]).Cette evaluation peut etre effectuee par le tuteur ou par un evaluateur. Certainauteurs preconisent par exemple une etape terminale consacree a l’evaluation duprojet ([Vivet, 1993]).
Definition 14 L’evaluation consiste en la revue d’un ou plusieurs travaux parl’evaluateur (ou par le tuteur a defaut d’evaluateur), aboutissant a l’attributiond’une note.
- Note : String
Évaluation
ÉvaluateurEffectue >
1..**
Tuteur
TravailConcerne >
1 *
1..* *
Effectue >
Ou
Fig. 7.16 – La classe Evaluation
Les grilles d’evaluation D’apres [GSN http, 2004], les rubrics sont l’outil d’aidea l’evaluation le plus couramment utilise pour l’evaluation des APCD de projets.Nous proposons un concept de grille d’evaluation, directement inspire de cesrubrics, et dont la definition est la suivante :
Definition 15 Une grille d’evaluation (rubric) est un outil d’aide a l’evaluationa l’usage des evaluateurs ou des tuteurs, qui propose un certain nombre de criteres
7.1 Presentation des concepts de modelisation 89
d’evaluation pertinents applicables a un ou plusieurs travaux (projet, etape outache).
ÉvaluationGrille d'évaluation< Utilise
* *
Ressource
Fig. 7.17 – La classe Grille d’evaluation
7.1.3.5 Les commentaires
Definition 16 Un commentaire est une ressource contenant des observationsformulees par un acteur (tuteur, evaluateur ou apprenant).
Les commentaires (figure 7.18) sont utilises dans plusieurs situations :– en accompagnement d’une evaluation, par le tuteur ou l’evaluateur ;– pour la formulation d’un feedback (figure 7.19) par les apprenants, concer-
nant les travaux d’un autre groupe.
Commentaire
Ressource
Fig. 7.18 – La classe Commentaire
Feedback
Commentaire
Fig. 7.19 – La classe Feedback
90 Le modele generique
7.1.4 Les ressources et outils
L’execution des taches par les apprenants necessite quasi-systematiquementl’utilisation de ressources et d’outils. Ces entites manipulant ou etant eux-memedes fichiers informatiques, nous commencons par definir le concept de fichier(figure 7.20).
- Nom : String- Chemin : String
Fichier
Fig. 7.20 – La classe Fichier
7.1.4.1 Les ressources
L’execution d’un scenario pedagogique fait appel, dans une tres grande ma-jorite des cas, a des ressources pedagogiques. Notre definition du concept deressource rejoint celle formulee par la norme IMS-LD. En effet, IMS-LD definitun concept nomme learning object, representant toute ressource, numerique ounon, utilisable et addressable. Il peut en outre s’agir de documents, d’enonces,de programmes, etc. La figure 7.21 illustre la classe Ressource representant ceconcept.
Definition 17 Une ressource est un objet pedagogique numerique ou non, utili-sable et adressable.
Fichier
Ressource
- Description : String
Fig. 7.21 – La classe Ressource
7.1.4.2 Les outils
Au meme titre que les ressources, les outils sont quasi systematiquementintegres aux scenarios pedagogiques. Encore une fois, IMS-LD definit un conceptde service, representant par exemple des outils de chat, de forum, etc. Notreconcept d’outil (figure 7.22) s’apparente donc au concept de service definit parIMS-LD.
Definition 18 Un outil est un service informatique (logiciel, chat, forum. . .).
7.2 Le modele generique 91
Outil
- Nom : String
Fig. 7.22 – La classe Outil
7.2 Le modele generique
Nous proposons dans cette section une presentation de notre modele generique,modele compose de classes representant les concepts introduits dans les sectionsprecedentes et des liens unissant ces classes (figure 7.23).
Remarque 8 Le modele presente par la figure 7.23 n’a subi aucun parametrage,mais contient tous les « parametrages » possibles : tous les attributs de toutes lesclasses et tous les liens possibles y sont representes, pour disposer d’une visionglobale de notre modelisation.
92 Le modele generique
1..*
1..* 1
Rel
ativ
e à
>
0..*
*1.
.*
Réa
lise
>
Pré
cède
>
Pré
cède
>
0..*
0..* 0.
.*0.
.*
App
rena
nt
Com
men
taire
Éva
luat
eur
Tut
eur
Gril
le d
'éva
luat
ion
Tâc
he in
divi
duel
le
- N
om :
Str
ing
- P
réno
m :
Str
ing
Per
sonn
e
Gro
upe
- N
om :
Str
ing
- D
ate_
Déb
ut :
Dat
e-
Dat
e_F
in :
Dat
e
Tra
vail
Scé
nario
AP
CD
- N
om :
Str
ing
- O
bjec
tif :
Str
ing
- A
uteu
r : S
trin
g
- In
titul
é : S
trin
g-
Dur
ée_P
révu
e : T
ime
- In
ter_
Gro
upe
: boo
lean
Éta
pe
Tâc
he
- In
titul
é : S
trin
g-
Obj
ectif
: S
trin
g-
Dur
ée_P
révu
e : S
trin
g-
Con
nect
ée :
bool
ean
- P
oint
_Val
idat
ion
: boo
lean
Tâc
he c
olle
ctiv
e
- N
ombr
e_P
artic
ipan
ts :
int
- C
olla
bora
tive
: boo
lean
- S
ynch
rone
: bo
olea
n
Con
trib
utio
n
- T
ype
: cha
r
Res
sour
ce
- D
escr
iptio
n : S
trin
g-
Pub
lique
: bo
olea
n
- N
om :
Str
ing
- C
hem
in :
Str
ing
Fic
hier
Exp
ert
- N
om :
Str
ing
- D
escr
iptio
n : S
trin
g
Rôl
e
Pla
n
Ou
Éva
lue
>*
1..*
Ou
Ou
Con
tient
>
Con
cern
e >
Pro
pose
>
1
1
1 *
1
1..*
*
0..*
0..*
Out
il
- N
om :
Str
ing
0..*
*
0..*
0..*
Syn
chro
avec
>É
valu
atio
n
- N
om :
Str
ing
Util
ise
>
**
< In
clut
0..1
0..1
< E
ffect
ue
1
*
*
*
Gèr
e >
1..*
*
Fee
dbac
k
Don
ner
feed
back
>
0..*
Val
ide
>
*C
once
rne
>1
1..*
Con
cern
e >
*1.
.*
Enc
adre
>1
1..*
Fig.7.
23–
Not
rem
odel
ege
ner
ique
dega
bari
tde
scen
ario
spe
dago
giqu
espo
ur
APC
Dde
proj
ets
7.3 Parametrage du modele generique : regles d’integrite 93
7.3 Parametrage du modele generique : regles d’integrite
Notre approche consiste en la proposition d’un noyau minimal, susceptibled’etre utilise pour tous les types de scenarios devant etre generes. La phase deparametrage consiste alors en l’agrementation de ce noyau minimal, avec une bat-terie de classes et de liens definis ci-apres, et selon certaines contraintes d’integrite.
7.3.1 Noyau minimal
Nous presentons ici (figure 7.24) un noyau minimal extrait de notre modelegenerique. Ce noyau, compose de classes et de liens, est defini comme etant leplus simple des parametrages du modele generique, permettant de representer unscenario minimal mais realiste.
1..*
Personne Étape1..*
Scénario APCD
1
Relative à >0..*
Apprenant*1..*
TâcheRéalise >
Travail
Groupe
Précède >
Précède >
0..*
0..*
0..*
0..*
Fig. 7.24 – Noyau minimal du modele generique
Ce noyau minimal permet de representer un scenario tres eloigne de ceuxgeneralement implantes sur le terrain. C’est la raison pour laquelle il doit etrecomplete, par parametrage.
7.3.2 Parametrage de la structuration du scenario
Les etapes permettent la structuration temporelle du scenario pedagogique.Nous supposons qu’un scenario pedagogique est necessairement constitue d’uneetape au moins, laquelle est constituee d’une ou plusieurs taches. Deux pa-rametrages sont alors possibles pour la classe Etape :
94 Le modele generique
– les etapes peuvent eventuellement etre construites de maniere recursive :une etape peut alors etre constituee d’etapes ;
– selon les objectifs de l’activite, les etapes peuvent etre executees par lesgroupes seuls (etape intra-groupe), ou collectivement par plusieurs groupes(etape inter-groupe).
7.3.2.1 Construction recursive d’etapes
Dans certaines activites (par exemple dans l’APC [Lapujade et al., 2003]), lesetapes peuvent etre construites de maniere recursive, c’est a dire qu’une etapepeut etre elle-meme constituee d’etapes (figure 7.25). Une telle etape est appeleeabstraite dans [Lapujade et al., 2003], c’est a dire qu’elle « ne donne pas lieu aun travail mais doit toujours etre decomposee en sous-etapes ».
Compositionmultivaluée
Écriture d'uneliste chaînée
générique
Écriture d'uneliste
d'objets
Programmationde la
classe Université
Programmation de la
classe Élément
Programmationde la
classe Liste
Programmationde la classe
ListeEnseignants
Programmationde la classe
ListeUV
Séquence
Séquence Synchro
Fig. 7.25 – Exemple d’etape composee d’etapes (d’apres [Lapujade et al., 2003])
Cette caracteristique n’est pas integree au noyau minimal (puisqu’on ne laretrouve pas dans tous les gabarits de scenarios), et doit faire l’objet d’un pa-rametrage. Ainsi, il est possible de definir un lien de composition entre la classeEtape et elle meme, comme le montre la figure 7.26.
Étape*
Fig. 7.26 – Introduction de la notion de recursivite des etapes
7.3 Parametrage du modele generique : regles d’integrite 95
7.3.2.2 Etape intra-groupe et inter-groupe
Par defaut, une etape est censee etre executee par les groupes de maniere au-tonome, ainsi chaque groupe travaille « en interne » sur les differentes etapes duscenario : ce cas de figure est nomme etape intra-groupe. Cependant, certaines ac-tivites existantes (ex. : [Daradoumis et al., 2000]) supposent l’utilisation d’etapesdites inter-groupe, ou plusieurs groupes (voire l’ensemble des groupes) travaillentcollectivement. Un exemple typique d’utilisation de cette strategie pedagogiqueest celui de la constitution des groupes par l’ensemble de la promotion au debutde l’activite. Pour supporter de telles etapes inter-groupe, un attribut est ajoutea la classe Etape, comme le montre la figure 7.27.
- Inter_Groupe : booleanÉtape
Fig. 7.27 – Gestion des etapes inter-groupe
7.3.3 Parametrage des taches
Nous pouvons extraire trois cas de figure quant a l’agencement temporel destaches au sein d’une etape :
– les taches se suivent de maniere sequentielle ;– les taches s’executent simultanement ;– certaines taches sont sequentielles alors que d’autres peuvent s’effectuer
simultanement : c’est un mix des deux cas precedents.
7.3.3.1 Taches sequentielles
Ce cas de figure est integre au noyau minimal. En effet, un lien d’associationnomme Precede est prevu entre la classe Tache et elle meme. Ce lien permet,lors de son instanciation, de preciser qu’un objet de type :Tache precede unautre objet de type :Tache dans le temps. Ceci permet donc de gerer le fait queplusieurs taches peuvent s’executer de maniere sequentielle au sein d’une etape.Plus particulierement, par exemple, une tache individuelle (qui est une tache)peut preceder une tache collective, ce qui est utile pour modeliser des gabaritstels que SPLACH.
7.3.3.2 Taches simultanees
Dans la plupart des scenarios etudies ([Lapujade et al., 2003], [George, 2001],[Markkanen et al., 2001]. . .), la precedence entre tache ne suffit pas a gerer toutes
96 Le modele generique
les situations, car certaines taches (typiquement des taches cooperatives ou indivi-duelles) doivent s’effectuer de maniere simultanee (un apprenant resp. un grouped’apprenants travaille sur une tache pendant qu’un autre apprenant resp. grouped’apprenant travaille sur une autre tache). Ce cas de figure est tres frequent.Pour permettre la gestion de ce type de synchronisation, un parametrage peutetre effectue sur le modele generique : il suffit de disposer un lien d’associationnomme Synchronisee avec entre la classe Tache et elle meme (figure 7.28).
Tâche
Synchronisée avec >
0..*
0..*
Fig. 7.28 – Gestion des taches synchronisees
Ce lien permet, lors de son instanciation, de preciser qu’un objet :Tache estsynchronise avec un autre objet de type :Tache dans le temps. L’execution detaches de maniere simultanee devient alors possible.
7.3.4 Contributions
Afin de specifier que les travaux des apprenants peuvent donner lieu a descontributions (ressources), il suffit d’integrer la classe Contribution au modelede gabarit de scenario, en la reliant a la classe Travail par un lien d’associationProduit, comme le montre la figure 7.29.
TravailProduit >
1..* 1..*Contribution
Fig. 7.29 – Gestion des contributions
7.3.5 Utilisation d’outils et ressources
Il est tres rare qu’un scenario soit base uniquement sur des taches effectueessans outils et/ou sans ressources. En effet, dans un contexte de travail a distance,l’apprenant dispose generalement d’outils de cooperation et de collaboration (ex. :chat, mail, forum, etc.), et de ressources (ex. : documents ecrits, audios, etc.) afinde realiser les taches qui lui sont prescrites.
7.3.5.1 Les outils
Il est possible de parametrer le modele generique afin de preciser qu’une tacheest susceptible de provoquer dans sa realisation par les apprenants l’utilisation
7.3 Parametrage du modele generique : regles d’integrite 97
d’outils. Pour cela, le modele est complete par l’adjonction d’une classe Outil,reliee a la classe Tache par un lien d’association nomme Utilise (figure 7.30).
TâcheUtilise >
* 0..*Outil
Fig. 7.30 – Utilisation d’outils pour l’execution des taches
7.3.5.2 Les ressources
De la meme maniere, il est possible de parametrer le modele generique afinde preciser qu’une tache est susceptible de provoquer dans sa realisation parles apprenants l’utilisation de ressources. Pour cela, le modele est complete parl’adjonction d’une classe Ressource (une ressource est un fichier, cf. 7.1.4.1),reliee a la classe Tache par un lien d’association nomme Utilise (figure 7.31).
TâcheUtilise >
* 0..*Ressource
Fig. 7.31 – Utilisation de ressources pour l’execution des taches
7.3.6 Roles
Pour les besoins de certains scenarios (ex. : [Daradoumis et al., 2000], ou en-core [Liflander, 1999]), et ce dans le but d’atteindre divers objectifs pedagogiques,il peut etre interessant d’instaurer un systeme de roles a differents moments del’activite. Les roles sont definis :
– soit pour toute la duree de l’activite ;– soit pour chaque etape ;– soit pour chaque tache.
7.3.6.1 Roles definis pour toute la duree du scenario
Un role peut etre defini pour chaque apprenant, et pour toute la duree duscenario (figure 7.32 page 98). L’apprenant joue donc dans ce cas le meme roledurant toute l’activite (ex. : chef de projet).
7.3.6.2 Roles definis pour chaque etape
Le role peut etre defini pour chaque etape, ce qui veut dire que dans le scenariogenere, il sera possible, pour un meme apprenant, de jouer des roles differents pourchaque etape (figure 7.33 page 98).
98 Le modele generique
Apprenant
Rôle
Scénario APCD
Fig. 7.32 – Definition de roles pour toute la duree du scenario
Apprenant
Rôle
Étape
Fig. 7.33 – Definition de roles pour chaque etape
7.3.6.3 Roles definis pour chaque tache
De la meme maniere, le role peut etre defini pour chaque tache, ce qui veutdire que dans le scenario genere, il sera possible, pour un meme apprenant, dejouer des roles differents pour chaque tache (figure 7.34).
Apprenant
Rôle
Tâche
Fig. 7.34 – Definition de roles pour chaque tache
7.3.7 Tutorat
Pour adjoindre le concept de tuteur au noyau minimal du modele generique,il suffit de relier la classe Tuteur presentee precedemment (cf. 7.1.1) a la classeGroupe par un lien d’association Encadre, dont la cardinalite est illustree par lafigure 7.35 page 99.
7.3 Parametrage du modele generique : regles d’integrite 99
TuteurEncadre >
1 *Groupe
Fig. 7.35 – Adjonction du concept de tuteur
7.3.8 Evaluation
Comme precise en 7.1.3.4, l’evaluation peut etre effectuee par deux typesd’acteurs :
– le tuteur ;– l’evaluateur.
7.3.8.1 Evaluation
Une evaluation concerne un ou plusieurs travaux (figure 7.36).
ÉvaluationConcerne >
1..* 1..*Travail
Fig. 7.36 – Evaluation d’un ou plusieurs travaux
7.3.8.2 Evaluation par un evaluateur
Si le tuteur ne fait qu’encadrer le groupe mais ne procede pas a son evaluation,alors le parametrage du modele s’effectue par l’adjonction d’un lien d’associationentre la classe Evaluateur et la classe Groupe (figure 7.37).
ÉvaluateurÉvalue >
1..* 1..*Groupe
Fig. 7.37 – Evaluation des groupes par les evaluateurs
7.3.8.3 Evaluation par le tuteur
Si le tuteur encadre le groupe mais procede egalement a son evaluation, alorsle tuteur est un evaluateur. Dans ce cas, le parametrage du modele s’effectuepar l’adjonction d’un lien d’association entre la classe Evaluateur et la classeGroupe, puis d’un lien d’heritage entre la classe Tuteur et la classe Evaluateur
(figure 7.38 page 100).
100 Le modele generique
ÉvaluateurÉvalue >
1..* 1..*Groupe
Tuteur
Fig. 7.38 – Evaluation des groupes par les tuteurs
7.3.9 Planification
Afin de mettre en place une strategie de planification des etapes par les ap-prenants (cf. 7.1.2.4), le modele est parametre en reliant la classe Groupe a laclasse Plan par un lien d’association Propose, puis la classe Plan aux classesEtape et Tache, respectivement par des liens d’association Concerne et Decrit.La figure 7.39 illustre ce parametrage.
Tâche
Groupe
Étape1
Relative à0..*
Concerne >
Décrit >
1
1..*1
*Propose >
1 1Plan
Fig. 7.39 – Planification par les groupes
7.3.10 Validation
La mise en place d’une validation est effectuee par parametrage du modelegenerique, en reliant la classe Apprenant (figure 7.40) et/ou la classe Tuteur
(figure 7.41) a la classe Contribution par un lien d’association Valide.
ApprenantValide >
0..* 1..*Contribution
Fig. 7.40 – Validation par l’apprenant
TuteurValide >
0..* 1..*Contribution
Fig. 7.41 – Validation par le tuteur
7.3 Parametrage du modele generique : regles d’integrite 101
7.3.11 Feedback
La mise en place d’un feedback est effectuee en reliant la classe Groupe a laclasse Contribution par un lien d’association Donne feedback, engendrant laclasse d’association Feedback (figure 7.42).
Groupe*1..*
ContributionDonne feedback >
Feedback
Fig. 7.42 – Feedback
Chapitre 8
Demarche de conception
Nous presentons, dans ce chapitre, la demarche de conception pres-crite par notre methode. Cette demarche est donc une proposition decheminement destine a conduire l’utilisateur vers un parametrage ju-dicieux du modele generique de gabarits de scenarios pour APCD deprojets.
Table des matieres8.1 Etape 1 : definition des acteurs et de leurs actions . 1048.2 Etape 2 : precision des concepts manipules . . . . . . 1058.3 Etape 3 : structuration des etapes . . . . . . . . . . . 106
8.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . 1068.3.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 108
104 Demarche de conception
8.1 Etape 1 : definition des types d’acteurs et de leurs ac-
tions
La premiere etape de notre demarche de conception consiste en la definitiondes types d’acteurs qui manipuleront les autres concepts lors de l’execution duscenario, ainsi que des actions effectuees par ces acteurs. L’enjeu de cette etapeest donc de decrire les liens entre les types d’acteurs et les actions disponiblespour ces types d’acteurs respectifs.
D’apres le noyau minimal du modele generique presente en section 7.3, untype d’acteur est au minimum retenu lors de cette etape : l’apprenant. En effet,un scenario pour activite collective doit faire intervenir au moins des acteurs ap-prenants rassembles au sein de groupes. Afin de repondre aux besoins de tous lesgabarits de scenarios etudies dans la bibliographie, le concepteur peut, lors decette etape, introduire les concepts de tuteur, d’evaluateur et d’expert.
De plus, a ce stade, le concepteur definit les actions realisees par les acteurs.Ces actions (ce que font les acteurs et comment ils realisent leurs intentions) sontdes faits generaux destines a permettre un premier parametrage automatique dumodele generique. En effet, en fonction des actions retenues par le concepteur, ilest possible d’isoler les classes associees dans le modele generique. Une liste mini-male d’actions possibles a donc ete elaboree, et est presentee par le tableau 8.1.
Actions Acteurs concernesRealiser une tache ApprenantTravailler en groupe ApprenantUtiliser des ressources ApprenantUtiliser des outils Apprenant, tuteur, evaluateurS’auto-organiser ApprenantJouer un role au sein du groupe ApprenantDeposer une contribution ApprenantConsulter une contribution Apprenant, tuteur, evaluateurValider une contribution Apprenant, tuteurEvaluer un travail Tuteur, evaluateurUtiliser une grille d’evaluation Tuteur, evaluateurCommenter un travail Apprenant, tuteur, evaluateurGerer les ressources ExpertAssister les apprenants Tuteur
Tab. 8.1 – Actions disponibles pour les differents types d’acteurs
Regle 1 Pour decrire un gabarit de scenario, le concepteur doit retenir au mi-nimum trois concepts :
8.2 Etape 2 : precision des concepts manipules 105
– l’acteur « apprenant » ;– l’action « realiser une tache » ;– l’action « travailler en groupe ».
Cette etape de la demarche est supportee par le formalisme presente dans lasection 9.1.
8.2 Etape 2 : precision des concepts manipules par les ac-
teurs
A ce stade, le concepteur a defini quels types d’acteurs interviennent dans lescenario, et, de maniere generale, quelles actions ils doivent y mener. La deuxiemeetape de notre demarche consiste en la precision de ces concepts (i.e. des classeset des attributs du modele generique) sur la base des acteurs et des actions definislors de l’etape precedente.
A partir des resultats de la premiere etape, il est possible d’etablir un premierparametrage automatique du modele generique, consistant en la selection (ou nonselection) de certaines classes et de certains attributs (en plus du noyau minimalpresente en 7.3). Les tableaux 8.3 et 8.3 presentent les consequences des choixoperes dans la premiere etape sur le parametrage du modele generique.
Action retenue Classe du modele mise en jeuUtiliser des ressources Ressource
Utiliser des outils Outil
Deposer/consulter/valider une contribution Contribution
Jouer un role au sein du groupe Role
Evaluer un travail Evaluation
Utiliser une grille d’evaluation Grille d’evaluation
Commenter un travail Commentaire
Tab. 8.2 – Classes selectionnees automatiquement en fonction des actions rete-nues
Certains attributs sont, s’ils sont disponibles, de fait obligatoires. A titred’exemple, si le concepteur decide que les apprenants peuvent s’auto-organiser, laclasse Plan est retenue, et l’attribut Etape.Pre-organisee : boolean devientdisponible. Cet attribut est dit obligatoire, ainsi le concepteur est contraint de leselectionner, afin de preserver l’integrite du modele. Le tableau 8.4 presente uneliste des attributs obligatoires pour chaque classe du modele.
106 Demarche de conception
Action retenue Attributs rendus disponiblesS’auto-organiser Etape.Pre-organisee : boolean
Valider contribution (tuteur) Etape.Point Validation-tuteur : boolean,Tache.Point Validation-tuteur : boolean
Valider contribution (apprenant) Etape.Point Validation-apprenant : boolean,Tache.Point Validation-apprenant : boolean
Tab. 8.3 – Attributs rendus disponibles automatiquement en fonction des actionsretenues
Classe Attributs obligatoiresScenario Nom : String
Etape Intitule : String, Pre-organisee : boolean
Tache Intitule : String
Tache collective Nombre-Participants : int, Collaborative :boolean, Synchrone : boolean
Travail Date-Debut : Date, Date-Fin : Date
Contribution Type : char
Ressource Description : String
Evaluation Note : String
Role Nom : String
Personne Nom : String, Prenom : String
Outil Nom : String
Tab. 8.4 – Attributs obligatoires
8.3 Etape 3 : structuration des etapes
Cette derniere etape consiste en la formulation d’informations supplementairesconcernant l’organisation des etapes de projet. En effet, nous constatons dans lalitterature que certains gabarits de scenarios prevoient une organisation figee pourtoutes les etapes. Ainsi, dans SPLACH, toute etape est constituee d’une phaseindividuelle asynchrone suivie d’une phase collective synchrone (cf. chapitre 2).Il convient donc d’ajouter a notre methode la possibilite pour le concepteur despecifier un ordonnancement des taches au sein d’une etape de projet. Il s’agitdu role de cette derniere etape de conception, nommee structuration des etapes.
Cette etape de la demarche est supportee par le formalisme presente dans lasection 9.2.
8.3.1 Principe
Le concepteur ordonnance dans cette etape un certain nombre de concepts,parmi lesquels certains sont disponibles uniquement selon certaines conditions.
8.3 Etape 3 : structuration des etapes 107
Ainsi, comme le montre le tableau 8.5, si l’attribut Collaborative : boolean dela classe Tache Collective a ete retenu, alors le concepteur peut manipuler destaches cooperatives ou collaboratives. Si ce n’est pas le cas, il peut uniquementmanipuler des taches collectives.
Concepts disponibles ConditionsTache individuelle aucuneTache collective Tache Collective.Collaborative : boolean non re-
tenuTache cooperative Tache Collective.Collaborative : boolean retenuTache collaborative Tache Collective.Collaborative : boolean retenuValidation aucuneEvaluation aucune
Tab. 8.5 – Structuration d’une etape de projet : concepts disponibles
Cette structuration des etapes abouti a un parametrage automatique dumodele generique. En effet, etant donne qu’il existe un lien d’association Precede
entre la classe Tache et elle-meme, il decoule de la structuration des etapes unparametrage de ce lien.
8.3.2 Exemple
Nous illustrons ici la structuration des etapes a l’aide d’un gabarit de scenarioinspire de SPLACH. Dans SPLACH, chaque etape est constituee d’une phaseindividuelle asynchrone suivie d’une phase collective asynchrone. Le diagrammede structuration des etapes produit est presente par la figure 8.1.
Groupe Chef de projetApprenant
Tâche individuelle
Tâche collective
Fig. 8.1 – Structuration des etapes pour un gabarit de scenario de type SPLACH
108 Demarche de conception
A partir de ce diagramme, un parametrage du modele generique est effectue,de la maniere presente par la figure 8.2.
Tâche
Précède >1..* 1
Tâche individuelle Tâche collective
Fig. 8.2 – Extrait du modele generique parametre automatiquement a partir dudiagramme de la figure 8.1
8.4 Conclusion
Notre demarche de conception s’articule donc en trois parties :
1. Definition des types d’acteurs et de leurs actions ;
2. Precision des concepts manipules par les acteurs ;
3. Structuration des etapes.
Ces trois etapes permettent d’aboutir a un parametrage du modele generiquedecrivant un gabarit de scenario. Le chapitre suivant presente les formalismesproposes pour l’accomplissement des etapes de la demarche.
Chapitre 9
Formalismes proposes
Toute methode de conception de systemes d’information doit s’ap-puyer sur des formalismes pour la description des mecanismes et descaracteristiques du systeme. Nous proposons deux formalismes (ouplutot deux adaptations de formalismes), destines a aider le concep-teur d’APCD de projets dans les etapes 1 et 3 de la demarche, asavoir : « definition des types d’acteurs de leurs actions » et « struc-turation des etapes ».
Table des matieres9.1 Formalisme de definition des acteurs et actions . . . 110
9.1.1 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . 1109.1.2 Les actions . . . . . . . . . . . . . . . . . . . . . . . . 1119.1.3 Les liens . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.2 Formalisme dedie a la structuration des etapes . . . 111
110 Formalismes proposes
9.1 Formalisme dedie a la definition des type d’acteurs et de
leurs actions
Nous proposons, pour la description des types d’acteurs mis en jeu dans legabarit de scenario et la specification des actions qu’il leur est possible d’entre-prendre, une adaptation du formalisme de cas d’utilisations UML. En effet, ils’agit de la fonction premiere des diagrammes de cas d’utilisation (use cases),que de permettre au concepteur (de systemes d’information, dans notre cas degabarits de scenarios pedagogiques pour APCD de projets) de modeliser les fonc-tionnalites du systeme.
Le passage automatique d’un diagramme de cas d’utilisation quelconque a uneimplementation informatique se revele complexe voire impossible, c’est la raisonpour laquelle nous proposons une solution intermediaire : perdre une partie dupouvoir d’expression en cas d’utilisation pour gagner la possibilite d’automatiserle passage du use-case a l’implementation.
9.1.1 Les acteurs
Nous proposons de restreindre le nombre d’acteurs disponibles a quatre :l’apprenant, le tuteur, l’evaluateur et l’expert.
Regle 2 Les types d’acteurs sont representes selon un code de couleurs preetabli :apprenant en noir, tuteur en bleu, evaluateur en rouge et expert en vert.
Le concepteur ne peut donc, lors de l’elaboration du diagramme de cas d’uti-lisation, utiliser que ces quatres types d’acteurs. La figure 9.1 propose un premierexemple mettant en jeu deux types d’acteurs : l’apprenant et le tuteur.
Apprenant
Réaliser des tâches
TuteurAssister
Fig. 9.1 – Exemple de diagramme de definition des acteurs et de leurs actions
Regle 3 Le diagramme de definition des types d’acteurs et de leurs actions nedoit comporter qu’une occurrence de chaque type d’acteur.
9.2 Formalisme dedie a la structuration des etapes 111
9.1.2 Les actions
De la meme facon que pour les acteurs, nous proposons de restreindre lenombre d’actions (cas d’utilisation) au noyau des quatorze actions enoncees auchapitre 8.
La figure 9.2 propose un exemple realiste de diagramme, mettant jeu deuxtypes d’acteurs : l’apprenant et le tuteur, dans un scenario de type APC.
Apprenant
Valider une contribution
Tuteur
Évaluer travail
Consulter contribution
Réaliser tâche
Déposer contribution
Travailler en groupe
Utiliser outils
Assister
Fig. 9.2 – Exemple de diagramme de definition des acteurs d’un scenario de typeAPC
9.1.3 Les liens
Lors de l’elaboration du diagramme de definition des types d’acteurs et deleurs actions, il n’est pas possible de relier n’importe quels concepts entre-eux. Lesliens doivent alors respecter les regles d’integrite presentees au chapitre precedant,par le tableau 8.1.
9.2 Formalisme dedie a la structuration des etapes
La specification d’une structure d’etape fait appel un agencement chrono-logique d’evenements. Pour ce faire, nous devons disposer d’une representationmettant graphiquement en exergue les notions d’anteriorite et de posteriorite.
112 Formalismes proposes
Ici aussi, UML propose un formalisme adapte a ce besoin : le diagrammed’activites. Le diagramme d’activites est une variante des diagrammes d’etats-transitions, et permet de representer une succession d’actions effectuees par lesdifferents acteurs. Chaque type d’acteur est dispose dans une trave, commel’illustre la figure 9.3.
Apprenant Groupe
Tâche individuelle
Tâche collaborative
Fig. 9.3 – Exemple de diagramme d’activite
Regle 4 Le diagramme de structuration des etapes est partitionne en traveesoccupees par les acteurs definis dans le diagramme de definition des acteurs et deleurs actions. Une travee supplementaire est ajoutee pour le groupe.
La figure 9.4 illustre le partitionnement issu de l’exemple de la figure 9.2.
Groupe TuteurApprenant
Fig. 9.4 – Partitionnement du diagramme de structuration des etapes : cas del’APC
9.2 Formalisme dedie a la structuration des etapes 113
Apres partitionnement, le diagramme d’activite est complete par une succes-sion des actions suivantes (les conditions de la disponibilite ou non de telle outelle action sont detaillees dans la section 8.3) :
– tache individuelle ;– tache collective ;– tache cooperative ;– tache cooperative ;– validation ;– evaluation.
Chapitre 10
Le logiciel Progetto : un outil d’aidea la conception d’APCD
La derniere composante de notre methode est l’outil destine asupporter et a mettre en œuvre cette methode. Un logiciel a doncete developpe dans le cadre de ce DEA, ayant pour nom Progettoet pour but de guider le concepteur dans sa demarche de creationde gabarits de scenarios pedagogiques pour APCD de projets. Cechapitre propose une presentation d’ensemble de l’implementation etdes fonctionnalites du logiciel.
Table des matieres10.1 Etude prealable . . . . . . . . . . . . . . . . . . . . . . 116
10.1.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . 11610.1.2 Description des acteurs . . . . . . . . . . . . . . . . . 11610.1.3 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 116
10.2 Choix techniques . . . . . . . . . . . . . . . . . . . . . . 11610.2.1 Besoins informatiques . . . . . . . . . . . . . . . . . . 11610.2.2 Choix de Java . . . . . . . . . . . . . . . . . . . . . . . 116
10.3 Fonctionnement du logiciel . . . . . . . . . . . . . . . . 11710.3.1 Definition des types d’acteurs et de leurs actions . . . 11810.3.2 Precision des concepts manipules par les acteurs . . . 11910.3.3 Structuration des etapes . . . . . . . . . . . . . . . . . 12110.3.4 Finalisation . . . . . . . . . . . . . . . . . . . . . . . . 12310.3.5 Utilisation de l’assistant . . . . . . . . . . . . . . . . . 12310.3.6 Autres fonctionnalites du logiciel . . . . . . . . . . . . 125
116 Le logiciel Progetto : un outil d’aide a la conception d’APCD
10.1 Etude prealable
10.1.1 Analyse des besoins
Une grande partie des besoins auxquels doit repondre le logiciel ayant eteenumeres au fil des chapitres de ce memoire, nous n’en rappelons ici que lesgrandes lignes.
Le developpement du logiciel Progetto (et de la methode du meme nom) estnee du constat qu’aucune aide n’est disponibles pour les concepteurs d’APCDdans les plateformes existantes. Or, un guidage peut se reveler precieux lors dela phase de conception.
Progetto s’adresse a des personnes non necessairement informaticiennes : lelogiciel doit donc disposer d’une interface simple et intuitive, permettant a l’uti-lisateur d’elaborer des gabarits de scenarios pedagogiques adaptes a ses besoins.Le guidage devra s’effectuer via des assistants intuitifs.
10.1.2 Description des acteurs
L’application n’implique dans son fonctionnement qu’un unique acteur : leconcepteur d’APCD de projets.
10.1.3 Cas d’utilisation
La figure 10.1 page 117 resume l’ensemble des utilisations que le concepteurpeut faire du logiciel.
10.2 Choix techniques
10.2.1 Besoins informatiques
Comme mentionne dans la section precedente, Progetto doit disposer d’uneinterface graphique conviviale et simple, permettant a l’utilisateur de manipu-ler des objets graphiques (acteurs des cas d’utilisations, diagrammes d’activites,etc.). De plus, Progetto doit permettre l’enregistrement des fichiers generes pourune reouverture ulterieure, ainsi que l’export au format XML (a destination dufutur outil auteur).
10.2.2 Choix de Java
Nous avons choisi de developper le logiciel en langage Java. Java est un lan-gage objet, ce qui nous a semble particulierement interessant dans notre situation,
10.3 Fonctionnement du logiciel 117
Concepteur
Créer un diagramme dedescription des acteurs et actions
Préciser les concepts
Créer un diagramme destructuration des étapes
Exporter le gabarit en XML
Fig. 10.1 – Diagramme general de cas d’utilisation du systeme
puisque notre modelisation a ete realisee notamment a l’aide d’UML, qui est unformalisme de modelisation objet. La transition entre modelisation UML et pro-grammation Java est donc relativement naturelle. De plus, Java permet de creerdes applications portables (Windows, Linux, Mac OS. . .), ce qui est un atoutquant a la distribution du logiciel.
Java permet de travailler selon deux choix d’implementation : applets ou pro-grammes autonomes. Bien que les applets soient plus souples d’utilisation car nenecessitent pas d’installation (un simple navigateur Internet suffit), nous avonschoisi de developper un logiciel autonome. Ce choix a notamment ete influencepar le fait que Progetto doit etre en mesure d’ouvrir et de sauvegarder des fichierssur la machine l’executant, ce qui est impossible via des applets.
10.3 Fonctionnement du logiciel
Le logiciel Progetto implemente de maniere fidele la methode de conception dumeme nom. A ce titre, le logiciel propose une demarche en trois etapes : definitiondes types d’acteurs de leurs actions, precision des concepts et structuration desetapes. La figure 10.2 page 118 presente l’interface du logiciel.
118 Le logiciel Progetto : un outil d’aide a la conception d’APCD
Fig. 10.2 – Progetto : interface du logiciel
10.3.1 Definition des types d’acteurs et de leurs actions
La premiere etape de la demarche, consistant en la definition des acteurs etde leurs actions, fait l’objet, dans Progetto, d’un editeur de cas d’utilisation. Leconcepteur peut donc definir les types d’acteurs intervenant dans son scenario,et les actions qu’il leur est possible d’effectuer. Bien entendu, le logiciel guidel’utilisateur, et ne l’autorise a disposer sur le modele que des concepts et des liensrespectant les regles d’integrite developpees au chapitre 8. La figure 10.3 page 119presente une copie d’ecran contenant un diagramme de definition des acteurs etde leurs actions pour un scenario de type SPLACH.
Description de l’interface de definition des acteurs et de leurs actions
Nous apportons ici quelques precisions concernant l’interface de definition desacteurs et de leurs actions presentee par la figure 10.3. Les chiffres entoures d’uncercle correspondent aux marques ajoutes a la figure 10.3.
➀ L’espace de dessin est la partie preponderante de l’interface de definition destypes d’acteurs et de leurs actions. C’est dans cette espace que le concepteur placeles differentes composantes (acteurs, actions, liens) du diagramme de definitiondes types d’acteurs et de leurs actions.
10.3 Fonctionnement du logiciel 119
1
5
3
4
2
Fig. 10.3 – Definition des acteurs et de leurs actions dans Progetto
➁ La barre d’outils permet au concepteur de choisir quel composant (concept)il souhaite deposer sur l’espace de dessin. Cette barre, composee de boutons adeux etats, permet a tout moment de connaıtre quel outil est selectionne.
➂ Un acteur est depose sur l’espace de dessin a l’aide d’un simple clic desouris, apres avoir selectionne l’acteur desire dans la barre d’outils. L’acteur ainsidepose peut etre renomme (clic droit puis Renommer), comme cela a ete faitdans la figure 10.3 : l’acteur Tuteur a ete renomme Chef de projet.
➃ De la meme maniere que pour les acteurs, les actions sont deposees surl’espace de dessin par un simple clic de souris, apres avoir selectionne l’actiondesiree dans la liste deroulante situee a la droite de la barre d’outils.
➄ A tout moment, un clic droit de souris sur l’espace de dessin provoquel’apparition d’un menu contextualise. Ainsi, dans l’exemple de la figure 10.3,le concepteur peut obtenir de l’aide concernant l’action Utiliser des outils, ousupprimer cette action du diagramme.
10.3.2 Precision des concepts manipules par les acteurs
Apres avoir pose les premieres briques du gabarit de scenarios en definissantles types d’acteurs en presence ainsi que les actions leur incombant, le concepteur
120 Le logiciel Progetto : un outil d’aide a la conception d’APCD
doit, selon les specifications de la methode Progetto, apporter quelques precisionsquant aux concepts manipules.
1
2 3
4 5
Fig. 10.4 – Interface de precision des concepts manipules par les acteurs
Description de l’interface de precision des concepts
Nous apportons ici quelques precisions concernant l’interface de precision desconcepts presentee par la figure 10.4.
➀ A partir des resultats de la premiere etape, il est possible d’etablir un pre-mier parametrage automatique du modele generique. Ce parametrage, consistanten la selection (ou non selection) de certaines classes et de certains attributs (enplus du noyau minimal) est effectue en partie par le logiciel. Ainsi, les reglespresentees dans le tableau 8.3 sont appliquees automatiquement par Progettopour generer, des l’affichage de la page de precision des concepts, une liste declasse (agrementees d’attributs) compte tenu des choix effectues dans l’etapeprecedente, comme le montre la figure 10.5.
➁ et ➂ Pour chaque concept, un certain nombre d’attributs sont disponibles.Parmi ceux-ci, certains sont obligatoires : ils apparaissent en rouge dans le logiciel.La selection d’un attribut s’effectue en cliquant sur cet attribut, puis en le placant
dans la liste des attributs retenus a l’aide du bouton .
10.3 Fonctionnement du logiciel 121
➃ Des qu’un concept ou un attribut est selectionne (simple clic gauche desouris), une image illustrative permet d’eclairer l’auteur sur la signification etl’utilisation de ce concept ou attribut.
➄ De la meme maniere, un texte explicatif apporte des precisions sur leconcept ou attribut selectionne afin que le concepteur cerne pleinement l’interetde la selection ou non selection de tel ou tel attribut.
Fig. 10.5 – Exemple de passage automatique de l’etape 1 a l’etape 2 dans Progetto
10.3.3 Structuration des etapes
Quand l’utilisateur a defini les types d’acteurs ainsi que les actions devantetre realisees par ces acteurs, il lui reste a specifier, si besoin, la maniere dontsont structurees les etapes de projet. Pour ce faire, Progetto propose une inter-face simplifiee, de type « editeur de diagrammes d’activites UML » (figure 10.6page 122).
122 Le logiciel Progetto : un outil d’aide a la conception d’APCD
2
1
3
Fig. 10.6 – Interface de structuration des etapes
Description de l’interface de structuration des etapes
Nous apportons ici quelques precisions concernant l’interface de structurationdes etapes presentee par la figure 10.6.
➀ Comme pour l’interface de definition des acteurs et de leurs actions, lastructuration des etapes s’appuie sur deux composantes principales : une barred’outils (dont le fonctionnement est analogue a celui decrit en 10.3.1 pour ladefinition des acteurs et de leurs actions) ainsi qu’un espace de dessin. La barred’outils possede cependant une particularite dans le cas de la structuration desetapes : les outils proposes sont differents en fonction des choix effectues par leconcepteur dans les etapes precedentes.
➁ L’espace de dessin est divise en travees. Selon les types d’acteurs definisprecedemment (etape 1) par le concepteur, le nombre et la nature des traveessont imposes par le logiciel (il y a autant de travees que de types d’acteurs plusune : celle reservee au groupe). Par exemple, si le concepteur a retenu deux typesd’acteurs, l’apprenant et le tuteur, Progetto trace automatiquement trois travees :une pour l’apprenant, une pour le tuteur et une pour le groupe ; c’est le cas de lafigure 10.6.
➂ Les actions (activites dans le cadre d’un diagramme d’activites UML) sontdisposees dans les travees, et ordonnancees chronologiquement de haut en bas.Ainsi, dans l’exemple de la figure 10.6, une etape de projet est composee d’une
10.3 Fonctionnement du logiciel 123
tache collective, suivie d’une validation par chaque apprenant, puis d’une valida-tion par le tuteur.
10.3.4 Finalisation
La derniere etape de creation d’un gabarit de scenarios dans Progetto consisteen la finalisation du gabarit. Le concepteur peut alors saisir des informationscomplementaires, comme le nom du gabarit, ou encore le nom de son auteur (fi-gure 10.7).
De plus, le concepteur dispose, dans un souci de clarification et de confir-mation, d’un enonce du scenario en langue naturelle, reprenant les differentescaracteristiques du gabarit de scenarios produit.
Remarque 9 Cette fonctionnalite de production d’un resume en langue naturellen’est pas disponible dans la version 0.1 du logiciel, et sera implementee dans lesversions futures.
Fig. 10.7 – Finalisation du gabarit de scenarios
10.3.5 Utilisation de l’assistant
La fonctionnalite majeure de Progetto est l’assistance a la creation de gaba-rits de scenarios. Cette assistance est realisee, en plus des multiples aides contex-
124 Le logiciel Progetto : un outil d’aide a la conception d’APCD
tuelles presentes tout au long de la demarche de creation, grace a un assistant ala creation de gabarits. A la maniere de nombreux logiciels actuels, cet assistantpermet, au travers de quelques questions (s’appuyant sur la typologie proposeeau chapitre 3), de batir une ebauche de gabarit, pouvant etre ensuite retravailleet modifie par le concepteur.
L’assistant creation de gabarits collecte les informations necessaires a la miseen place d’un gabarit minimal par le biais de cinq etapes, concernant respective-ment :
1. Le but du scenario ;
2. Le degre de liberte accorde ;
3. La taille des groupes ;
4. Les roles ;
5. La strategie d’evaluation.
Pour chacun de ces points, Progetto oriente le concepteur vers l’option corres-pondant le mieux a ses besoin, en lui apportant une aide textuelle. La figure 10.8presente, a titre d’exemple, les trois premiers ecrans de l’assistant creation degabarits de scenarios propose dans Progetto.
Fig. 10.8 – L’assistant creation de gabarits de scenarios dans Progetto
10.3 Fonctionnement du logiciel 125
10.3.6 Autres fonctionnalites du logiciel
Le logiciel permet de manipuler les fichiers crees (enregistrement/ouverture),en gerant un type de fichier Progetto (extension .pto).
En plus de ces fonctionnalites, Progetto permet d’exporter le gabarit descenarios genere au format XML (Extended Markup Language). Le fichier XMLainsi cree contient en fait le modele generique parametre (classes, attributset liens), plus quelques informations supplementaires (nom de l’auteur, nomdu gabarit, etc.). Cette fonctionnalite est donc particulierement interessente,du fait qu’elle autorise d’une part une analyse semantique, mais egalement uneimplementation en tables d’une base de donnees (il suffit d’utiliser le fichier XMLpour generer des structures de tables de bases de donnees).
Enfin, ce document XML servira de relais entre l’outil d’aide a la conceptionde gabarits de scenarios presente ici, et l’outil auteur de scenarios pedagogiques,qui sera developpe ulterieurement. Cet outil auteur aura pour but de permettrea un auteur lambda d’utiliser un gabarit de scenarios precedemment cree pourl’instancier en un scenario particulier, et eventuellement l’exporter dans un formatnormalise (cf. chapitre 11).
Chapitre 11
Positionnement par rapport a lanormalisation
De nombreux travaux portent actuellement sur la normalisationdans les EIAH. Visant principalement a rendre les differents conte-nus pedagogiques utilisables dans des contextes heterogenes (Web,support papier, cours, TD, etc.), cette normalisation s’est d’abordcantonnee a la description des contenus d’apprentissage (ex. : LOM,Learning Object Metadata). Or, depuis quelques temps, la norma-lisation va au dela de la description des contenus, pour s’interesseraux processus d’apprentissage dans leur ensemble. Dans cette mou-vance, une proposition se distingue et semble etre appelee a devenirun standard : IMS Learning Design. Nous presentons dans ce chapitreIMS LD, puis faisons le rapprochement avec nos travaux et degageonsquelques perspectives.
Table des matieres11.1 Presentation succincte de IMS Learning Design . . . 12811.2 IMS-LD pour la description de gabarits de scenarios ?129
11.2.1 Ce qu’il est possible de faire . . . . . . . . . . . . . . . 12911.2.2 Ce qui reste en suspend. . . . . . . . . . . . . . . . . . . 129
11.3 Solution proposee . . . . . . . . . . . . . . . . . . . . . 130
128 Positionnement par rapport a la normalisation
11.1 Presentation succincte de IMS Learning Design
Learning Design tient ses origines des travaux de l’Open University of Ne-therland. Des decembre 2000, une premiere version d’EML (Educational Model-ling Language) a ete rendue publique. Ce langage de modelisation de contenuspedagogiques a vite montre ses limites, notamment par le fait que les specificationsd’EML etaient tres importantes. A EML a donc succede le projet Learning Design(integrant lui meme EML), ayant pour but de developper un cadre supportantla diversite et l’innovation pedagogique, tout en favorisant l’interoperabilite desunites d’apprentissage.
Un document LD conforme au standard IMS est un fichier au format XML.Ce fichier XML s’organise de la maniere suivante (la traduction francaise destermes de LD a ete proposee par Anne Lejeune dans [Lejeune, 2003]) :
1 <!-- Version originale -->
2 learning-design
3 title
4 learning-objectives
5 prerequisites
6 components
7 roles
8 activities
9 environments
10 method
11 play
12 act
13 role-parts
14 metadata
<!-- Traduction en francais --> 1
mise en scene 2
titre 3
objectifs 4
pre-requis 5
composants 6
roles 7
activites 8
environnements 9
methode 10
piece 11
acte 12
partition 13
meta-donnees 14
Fig. 11.1 – Structure d’un fichier XML Learning Design
Le learning design peut donc etre assimile a une mise en scene (ligne 10 etsuivantes de la figure 11.1). Cette mise en scene specifie des pieces composeesd’actes sequentiels, mettant en jeu un ou plusieurs acteurs. Chaque acteur jouedans un acte un role associe a une activite effectuee dans un environnement(∼ decor). Une activite, au sens d’IMS-LD, est un script decrivant ce que chaquerole fait sur scene pendant un acte de la piece [Lejeune, 2003].
11.2 IMS-LD pour la description de gabarits de scenarios ? 129
11.2 IMS-LD pour la description de gabarits de scenarios ?
Nous tentons d’etablir, dans cette section, un rapprochement entre nos travaux(notamment notre modelisation generique) et l’approche IMS-LD.
11.2.1 Ce qu’il est possible de faire
Il est clair que la structuration des scenarios en pieces, actes, etc. proposeepar LD est applicable et utilisable dans le cadre de la description de gabaritsde scenarios (il s’agit meme du plus important point de comptabilite entre notreapproche et IMS-LD). Au meme titre, les notions d’objets pedagogiques (res-sources adressables et utilisables) et de services (chats, forums, etc.) presententdes caracteristiques tres proches de nos concepts de ressource et d’outil. Enfin,les activites dites « de support » resp. « d’apprentissage » correspondent aux ac-tivites des tuteurs, evaluateurs et experts, resp. des apprenants.
Il semble donc qu’IMS-LD prevoit bon nombre des situations pouvant etre for-mulees dans nos gabarits de scenarios pedagogiques pour APCD de projets. Ce-pendant, quelques specificites de notre modelisation ne peuvent etre representesa l’aide d’IMS-LD (figure 11.2).
Gabarit de scénario
Progetto
Scénario pédagogique
IMS-LD
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Partiecommune
Fig. 11.2 – Progetto et IMS-LD : deux approches differentes et quelques pointscommuns
11.2.2 Ce qui reste en suspend. . .
Dans Progetto, le concept de groupe est central. Une classe nommee Groupe estd’ailleurs presente dans le modele generique, ce qui traduit une volonte d’orienter
130 Positionnement par rapport a la normalisation
la conceptualisation a un niveau « collectif ». Dans IMS-LD, la notion de groupen’est pas disponible explicitement, mais decoule de l’association de plusieurs per-sonnes (ou plus precisement de plusieurs roles) a une activite donnee. Ceci nepose pas de probleme lors de l’instanciation de l’activite pedagogique, mais nuita notre objectif de creer une modelisation explicite d’activites collectives (ou leconcept de groupe tient toute son importance). Cette « carence » d’IMS-LD pourla specification d’activites collectives a par ailleurs fait l’objet de publications vi-sant a l’enrichir, comme par exemple [Hernandez et al., 2004].
De cette premiere incompatibilite en decoule une deuxieme. Si la specificationdu concept de groupe n’est pas indispensable dans la description de scenariospedagogiques d’APCD, elle l’est dans le cas ou l’on souhaite decrire des gabaritsde scenarios. En effet IMS-LD travaille au niveau des scenarios, alors que noustravaillons au niveau des gabarits de scenarios (ce qui concretement implique lagestion de donnees supplementaires, correspondant a un niveau de specificationplus eleve).
11.3 Solution proposee
Face a cette situation d’incompatibilite entre notre approche et l’approcheIMS-LD, mais conscients qu’IMS-LD est en passe de devenir un standard, nousnous devons de proposer une integration de l’approche IMS-LD (se traduisantpar la possibilite de creer des scenarios au format LD) a un moment de notreprocessus de conception de scenarios.
Etant donne qu’IMS-LD travaille au niveau des scenarios, la solution proposeeconsiste a considerer que l’export au format LD ne releve par de l’outil concepteurpresente dans le cadre de nos travaux de DEA. Cependant, cet outil concepteurn’est pas destine a etre utilise seul, mais produit des fichiers a destination d’unoutil auteur non-encore developpe (cf. 10.3.6). Nous rappelons que l’outil auteuraura pour but de produire des scenarios pedagogiques (instances des gabarits descenarios). Il « parlera le meme langage » qu’IMS-LD, et pourra donc exporter cesscenarios au format IMS-LD. Nous prevoyons donc d’integrer a cet outil auteurune fonctionnalite d’export des scenarios produits au format XML respectant lanorme IMS-LD (figure 11.3 page 131).
11.3 Solution proposee 131
Définition d'un gabarit de scénario :fichier XML propriétaire
Description d'un scénario : fichier XML compatible LD
Concepteur
Auteur
Fig. 11.3 – Demarche globale de production d’un scenario pedagogique pourAPCD de projets
Synthese de la troisieme partie
Cette troisieme et derniere partie a ete consacree a la presentation de Progetto,notre methode de conception de gabarits de scenarios pedagogiques pour lesAPCD de projets. Nous avons ainsi presente toutes les composantes de cettemethode, a savoir : un modele generique de gabarits de scenarios, une demarchede conception en trois etapes, des formalismes de description des concepts et unoutil (nomme Progetto), permettant de mettre en œuvre la methode. Enfin, nousavons effectue un rapprochement entre nos travaux et IMS Learning Design, etavons explique comment nous prevoyons d’adapter les scenarios produits a cettenorme.
Conclusion
Bilan de nos travaux
Au cours de ce stage de DEA, nous avons aborde le probleme des acti-vites pedagogiques collectives distantes. Plus particulierement, nous nous sommesinteresses a la pedagogie de projet, dans un contexte d’activites collectives dis-tantes mediatisees par ordinateur. Constatant qu’aucune methode de concep-tion de gabarits de scenarios pedagogiques pour ce type d’activite n’existait,nous avons decide de construire une methode de conception de gabarits descenarios pour APCD de projets.
Dans la premiere partie de ce memoire, nous avons rappele les bases theoriquespedagogiques sur lesquelles se fondent nos travaux. Un etat de l’art a ete realise,permettant de disposer d’une synthese et d’une analyse des travaux effectuesjusqu’a present concernant la description de gabarits de scenarios pedagogiquespour les APCD de projets, et plus generalement de scenarios pedagogiques etd’outils destines a supporter ces scenarios. Une typologie d’APCD de projetspar objectifs a ete proposee, afin de pouvoir guider un concepteur d’APCD deprojets vers un gabarit de scenario adapte a ses besoins. Apres avoir indique etjustifie notre demarche de modelisation, nous avons presente, dans une deuxiemepartie, l’ensemble des modeles MOT et UML des gabarits de scenarios etudies.L’analyse de ces modeles ayant revele de fortes similitudes entre tous les gaba-rits etudies, nous avons pose l’hypothese selon laquelle il est possible de fondernotre methode de conception sur un modele generique de gabarits de scenariospedagogiques pour les APCD de projets. La troisieme et derniere partie de cememoire a ete consacree a l’enonciation et la justification de notre methode deconception, a travers la presentation de ses composantes : modele generique,demarche de conception, formalismes proposes et outil support de creation degabarits de scenarios pour APCD de projets. Conscients de la mouvance actuelleet de l’importance sans cesse grandissante de la normalisation dans les EIAH,nous avons egalement consacre un chapitre, dans cette derniere partie, au rap-prochement entre notre methode et IMS Learning Design. Nous y avons presentedes perspectives nous semblant particulierement interessantes quant a la compa-tibilite et la complementarite entre notre approche et IMS-LD.
134 Conclusion
Apport scientifique
L’apport scientifique principal de nos travaux reside en la proposition d’unemethode de conception de gabarits de scenarios pedagogiques pour les APCDde projets : Progetto. Aucune methode de ce type n’existait jusqu’a present.Nous avons effectue un parallele entre les systemes d’information, domaine danslequel des resultats eprouves existent en termes de techniques de modelisationet de methodes de conception, et les activites pedagogiques. A l’heure des plate-formes d’enseignement a distance normalisees, ces activites pedagogiques doivents’inserer dans ces plateformes constituant autant de systemes d’information.
Nous proposons egalement une premiere ebauche de typologie d’APCD de pro-jets par objectifs. Nous voyons en cette typologie (et dans les reflexions qu’elleengendre) un reel interet pedagogique, puisque qu’a ce jour, aucun guidage n’estfourni au niveau « pedagogique » aux concepteurs d’activites collectives sur lespateformes d’enseignement a distance. Cette typologie se propose d’apporter unetelle aide en fonction des objectifs pedagogiques des concepteurs, bien que noussoyons conscients qu’aucune « recette » n’existe en matiere de pedagogie, et quenotre typologie reste tres perfectible.
Enfin, nos travaux ont permis de realiser un logiciel operationnel, Progetto,implementant la methode du meme nom. Ce logiciel permet de definir des gabaritsde scenarios pour APCD de projets tres diversifies, propose un guidage sous formed’assistant (s’appuyant sur la typologie sus-citee), et contient egalement quelquesgabarits types issus de la bibliographie (SPLACH, APC, SYMBA) sur lesquelsl’utilisateur peut s’appuyer. Nous participons donc par ce biais a la concretisationdes recherches en EIAH, et au rapprochement entre recherche et implementation.
Limites
La principale limite de nos travaux leur est fixee par le domaine dans lequel ilsevoluent : une modelisation informatique ou le guidage d’un logiciel ne peuventintegrer toute la richesse du processus de creation pedagogique. Progetto s’appuiedonc sur un modele dit generique, mais cette genericite ne reste vraie que si l’onne sort pas du cadre des gabarits rencontres dans la litterature. Autrement dit,notre modele generique est capable, par parametrage, de generer tous les gabaritsde scenarios pour APCD rencontres dans la litterature plus des modeles hybrides,mais ne peut pretendre repondre a toutes les situations pedagogiques emanant del’imagination d’un concepteur d’APCD. Nous sommes conscients de cette limite,et voyons en Progetto une aide a la conception plutot qu’une methode universelle.
Conclusion 135
Perspectives
Notre approche est issue du monde du genie logiciel et des systemes d’infor-mation : apres avoir observe le fonctionnement et l’organisation d’un systeme(d’information), nous en avons propose une modelisation. Cette modelisationimplemente les concepts etudies sous la forme de classes (elles-meme instancieesen objets). Cette approche cohabite, notamment dans le domaine des EIAH, avecune autre approche, issue du domaine de l’intelligence artificielle et consistant enla modelisation de connaissances, notamment par le biais d’ontologies. Alors quel’approche ontologique occupe aujourd’hui une place importante dans les EIAH,nous reflechissons aux apports d’une telle approche dans le cadre de nos objectifsde recherche (i.e. assister les concepteurs d’APCD de projets dans leur demarche).
A ce titre, nous participons, depuis quelques mois, au projet OURAL (Onto-logies pour l’utilisation de ressources de formation et d’annotations semantiquesen ligne) du CNRS (programme TCAN : Traitement des connaissances, appren-tissage et NTIC). Au sein de ce projet, nous tentons de fournir des elementspertinents pour la construction d’ontologies, en nous referant a notre experiencede modelisation des activites pedagogiques collectives, notamment sur la base del’analyse bibliographique presentee dans ce document. Nous sommes confrontes,dans ce cadre, au probleme du passage d’une approche « systemes d’informa-tion » a l’approche « ontologies ». Concretement, il s’agit de comprendre les en-jeux et de proposer des solutions aux problemes lies au passage d’une modelisationobjet de type UML a une ontologie1 dans le cadre des EIAH. Il s’agit d’une desperspectives de nos travaux de DEA.
A plus court terme, nous souhaitons continuer le developpement du logicielProgetto, afin d’en faire un outil completement operationnel pour les concepteursd’APCD. Nous sommes conscients que la pertinence de notre outil repose demaniere preponderante sur la qualite de la typologie permettant de guider leconcepteur vers un gabarit adapte a ses objectifs pedagogiques. C’est la raisonpour laquelle l’une des priorites nous semble etre l’amelioration et l’amenagementde la typologie presentee au chapitre 3 de ce memoire.
1Nous travaillons, au sein du projet OURAL, avec l’editeur d’ontologies open-source Protege(http://protege.stanford.edu/).
Annexes
A Exemple de fichier XML genere par Progetto
Cette annexe presente le listing du fichier XML genere automatiquement parle logiciel Progetto lors de l’edition de l’un des gabarits types disponibles : l’APCd’Anne Lapujade.
1 <?xml version="1.0" encoding="ISO-8859-1"?>
2
3 <GabaritAPCD>
4
5 <!-- Entete du type de scenario -->
6 <entete>
7 <nom>Activite pedagogique collective (APC)</nom>
8 <auteur>Anne Lapujade</auteur>
9 </entete>
10
11 <!-- Acteurs -->
12 <acteurs>
13 <apprenant>
14 <nom>Apprenant</nom>
15 </apprenant>
16 <tuteur>
17 <nom>Tuteur</nom>
18 </tuteur>
19 </acteurs>
20
21 <!-- Le modele du scenario (parametrage du modele generique) -->
22 <modele>
23 <classes>
24 <classe id="scenario">
25 <attribut>
26 <nom>Nom</nom>
27 <type>String</type>
28 </attribut>
138 Exemple de fichier XML genere par Progetto
29 </classe>
30 <classe id="etape">
31 <attribut>
32 <nom>Intitule</nom>
33 <type>String</type>
34 </attribut>
35 <attribut>
36 <nom>Duree prevue</nom>
37 <type>date</type>
38 </attribut>
39 <attribut>
40 <nom>Point de validation tuteur</nom>
41 <type>boolean</type>
42 </attribut>
43 </classe>
44 <classe id="tache">
45 <attribut>
46 <nom>Intitule</nom>
47 <type>String</type>
48 </attribut>
49 <attribut>
50 <nom>Objectif</nom>
51 <type>String</type>
52 </attribut>
53 <attribut>
54 <nom>Duree prevue</nom>
55 <type>date</type>
56 </attribut>
57 <attribut>
58 <nom>Connectee</nom>
59 <type>boolean</type>
60 </attribut>
61 <attribut>
62 <nom>Point de validation apprenant</nom>
63 <type>boolean</type>
64 </attribut>
65 </classe>
66 <classe id="tache collective">
67 <est-un ref="tache"/>
68 <attribut>
69 <nom>Collaborative</nom>
70 <type>boolean</type>
71 </attribut>
Annexes 139
72 <attribut>
73 <nom>Synchrone</nom>
74 <type>boolean</type>
75 </attribut>
76 </classe>
77 <classe id="tache individuelle">
78 <est-un ref="tache"/>
79 </classe>
80 <classe id="travail">
81 <attribut>
82 <nom>Date de debut</nom>
83 <type>date</type>
84 </attribut>
85 <attribut>
86 <nom>Date de fin</nom>
87 <type>date</type>
88 </attribut>
89 </classe>
90 <classe id="personne">
91 <attribut>
92 <nom>Nom</nom>
93 <type>String</type>
94 </attribut>
95 <attribut>
96 <nom>Prenom</nom>
97 <type>String</type>
98 </attribut>
99 </classe>
100 <classe id="apprenant">
101 <est-un ref="personne"/>
102 </classe>
103 <classe id="groupe">
104 <attribut>
105 <nom>Nom</nom>
106 <type>String</type>
107 </attribut>
108 </classe>
109 <classe id="tuteur">
110 <est-un ref="personne"/>
111 </classe>
112 <classe id="evaluation">
113 <attribut>
114 <nom>Note</nom>
140 Exemple de fichier XML genere par Progetto
115 <type>String</type>
116 </attribut>
117 </classe>
118 <classe id="outil">
119 <attribut>
120 <nom>Nom</nom>
121 <type>String</type>
122 </attribut>
123 </classe>
124 <classe id="ressource">
125 <attribut>
126 <nom>Description</nom>
127 <type>String</type>
128 </attribut>
129 </classe>
130 <classe id="fichier" >
131 </classe>
132 <classe id="contribution">
133 <est-un ref="ressource"/>
134 </classe>
135 </classes>
136 <liens>
137 <association>
138 <nom>Precede</nom>
139 <origine ref="etape" card="0..*"/>
140 <destination ref="etape" card="0..*"/>
141 </association>
142 <association>
143 <nom>Relative a</nom>
144 <origine ref="etape" card="1"/>
145 <destination ref="tache" card="0..*"/>
146 </association>
147 <association>
148 <nom>Realise</nom>
149 <origine ref="apprenant" card="1..*"/>
150 <destination ref="tache" card="*"/>
151 <classe-association ref="travail"/>
152 </association>
153 <association>
154 <nom>Precede</nom>
155 <origine ref="tache" card="0..*"/>
156 <destination ref="tache" card="0..*"/>
157 </association>
Annexes 141
158 <association>
159 <nom>Synchronisee avec</nom>
160 <origine ref="tache" card="0..*"/>
161 <destination ref="tache" card="0..*"/>
162 </association>
163 <association>
164 <nom>Encadre</nom>
165 <origine ref="tuteur" card="1"/>
166 <destination ref="groupe" card="*"/>
167 </association>
168 <association>
169 <nom>Utilise</nom>
170 <origine ref="tache" card="*"/>
171 <destination ref="outil" card="0..*"/>
172 </association>
173 <association>
174 <nom>Produit</nom>
175 <origine ref="travail" card="1..*"/>
176 <destination ref="contribution" card="1..*"/>
177 </association>
178 <association>
179 <nom>Valide</nom>
180 <origine ref="apprenant" card="0..*"/>
181 <destination ref="contribution" card="*"/>
182 </association>
183 <association>
184 <nom>Valide</nom>
185 <origine ref="tuteur" card="0..*"/>
186 <destination ref="contribution" card="*"/>
187 </association>
188 <association>
189 <nom>Concerne</nom>
190 <origine ref="evaluation" card="1"/>
191 <destination ref="outil" card="1..*"/>
192 </association>
193 <composition>
194 <nom>Est compose de</nom>
195 <compose ref="scenario"/>
196 <composant ref="etape" card="1..*"/>
197 </composition>
198 <composition>
199 <nom>Se decompose en</nom>
200 <compose ref="etape"/>
142 Exemple de fichier XML genere par Progetto
201 <composant ref="etape" card="*"/>
202 </composition>
203 <agregation>
204 <compose ref="groupe"/>
205 <composant ref="apprenant" card="2..*"/>
206 </agregation>
207 </liens>
208 </modele>
209
210 </GabaritAPCD>
Bibliographie
[Anzieu et al., 1982] Anzieu (Didier) et Martin (Jacques-Yves), La dynamiquedes groupes restreints, Le psychologue, Presses universitaires de France, Paris,decembre 1982.
[Betbeder, 2003] Betbeder (Marie-Laure), Symba : un environnementmalleable support d’activites collectives en contexte d’apprentissage, these dedoctorat, universite du Maine, decembre 2003.
[Berger et al., 2000] Berger (Jean-Francois) et Rieben (Pierre), « Environ-nements interactifs d’apprentissage sur Internet. Strategies de conception etexperimentations », dans les actes du colloque TICE’2000 (Technologie del’information et de la communication dans les enseignements d’ingenieurs etdans l’industrie), Troyes, 18-20 octobre 2000, p. 185-194.
[Booch et al., 2000] Booch (Grady), Rumbaugh (James) et Jacobson (Ivar),Le guide de l’utilisateur UML, Eyrolles, Paris, 2000.
[Charlier et al., 2000] Charlier (Bernadette) et Daele (Amaury), « Learn-Nett : une experience d’apprentissage collaboratif a distance », dans les actesdu 1er Congres des chercheurs en education, Bruxelles, mai 2000.
[Chikofsky et al., 1990] Chikofsky (Elliot J.) et Cross (James H.), ReverseEngineering and Design Recovery : A Taxonomy, IEEE Software, volume 7(1), janvier 1990, p. 13–17.
[Cohen, 2001] Cohen (Elizabeth G.), Le travail de groupe : strategies d’ensei-gnement pour une classe heterogene, Montreal, Cheneliere/McGraw-Hill, 1994,212 p.
[Collis, 1997a] Collis (Betty) et Veen (Jan van der), « Telematic Tools toSupport Group Projects in Higher Education », universite de Twente, rapportn◦CTIT/IDYLLE/D/N21, 1997.
[Collis, 1997b] Collis (Betty), « Supporting Project-Based Collaborative Lear-ning Via a World Wide Web Environment », dans Kahn (Badrul H.), Web-Based Instruction, p. 213-219, collection NJ : Educational Technology Publi-cations, Englewood-Cliffs, 1997.
[Daradoumis et al., 2000] Daradoumis (Thanasis), Xhafa (Fatos) etMarques (Joan Manuel), « A Methodological Approach to NetworkedCollaborative Learning : Design and Pedagogy Issues », dans les actes de la
144 Bibliographie
2e conference International Conference on Networked Learning, universite deLancaster, Angleterre, 17-19 avril 2000.
[Daele et al., 2002] Daele (Amaury), Brassard (Caroline), Esnault (Li-liane), O’Donogue (Michael), Uyttebrouck (Eric) et Zeiliger (Ro-main), « Conception, mise en oeuvre, analyse et evaluation de scenariospedagogiques recourant a l’usage des technologies de l’information et de lacommunication », rapport du projet Recresup-WP2, FUNDP, disponible surhttp://tecfa.unige.ch/proj/recreasup/rapport/WP2.pdf (consulte le 21-08-2004).
[De Lievre et al., 2002] De Lievre (Bruno), Quintin (Jean-Jacques) etDepover (Christian), « Une experience d’implantation d’activites organiseesa distance au niveau universitaire », dans les actes du Colloque de l’AIPU,Louvain-La-Neuve, mai 2002, 12p.
[Dirckinck-Holmfeld, 1994] Dirckinck-Holmfeld (Lone), « Project Pedagogyas the Fondation for Computer Supported Collaborative Learning », IFIP,Joint Working Conference WG 3.3 & WG 3.6., Nantes, 27-30 octobre 1994.
[Fougeres et al., 2002] Fougeres (Alain-Jerome) et Canalda (Philippe),« iPedagogique : un support adapte a la gestion de projets d’etudiants », dansles actes de CAOE’02, Bordeaux, 2002.
[George, 2001] George (Sebastien), Apprentissage collectif a distance.SPLACH : un environnement informatique support d’une pedagogie de pro-jet, these de doctorat, universite du Maine, juillet 2001.
[GSN http, 2004] Global Schoolhouse, Assessment of Project-Based Learning,http://www.gsn.org/web/pbl/plan/assess.htm, consulte le 21-08-2004.
[Gregoire et al., 1999] Gregoire (Reginald) et Laferriere (Therese), Ap-prendre ensemble par projet avec l’ordinateur en reseau, guide a l’intentiondes enseignants et des enseignantes, Rescol (Reseau scolaire canadien), univer-site de Laval, 1999.
[Henri et al., 2001] Henri (France) et Lundgren-Cayrol (Karin), Apprentis-sage collaboratif a distance : pour comprendre et concevoir les environnementsd’apprentissage virtuels, Presses de l’universite du Quebec, Sainte-Foy, Canada,2001.
[Hernandez et al., 2004] Hernandez (Davinia), Asensio (Juan) etDimitriatis (Yannis), « IMS Learning Design for the Formalization ofCollaborative Learning Patterns », dans les actes de la 4e conference Interna-tional Conference on Advanced Learning Technologies (a paraıtre), Joensuu,Finlande, aout 2004.
[Jermann et al., 1999] Jermann (Patrick) et Dillenbourg (Pierre), « An Ana-lysis of Learner Arguments in a Collective Learning Environment », dans lesactes de la conference CSCL’99 (Computer Support for Collaborative Lear-ning), universite de Stanford, Palo Alto, Etats-Unis, 12-15 decembre 1999.
Bibliographie 145
[Lapujade, 1997] Lapujade (Anne), Definition d’un meta-modele etpreservation de son integrite dans le meta-atelier de conception de systemes deformation MATIF, these de doctorat, universite de Toulouse 1, janvier 1997.
[Lapujade et al., 2003] Lapujade (Anne) et Leclet (Dominique),« Modelisation et implantation d’activites pedagogiques collectives dis-tantes. Un domaine d’experimentation : l’apprentissage de la programmationC++ », dans les actes du colloque ALCAA’2003 (Agents logiciels, cooperation,apprentissage et activite humaine), Bayonne, septembre 2003, p. 68-79.
[Lejeune, 2003] Lejeune (Anne), « IMS Learning Design : presentation de lamethode », presentation au seminaire Hypermedias, education et formation,universite de Paris VI, 16 mai 2003.
[Lemaıtre, 2000] Lemaıtre (Denis), « La pedagogie de projet dans la formationdes ingenieurs : conceptions et enjeux », dans les actes de CIFA’2000 (Congresinternational francophone d’automatique), Ecole Centrale de Lille, 5-8 juillet2000.
[Liflander, 1999] Liflander (Veli-Pekka), « Expansive Knowledge Construc-tion in Network-Based Project Learning », dans les actes de la conferenceENABLE’99, EVITech Digital Press, Institut de technologie d’Espo-Vanta,Finlande, 2-5 juin 1999.
[Mabardi, 1996] Mabardi (Jean-Francois), « La “formation au projet” et la“formation par le projet” », dans les actes de Projet et pedagogie, organisepar l’Association europeenne pour l’enseignement de l’architecture, Louvain-La-Neuve, Belgique, 1996, p. 17-21.
[Markkanen et al., 2001] Markkanen (Hannu), Donzellini (Giuliano),Ponta (Domenico), « NetPro : Methodologies and Tools for Project BasedLearning in Internet », dans les actes de la conference Ed-Media’2001 (WorldConference on Educational Multimedia, Hypermedia & Telecommunications),Tampere, Finlande, 2001.
[Morley et al., 2000] Morley (Chantal), Hughes (Jean) et Leblanc (Ber-nard), UML pour l’analyse d’un systeme d’information, Dunod informatiques,Paris, 2000.
[OMG http, 2004] Object Management Group, UML Resource Page,http://www.uml.org/, consulte le 21-08-2004.
[Paquette, 1996] Paquette (Gilbert), La modelisation par objets types : unemethode de representation pour les systemes d’apprentissage et d’aide a latache, Sciences et techniques educatives, Paris, avril 1996.
[Paquette, 1997] Paquette (Gilbert), « Le campus virtuel : un reseau d’acteurset de ressources », Revue de l’Association canadienne d’education a distance,volume 12, n◦1/2, 1997, p. 85-101.
146 Bibliographie
[Paquette, 2002] Paquette (Gilbert), L’ingenierie pedagogique : pourconstruire l’apprentissage en reseau, Presses de l’universite du Quebec, Quebec,2002.
[Rolland et al., 1988] Roland (Colette), Foucaut (Odile), Benci
(Guillaume), Conception de systemes d’information : la methode REMORA,Eyrolles, Paris, 1988.
[Roschelle et al., 1995] Roschelle (Jeremy) et Teasley (Stephanie),« Construction of Shared Knowledge in Collaborative Problem Solving »,dans O’Malley (Claire), Computer-Supported Collaborative Learning, NewYork, 1995.
[Slavin, 1995] Slavin (Robert), Cooperative Learning : Theory, Research andPractice, 2e edition, Allyn & Bacon, Boston, 1995.
[Suthers, 2002] Suthers (Dan) et Angeles Constantino-Gonzalez (Marıade los), « Coaching Collaboration in a Computer-Mediated Learning Envi-ronment », dans les actes de la conference CSCL’02, universite du Colorado,Boulder, Etats-Unis, 7-11 janvier 2002.
[Synteta, 2002] Paraskevi Synteta (Vivian), Project-Based e-Learning in Hi-gher Education : the Model and the Method, the Practice and the Portal, Pro-position de these, FPSE, universite de Geneve, 2002.
[Vassileff, 1997] Vassileff (Jean), La pedagogie du projet en formation, Chro-nique sociale, Lyon, 1997.
[Vayer et al., 1987] Vayer (Pierre) et Roncin (Charles), L’enfant et le groupe,Presses universitaires de France, Paris, 1987.
[Vivet, 1993] Vivet (Martial), « La reception des productions des apprenants :une phase essentielle dans la conduite de projet », dans les actes du 4e Colloqueinternational de la robotique pedagogique, INRP, Liege, 1993, p. 117-134.
[Ward et al., 1997] Ward (Douglas R.) et Thiessen (Esther L.), « SupportingCollaborative Project-Based Learning on the WWW », dans les actes de la2e conference International Conference on Computer Support for CollaborativeLearning, universite de Toronto, 1997.
[Walliser, 1977] Walliser (Bernard), Systemes et modeles, Seuil, Paris, 1977.
top related