Analysons à présent comment fonctionne l’outil de learning analytics natif de Moodle …

Une vidéo pour démarrer

Pour aborder ce point, la meilleure ressource l’a semblé être cette vidéo d’un webinaire animé par Elizabeth Dalton en 2019. Son intervention dure environ 35 minutes et la séance de questions-réponses qui suit, jusque la minute 43, est très intéressante.

La seconde partie est une activité participative plus pédagogique dont les apports essentiels sont résumés dans cette vidéo de Elizabeth Dalton sur la démarche qualité soutenue par les learning analytics. La suite de cet article résume ce que retient de la vidéo, de ma lecture de la documentation liée et de mes tests sur mon moodle local.

L’activation des learning analytics

Il faut commencer par activer les analytics Moodle via le menu d’administration du site « Fonctions avancées », en cochant le paramètre « enableanalytics ». Une fois ce paramètre coché, le menu d’administration du site présente de nouvelles options sous le libellé « Analyse de données », une traduction élégante du terme « Analytics ».

Dans les règlages des analytics, on a le choix entre utiliser un processeur de prédiction en PHP ou en Python, et Elizabeth nous dit que le processeur PHP ne permet que de la prédiction mais qu’il n’exige aucune configuration particulière du serveur. Alors que le processeur en Python (maintenu par Moodle HQ) exige que Python soit activé et que certaines librairies soient installées, tout cela pour avoir accès à des algo de type « feed-forward neural network ». Plus d’infos sur les algo d’analytics Moodle … Autre élément intéressant à souligner : les librairies Python semblent plus performantes que les librairies PHP. Je note aussi que dans la page de documentation officielle sur la configuration des learning analytics, on documente la possibilité de configurer le service Python sur un serveur externe. Ca permet de limiter la charge sur les machines de frontend, mais ça peut aussi engendrer de la latence entre les 2 serveurs.

Dans un Moodle de production les modèles d’analyse de données sont lancés automatiquement par des tâches cron, mais il est aussi possible, pour des tests, de lancer les analyses de données en ligne de commande. Le paramètre admin à cocher dans ce cas : « analytics | onlycli ».

Les modèles d’analyse de données

Via le menu « Modèles d’analyse de données », on peut voir une série de modèles définis par défaut et il est possible de définir de nouveaux modèles directement via l’interface. Un modèle est composé des éléments suivants :

• une cible : ce qu’on espère détecter, on peut en installer de nouvelles via des plugins additionnels;
• des indicateurs : les mesures liées à notre cible, actions qui semblent liées indirectement aux actions enregistrées dans la table des logs (déjà évoquée dans mon article sur le mémoire étudiant)
• un intervalle d’analyse : hier, la semaine passée, le mois passé, …
• un contexte : toute la plateforme, une catégorie de cours précis, un cours précis (pratique pour faire des tests dans quelques cours)

Les quelques modèles présents par défaut sont très expérimentaux, mais il y a des cibles et indicateurs de test qui sont configurés pour nous aider. J’épingle par exemple le modèle « Students at risk of dropping out » qui est pris en exemple et qui me semble intéressant à étudier car il compte 49 indicateurs et semble moins expérimental.

Pour l’instant, l’interface permet surtout d’éditer les modèles existants et d’en créer de nouveaux sur base des indicateurs préenregistrés (une soixantaine dont la moitié lié spécifiquement à une activité ciblée). Je n’ai pas l’impression d’avoir ce qu’il me faut pour construire mon indicateur des activités non effectuées par les étudiants, en comparaison avec les activités des étudiants du cours.

Pour une cible donnée, il est possible de définir plusieurs modèles, basés sur des indicateurs différents pour tester différentes approches.

La validation des modèles

Une des actions possible sur un modèle est de l’évaluer et ce traitement sort un taux de pertinence pour le modèle et la variance liée à ce résultat. Ce type d’évaluation vaut pour les modèle prédictifs qui peuvent être validés à postériori. La question de la validation des modèles en comparant avec les données a postériori est délicate puisque si le prof exploite le reporting pour faire du feedback aux étudiants, on peut changer le futur …

