Leur objectif était précisément de produire un tableau de bord avec des indicateurs de réussite pour les étudiants dans un Moodle qui compte plus de 70 000 étudiants et 17 000 cours.

Benjamin a aussi présenté un bilan du projet LRS de l’université de Lorraine le 10 octobre 2019 lors d’une journée d’échange thématique nationale. 

Ce projet a été financé sur un budget lié à l’aide à la réussite en première année et a impliqué des informaticiens et des chercheurs en informatique. Il intégrait aussi des responsables de programme pour permettre la mise en place d’activités de remédiation pour les étudiants en décrochage. Benjamin m’a relayé l’adresse de l’académique responsable du projet qui pourra m’en dire plus sur les publications concernant les indicateurs.  
 
L’intérêt de l’approche LRS (Learning Record Store) par rapport à l’approche Learning Analytics native de Moodle est qu’il est possible d’intégrer des données provenant d’autres sources que Moodle. En l’occurrence, ils ont aussi intégré des informations sur les notes officielles provenant de leur service Apogée (chez nous, l’équivalent serait le service OSIS). Ils imaginent aussi intégrer les données sur les accès wifi de l’étudiant (qui peuvent permettre d’avoir une idée de sa présence sur le site), sur les accès à la bibliothèque, … Mais ces échanges de données entre services représentent parfois un grand défi technique. Par exemple, faire le lien entre un cours Moodle et un cours dans OSIS est loin d’être évident car il n’y a pas d’obligation d’encode le code cours officiel dans Moodle. 

Benjamin souligne deux grands défis par rapport à ce type de projet. 

DEFI 1 : Eviter de faire une collecte massive de données sans sélection préalable 

Il témoigne notamment du fait que les chercheurs ont fait preuve d’un grand enthousiasme par rapport au fait qu’il était possible de brasser toutes les données liées aux activités étudiantes. Mais une telle approche est à proscrire pour 2 raisons :  

• L’approche massive a le désavantage d’être très lourde techniquement. Si on veut que le système de reporting soit optimisé, il faut l’alimenter avec le strict minimum de données nécessaire pour produire les indicateurs; 
• Sur le plan juridique (RGPD), le traitement de données à caractère personnel est autorisé à condition d’être déclaré aux utilisateurs (principe de transparence), de servir exclusivement la finalité ciblée (principe de finalité) et de se restreindre à la collecte des données strictement nécessaires pour atteindre cette finalité (principe de proportionnalité). 

Il me paraît donc essentiel de faire taire dès le départ le fantasme d’envisager le LRS comme le lieu de collecte de toutes les données étudiantes qui deviendrait une mine d’or pour les chercheurs en sciences de l’éducation. Le déploiement de l’outil passe par une démarche de recherche avec la formulation d’hypothèses concernant les indicateurs à tester, une sélection des données pertinentes à collecter, une implémentation technique du système de reporting lié et une mesure de l’impact des indicateurs calculés.  

DEFI 2 : Construire une structure de données qui permette de calculer facilement les indicateurs souhaités  

L’outil de LRS est livré avec certains modèles pour l’analyse de données mais les gestionnaires ne peuvent pas se passer d’une réflexion préalable sur la structuration des données, en particulier s’il faut fédérer les données de sources différentes. 

Voici la structure de LRS, basée sur le modèle One Roster de IMS Global, qui a permis à l’équipe de Benjamin de collecter à la fois les données sur les actions étudiantes dans Moodle (dans la lourde table des logs), les informations sur les activités Moodle liées à une note Moodle et les informations sur les notes de Apogée: 

• La table ”User” collecte les données sur les utilisateurs, avec notamment leurs numéros d’identification institutionnel et leurs données administratives ; 
• La table “Class” reprend les données sur un cours du programme de cours, lié à une année académique données ; 
• La table “Enrollment” fait la jointure entre les deux premières; 
• La table “Event” reprend toutes les actions d’un utilisateur dans le cours Moodle lié (c’est un extrait de la table des logs de Moodle) ; 
• La table “Lineitem” définit une activité Moodle ou Apogée à laquelle une note étudiante a été associée ; 
• La table “Result” contient les informations sur la note de l’étudiant, qui peut soit provenir de Moodle ou de Apogée ; 
• La table “Risk” contient l’indicateur de risque calculé pour l’étudiant dans un cours donné. 

