L'enseignement d'unités de valeurs scientifiques ou techniques est essentiellement fondé sur l'acquisition de connaissances conceptuelles et la validation d'un savoir-faire. Au cours d'une formation, l'apprenant et l'enseignant doivent coopérer pour surmonter des difficultés organisationnelles et pour introduire (enseignants) ou pour acquérir (étudiants) des compétences implicites aux activités pédagogiques, telle que la gestion de projets. L’instrumentation de ces activités coopératives conduit à concevoir des systèmes d’information complexes (coopératifs, interactifs et distribués) communément qualifiés d’environnements interactifs d’apprentissage humain (EIAH).

Du fait de leur complexité, les EIAH doivent comporter un minimum d’assistance. L’identification des différents niveaux d’assistance peut conduire à concevoir un véritable système de médiation dans lequel la communication homme-machine jouera un rôle majeur. Un tel système sert d’intermédiaire de coopération entre les utilisateurs et le système et réciproquement. En effet, le système ne peut réaliser les tâches qui lui sont affectées, sans la coopération des utilisateurs. Les processus dynamiques, coopératifs et autonomes, nécessaires à cette interaction, doivent alors intégrer une représentation des connaissances et des comportements de l’utilisateur, et posséder une réelle capacité à communiquer. L’approche à base d’agents logiciels apporte une réponse à cette problématique (Ferber, 1997).

Nous rapportons dans cet article l'intégration expérimentale réussie d'une pédagogie par projets assistée par l’environnement iPédagogique, mise en œuvre ces cinq dernières années au département de Génie Informatique de l’Université de Technologie de Belfort-Montbéliard. Cet environnement, rentrant dans la classe des systèmes complexes distribués et coopératifs, justifiait la conception d'un système d'aide multi-usages et multiutilisateurs. L'objectif principal de ce système est de faciliter l'utilisation et la gestion de l’environnement pédagogique en proposant un ensemble "intelligent" d'aides et de conseils pour tous les utilisateurs : étudiants, enseignants, administrateurs. Ce système modélisé puis réalisé selon une approche agents est constitué de 5 agents d'assistance (gestion d’UV, gestion des projets d’étudiants, assistance aux utilisateurs, gestion des documents/formulaires et utilisation du système) et de deux agents d'interface (communication avec l’IHM et la base de données).

Cet article est structuré comme suit : la section 2 présente deux problématiques induites par l’assistance à la gestion de projets d’étudiants, à savoir la pédagogie de projets et l’assistance dans les environnements d’apprentissage. Dans la section 3 nous décrivons l’environnement iPédagogique développé de façon expérimentale. Nous présentons dans un premier temps les objectifs que nous nous sommes fixés, l’architecture générale de l’outil pédagogique, puis son interface. Les 2 sections suivantes proposent la mise en œuvre d’une assistance à la gestion de projets d’étudiants. Nous détaillons la méthodologie de développement de projets informatiques que nous avons retenue et l’expérimentation de l’assistance aux étudiants sur les projets d’une unité de valeur d’informatique. Finalement, dans la section 6, après avoir évoqué les éléments de conclusion sur notre approche, nous proposons les perspectives méthodologiques et pédagogiques qui s’en dégagent.