L’idéal est de pouvoir disposer de larges jeux de données pour tester un modèle et c’est la raison pour laquelle l’outil permet d’exporter un modèle et le jeu de données d’entraînement pour le passer d’une infra de test à une infra de prod ou pour l’échanger avec une autre institution pour tester sa robustesse. Tout le process d’échange de données se déroule sous couvert de l’anonymisation des données, RGPD oblige …

La rubrique « Informations du site » est destinée à décrire l’usage général de la plateforme, information importante en cas d’échange de données entre institution.

Je me demande si une réinitialisation des cours engendre une perte des données dans les modèles ou s’il garde ses traces même si les cours sont réinitialisés. Vu qu’il y a des tables dédiées aux analytics, je penserais plutôt que les données sont préservées, mais ce sera intéressant de vérifier.

Le reporting lié aux modèles

Une fois qu’un modèle est actif, la liste des actions liées permet d’afficher un « Rapport d’indication » qui met en évidence les notifications générées par le modèle et un rapport des « Eléments non valides » qui affiche les données qui posent problème, que le modèle ne peut pas exploiter (pas assez d’étudiants par exemple).

Côté enseignant, le système prévoit d’envoyer des notifications dans la cloche mais on peut désactiver cela en décochant une permission dans la configuration des rôles (analytics:listinsights). Mais d’après ce que je lis sur le système de notification des analytics dans la doc officielle, si on désactive ces notifications, les profs n’ont plus accès aux reporting des analytics. Il semble qu’il y ait un nouveau rapport disponible dans un cours pour accéder aux reporting des analytics, mais si on autorise pas les notifications aux profs, ils n’y ont pas accès. Via ce rapport, les enseignants ont accès une vue plus détaillée de la situation de chaque participant et à une série d’actions, comme par exemple envoyer un message aux étudiants en risque de décrochage.

Je note quand même que le modèle « Upcoming events » permet une vue via le calendrier et Elizabeth nous dite que c’est le premier modèle qui offre une vue étudiante. Donc, il y a moyen que le reporting d’un modèle soit reporté dans un outil existant, et sans doute aussi dans un rapport dédié. Et il y a moyen d’offrir une vue étudiante sur les résultats d’un modèle, reste à voir si cette vue peut être personnalisée pour chaque participant ou pas.

Le Partage de modèles et de jeux de données ?

Elizabeth nous dit qu’il y a un espace d’échange pour partager les modèles et jeux de données à l’adresse https://moodle.org/analytics. Mais je suis déçue de constater que cette adresse renvoie vers le forum sur les analytics dont j’ai montré dans mon précédent article qu’il me paraissait un peu mort …

C’est très déroutant de regarder une vidéo de Elizabeth, très enthousiaste par rapport au projet, ouverte aux suggestions d’évolution, en sachant qu’elle n’est plus là pour le projet et qu’il ne semble pas y avoir de nouveau pilote à bord …

Je note toutefois des informations intéressantes dans ce forum (au milieu des diverses incitations à utiliser Intelliboard) : il y a des plugins additionnels qui permettent de construire facilement des rapports pour les profs sur base de requêtes SQL comme le plugin Ad-hoc database queries et sa doc très fournie avec des exemples de requêtes (avec une requête pour sortir la Most popular activity que j’épingle)ou le plugin Configurable report. Et depuis la version 3.11, il y a aussi un outil de reporting natif Report builder. Intéressant à noter pour faire du reporting lié aux analytics.

Les modèles que j’aurais envie d’analyser

Pour mémoire, ce premier survol de l’outil me donne envie de me plonger plus loin dans la mécanique de conception de 2 modèles : « Students at risk of dropping out » pour ses nombreux indicateurs et « Upcoming events » pour sa possibilité de reporting étudiant.

Temps de travail sur cet article : 1 journée