BoardZ Moodle Stat Project

Ce projet est porté par l'Université d'Avigon (UAPV) sous la direction de Thierry Spriet,Vice-président délégué au numérique et à l'innovation pédagogique, et a été confié à la société ActiveProLearn, en Décembre 2018. ActiveProLearn est un laboratoire privé d'innovation pédagogique et technologique dans l'éducation spécialisé sur socle LMS MOODLE.

Le projet BoardZ reprend les mêmes objectifs que son prédécesseur (AVP BoardZ sur Github), mais au sein d'un partenariat public/privé destiné à :

• Fournir un support au dispositif permettant à d'autres acteurs d'utiliser la technologie avec une garantie d'assistance.
• Garantir une viabilité à long terme de l'effort architectural et technologique.
• Assurer une construction adoptant des normes industrielles et des standards d'architecture propre à la nécessité du projet, dans une vision de construction à long terme.
• forger un modèle de soutien budgétaire à long terme, indépendamment des décisions ou changments d'environnement locaux.

Bénéficiant d'une longue expérience et d'une recherche opérationnelle de plusieurs années sur les thèmes des statistiques, calculs de temps, tracking, reporting, extraction de données à partir d'une plate-forme Moodle, le projet récupérera des éléments du projet BoardZ initial, mais en intégrant sa propre ligne de design technique.

Les objectifs de BoardZ deuxième génération, seront de :

• Anticiper les problèmes de performance sur des calculs à forte volumétrie de population et d'usages générés.
• Introduire des principes d'extensibilité, afin que le dispositif de calcul puisse être complété, amendé, étendu.
• S'appuyer sur des design simples, avec des technologies et des usages de formats connus par la communauté Moodle (tels que templates Mustache, bases de données MySQL/MariaDB)
• Adopter autant que possible des syntaxes et des sémantiques proches du lexique Moodle, afin de ne pas créer une rupture de culture.
• Récupérer des définitions fonctionnelles de la version antérieure lorsque c'est pertinent.
• Récupérer des concepts, algorithmes et éléments d'architecture de la version antérieure lorsqu'ils sont pertinents pour la nouvelle architecture.
• Récupérer des assets de la version antérieure lorsqu'ils sont facilement réutilisables.

Afin de pouvoir adresser des performances de calcul et d'absorption en temps réel sur des volumes de données importants ou sur des environnements multi-tenants (Moodle multiples, Moodle en batterie virtualisés (VMoodle)) les choix de départ de la version 2 sont différents de la première version développée en PHP sous Symphony.

L'objectif final est de disposer d'un serveur de calcul autonome capable de suivre en temps quasi réel l'ensemble des activités et usages de la population inscrite, afin d'en tirer des indicateurs pédagogiques et opérationnels sans altérer la performance frontale de Moodle.

L'objectif de calcul est important, en ce sens que les requêtes et agrégations de données peuvent adresser des formules non-linéaires (quadratiques, n-quadratiques) dans une exploration temporelle multi-dimensionnelle. de ce fait, les charges de calcul et l'organisation du stockage ne serait pas supportable s'il était directement intégré dans le code de Moodle et opéré comme service directe du LMS.

Accomplir cet objectif de pouvoir calculer efficacement un grand nombre d'indicateurs dans un grand nombre de contextes variés, et sur des formules non linéaires, nécessite de dissocier le moteur de calcul sur une infrastructure dédié, et de créer les ponts d'alimentation et de restitutions de données entre le serveur et l'environnement d'exploitation moodle.

Au delà de l'objectif architectural (et ce que l'objectif architectural doit servir), c'est le besoin, pour les institutions d'enseignement, de pouvoir disposer d'indicateurs réflexifs et comparés sur l'apprentissage, permettant à un apprenant (ou à un enseignant) d'observer son positionnement relatif par rapport au groupe, la promotion ou la session.

En effet, le numérique nous permet de collecter en continu des données élémentaires dont l'exploitation permet de donner des indications sur le “comportement d'usager” de l'utilisateur. Il serait déontologiquement abusif d'induire une extrapolation sociologique du “comportement d'usager” et de réaliser une projection sur le profil psychologique, social ou cognitif de l'utilisateur, mais à une échelle statistique, ou comparée, sur une population donnée, soumise au même “contrat institutionnel” qui définit les objectif et le cadre dans lequel ces objectifs sont proposés, des déductions des signaux que représentent les traces de comportement sur la plate-forme restent exploitables.

• Objectif 1 : sur la base d'activités sélectionnées et choisies, un positionnement comparatif des indicateurs de l'individu par rapport à un groupe de référence, appelé également indicateur de positionnement

Exemple :

Un forum est mis en place comme point central de l'animation d'un cours. La participation à ce forum a été institutionnellement établie comme une contrainte principale du contrat pédagogique. Tous les inscrits subissent la contrainte (pas d'auditeur libre ou d'exception de statut). Dans ce cas la mesure comparée du nombre d'intervention dans le forum est un des indicateurs possibles d'analyse du positionnement d'un étudiant dans son groupe de référence (mais pas le seul)

• Objectif 2 : Le calcul de temps de connexion, à des fins de comptabilité des actions de formation continue.

Deux défis majeurs sont identifiés dans ce projet :

1. Le défi de la performance et la réactivité des affichages statistiques
2. Le défi de la maniabilité et la flexibilité d'administration et de configuration
3. Le défi de l'évolutivité et l'extensibilité

Le défi de la performance vient essentiellement d'une volumétrie prévisible importante dans le cadre d'utilisation de plates-formes universitaires, avec des populations d'inscrits que quelques milliers à quelques dizaines de milliers d'étudiants.

Si on table sur une adoption croissante des indicateurs dynamiques dans l'usage des interfaces de cours, et d'un appel croissant à des “tableaux de bord” agrégés pour piloter la pédagogie, alors une croissance horizontale et verticale de la volumétrie doit être anticipée.

Le requétage temporel sur des grandeurs historisées pose également un problème d'efficience de calcul. Si les résultats sont calculés “au moment du rendu”, des stockages classiques des échantillons doivent être systématiquement reparcourus pour obtenir les valeurs d'indicateurs sur la période demandée. Précalculer ces résultats sous la forme d'un simple cache de requêtes n'est pas une solution, car un changement infime dans la période souhaitée entraine un nouveau stockage de résultat. La consommation en cache sera alors énorme.

Le défi consiste donc à trouver un modèle de données capable de proposer un compromis entre ces deux contraintes.

• Journal de bord : Le journal de bord des développements en cours.
• Documentation de conception : Les principes de construction.
• Documentation d'installation : L'installation du serveur et sa mise en oeuvre.
• Documentation d'administration : L'administration du serveur.
• Documentation d'intégration : L'intégration dans Moodle.
• Documentation d'extension : Les APIs et l'extensibilité.