INFRASTRUCTURE : Un LRS suppose aussi un serveur de calcul et un service web de reporting 

Le service Learning Record Warehouse de Apereo est lié à une base de données MongoDB et les algorithmes prédictifs tournent sur un serveur de calcul Apache Spark. Le tableau de bord étudiant est affiché via une application web développée en Symfony. 

Dans leur infrastructure, l’échange de données se fait via des scripts personnalisés car ils souhaitaient que les données soient envoyées la nuit via une tâche cron. Le plugin TRAX Logs de Moodle se semblait pas à l’époque autoriser cette prouesse, mais il semble qu’il ait évolué pour permettre de planifier l’envoi des données au LRS et pour permettre de sélectionner les données à envoyer. 

Quand je questionne Benjamin sur les performances du service LRS, il m’indique que l’élément qui a demandé le plus d’optimisation dans leur infrastructure est la base de données MongoDB.

RESULTATS : Un tableau de bord étudiant avec des indicateurs comparatifs et prédictifs 

Leur tableau de bord affiche pour chaque cours des informations liées à l’activité de l’étudiant.  

Les activités sont analysées au travers des indicateurs suivants : 

• Le nombre de consultations de ressources 
• le nombre de clics dans le cours 
• le score aux activités 
• le nombre de devoirs rendus 

L’engagement est mesuré au travers d’un seul indicateur qui comptabilise le nombre de jours actifs. 

La participation est mesurée au travers de l’indicateur de nombre de sujets vus dans le forum. 

Ces indicateurs sont comparés avec les indicateurs des étudiants de la cohorte précédente pour fournir des indicateurs prédictifs de la réussite de l’étudiant. 
 
Ce tableau de bord affiche aussi une vision de la progression de l’étudiant et un feedback personnalisé en fonction de ses résultats. 

ENJEUX JURIDIQUES : A ne pas négliger ! 

J’ai déjà évoqué les précautions à prendre avant de collecter des données, voyons à présent les précautions à prendre pour gérer correctement ces données. 

En terme de gestion, voici les différentes règles à respecter et l’approche qui a été implémentée dans le projet LRS de l’université de Lorraine : 

• Droit d’accès aux données : les données de l’étudiant sont affichées à l’étudiant, il n’y a donc pas de problème avec cette règle ;  
• Droit d’opposition : pour accéder au tableau de bord étudiant, des conditions d’utilisation doivent être acceptées et marquent l’accord de l’étudiant pour que le traitement de ses données soit autorisé ; 
• Droit de portabilité : l’étudiant peut exporter ses données sous forme d’un fichier .json ; 
• Droit de rectification : les données de Moodle sont liées à ses actions et les données de Apogée sont liées à ses notes; au besoin l’étudiant est renvoyé vers le service compétent pour la rectification; 
• Droit de limitation : les données sont conservées avec un certain délai à respecter ; si elles étaient partagées avec des tiers (les enseignants, par exemple), il faudrait définir le délai d’accès et veiller à le faire respecter; 
• Droit de déréférencement : les données ne sont pas indexées par un moteur de recherche, il n’y a donc aucune implication pour ce point; 
• Droit d’effacement : un élément très délicat à gérer dans un projet de learning analytics où des algorithmes prédictifs sont utilisés, en se basant sur les résultats passés. 
   

Je note que cette analyse a été réalisée conjointement avec leur DPO. C’est un acteur qui me paraît incontournable dans un projet de learning analytics. Si un tableau de bord enseignant était envisagé, les précautions de gestion devraient être revisitées et que cela aurait d’autres impacts sur la gestion technique du projet. 

Conclusions

La quête d’indicateurs de réussite et surtout d’aide à la réussite s’apparente à une ruée vers l’or qui suppose un balisage précis des différents terrains de fouille sinon elle risque de devenir une quête irréalisable.  

Le potentiel des outils de LRS réside dans la possibilité de collecter des données émanant de différents systèmes mais suppose une réflexion sur la manière d’organiser ces données. Les performances des outils LRS mérite d’être testée. 

Les enjeux juridiques liés aux learning analytics méritent d’être approfondis. 

Prochain article

Cet échange me donne envie de reparcourir le travail d’analyse des données de la table des logs de Moodle, réalisé dans le cadre d’un mémoire étudiant … Rendez-vous prochainement pour un nouvel article sur ce point 😉 

Temps de travail pour cet article : 1 demi-jour