patron de scénario pédagogique pour Prodagéo

A la suite des conclusions tirées du projet réalisé entre les étudiants de BTS IRIS et de l’IUT Info-Com (1, 2), je me suis mis en tête de refondre la grille du scénario. L’idée qui m’animait était que le scénario d’origine était trop centré sur l’outil BLOG par rapport au fonctionnement général du projet : un outil doit répondre à un besoin et non pas limiter un fonctionnement. Il fallait donc mettre en place un document qui permette de synthétiser tous les aspects du projet pour pouvoir, in fine, répondre à 2 questions :

  • Comment évaluer le travail des étudiants au cours du projet ?
  • Quels outils sont nécessaires pour le bon déroulement du projet ?

Le document se découpe en 7 parties :

    1. présentation générale du projet,
    2. les acteurs,
    3. l’approche pédagogique,
    4. le déroulement du projet,
    5. le suivi par les enseignants,
    6. l’évaluation,
    7. l’instrumentation.

      Les points 2, 3 et 4 correspondent au scénario d’apprentissage tandis que les points 5 et 6 correspondent au scénario d’encadrement.

      Cette grille servira de base pour les prochains projets réalisés lors de l’année 2009-2010. N’hésitez pas à la parcourir, l’utiliser et la critiquer : elle est là pour ça …

      Accéder à la grille du scénario pédagogique.

      Instrumentation d’un projet

      Voici une carte qui positionne un ensemble de fonctionnalités qui peuvent être nécessaires pour un projet de type Prodageo. L’utilisation de cette carte doit se faire en 2 temps : il faut d’abord définir le besoin puis choisir la (ou les) fonctionnalité(s) la (les) plus adaptée(s) pour y répondre.

      Les trois domaines répertoriés où il faut envisager une instrumentation sont :

      • la communication (dans un sens très large),
      • la gestion de projet (planification, suivi, …),
      • le domaine d’activité avec ses outils métiers spécifiques.
      carte de définition des besoins et des outils pour Prodagéo

      carte de définition des besoins et des outils pour Prodagéo

      Afin de séparer les multiples outils de communication existant, ce domaine a été divisé en 3 : communication synchrone, communication asynchrone et communication latente, cette dernière étant une mise à disposition de données.

      Afin de ne pas surcharger cette carte, un petit logo (rss ou enveloppe) indique le mode de suivi des outils qui le nécessitent : soit par fil RSS, soit par mail.

      L’objectif à terme est de proposer une liste de solutions logicielles pour chaque fonctionnalité recensée, en se limitant aux solutions faciles à mettre en oeuvre (hébergées ou très grand public).

      N’hésitez pas à approter votre point de vue sur cette classification …

      Synthèse de la veille collaborative (suite)

      Nous venons de nous rencontrer entre enseignants des 2 formations concernés (BTS IRIS et IUT GIDO) et avons essayé de faire un bilan de ce projet. Tout d’abord le résultat global est plutôt positif :

      • C’est un exercice original et motivant,
      • Il permet de mettre en pratique des méthodes et outils vus au cours de la formation,
      • Lorsque la collaboration se passe bien, les résultats sont riches.

      Les critiques portent essentiellement sur l’organisation qui n’était pas assez précise (répartition des tâches, résultat attendu, outils mal adaptés, difficulté à respecter les délais). Ces différents points étaient ressortis de l’enquête auprès des étudiants dont les résultats sont présentés ici.
      Et maintenant, qu’est-ce qu’on fait ?
      Nous étions tous d’accord pour dire qu’il était intéressant de reconduire un projet analogue l’année prochaine en corrigeant quelques imperfections :

      • Bien définir l’objectif du projet et le résultat attendu de la collaboration. Ce résultat doit être limité à un artefact qui n’est pas forcément un rapport papier. C’est à partir de ce choix que vont découler les autres ajustements.
      • Une fois l’objectif final défini, on peut identifier comment les étudiants de chaque formation peuvent concourir pour l’atteindre. Cela nous permettra de définir les rôles et responsabilités des différents étudiants.
      • A partir de ces clarifications, nous pourrons repérer les modes de communication les plus adaptés entre les étudiants et en déduire les outils mettre en œuvre. Il est apparu un manque de communication synchrone entre les étudiants lors de ce projet, il faudra sûrement en tenir compte pour la prochaine occurrence et prévoir sans doute une rencontre en présentiel supplémentaire au cours du projet.
      • Nous n’aurons plus alors qu’à définir un planning complet et précis du déroulement du projet (qui sera transmis aux étudiants) et définir les critères d’évaluation pour chaque formation. Il apparaît que la note reste toujours une carotte efficace pour motiver les étudiants et les inciter à s’impliquer dans une activité.

      Sachant que le projet se déroulera l’année prochaine à la même période (fevrier-mars), il nous reste une dizaine de mois pour mettre au point une nouvelle version du scénario. L’objectif actuellement est de mettre au point une grille pour définir le scénario à partir de la grille actuelle et des conclusions tirées de l’expérience.

      Synthèse de la veille collaborative

      Eh oui! …La veille collaborative est fini … Pendant 2 mois les étudiants du BTS IRIS et de l’IUT Info-Com de DIJON ont dû travailler ensemble pour construire des dossiers sur des thèmes de l’informatique professionnelle. A la suite de ce travail collaboratif, un questionnaire a été envoyé à chacun pour évaluer cette activité. Voici les premiers résultats. D’emblée, on constate que les étudiants ont bien adhéré au principe d’un travail collaboratif et qu’ils ont été satisfaits de la durée et de la définition du cahier des charges. La satisfaction est beaucoup plus mitigée par rapport à l’instrumentation proposée (wiki et blog) et la fréquence des rencontres entre les étudiants des 2 formations. La grande majorité n’est pas satisfaite de la collaboration qui s’est établie …

      A la lumière de ces résultats et à la suite d’un débriefing avec les étudiants IRIS, il est ressorti ce qui suit :

      • Il faudrait prévoir une rencontre toutes les 2 ou 3 semaines entre les deux formations à conditions que chacun avance dans son travail respectif. Cette réunion peut se faire en face à face ou à travers des outils standards : clavardage, audioconférence, visioconférence, …
      • Il faut plus définir les rôles et responsabilités de chacun : les ‘veilleurs’ cherchent des documents, les lisent et piochent les passages intéressants tandis que les ’spécialistes métier’ construisent tout au long du projet une synthèse (sous forme de carte par exemple). Cette synthèse sert de base pour chaque rencontre inter-formation.
      • L’utilisation conjointe du blog et du wiki n’a pas été jugée judicieuse : il était difficile de savoir quel outil utiliser quand. Il paraît judicieux d’utiliser un outil de partage de signet (Diigo semble tout à fait approprié avec la possibilité de surligner des passages) plutôt qu’un blog pour partager les ressources repérées.
      • Certains étudiants ont fait ressortir le manque de planification du projet : pour une prochaine fois, on peut envisager un scénario agile qui se déroulerait comme suit :
        • une rencontre de présentation
        • une phase de recherche de vocabulaire métier de base avec définition (on peut envisager une construction collaborative d’un lexique)
        • puis une alternance de rencontres / périodes de veille pour approfondir un des aspects du sujet d’étude.

      Voilà pour une première synthèse à partir des réponses des étudiants à l’enquête d’évaluation du projet. Une rencontre avec les enseignants de l’IUT a eu lieue, et la synthèse est ici

      instrumentation de Prodagéo

      Je me pose pas mal de questions sur l’instrumentation des projets Prodagéo à partir du constat des expériences passées.

      1 – le constat

      Lors du premier projet, les étudiants étaient d’une part à Dijon et d’autre part à Safi au Maroc. Les échanges se sont fait sous forme de clavardage (pour la transmission du cahier des charges) puis par mail pour le suivi du projet. Une plateforme Moodle a été utilisée pour synchroniser les actions des différents intervenants.

      Lors du second projet, le travail s’est articulé autour de blogs et de wikis.

      2 – la critique

      Pour le premier projet, les outils utilisés n’étaient pas liés entre eux, ce qui demande un effort de la part des étudiants alors que l’on pourrait être en droit d’attendre de l’informatique moderne de faciliter le travail et la collaboration. De plus Moodle a été détourné de sa fonctionnalité initiale pour l’adapter à notre besoin (c’est plus simple d’utiliser ce qui existe déjà, quitte à l’adapter, que de mettre en place un nouvel outil).

      L’outil blog, qui a été initialement choisi pour la veille collaborative, ne semble en fait pas adapté. Il est très pratique pour les enseignants pour suivre l’avancée des travaux mais n’est pas ergonomique pour les étudiants utilisateurs (et c’est quand même eux les premiers intéressés…). Il aurait sans doute été plus judicieux d’utiliser :

      - un outil de type forum pour instrumenter la discussion entre les étudiants,
      - un outil de marquage de signets ou un fil RSS pour partager le fruit des recherches.

      3 – les conclusions

      Existe-t-il un outil qui intègre ces différentes fonctionnalités ? OUI !!! Le réseau social ! Et la lecture de cet article de Bertrand Duperrin m’incite à penser que c’est peut-être effectivement la bonne solution… Pour l’instant, j’ai repéré plusieurs acteurs dans le domaine qui semblent répondre à mes attentes et qui sont gratuits : Ning, Grou.ps, BuddyPress et Xwiki. Les deux premiers sont hébergés alors que les derniers sont à héberger (ce qui est un inconvénient à mes yeux : installation, configuration, maintenance, … demandent beaucoup de temps). Les connaisseurs pourront me dire que les LMS (Moodle, Dokéos, Claroline, … et les autres) offrent toutes ces fonctionnalités et qu’en plus, ils respectent le standard SCORM (utile pour indexer, produire, transférer, reprendre un parcours pédagogique). C’est vrai, mais c’est délicat d’ajouter à la plate-forme pédagogique d’un établissement des étudiants extérieurs. De plus, je trouve intéressant que nos étudiants soient confrontés à des environnements autres que pédagogiques (dans l’absolu, j’aimerai bien travailler avec un outil professionnel, par exemple bluekiwi ou Xwiki, que j’ai déjà mentionné ci-dessus, et il y en a sûrement d’autres …).

      Tout cela est encore à approfondir, ce n’est qu’un début de réflexion … Je viens de constater que je ne suis pas le seul à avoir ces velléités puisque Gabriel Flacks présente ici son utilisation pédagogique de Ning…

      Prodagéo : un patron de scénario

      Les expériences de projets pédagogiques géodistribuées présentées dans ce blog offrent des avantages certains pour les étudiants :
      - situation proche de la vie professionnelle,
      - communication à caractère professionnel en utilisant des outils variés,
      - mise en pratique de compétences métier.

      Cela leur permet aussi, dans une analyse réflexive, d’évaluer l’influence du choix d’un outil de communication sur le déroulement du projet. Tous ces aspects me poussent à faciliter la mise en oeuvre de tels projets. Je vous livre donc dans un premier temps le patron du scénario Prodagéo réalisé à partir des 2 expériences présentées dans ce blog. L’objectif de ce patron est de rendre le scénario transférable et exploitable dans des situations variées. Il présente les grandes étapes d’un projet Prodagéo en mettant l’accent sur la chronologie du projet et le positionnement des enseignants à chaque étape.

      patron de scénario pour Prodagéo

      patron de scénario pour Prodagéo

      D’autres documents suivront pour aider à la définition de tels projets…

      Un nouveau projet qui démarre

      Cela fait quelques temps que je vous parle de veille collaborative, de co-construction du savoir, …
      Voici la présentation d’un projet de veille collaborative telle qu’elle a été faite qux étudiants des 2 formations (BTS IRIS et IUT info-com) de Dijon qui se sont réunis il y a quelques jours dans les locaux de l’IUT.
      Ce projet se déroule de mi-janvier à fin mars 2009. Le scénario du projet est disponible ici.

      Un scénario pour la veille collaborative

      Voici une représentation graphique du scénario du projet de veille collaborative entre les étudiants du BTS IRIS du lycée Eiffel et ceux de l’IUT info-Com (2 formations de Dijon).

      scenario_veille_collaborative2

      Voici la liste des différents sujets abordés :

      - les méthodes agiles de gestion de projet
      - les superviseurs
      - les mesures de pression et déplacement
      - la boucle locale
      - la virtualisation
      - les design pattern
      - les capteurs de vision et leur utilisation industrielle

      Dès que les blogs de veille seront en place, les différentes adresses seront diffusées largement …

      Prodageo : première synthèse

      Voilà que notre expérimentation de mini-projet Prodagéo touche déjà à sa fin et pour l’instant, je n’ai pas beaucoup écrit à ce sujet. Je vais donc essayer de me rattraper aujourd’hui en faisant un compte rendu des observations et premières conclusions que nous pouvons faire à la fin de ces quinze jours.

      1 – le transfert du cahier des charges de Safi vers Dijon
      Le transfert d’information en lui-même s’est plutôt bien passé, l’erreur était plus au niveau des étudiants marocains qui n’ont pas bien assimilé le découpage du projet. En effet, il était précisé dans les cahiers des charges que les techniciens faisaient leur mesure et transmettaient le résultat sur la ligne série, tandis que les ingénieurs remplissaient leur base de données à partir d’un fichier texte (cela n’est pas très judicieux mais il faut se débrouiller pour trouver une solution d’interface entre des techniciens qui ne connaissent pas encore les fichiers et des ingénieurs qui n’ont pas entendu parler de la ligne série : nous fournissions un petit exécutable qui lit la ligne série et remplit le ficher texte). Nulle part il n’y a de précision sur ce qui se passe entre les deux et c’est une imprécision du cahier des charges que j’assume. Cependant, il est du rôle du chef de projet de comprendre le fonctionnement global du système et de questionner le client pour éclaircir tous les points obscurs. Je doute fort qu’un chef de projet rencontre une fois dans sa carrière un cahier des charges exhaustif et complet … Les étudiants marocains ont fait un raccourci tranquillisant en disant, tout ce qu’on a pas à faire, c’est aux techniciens de le faire. Il en est ressorti que le résultat du transfert de cahier des charges est un échec.
      Quelles conclusions en tirer ? D’abord chercher à avoir des documents pour les étudiants plus précis et complet (c’est toujours possible), ensuite, inciter les chefs de projet à analyser l’ensemble du projet avec toutes les contraintes et précisant toutes les interfaces (composée de quelques schémas UML par exemple).
      Force est de constater que l’éloignement et l’impossibilité de se rencontrer en face à face ne simplifie pas les échanges mais cela fait partie de l’exercice. C’est une situation qui peut se rencontrer régulièrement dans la vie professionnelle. Il est, me semble-t-il, important de sensibiliser et former les étudiants à la reformulation pour qu’ils puissent s’assurer d’avoir bien compris les consignes ou informations.
      Pour palier le problème de transmission de cahier des charges et ne pas embrigader les étudiants dans une mauvaise piste, nous, enseignants, sommes intervenu pour recadrer le projet en fournissant le ‘vrai’ cahier des charges. nous aurions dû aussi informer les étudiants marocains de ce recadrage afin qu’ils puissent repartir sur les bonnes bases.

      2 – la gestion du temps
      On retrouve en condensé tous les travers des projets que vivent les étudiants en 2ème année :
      - Difficulté à appréhender le problème et à rentrer dans le projet
      - A la fin de la période d’analyse du problème et de découverte des outils et logiciels, les étudiants sont déjà en retard par rapport au planning.
      - Le travail de réalisation (développement, mise en oeuvre du matériel) est intense et correspond à peu près à ce qui est planifié. Mais cela ne suffit pas à rattraper le temps perdu au début.
      C’est une très bonne sensibilisation à la gestion du temps dans un projet et cela servira de base sur laquelle on pourra s’appuyer pour dynamiser les étudiants lors des prochains projets en insistant sur les risques à ne pas respecter les délais intermédiaires.

      3 – le travail en équipe
      Sur un petit projet de quinze jours, il est difficile de découper le travail à réaliser pour responsabiliser chaque étudiant sur une tâche spécifique. Les groupes ont dans l’ensemble fonctionné de manière fusionnelle : “on fait tout tous ensemble”. Cela ne correspond pas au fonctionnement normal d’un projet et c’est une limite de notre exercice. Il est apparu un étudiant qui ne s’est pas intégré dans son groupe et qui s’est donc mis en marge par rapport à l’équipe. C’était un des deux groupes de 4 étudiants : c’est trop ! Il apparaît que pour cet exercice, un groupe ne doit pas contenir plus de 3 étudiants.

      4 – l’utilisation des outils proposés
      pour cette première expérience, on s’était centré sur 3 outils :
      - Moodle pour régler les délais et synchroniser les tâches
      - Subversion pour gérer des versions d’un document
      - TestLink pour rédiger des plans et campagnes de tests
      L’utilisation de Moodle n’a pas posé de problèmes à Dijon puisque les étudiants sont habitués à rendre leur travaux sur un serveur FTP, Les marocains ont eu plus de réticences à l’utiliser.
      TestLink est un logiciel sûrement puissant mais qui n’est pas aisé de prise en main et nécessite un apprentissage. Aucun enseignant disponible à ce moment ne maîtrisait l’outil, il a été abandonné lors du travail préparatoire d’analyse des marocains. Leur plan de tests s’est réduit à un tableau.
      Enfin, je ne sais pas comment Subversion a été utilisé à Safi mais à Dijon, il n’a pas servi ou presque. Les étudiants ne sont pas sensibles au problème de versions et de restauration …
      En conclusion, il faut que les étudiants soient formés aux outils de gestion de projet utilisés avant un mini-projet Prodagéo.

      5 – les tests
      Nos techniciens ne savent pas tester !!! Ils nous font des beaux plans de tests, mais au moment du test, si on prend le temps de le faire, on modifie les paramètres, on adapte, on biaise les tests …
      Un exemple significatif est le test d’émission d’une trame toutes les heures. Les étudiants nous disent : “à quoi ça sert de faire le test pendant la nuit puisqu’on a vu que ça fonctionne quand on demande une émission toutes les 10 minutes ? “. On a bataillé pour que le test se fasse quand même en respectant le protocole défini. Le lendemain matin, oh ! surprise ! au bout de 2 trames, plus rien : les PCs s’étaient mis en veille !!!

      6 – la position des enseignants
      Nous avions prévu que nous serions support technique. Il s’est avéré dès le résultat de la transmission du cahier des charges que nous devions aussi superviser l’avancement du projet et nous donner la liberté de recadrer les étudiants après chaque jalon d’avancement du projet. Il faut alors envisager le projet comme une course à la boussole par étape. On joue le rôle de la voiture balais pour tous les candidats qui se sont trompés sur la position de l’arrivée d’une étape : on les amène sur la ligne de départ de l’étape suivante.

      7 – correction à prévoir dans le planning
      Afin de mieux responsabiliser les ingénieurs dans leur rôle de chef de projet, il faudra la prochaine fois leur demander de réagir à l’analyse faite par les techniciens pour préparer leur travail. Les techniciens devront en avoir le retour avant le début du codage afin de pouvoir le prendre en compte.

      8 – intégration des différents éléments du projet

      Deux groupes ayant finalisé leur travail 4 heures avant la fin du temps imparti, nous leur avons proposé de travailler sur l’intégration générale de tous les composants (acquisition, interface, portail). Ils ont ainsi pu sentir la difficulté de reprendre le travail d’un autre et l’utilité de tous les documents demandés (manuel d’installation, d’utilisation, analyse, commentaires dans le code, …). Espérons que cela leur sera profitable et qu’ils s’en souviendront lors de la rédaction de leurs prochains documents. L’intégration n’a pour l’instant pas abouti.

      9 – intégration du projet dans la progression pédagogique à Dijon
      Nous avons pu pendant cette quinzaine faire une synthèse de tout le premier semestre : analyse, intégration de matériel, acquisition, … Cela nous a permi aussi de sensibiliser à la vie d’un projet, ses étapes, ses documents, son rythme. Deux points spécifiquement disciplinaires sont à soulever :
      - cela a été l’occasion d’avoir une vraie mise en situation pour valider des tâches de l’habilitation électrique (et ça, je trouve que c’est un petit exploit)
      - nous avons pu faire travailler nos étudiants avec du matériel de mesure : GBF et oscilloscope afin de valider le comptage d’événement et de visualiser les trames échangées entre le SHT71 et le PC (ou DK41)

      La quinzaine a donc été bien riche, je ne pense pas qu’on ait fait le tour complet de son analyse mais c’est déjà bien riche. Je ne peux pas vous quitter sans préciser que tous les groupes sont arrivés à acquérir les informations demandées. Le calibrage du travail demandé était donc correct, ce n’était pas forcément gagné d’avance.

      C’était passionnant de monter tout cela et de le partager pendant deux semaines avec nos élèves. C’est à faire et à refaire.
      Nous sommes ouvert pour fournir toutes les informations nécessaires à qui voudrait tenter l’aventure …

      Prodagéo Dijon – Safi, c’est parti !!!

      Ca y’est, le projet est lancé ! Le planning de la quinzaine va être bien chargé, vous avez ici le scénario prévu avec les documents que doivent fournir les différents groupes…
      Vous pouvez aussi consulter les configurations matérielles utilisées par les différents groupes ainsi que le cahier des charges que nous avions fourni aux étudiants marocains.
      Où en est-on ce soir ?
      Les 6 groupes ‘chefs de projets’ ont transmis leur Cahier des charges aux techniciens de Dijon. Globalement ça s’est bien passé techniquement, et socialement. Pour ce qui est du contenu transmis, j’ai demandé à mes étudiants de Dijon de rédiger un court rapport de ce qu’ils ont compris de leur cahier des charges. Voici le bilan :
      1 équipe n’a rien rendu (aïe, aïe aïe …)
      les 5 autres équipes ont des imprécisions non négligeables sur le fonctionnement général du système et les limites de leur travail.
      Aucune équipe n’a fait état d’un cahier de recette ni de tests, peut-être n’ont-ils pas jugé nécessaire d’en parler, ce sera à éclaircir demain.

      Il faut donc recadrer cela afin de retourner dans le cadre du projet. Nous pensons demain commencer en donnant à nos étudiants les documents que nous avons fournis aux étudiants marocains afin qu’ils comparent avec ce qu’ils ont compris. Cela devrait leur permettre de retrouver le bon chemin.

      L’impression générale de la journée est très bonne, tout le monde s’est pris au jeu, aussi bien les élèves que les profs …. C’est bon de se faire plaisir au boulot !