1.1 Organisation de la matière

Le découpage de la matière dans les cours de science des données, ainsi que le timing sont importants pour obtenir un travail sur la durée des étudiants tout au long de l’année qui est une nécessité pour un apprentissage efficace et durable. Voici quelques idées à développer pour assurer cet apprentissage progressif et continu.

1.1.1 Découpage

Module Nous avons entre 6 et 12 modules selon les cours. Chaque module demande entre 10 et 15h de travail dont 6h en présentiel. Il s’étale sur une semaine (minimum). Un timing classique est : 3h de préparation à domicile, présentiel de 2h, travail à nouveau à domicile 1h, présentiel de 4h, et enfin, travail à domicile 2h pour finaliser le tout. Au niveau de chaque module, on précise les objectifs, et en fin de module, il faut un bilan avec évaluation certificative pour que l’étudiant puisse vérifier qu’il ait bien compris les concepts abordés de lui-même et pour forunir la quantification de ses acquis dans le but de’établir sa note pour le cours.
Capsule Un ensemble plus restreint d’items à apprendre (généralement un ou deux items max). Section du bookdown et/ou vidéo avec des exercices H5P/learnr niveau I entrelacés. Préciser également l’objectif et faire un mini-bilan à la fin de la capsule.
Tâche Item d’apprentissage unique lié à un et un seul matériel pédagogique (sous-section bookdown, présentation H5P, mini-learnr, très courte vidéo ou gif animé).
Activité Exercice réalisé par l’étudiant. Inclus dans les items précédents.

1.1.2 Quatre niveaux de difficulté

Au fil de l’élaboration de notre matériel pédagogique, nous avons observé que certains formats sont plus adaptés pour des niveaux de difficulté plus simples, et d’autres pour des tâches plus complexes. Par exemple, des petits widgets H5P sont utiles pour garder l’étudiant actif au milieu de la lecture d’un texte un peu long, autant qu’ils lui permettent de s’auto-évaluer. Par contre, les jeux de données à analyser soi-même avec des directives minimalistes dans des projets GitHub en groupe sont d’un niveau de difficulté nettement plus élevé. Au final, nous définissons quatre niveaux de difficulté croissants, et nous leurs associons des matériels et des objectifs différents. L’idéal est de balayer un même concept au travers de matériel appartenant chaque fois à l’un de ces quatre niveaux de difficulté pour assurer la gradation de difficulté et la répétition non monotone des concepts, facteurs clés d’un apprentissage actif réussi.

1.1.2.1 Niveau 1

Exercices simples directement inclus dans le bookdown.

Objectif : rendre l’étudiant actif et lui permettre une auto-évaluation de la compréhension correcte des concepts en direct.
Type : H5P, learnr avec 1 ou 2 exercices, applications Shiny simples directement intégrés dans le bookdown.
Code R : pas d’écriture de code directement, éventuellement utiliser des widgets H5P du genre remplir les blancs dans du code à partir d’une liste de fragments, indiquer si un code présenté est correct ou non, s’il effectue un traitement donné ou pas (question true/false), …
Lieu : travail à domicile.
Suivi de l’utilisation des outils dans le rapport de progression.

1.1.2.2 Niveau 2

Auto-évaluation des principes théoriques à semi-pratiques par l’étudiant via des learnrs comportant plusieurs questions.

Objectif : pouvoir vérifier ses acquis, faire un bilan de progression en auto-évaluation.
Type : learnrs exécutés soit dans le bookdown, soit dans RStudio, à voir…
Code R : écriture minimale de code via des exercices guidés.
Lieu : travail à domicile et/ou en présentiel.
Suivi avec acquisition de badges. Les évaluations plus “théoriques” passent aussi par des learnrs. Question : évaluation en fin d’AA pendant la période d’examen, ou évaluation en continu ?

1.1.2.3 Niveau 3

Projets GitHub individuels cadrés.