Traditionnellement, le projet est une activité qui s’inscrit dans le processus d’apprentissage et de validation d’unités de valeur techniques (UV). Cette activité met en œuvre des compétences d’analyse, de spécification, de conception ou de développement logiciel par exemple. Ainsi, le projet comme support d’apprentissage est quasi-systématiquement adopté par le corps enseignant dans sa démarche pédagogique (Berger et Rieben, 2000). Dans les processus d’apprentissage et d’évaluation de l’étudiant, il peut représenter une quote-part variant entre le quart et la moitié du temps consacré à l’UV et à l’évaluation finale. Cependant cette activité n’est pas ou prou supportée par les systèmes pédagogiques STIC (Ramel et Prevot, 2000). Il y a de nombreuses raisons à cela. Notons la complexité de cette activité qui met en jeu de nombreux acteurs : l’administrateur, les enseignants experts et suiveurs, les apprenants, sans oublier l’outil support pédagogique. Ces différents acteurs interagissent entre eux et de manières multiples. Ils s’adaptent continuellement, coopèrent, communiquent et négocient. Les projets d’UV, si on considère leurs 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 de nombreux procédés pédagogiques d’initialisation, de gestion, de suivi et d’évaluation (Synteta et Schneider, 2002). Ces procédés sont complexes. En plus d’être grandement interactifs et multi-partenaires, ils mettent en jeu de très nombreuses données et relations entre ces données, et ils 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. 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…). Les méthodes et outils procéduraux actuels ne permettent pas d’appréhender une telle complexité et de telles évolutions (Godard, Bignon et al., 2001).

Les EIAH peuvent être étudiés de deux points de vue : pour l’assistance humaine (pédagogie, ergonomie et psychologie) et pour l’assistance système (ingénierie éducative). La volonté de simplifier l’utilisation de certains systèmes d’information complexes a permis de réaliser des prototypes de systèmes d’aide qui comportent une représentation des connaissances et qui mettent en œuvre des capacités d’intervention, de dialogue et d’explication (Beaufils, Blondel et al., 1998).

Les principaux travaux sur l’assistance dans les EIAH portent sur les systèmes conseillers, le suivi synchrone d’activités d’apprentissage, la délivrance d’informations, l’aide à l’utilisation. Cependant la terminologie associée à l’aide reste assez imprécise. Elle contient les notions d’assistance, de guidage, de conseil et d’explication. Le terme d’aide se rapporte généralement à l’aide en ligne disponible dans les logiciels, souvent assimilée à un mode d’emploi. L’assistance à l’utilisateur comporte une prise en charge partielle de la tâche. Elle est souvent mise en œuvre par des agents logiciels qui effectuent une partie de la tâche ou guident fortement l’utilisateur. Le guidage consiste à accompagner l’utilisateur dans l’accomplissement de la tâche. Le conseil est analogue au guidage mais produit davantage des informations d’ordre méthodologique. Enfin, l’explication a pour fonction de détailler et d’expliciter le fonctionnement ou le résultat d’une action ou d’un raisonnement.

Pour l’identification des conseils délivrables par un système d'assistance à la gestion de projets d'étudiants, nous nous sommes référés à (Paquette et Tchounikine, 2002) qui proposent de différencier les conseils essentiellement liés à la démarche préconisée ou aux produits élaborés :

• des conseils «démarche», répartis en 3 classes, les conseils positifs qui aident l’utilisateur dans le choix des actions à réaliser, les avertissements qui avertissent l’utilisateur des implications de ses choix et les conseils négatifs qui signalent à l’utilisateur s’il risque de contrevenir à une règle ;

• des conseils «cohérence», délivrés sur identification de valeurs ou d’enchaînements incohérents ;

• des conseils «qualité», faisant essentiellement intervenir les notions d’état, d’importance et éventuellement de statut, connaissances prédéfinies dans une typologie de conseils à formuler.

Le lecteur intéressé par la description d’EIAH récents, proposant eux aussi des niveaux d’assistance, pourra notamment se référer aux systèmes suivants : les plate-formes agents d’apprentissage à distance BAGHERA (Pesty, Webber et al., 2001), SIGFAD (Mbala, Reffay et al., 2003) et SMART-Project (Bousmah, Elkamoun et al., 2005), ainsi que les environnements ESSAIM (suivi pédagogique synchrone pour activités d’apprentissage à distance) (Despres, 2001) et SPLASH (environnement support à une pédagogie de projet) (George et Leroux, 2001).

Nos principales motivations sont d’améliorer l’efficacité de l’enseignement traditionnel sous un angle multi-utilisateurs (apprenants, enseignants auteurs et intervenants). Nous nous sommes intéressés à la nature des supports, de la communication et de l’organisation, ce qui nous a amenés à considérer :

