pascal lando progetto : une m´ethode de … sciences et technologies de l’universit´e de...

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).


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.


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



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


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.


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


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.


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.


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


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


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.


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


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.


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.


É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.


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) ;


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


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.


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.


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.


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


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


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.


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


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


Groupe

- Nom : String

Manager


Deliverable

- Nom : String- Chemin : String

Tuteur


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.


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


La figure 5.9 presente le diagramme de classes du gabarit de scenarios deSYMBA.

5.5 iPedagogique 67

Tuteur


Groupe

- Nom : String

Apprenant


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



La figure 5.11 presente le diagramme de classes du gabarit de scenarios deiPedagogique.

Personne


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.


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.


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


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.


É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.


- 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.


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]).


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


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.


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


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


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.


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 :


– 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


ListeEnseignants


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.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


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


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).


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.


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).


É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 >


Fig. 7.40 – Validation par l’apprenant

TuteurValide >


Fig. 7.41 – Validation par le tuteur


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.


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


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.


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.


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


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 .


➃ 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).


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


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-


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.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 

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

 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/).

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 

6 <entete>

7 <nom>Activite pedagogique collective (APC)</nom>

8 <auteur>Anne Lapujade</auteur>

9 </entete>

10

11 

12 <acteurs>

13 <apprenant>

14 <nom>Apprenant</nom>

15 </apprenant>

16 <tuteur>

17 <nom>Tuteur</nom>

18 </tuteur>

19 </acteurs>

20

21 

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>


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>


48 </attribut>

49 <attribut>

50 <nom>Objectif</nom>


52 </attribut>

53 <attribut>

54 <nom>Duree prevue</nom>


56 </attribut>

57 <attribut>

58 <nom>Connectee</nom>


60 </attribut>

61 <attribut>

62 <nom>Point de validation apprenant</nom>


64 </attribut>

65 </classe>

66 <classe id="tache collective">

67 <est-un ref="tache"/>

68 <attribut>

69 <nom>Collaborative</nom>


71 </attribut>

Annexes 139

72 <attribut>

73 <nom>Synchrone</nom>


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>


84 </attribut>

85 <attribut>

86 <nom>Date de fin</nom>


88 </attribut>

89 </classe>

90 <classe id="personne">

91 <attribut>

92 <nom>Nom</nom>


94 </attribut>

95 <attribut>

96 <nom>Prenom</nom>


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>


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>



116 </attribut>

117 </classe>

118 <classe id="outil">

119 <attribut>

120 <nom>Nom</nom>


122 </attribut>

123 </classe>

124 <classe id="ressource">

125 <attribut>

126 <nom>Description</nom>


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..*"/>


157 </association>

Annexes 141

158 <association>

159 <nom>Synchronisee avec</nom>

160 <origine 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"/>


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.

http://tecfa.unige.ch/proj/recreasup/rapport/WP2.pdf

http://www.gsn.org/web/pbl/plan/assess.htm

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.

http://www.uml.org/

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.