Objectif : effectuer une transition douce vers l’application pratique des concepts. Analyse de données réelles fortement guidée.
Type : projets RStudio avec fichiers partiellement remplis, tâches bien précises et nombreux commentaires d’aide dans les fichiers “template” fournis.
Code R : écriture de code par rapport à un résultat attendu bien cadré et spécifié. Essentiellement carnet de notes, mais d’autres formes (rapport, présentation, article…) peuvent également être abordées brièvement à ce stade.
Utilisation d’une batterie de tests pour que l’étudiant puisse avoir un retour immédiat sur ce qu’il a réalisé correctement ou non, et dans ce derniers, avoir des conseils pour corriger ses erreurs.
Évaluation par grille critériée remplie de manière semi-automatique en s’appuyant sur les mêmes tests que ci-dessus.
Lieu : travail en présentiel essentiellement en individuel.
Évaluation et retour de temps en temps via l’inspection des dépôts GitHub des étudiants. Historique du travail de chaque étudiant via Git. Retour important ici (s’astreindre à visualiser quelques dépôts chaque semaine et faire des retours via issues GitHub, mails, ou Discord).

1.1.2.4 Niveau 4

Analyse libre de données dans des projets GitHub en groupe.

Objectif : acquérir un certain degré d’autonomie dans l’analyse des données en pratique.
Type : projet RStudio avec instructions réduites au minimum, pas de fichiers partiellement préremplis.
Code R : écriture de code en fonction des objectifs fixés par l’étudiant lui-même. Il est aussi responsable de l’organisation et de la maintenance de ce code jusqu’à l’aboutissement du projet. Présentation sous forme de carnet de notes, et ensuite sélection des éléments les plus pertinents pour rédiger un rapport qui doit être “présentable” à un panel de lecteurs.
Travail par groupe de deux ou quatre étudiants pour mobiliser l’intelligence collective et permettre aux étudiants plus faibles de ^progresser grâce aux apports des plus forts dans le groupe.
Lieu : travail en présentiel à compléter à domicile.
Le ou les rapports font l’objet d’une évaluation détaillée avec grille critériée et sont la base de la note pour la partie pratique. Historique de l’activité via Git. Typiquement, un gros projet qui reprend les notions de plusieurs modules sur un quadrimestre.

1.1.3 Timing

Les différents modules sont placés à l’horaire à des semaines bien définies. L’étudiant doit prendre conscience qu’il a une semaine pour assimiler le contenu du module, tout en lui permettant une certaine flexibilité (aussi pour les étudiants en passerelle qui arrivent plus tard et qui doivent pouvoir rattraper progressivement). Éventuellement, pour eux il faudrait pouvoir établir un calendrier adapté.

L’étudiant doit avoir une vision précise des différentes deadlines qui sont imposées pour synchroniser les activités de telle façon que les travaux de groupe puissent être entamés de manière adéquate. Pour un exemple d’un tel planning, voyez [ici]https://wp.sciviews.org/sdd-umons/?iframe=wp.sciviews.org/sdd-umons-2023/temps.html). Pour motiver les étudiants davantage, vous pouvez mettre en place un système de badges une fois les modules achevés (exercices réalisés et évaluation certificative réussie). Et pourquoi pas, la possibilité d’obtenir de badges “spéciaux”, liés à des points bonus : entre-aide, excellence, esprit d’initiative…

1.1.4 Mode d’évaluation

Privilégier une évaluation continue avec une bonne part d’évaluation formative (un retour vers l’étudiant qui indique ce qu’il peut améliorer et comment, sans forcément lui attribuer une note), et inclure une courte évaluation certificative (1/2h, 3 ou 4 questions courtes) à la fin de chaquez module. Vous pouvez moyenner les différentes évaluations certificatives des modules pour la note finale… et donc décider de ne pas organiser d’examen final. Cela permet de dégager du temps pour un travail en cours d’année et cela fait bien comprendre aux étudiant l’importance du travail sur la durée pour votre cours. Nous appliquons cette recette avec succès. Par contre, il faut bien expliquer les objectifs, l’approche pédagogique et le mode d’évaluation en début d’année : les étudiants n’y étant pas habitués, ils peuvent être surpris.