CHAPITRE 5. La coopération dans les systèmes d’aide et/ou coopératifs
5.2. Application : iPédagogique pour la gestion de projets d’étudiants
projets d’étudiants intégré dans l’outil iPédagogique, présenté au chapitre 3, et qui s’inscrit ici dans le domaine du CSCL83 (George et Leroux, 2001). La gestion, le suivi et l’évaluation de projets sont des activités coopératives dans lesquelles, étudiants, enseignants et systèmes pédagogiques sont de véritables partenaires. Nous nous sommes alors intéressés à la modélisation, puis à l’instrumentation de ces activités coopératives (Ospina et Fougères, 2005). La TA offre un cadre bien adapté pour une telle modélisation d’activités et leurs médiatisations par des outils logiciels de type EIAH (Bourguin, 2000). Les deux caractéristiques suivantes contribuent, elles aussi, à justifier la démarche de développement orientée activité, adoptée :
C1 : les EIAH sont des systèmes complexes, multi-usages (ponctuels, continus ou discontinus, en présentiel ou à distance) et multi-utilisateurs. Ce caractère distribué et coopératif, justifie par ailleurs le développement conjoint d’un système de médiation, thème du chapitre 6 ;
C2 : les EIAH sont devenus des collecticiels. L’instrumentation de l’activité de projets d’étudiants en est une illustration : coopération entre les étudiants du groupe projet, entre les étudiants et l’enseignant tuteur, entre les membres de l’équipe enseignante, entre les acteurs et l’EIAH, entre les acteurs du moment et les futurs acteurs (mémorisation d’activité).
5.2.1. Présentation
Traditionnellement, le projet est une activité qui s’inscrit dans le processus d’apprentissage et de validation d’unités de valeur techniques. Comme support d’apprentissage il est quasi-systématiquement adopté par le corps enseignant dans sa démarche pédagogique, avec une quote-part variant entre le quart et la moitié du temps consacré à l’UV et à l’évaluation finale. Cependant cette activité est peu supportée par des systèmes pédagogiques (Tchounikine, 2002). Les raisons en sont nombreuses. Notons la complexité de cette activité qui associe des acteurs variés : les étudiants, les enseignants (experts et tuteurs), l’administrateur, sans oublier l’outil support pédagogique. Ces acteurs interagissent entre eux de multiples manières : ils s’adaptent continuellement, coopèrent, communiquent et négocient. Les projets d’UV, dans les phases d’initialisation par l’enseignant expert, de conduite par les groupes d’étudiants, de suivi par les enseignants tuteurs et d’évaluation par les enseignants évaluateurs, mettent en jeu des procédés pédagogiques d’initialisation, de gestion, de suivi et d’évaluation. Ces procédés sont complexes. En plus d’être grandement interactifs et multipartenaires, ils gèrent de très nombreuses données et relations entre ces données, et sont évolutifs. Ainsi le processus de conception et de développement de projet logiciel peut se décomposer, selon sa nature (cycle en V, prototypage rapide, etc.), en de nombreuses activités tout le long du projet (figure 21.a). Ces activités sont sujettes à de nombreuses itérations (nouveaux besoins, nouvelles spécifications, revues et corrections, améliorations, tests, intégrations, planning du projet, etc.).
83
Coopération dans les systèmes d’aide système validé système construit jeux de tests spécifications de conception spécifications fonctionnelles Spécifier Concevoir Réaliser et Tester Valider méthode de développement composants matériels et logiciels Système qualité cahier des charges dossier de tests Groupe étudiants Enseignant tuteur/évaluateur
Buts : écrire un cahier des charges (CdC) à partir d’une expression de besoins.
Description : définir les objectifs et les limites du projet.
Acteurs : l’équipe projet (responsable, rédacteurs, interviewers).
Tâches étudiants : étudier la faisabilité, identifier les services attendus, fixer les objectifs, répartir les rôles, rédiger le CdC et remettre le CdC.
Délais : 10 % par défaut (+ 5 % si choix tardif).
Validation : validation (ou rejet) et commentaires de l’enseignant tuteur sur le CdC.
Documents en entrée : description des besoins (énoncé du projet). Documents en sortie : cahier des charges.
Tâches tuteur : mettre à disposition les documents nécessaires à la rédaction du CdC, lire le CdC, valider le CdC (validation ou rejet), rédiger des commentaires.
Figure 21. a) La gestion de projets d’étudiants (GPE) : une activité coopérative ; b) Fiche de
définition de la première tâche à mener dans la phase 1 : « Rédiger le cahier des charges »
5.2.2. Description de l’application
Selon Betbeder et Tchounikine (2005) la conception d’une activité collective médiatisée dans un contexte d’apprentissage peut suivre quatre objectifs : (1) l’apprentissage d’un domaine, (2) le développement de compétences (analyse, synthèse, évaluation, etc.), (3) l’apprentissage du travail collectif, ou encore (4) la structuration d’un public cible en une communauté d’apprenants (liens sociaux). Dans une pédagogie par projet ces quatre objectifs sont visés. Le concept de projet et les processus associés (création, développement, gestion, suivi, validation, etc.) restent cependant des notions très abstraites ; nous ne considérons ici que la conception de projets logiciels. Cependant, nous ne doutons pas de l’extension de notre démarche à d’autres domaines techniques puisque nous nous inscrivons dans un processus de conception plus général, une « systèmique universelle » (Matta et al., 1999 ; Potteck, 2009) :
Conception de Projet ::= [ Définition (besoins),
Elaboration (spécifications, architecture),
Développement (système)] (5.4)
Dans les deux sections suivantes nous décrivons brièvement la modélisation des activités de gestion de projets d’étudiants (GPE) et de suivi de projets d’étudiants (SPE). Ces modélisations orientées par la TA (figure 21.b), utilisent les modèles de l’organisation, des tâches et des acteurs, de CommonKADS (Ospina, 2007). Elles constituent la base de notre proposition de système d’assistance pour la plate-forme iPédagogique (Ospina et al., 2005).
5.2.2.1. Modélisation de l’activité de GPE
La gestion de projet comporte deux fonctions : la direction de projet (décisions stratégiques ou tactiques) et la gestion de projet proprement dite (décisions opérationnelles). Aussi, entrant dans une logique de projet, les étudiants accomplissent des activités variées telles que : identification des tâches à mener (structuration), détermination des quantités/qualités de ressources nécessaires aux tâches (estimation), définition des rôles, affectation des ressources, identification des contraintes (organisation), maîtrise du calendrier et des risques (planification), établissement de l’enchaînement des tâches, définition des priorités, synchronisation (ordonnancement), contrôle périodique de l’avancement réel du projet (suivi).
Coopération dans les systèmes d’aide
- 78-Acteurs : étudiants
Activité : Gestion de projet – Phase 1
(a)
Acteurs : étudiants Activité : Gestion de Projet
Acteur : enseignant tuteur Activité : Suivi de Projet
(b)
Figure 22. Diagrammes d’activité de la phase 1, (a) pour la GPE, et (b) pour la SPE Un modèle objet du développement de projets logiciels a été conçu pour faciliter la coopération dans les activités de suivi et de gestion des projets (Fougères et Ospina, 2004). Le modèle de tâches rassemble les diagrammes d’activité de chacune des phases de la GPE (figure 22.a). Dans (Canalda et al., 2002) nous avons présenté une première approche de GPE fondée sur une synchronisation de fragments de procédés coopératifs. Nous l’avons étendue en spécifiant l’activité de suivi et en y joignant la composante de médiation (Ospina et al., 2005).
5.2.2.2. Modélisation de l’activité de SPE
Pour la structuration et l’évaluation des projets d’étudiants nous avons proposé un processus de suivi de projets. Les acteurs d’un projet interagissent continuellement (coordination, communication et négociation). En plus d’être interactifs et multipartenaires, les procédés pédagogiques déployés dans la SPE comportent de nombreuses données et relations, et sont évolutifs. Le processus de SPE (figure 22.b) doit permettre : (1) aux enseignants, d’aider les étudiants dans leur démarche, d’apprécier la complexité des projets proposés et d’évaluer finement le travail réalisé ; et (2) aux étudiants, de mesurer l’état d’avancement de leur projet, d’élaborer des actions correctrices, de structurer la conception et de produire une synthèse.
5.2.2.3. Proposition d’un système d’assistance intégré dans iPédagogique
Le système d’assistance intégré dans iPédagogique est constitué de cinq agents d’assistance (figure 23.a) : un assistant de gestion d’UV, un assistant pour la GPE, un assistant de profil utilisateur, un assistant pour l’utilisation des formulaires et un assistant tutoriel. Notons que le nombre de cinq agents n’est pas arrêté ; il correspond seulement à un stade expérimental. L’étude des services rendus par l’environnement nous a permis d’identifier cinq classes d’utilisation et d’y associer systématiquement un assistant logiciel. Après avoir validé cette approche globale d’assistance (Ospina et al., 2005), nous nous sommes concentrés sur les aspects exclusivement coopératifs de l’usage d’iPédagogique pour proposer le concept de système de médiation ; ce que nous développerons dans le chapitre suivant (cf. § 6.2)
Coopération dans les systèmes d’aide
Système d’exploitation Serveur Apache + Base de donnée
Environnement Pédagogique
Interface Homme Machine Système de Multi-Assistance
BD AgentBD AgentIHM Utilisateur Assistant gestion UV Assistant tutoriel Assistant GP Assistant utilisateur Assistant formulaire
Figure 23. a) Architecture d’iPédagogique avec visualisation des agents d’interfaces ; b) les
onglets "Projet" pour les étudiants et "Administration" pour l'enseignant responsable.