• la richesse des interactions : communication, négociation, coopération, l’accès aux ressources ;

• les contraintes spatiales et temporelles de la nouvelle offre et des nouveaux besoins en formation ;

• la mutualisation des ressources (enseignants, logiciels, locaux, administration, etc.) ;

• l’(auto-)évaluation du savoir-faire et des connaissances ;

• la pédagogie orientée projet (validation des compétences par des projets collectifs ou personnels).

Notre démarche expérimentale de conception de l’environnement ipédagogique facilite l’intégration de nouveaux services au moyen de solutions technologiques appropriées. Cette démarche se déroule en phases itérant les étapes suivantes : élicitation des besoins en formation, conception et mise en œuvre de solutions, retour d’expérience d'utilisation facilitée par la participation positive des étudiants.

iPédagogique est une plate-forme auteur pour l’enseignement en présentiel et à distance d’unités de valeurs scientifiques et techniques dont la pédagogie est orientée projet. Le premier objectif de cette plate-forme est d’améliorer la relation pédagogique enseignant/apprenant et d’accroître l’autonomie des étudiants en leur permettant d’être acteurs de leur formation. Cela concerne le support pédagogique des UV et les supports électroniques (cours, TD et TP) utilisables lors des séances en présentiel et disponibles en permanence (auto-apprentissage) (Fougères et Canalda, 2002). Le second objectif de cette plate-forme est d’offrir une assistance aux étudiants (Ospina et Fougères, 2003), centrée sur deux activités : la réalisation des TP interactifs et la gestion des projets tutorés (Canalda, Chatonnay et al., 2002). La plate-forme offre également un support organisationnel à l’enseignant responsable d’une UV. Elle permet aussi la diffusion d'informations pédagogiques et administratives.

Cette plate-forme nous l’avons voulue ouverte, c’est-à-dire extensible dans les schémas pédagogiques à mettre en œuvre, adaptable à différents types de matières, et configurable par un utilisateur néophyte. La mise en œuvre fait appel à des outils logiciels et matériels très répandus (MySql, Apache, PHP5, HTML/XML/XSLT et javascript) qui facilitent intégration ou interopérabilité.

Le contexte d’utilisation d’iPédagogique se répartit suivant quatre missions : enseigner, apprendre, réaliser et interagir. La figure suivante (Figure 1) présente les différents rôles que les utilisateurs peuvent remplir et les fonctionnalités qui leur sont proposées. Les cas d’utilisation considérés dans la suite de l’article sont ceux invoqués par les acteurs « Membre projet », « Tuteur » et « Assistant GP ».

Le contexte interactionnel – pris dans le sens du paradigme actionnel (Vernant, 2005) – entre les différents acteurs (humains et artificiels) agissant collectivement avec iPédagogique, est très diversifié. Il va de la communication à la coopération en passant par la collaboration et la négociation (Tableau 1) et se décline selon deux points de vue, celui des types d’interaction et celui des acteurs de la formation.

Toute la démarche méthodologique de modélisation a été menée en tenant compte d’un public varié d'enseignants (matières enseignées) et d'apprenants (élèves-ingénieurs, étudiants d’IUT et d’IUP). Cela a abouti à l’élicitation des fonctionnalités qui apparaissent, pour la plupart, dans les intitulés d'activités de la Figure 2. Ces deux captures d’écran illustrent notre propos en présentant respectivement : a) la gestion de projet vue du point de vue de l'étudiant, et b) l'administration des projets.

Nous abordons dans cette partie la dimension coopérative de certaines activités et le travail de modélisation qui permet d’identifier les outils logiciels susceptibles d’apporter une assistance pour la réalisation de tâches coopératives. La théorie de l’activité nous offre ce cadre de modélisation, notamment dans le contexte des EIAH (Bourguin, 2000). Les caractéristiques suivantes des EIAH justifient la démarche de développement orienté activité que nous avons adoptée :

