Maquette de cours de technologie pair-à-pair

Je présente ici une maquette de ce que pourrait être un cours de technologie pair-à-pair dans une école d'ingénieur, en me basant sur ma pratique des contributions pair-à-pair à l'UTC entre 2013 et 2017.

Analyse de l'expérience menée à l'UTC

Points positifs : Implication, couverture technologique, capitalisation

  • Un engagement fort des étudiants en général, l'enjeu de la formation qu'ils vont devoir jouer "pour de vrai" en présentiel motive et implique.

  • Une efficacité pédagogique en particulier sur des sujets émergents, l'enseignant et les étudiants étudient de conserve des technologies que l'enseignant ne maîtrise pas a priori.

  • La constitution d'une base pouvant être réappropriée dans des cours classiques (j'ai ainsi réintégré quatre modules issus de contributions dans un cours de niveau inférieur).

Point négatif : La disparité des contributions

Lorsque l'exercice est manqué totalement ou partiellement, les étudiants qui suivent la contribution perdent leur temps.

Les étudiants sont astreints à l'exercice dans le cadre d'un cours d'informatique classique, pour une partie d'entre eux l'exercice est fait "à contre-cœur" et donne de mauvais résultats. D'autres étudiants sont motivés pour l'exercice mais ne le travaillent pas assez ou mal (par défaut d'organisation). Ces deux populations ont toujours été minoritaires dans mon expérience, disons 20% et 20% au maximum, mais au final si on se retrouve avec environ un tiers des contributions qui sont inutiles ou peu utiles pour ceux qui y assistent.

Il y a donc un enjeu à faire en sorte que ce soit plus régulièrement qualitatif, grâce à plus de suivi et une validation systématique par l'enseignant (go / no go) .

Autres attente ou ouvertures (formulées par les étudiants)

  • Avoir du temps pour préparer

  • Avoir du temps pour jouer le cours (privilégier les formats de 45 à 60 minutes sur les formats de 30 minutes)

  • Travailler moins de sujets différents à la fois (privilégier une thématique cohérente par semaine pour 4 à 6 contributions plutôt qu'un sujet par contribution)

  • Allez au bout de l'exercice en intégrant des évaluations sommatives (examen portant sur les contributions)

  • Enregistrer le cours présentiels pour capitaliser sur l'oral

Travail "individuel de groupe"

Les étudiants gagnent à travailler en groupe, pour optimiser leur investissement individuel dans un cadre collaboratif. La bonne formule semble être un sujet à travailler à plusieurs, mais pré-découpé avec un module d'une heure par personne. Regroupés, ces modules forment une sorte de séminaire qui peut se dérouler en présentiel sur une demi-journée ou une journée, sur une semaine en plusieurs séances, ou être joué à distance.

Par exemple sur une technologie de type base de données NoSQL, on peut poser un sujet avec cinq modules :

  • Principes, installation, hello world, fonctions de base

  • Modélisation, création, insertion

  • Interrogation simple

  • Interrogation avancée

  • Interfaçage avec un langage de programmation

Scénario pour un cours de technologie pair-à-pair en école d'ingénieur (en informatique)

Exemple d'organisation

  • 24 étudiants répartis en 4 à 6 groupes de 4 à 6

  • Un sujet par groupe :

    • dimension technologique forte : à la fois intéressant techniquement pour ce que ça permet de faire et ce que ça permet de penser) ;

    • "à la mode" : donc mobilisable en pratique en dehors de l'école

    • intéressant pédagogiquement et peu ou pas traité dans les enseignements classiques : donc qui permet de compléter le parcours d'enseignement

  • Chaque sujet est découpé en un module par étudiant, chaque étudiant travaille avec son groupe sur l'ensemble (cohérence globale) et développe son module (son cours)

Exemple de sujets en informatique

  • Gestion et l'analyse de données NoSQL (stack ElasticSearch)

  • Calcul distribué (Spark, Hadoop)

  • Virtualisation (Docker)

  • Web (Mongo/Django)

  • BlockChain

  • Deep learning

  • Sécurité, crypto

  • ...

Livrables

  • Une partie théorique rédigée qui développe : le contexte de genèse et d'usage, un à trois concepts nouveau (ou approfondis), un exemple simple.

  • Une vidéo de 10 minutes qui en fait l'exposé.

  • Une partie pratique qui consiste à articuler des exercices d'illustration (45 minutes), avec un support d'autoformation (exercices corrigés).

  • Une ou plusieurs séances d'1 heure à l'UTC, ouvertes aux autres étudiants du cours, à d'autres étudiants de l'UTC, co-encadrées par le groupe, l'étudiant et l'enseignant.

  • Une ou plusieurs séances en présentiel ou à distance avec des partenaires (par exemple une entreprise intéressée au sujet).

  • Une partie qui consiste à faire concevoir ou faire jouer avec un POC réalisé et/ou mise en place par le groupe (2 à 4 heures mutualisées au niveau du groupe).

    Cette partie a pour fonction d'ancrer la technologie dans un exemple d'usage pour le groupe qui fait le cours, et peut servir à encadrer un travail complémentaire en autonomie.

Organisation

4h par semaine de suivi enseignant et 4h par semaine de travail en autonomie :

  • Séance 1-6 : Préparation des formations

  • Séances 7-12 : Formations en présentiel, travail sur les POC en autonomie, évaluations et améliorations pair-à-pair

Le rôle de l'enseignant est :

  • de valider la démarche pédagogique,

  • de suivre les livrables,

  • de participer à valider le contenu,

  • de donner le go pour jouer la formation.

L'évaluation est constituée pour partie d'évaluation pair-à-pair et pour partie d'évaluation par l'enseignant.

Besoins pour la mise en place d'un tel cours

  • Encadrement étudiant classique (4h par semaine pour un groupe de 24 étudiants pendant 12 à 14 semaines)

  • Clients et serveurs informatiques permettant de tester "librement" (à mettre en place et à gérer)

  • Observation critique du dispositif

Logiciels libres et plate-forme collaborative intégrée

Afin d'assurer la continuité du dispositif, tous les contenus et codes produits doivent l'être :

  • dans le respect de la loi sur la propriété intellectuelle (les inputs sont libres pour être légalement utilisables quelque soit le contexte)

  • sous des licences libres (les output sont libres pour être facilement réutilisables)

  • sur des technologies libres (pour que les conditions pédagogiques soient reproductibles)

  • sur une plate-forme assurant la continuité documentaire (typiquement Scenari)

Étant donné que beaucoup de technologies récentes en informatique sont libres, ces conditions laissent beaucoup de possibilités ouvertes.

Autres scénarios

Sur un modèle assez proche, on pourrait traiter :

  • des sujets non informatiques

  • des sujets informatiques de vulgarisation (dans ce cas les étudiants qui donnent les cours ne peuvent pas être également la cible des cours)