• Les EIAH sont des systèmes complexes, multi-usages et multi-utilisateurs. Leur caractère distribué et/ou coopératif, ainsi que leur appropriation difficile justifient la modélisation puis l'instrumentation des activités supportées afin d'assurer la pertinence des solutions proposées.

• Les EIAH sont des collecticiels. L’activité de projets d’étudiants en est une illustration : coopération entre les étudiants d'un groupe de projet, entre les étudiants et les enseignants, entre l’équipe enseignante, entre les acteurs du moment et les futurs (mémorisation d’activité).

Nous nous intéressons dans la suite aux activités qui sont associées à une pédagogie par projets, et qui sont instrumentables dans un EIAH : gestion, suivi, réalisation et évaluation. Le concept de projet et les processus associés sont des notions très abstraites, aussi ne considérerons- nous ici que la conception de projets logiciels. Nous ne doutons pas cependant de l’extension de notre démarche à d’autres domaines techniques inscrits dans un processus de conception plus général (Matta, Ribière et al., 1999) :

Un projet logiciel est une démarche spécifique qui permet de structurer méthodiquement un système logiciel à venir (la DSI du CNRS a mis en ligne une information très éclairante sur le sujet https://www.dsi.cnrs.fr/conduite-projet/). Il est défini et mis en œuvre pour élaborer une réponse à des besoins spécifiques. Il implique un objectif et des actions à entreprendre avec des ressources données. Un projet est constitué de tâches caractérisées par un début et une fin, consommatrices de ressources et reliées entre elles par une relation d’antériorité. Ces définitions sont à la base du modèle de la figure 3.

La réalisation d'un projet logiciel peut se décomposer en plusieurs activités coopératives (spécification, conception, développement, tests et validation), sujettes à de nombreuses itérations (nouveaux besoins ou spécifications, revues, corrections, améliorations, tests, intégrations, planning,…).

La gestion de projet comporte deux fonctions : la direction de projet et la gestion de projet proprement dite. La première fonction, qui s’intéresse à des décisions stratégiques ou tactiques, n’est pas celle qui est principalement évaluée dans nos formations, même si l’on peut insister pour que les étudiants à l’intérieur d’un groupe alternent les rôles de responsabilité. La seconde, par contre, traite de décisions opérationnelles, plus facilement évaluables et justifiables aux grés des différentes réalisations. En effet, les étudiants y déploient et peuvent y rapporter des activités variées telles que : structuration des tâches à mener, estimation des quantités/qualités de ressources nécessaires, organisation, planification, ordonnancement, suivi de l’avancement réel du projet par rapport aux prévisions.

Un modèle objet du développement de projets logiciels a été conçu pour faciliter la coopération entre enseignants et étudiants dans le suivi et la gestion des projets, puis pour guider la conception d’un système de médiation pour cette activité (Fougères et Ospina, 2004). Le modèle de tâches permet de concevoir les diagrammes d’activité associés à chacune des phases de la GPE (Figure 4.a). A titre d’illustration, le Tableau 2 décrit la phase d’analyse des besoins pour un projet, conduisant à la rédaction du cahier des charges et à sa validation par l’enseignant tuteur du groupe d’étudiants.

Pour la structuration et l’évaluation des projets d’étudiants nous proposons un processus de suivi de projets. En effet, les différents acteurs d’un projet interagissent de multiple manière : ils se coordonnent, coopèrent, communiquent et négocient. En plus d’être interactifs et multi-partenaires, les procédés pédagogiques déployés dans la GPE comportent de nombreuses données et relations, et sont évolutifs. Le processus de SPE (Figure 4.b) doit permettre :

• aux enseignants tuteurs, d’aider les étudiants dans leur démarche, d’apprécier la complexité des projets proposés et d’évaluer plus finement le travail réalisé ;

• aux étudiants, de mesurer l’état de leur projet et le comparer aux prévisions, d’élaborer des actions correctrices, de structurer la conception et de produire une synthèse.

L'objectif d’un système de médiation est de faciliter l'utilisation d’un système complexe (distribué ou coopératif par exemple), en apportant une aide aux utilisateurs individuels ou aux groupes dans la résolution de leurs problèmes et en prenant en charge certaines fonctionnalités de l’application. La signification du terme de médiation correspond à la notion d’intermédiaire de coopération bilatérale entre au moins deux types d’acteurs : des utilisateurs et un système. Il apparaît donc que la médiation est un processus flexible qui s'applique à toutes sortes de situations de coopération (Giraldo et Reynaud, 2002). Dans l’absolu, un utilisateur disposant d’un système de médiation peut se dispenser d’appréhender la complexité d’un système ou d’une application. Le processus de médiation établit donc un lien entre les acteurs qui doivent agir ensemble pour atteindre un consensus sur une activité commune, en assumant notamment les tâches suivantes :

• faciliter la communication et la coopération entre une application et ses utilisateurs ;

• assister l’usage d’une application (interactions homme/machine), partagée ou non ;

• faciliter la découverte des fonctionnalités offertes par l’application.

Les systèmes de médiation sont des systèmes indépendants qui servent d’interface entre l’homme et l’application afin d’enrichir leur relation. Dans notre démarche de conception de tels systèmes nous avons retenu 3 hypothèses (Ospina et Fougères, 2003) :

• Hypothèse 1 : l’assistance adaptée à l’utilisation d’un système complexe correspond en fait à une multi-assistance. Il nous faut nous assurer qu’il existe une assistance pour tous les types d’utilisateurs dans un contexte multi-usages. Ceci nous a conduit à concevoir un système de médiation composé d’assistants pour chaque type d’utilisation : emploi de l’outil, appropriation des connaissances, administrations, développement de tâches, etc.

• Hypothèse 2 : le système de médiation doit être indépendant de la partie applicative de l’outil et de son interface. L’hypothèse précédente conduit à réaliser un système distribué capable de spécialiser l’assistance selon les usages. Cette seconde hypothèse, principalement méthodologique, apporte des qualités de modularité, de réutilisabilité et de généricité à notre système.

• Hypothèse 3 : le système de médiation se construit de façon adéquate sous la forme d’un système à base d'agents. La solution d’assistance proposée est rendue opérationnelle par un système autonome, composé d’assistants attachés à des tâches spécifiques d’aide aux utilisateurs. Notre hypothèse consiste alors à spécialiser chaque agent en fonction des cas d’utilisation identifiés, afin de fournir les aides ou les conseils aux utilisateurs avec le maximum de pertinence.

Les environnements de travail coopératifs sont constitués de composants distribués, hétérogènes et autonomes. Les systèmes développés en intelligence artificielle distribuée, notamment les systèmes à base d’agents, sont donc bien adaptés. En effet, le principal intérêt de ces systèmes réside dans la distribution des agents logiciels, entités communicantes, autonomes, réactives et compétentes (Ferber, 1997), susceptibles de réaliser des tâches ou de résoudre des problèmes collectivement. Pour concevoir un système à base d’agents selon nos critères d’assistance, chaque agent doit posséder trois propriétés : autonomie, communication et « intelligence » (expertise, savoirs-faire). L’approche formelle que nous suivons consiste à définir une architecture modulaire pour ce type d’agents, à définir leur modèle de communication et à adopter une méthodologie rigoureuse d’acquisition de leur expertise (Fougères, 2003). L’apport potentiel des agents concerne :

• la prise en charge d’actions répétitives (i.e. la délégation de tâches sans intérêt pour l’utilisateur),

• la prise de décision par compréhension du contexte d’utilisation (la pertinence de l’intervention),

• la personnalisation de l’information (les préférences, les buts et les capacités de l’utilisateur),

• une interactivité plus naturelle (les modalités et la présentation des informations à l’utilisateur),

• l’adéquation aux systèmes distribués et coopératifs (les interactions distribuées et personnalisées).

Les comportements individuels et coopératifs des agents sont variés : initialisation, planification des actions, émission et réception de messages, recherche de documents ou d’information, supervision de procédures. Chacun de ces services correspond à la mise en œuvre de compétences d’un agent.

La communication est le principal mécanisme de coopération entre agents. Pour s’échanger des informations, se demander des services ou dialoguer, nos agents expriment leurs intentions selon un langage proche de KQML, dérivé de la théorie des actes de langage (Finin, Fritzson et al, 1994). Le format retenu est défini par le quintuplet <intention, émetteur, récepteur, langage, message>. Il permet de représenter le contexte, l’intention et le message de la communication. A titre d’illustration voici un échange type entre un utilisateur, un agentIHM et un assistantGP (assistant de gestion de projet), suite à une demande de conseil lors de la phase n de développement d’un projet :

Nous avons présenté la gestion de projets d’étudiants et leurs suivis comme des activités complexes, coopératives et peu instrumentées. Après avoir conçu un environnement pédagogique offrant ces fonctionnalités, c’est tout naturellement que nous nous sommes interrogés sur le juste niveau d’assistance à proposer à un tel environnement afin d’en faciliter l’utilisation. L’environnement s’est alors révélé un terrain d’expérimentation idéal pour la conception d’un système de médiation.

L'objectif général du système de médiation est de faciliter l'utilisation et la gestion de cet environnement pédagogique complexe en proposant un ensemble ergonomique et intelligent d'aides et de conseils à tous les utilisateurs, familiarisés ou non à ce type d’environnement. La figure 5 présente l'architecture de ce système, constitué de 5 agents (assistants logiciels) :

• Un assistant de gestion d’UV qui gère l'information d'une UV et assiste l'enseignant responsable dans ses tâches de gestion de planning, de Cours/TD/TP, d'étudiants, d'intervenants, d'informations.

• Un assistant pour la gestion des projets étudiants. En cours de semestre, le site pédagogique simplifie la gestion des projets par l’enseignant responsable en l’assistant dans les tâches de diffusion des sujets des projets, d’inscriptions à ces projets, de suivi des plannings et des groupes de projets, de répartition des rôles à l’intérieur des groupes, de prises de rendez-vous, de rappel des contraintes de phases, etc. La figure 6 fournit une illustration de son activité (communication et intervention).

Remarque : le nombre de 5 agents n’est pas arrêté ; il correspond seulement à notre stade expérimental. L’étude des services rendus par l’environnement (Figure 1), nous a permis d’identifier 5 classes d’utilisation, et d’y associer systématiquement un assistant logiciel (Figure 5). Nous avons par ailleurs présenté le processus d'agentification du système de médiation dans (Ospina et Fougères, 2003).

Les connaissances nécessaires à la médiation des projets d’étudiants sont de deux natures : des connaissances initiales portant sur le domaine (projets d’étudiants) et des connaissances acquises au travers des activités assistées par iPédagogique, principalement les mémoires d’activité et de résolution de problèmes. Leur modélisation respecte une démarche de gestion des connaissances (Zacklad, 2000), à savoir : capitalisation du patrimoine de connaissance existant (connaissances tacites en GPE), partage des connaissances destinées aux différents groupes de projets et création de nouvelles connaissances, issues de la réalisation des projets et des résolutions de problèmes (Ospina, Fougères et al., 2005).

Pour assister les premières utilisations, le système de médiation doit se référer à des connaissances stables et expertes, issues d’une conceptualisation du contexte d’activité de réalisation de projets d’étudiants : les connaissances du domaine de la gestion de projets d’étudiants et la base de conseils, couvrant la réalisation de l’ensemble des phases d’un projet.

• Modèle du domaine. Il comprend les connaissances de définition de projets d’étudiants et les connaissances associées aux activités de gestion, suivi et évaluation. Les informations sur l’organisation concernent les connaissances des utilisateurs et leurs rôles dans les activités coopératives. Elles peuvent évoluer, puisque selon le contexte d’utilisation le système est en mesure de compléter les profils utilisateur. Cette modélisation dynamique spécifique fait encore partie de nos perspectives. Nous espérons qu’à terme le système sera capable de faire des suggestions personnalisées et adaptées pendant le déroulement du projet.

• Modèle des conseils. Nous traitons ici des connaissances requises pour deux types d’assistance : le conseil et l’explication. Le conseil produit des informations d’ordre méthodologique. L’explication a pour fonction de détailler et d’expliciter le fonctionnement ou le résultat d’une action ou d’un raisonnement. La diffusion des conseils est administrée dans notre système par un ensemble d’agents (Figure 7). Les structures de conseil, traduites en XML, comportent les informations suivantes : identification, description, type et emplacement.

Les connaissances initiales sont élaborées à partir d’extrapolations et se développent par l’invocation du système de médiation. Pour accroître ce niveau de connaissances en transposant la notion d’expérience, nous construisons une mémoire d’activité.

• Mémoire d’activité. Les tâches réalisées sur un système coopératif produisent des connaissances qui peuvent être mémorisées, puis remémorées pour assister de futurs utilisateurs. Un de nos apports au modèle de mémoire de projets de (Matta, Ribière et al., 1999), est l’introduction d’une base de cas, regroupant les connaissances de projets. Un projet est représenté sous forme de cas (Aamodt et Plaza, 1994), formalisation d’une fiche de synthèse de projet (Figure 8.a). Cette fiche conserve la trace du déroulement global du projet et fait référence à un ensemble de situations de résolution de problèmes (expérience) dont la connaissance pourra être utile à de futurs étudiants. La fiche est remplie de façon coopérative (interaction entre étudiants, tuteurs et agents du système de médiation).

• Mémoire de Résolution de problèmes. Le deuxième niveau de mémorisation de notre système concerne les connaissances acquises pendant les situations de résolution de problèmes. Le processus de résolution de problèmes retenu correspond au schème suivant : description du problème, analyse du problème, choix d’une solution, réalisation de la solution, évaluation de la solution. Les étudiants ayant effectué une tâche de résolution de problèmes ont la possibilité de la consigner dans une fiche (Figure 8.b). L’élaboration de cette fiche est, elle aussi, coopérative. Pour s’assurer de ne conserver que des fiches ayant une relative pertinence pédagogique, un processus de filtrage est prévu pendant la phase d’évaluation de l’enseignant tuteur. Celui-ci coopère au processus de mémorisation, en assurant le rôle de garant de la représentativité du problème identifié et résolu.

Les mémoires d’activité et de résolution de problèmes sont complétées et détaillées par coopération des acteurs avec le système pendant le déroulement des projets. La sauvegarde de ces connaissances dans la base de cas est gérée par le système de médiation. Certaines connaissances initiales, telles que les profils utilisateur, restent contextuelles. Elles ne sont donc conservées que sur la durée du projet.

La figure 9 présente le schéma général de mémorisation des connaissances sous forme de cas dans notre système de médiation. Il est divisé en deux processus :

• la mémorisation d’activité (Figure 8.a), conduisant à l’élaboration d’une fiche de synthèse, et qui est guidée par une modélisation des activités (gestion, suivi et évaluation) ;

• la mémorisation des actes de résolution de problèmes, reflétant la prise d’autonomie des étudiants dans la rédaction de compte-rendu de résolution de problèmes (Figure 8.b) ; ce processus coopératif comporte un filtre assuré par le tuteur, responsable pédagogique.

La base de cas ainsi enrichie augmente la capacité du système de médiation en terme d’assistance aux futurs étudiants. Dans la figure suivante, les BD blanchies enregistrent les informations temporaires, par opposition aux BD grisées qui constituent la mémoire long terme du système de médiation.

Nous venons de rendre compte d’une expérience de mise en place d’un support pédagogique pour un groupement d’Unités de Valeurs d’un département de Génie Informatique destinées à des étudiants de 1^ère année. La vocation principale de cet outil est d’améliorer la relation pédagogique enseignant/enseigné et d’accroître l’autonomie des étudiants en leur permettant d’être acteurs de leur formation. Un second objectif pour l’outil est d'offrir une véritable assistance à la gestion de projets d’étudiants sur une plate-forme d’apprentissage, dont la pédagogie est orientée projet (offrant une sensibilisation implicite des étudiants à la gestion de projet). Il s’agit pour les étudiants de bénéficier d’un accompagnement de développement de projets et de suivi de planning, leur permettant d’ordonnancer dynamiquement les différentes phases du projet, allant du choix d’un sujet à l’élaboration par un travail collaboratif. Les contraintes d’utilisation sont fortes : grand nombre d’étudiants, grand nombre de projets, diversité des contenus pédagogiques, une organisation sur deux sites géographiques.

Toute notre démarche a été mise en œuvre au sein de la formation d’ingénieurs de l’UTBM, notamment dans l’apprentissage d’UV comme celles traitant des concepts des systèmes d’exploitation centralisée, des architectures logicielles client/serveur et des systèmes à base de connaissances. Nous avons ainsi modélisé un procédé coopératif d’aide à la gestion de projets tutorés que nous avons intégré à iPédagogique. Nous avons expérimenté une solution web ouverte (pages html, formulaires, fonctions javascript et base de données) qui intègre des outils d’aide à la planification et des outils de communication (e-mail, forum). Nous bénéficions d’un retour d’expérience (entre 2001 et 2005) qui plébiscite l’usage des nouvelles technologies et de ces nouveaux procédés pédagogiques, tant du point de vue des apprenants que celui des enseignants (+ de 500 utilisateurs). L’expérimentation se poursuit aujourd’hui sur d’autres UV (Systèmes d’Information, Multimédia, Algorithmique et Programmation Orientée Objet), en intégrant d’autres dimensions comme celle de la conscience de groupe. Notre modèle pédagogique, qui se dessine, prend les contours d’une formation “nomade” avec toute la flexibilité que cela comporte : une formation à la carte, une plate-forme configurable.

Dans cet article, nous avons plus particulièrement présenté la définition et la conception d’un système de médiation pour un environnement pédagogique qui allie complexité (distribution des niveaux d’assistance en fonction des usages) et clarté de présentation puisque l’assistance est conçue comme un véritable système, connecté à la couche applicative de l’environnement et à l’IHM. Nous tenons à insister sur le fait que l’objectif d’une médiation n’est pas de se substituer aux utilisateurs, mais bien de les aider à évoluer et à coopérer dans leurs différentes tâches. La gestion de projets d’étudiants proposée par l’outil iPédagogique a été expérimentée pendant 5 ans. Après le plébiscite accordée par les différents utilisateurs (étudiants, enseignants, administrateur) et l’observation de leurs modes d’utilisation, c’est le développement d’une véritable assistance qui s’est imposée. Plutôt que de travailler sur la seule perspective d’une assistance à la gestion de projets, une réflexion plus générale, centrée sur l’ensemble des cas d’utilisation identifiés lors de la modélisation de la première version de l’outil, a guidé la conception du système de médiation.

La réalisation de l'assistance dans iPédagogique concerne actuellement la gestion des projets d’étudiants (objectif du prototype développé), mais notre souci de généricité rend le modèle utilisable pour l’ensemble de l’assistance, comme nous l'avons présenté dans la section 5.3. Au-delà des résultats attendus pour cette phase du projet, les perspectives de ce travail rentrent dans l’élaboration d’une méthodologie de conception de système de médiation adapté aux systèmes coopératifs. Ceci s’étend autant à la définition d’une architecture de médiation, à la résolution des problèmes de communication et de coopération entre les composants de cette architecture et à l’acquisition des connaissances nécessaires à la mise en œuvre efficace et pertinente de l’assistance dans le domaine cible.