Chapitre 7 — Rapports natifs, Report Builder et analytics

Après avoir sécurisé, configuré et organisé votre plateforme dans les chapitres précédents, il est temps de répondre à la question que tout établissement finit par poser : que se passe-t-il réellement sur mon Moodle ? Qui se connecte, qui travaille, qui décroche, quels cours vivent et lesquels végètent ? Moodle 5.2 embarque un arsenal de reporting étonnamment riche — et étonnamment méconnu : rapports de cours natifs, journaux d’événements, générateur de rapports personnalisés (le Report Builder, ou « générateur de rapports »), analytique d’apprentissage prédictive (Learning Analytics) et statistiques historiques.

Ce chapitre est entièrement fonctionnel : tout se passe dans l’interface web, sans une ligne de PHP. La création de sources de données personnalisées pour le Report Builder, elle, relève du développement de plugins et sera traitée dans la partie développeur de cette formation.

💡 Pour un dev React : pensez à l’écosystème reporting de Moodle comme à une stack analytics complète que vous auriez à construire vous-même sur un projet Next.js : les logs sont votre table d’événements (façon Segment ou PostHog), les rapports de cours sont des dashboards pré-câblés, le Report Builder est un query builder visuel (comme Metabase ou Retool) posé sur un ORM aux jointures prédéfinies, et les audiences sont les ACL de partage de vos dashboards. Une fois cette carte mentale posée, tout le chapitre devient familier.

7.1 Panorama : où vivent les rapports dans Moodle

Avant de plonger dans chaque rapport, il faut comprendre la géographie du reporting dans Moodle, car les rapports sont disséminés à trois niveaux distincts, chacun avec son contexte et ses permissions.

7.1.1 Les trois niveaux de rapports

Concrètement, dans Moodle 4.x/5.x avec le thème Boost (Bootstrap 5 depuis Moodle 5.x) :

• Au niveau site : connectez-vous en administrateur, ouvrez Administration du site (dans la barre de navigation principale), puis l’onglet Rapports. Vous y trouvez une longue liste : Journaux (Logs), Journaux en direct (Live logs), Activité du cours, Sauvegardes, Aperçu des statistiques , Instances de questions, Vérifications de sécurité, Aperçu de performance, Générateur de rapports (Report builder), Surveillance des événements (Event monitoring), Insights, etc.
• Au niveau cours : entrez dans un cours ; sous le nom du cours, la navigation secondaire affiche des onglets — Cours, Paramètres, Participants, Notes, Rapports, Plus. Cliquez sur Rapports : une page d’index liste tous les rapports disponibles pour ce cours (l’affichage exact dépend des permissions de votre rôle et des fonctionnalités activées, par exemple l’achèvement).
• Au niveau utilisateur : ouvrez le profil d’un utilisateur (le vôtre ou celui d’un étudiant depuis la liste des participants). La section Rapports du profil propose : Journaux d’aujourd’hui, Tous les journaux, Rapport résumé, Rapport complet, Sessions de navigateur, Aperçu des notes. Ces rapports sont contextualisés : vus depuis la page de profil dans un cours, ils sont restreints à ce cours.

⚠️ Piège : le même rapport « Journaux » existe au niveau site ET au niveau cours — c’est le même moteur, mais le périmètre change. Un enseignant qui consulte les logs dans son cours ne voit que les événements de ce cours ; l’administrateur au niveau site voit tout. Ne cherchez pas un « rapport global » dans un cours : il n’existe pas à ce niveau, c’est le contexte qui borne les données.

7.1.2 Qui voit quoi : les capabilities de rapports

Comme tout dans Moodle (chapitre 6 sur les rôles), l’accès aux rapports est gouverné par des capabilities (capacités). Chaque rapport de cours est en réalité un plugin de type report (vous les retrouverez dans le dossier /report du code source), et chacun déclare sa propre capability de consultation. Les plus importantes :

Deux réglages complémentaires méritent d’être connus : dans Administration du site → Utilisateurs → Permissions → Politiques utilisateur, les enseignants voient par défaut les rapports de leurs étudiants ; et pour laisser un étudiant consulter son propre rapport d’activité, activez dans les paramètres du cours (ou via showreports au niveau site) l’option « Montrer les rapports d’activité » — sinon la section Rapports du profil reste vide pour lui.

💡 Pour un dev React : le système de capabilities appliqué aux rapports, c’est exactement un middleware d’autorisation par route. Chaque page de rapport fait l’équivalent d’un requireCapability('report/log:view', context) avant de rendre quoi que ce soit — comme un middleware.ts Next.js qui vérifie une permission dans la session avant de servir /dashboard/logs. Le « contexte » (site, cours, utilisateur) joue le rôle du scope de votre token.

📚 Aller plus loin : la liste complète des rapports disponibles selon le contexte est documentée sur docs.moodle.org (pages « Reports » et « Course reports »). Côté architecture, chaque rapport de la liste correspond à un plugin report_xxx — vous pouvez d’ailleurs en installer d’autres depuis le répertoire des plugins Moodle (moodle.org/plugins), catégorie « Reports ».

7.2 Les rapports natifs de cours en détail

Cette section est le quotidien de l’enseignant et du gestionnaire pédagogique. Chaque rapport répond à une question précise ; apprenez à choisir le bon.

7.2.1 Journaux (Logs) : la boîte noire du cours

Chemin : Cours → Rapports → Journaux (Logs).

C’est le rapport le plus brut et le plus puissant : il interroge le magasin de logs standard (standard log store, table mdl_logstore_standard_log) qui enregistre chaque événement de la plateforme — consultation d’une page, remise d’un devoir, modification d’un paramètre, tentative de quiz, tout.

L’écran présente une barre de filtres en haut, puis un bouton « Obtenir ces journaux » (Get these logs) qui exécute la requête. Les filtres disponibles :

Le résultat est un tableau paginé : Heure, Nom complet de l’utilisateur, Utilisateur concerné (l’« affected user », par exemple l’étudiant dont l’enseignant a noté le devoir), Contexte de l’événement, Composant, Nom de l’événement, Description, Origine, Adresse IP. La description est parlante : « The user with id ‘123’ viewed the ‘quiz’ activity with course module id ‘456’ ».

En bas de page, un menu déroulant permet d’exporter la table au format CSV, Excel (.xlsx), ODS, HTML, JSON ou PDF — pratique pour une analyse fine dans un tableur ou un notebook.

⚠️ Piège : le filtre par date ne propose que un jour à la fois dans l’interface standard des logs de cours. Pour une plage de dates, il faut soit exporter et filtrer ailleurs, soit passer par le Report Builder ou un plugin. Autre piège classique : la rétention des logs — si votre politique de nettoyage (chapitre 5, réglage loglifetime du log store standard) purge les logs après 90 jours, aucune interface ne vous rendra les événements plus anciens. Le rapport ne montre que ce que la base contient encore.

💡 Pour un dev React : mdl_logstore_standard_log est une table append-only d’événements, exactement comme un event stream que vous enverriez à PostHog ou Amplitude : {eventname, component, action, userid, relateduserid, contextid, timecreated, ip, other}. Le rapport Logs n’est qu’un SELECT ... WHERE paramétré par les filtres, avec pagination serveur. Si vous avez déjà construit un audit trail dans une app SaaS, vous êtes en terrain connu.

7.2.2 Journaux en direct (Live logs) : le temps réel

Chemin : Cours → Rapports → Journaux en direct (Live logs). Existe aussi au niveau site.

Ce rapport affiche les événements de la dernière heure, rafraîchis automatiquement (par défaut toutes les 60 secondes). Un bouton « Pause des mises à jour en direct » (Pause live updates) fige l’affichage — indispensable quand vous voulez lire une ligne avant qu’elle ne défile. Les lignes récentes sont surlignées à chaque rafraîchissement.

Cas d’usage concrets : surveiller une session d’examen en salle (voir en direct qui démarre le quiz, qui le soumet), vérifier qu’un étudiant « bloqué » au téléphone accède bien à l’activité, ou observer l’effet immédiat d’une annonce.

⚠️ Piège : « en direct » signifie pull périodique, pas WebSocket : la page interroge le serveur à intervalle régulier. Laisser des dizaines d’onglets Live logs ouverts sur un gros site génère une charge inutile. Fermez-les après usage.

7.2.3 Rapport d’activité (Activity report) : le pouls des contenus

Chemin : Cours → Rapports → Rapport d’activité (plugin report_outline, parfois traduit « Activité du cours »).

Une ligne par activité et ressource du cours, avec : le nombre de vues (views), le nombre d’utilisateurs distincts ayant consulté, le nombre d’articles de blog associés, et la date de dernier accès. C’est le rapport « quels contenus vivent, lesquels sont morts » : si votre superbe vidéo du chapitre 4 affiche 3 vues par 2 utilisateurs alors que le cours compte 200 inscrits, vous avez un problème de scénarisation, pas un problème technique.

Notez que le comptage démarre à la date d’activation des statistiques/logs et dépend de la rétention : un cours ancien peut afficher des compteurs partiels si les logs ont été purgés.

7.2.4 Participation au cours (Course participation) : l’outil de relance

Chemin : Cours → Rapports → Participation au cours.

C’est, de loin, le rapport le plus actionnable pour un enseignant, et il est scandaleusement sous-utilisé. Il croise quatre paramètres :

1. Module d’activité : une activité précise du cours (un devoir, un forum, un quiz…) ;
2. Période : depuis 1 jour, 1 semaine, … jusqu’au début du cours ;
3. Afficher seulement : un rôle (typiquement Étudiant) ;
4. Afficher les actions : Consultation (View), Message (Post, c’est-à-dire contribution), ou Toutes les actions.

Le résultat : la liste des utilisateurs du rôle choisi avec une colonne Oui/Non — a-t-il, oui ou non, effectué l’action sur cette activité dans la période ? Chaque « Oui » indique aussi le nombre d’occurrences.

Et voici la killer feature : chaque ligne a une case à cocher, avec des boutons « Sélectionner tous les ‘Non’ » puis, dans le menu « Avec les utilisateurs sélectionnés… », « Envoyer un message ». En trois clics, vous envoyez un message groupé (via la messagerie interne, avec copie email selon les préférences des destinataires) à tous les étudiants qui n’ont pas encore rendu le devoir. C’est l’outil de relance de masse le plus efficace de Moodle.

💡 Pour un dev React : Course participation, c’est une requête d’anti-jointure (les inscrits MOINS ceux qui ont un événement correspondant) avec une action bulk branchée sur le résultat — l’équivalent d’un LEFT JOIN ... WHERE event IS NULL suivi d’un sendBulkMessage(selectedUsers). Si vous deviez le coder : un composant tableau avec sélection multiple contrôlée et une server action de notification. Moodle vous l’offre en natif.

⚠️ Piège : la distinction View / Post dépend du type d’activité : pour un forum, « Post » = a écrit un message ; pour un devoir, « Post » = a soumis ; pour une ressource (fichier, page), il n’existe que « View » — une ressource ne se « poste » pas. Si vous sélectionnez « Post » sur une ressource, le rapport sera vide et vous croirez à un bug. Vérifiez aussi la période : « depuis le début du cours » utilise la date de début définie dans les paramètres du cours, pas la date de création.

7.2.5 Achèvement d’activités (Activity completion report) : la matrice de progression

Chemin : Cours → Rapports → Achèvement d’activités (plugin report_progress). Visible seulement si l’achèvement d’activité est activé au niveau du site et du cours (chapitre sur la configuration des cours).

C’est la fameuse matrice étudiants × activités : une ligne par étudiant, une colonne par activité à suivi d’achèvement, et à chaque intersection une case — vide (non achevé), cochée en trait plein (achevé automatiquement selon les conditions), cochée manuellement par l’étudiant, ou marquée par l’enseignant. Des filtres permettent de restreindre par nom, prénom, ou par type d’activité, et de choisir l’ordre des activités.

L’enseignant disposant des droits peut surcharger un état d’achèvement en cliquant sur la case (utile quand un étudiant a validé « hors plateforme »). Deux boutons d’export en bas : « Télécharger au format tableur (UTF-8 .csv) » et « Télécharger au format Excel » — le CSV exporté contient les états et horodatages, parfait pour un suivi de cohorte dans un tableur.

⚠️ Piège : ce rapport n’affiche que les activités dont le suivi d’achèvement est configuré. Si un enseignant crée ses activités sans conditions d’achèvement (ou avec le suivi désactivé par défaut dans les préférences du cours), la matrice est vide ou trompeuse. La qualité de ce rapport se joue à la conception du cours, pas au moment de le consulter — un point à marteler dans vos formations d’enseignants.

7.2.6 Achèvement de cours (Course completion)

Chemin : Cours → Rapports → Achèvement de cours (plugin report_completion). Nécessite que l’achèvement de cours soit activé et que des critères soient définis (activités requises, note, durée d’inscription, validation manuelle par un rôle, auto-validation…).

Le rapport liste les étudiants avec une colonne par critère d’achèvement du cours (et non par activité), plus les colonnes d’approbation manuelle si des rôles doivent valider, et la colonne finale « Cours achevé ». Les enseignants habilités cochent directement les validations manuelles dans le rapport. Export CSV/Excel identique au rapport précédent.

La différence conceptuelle avec le rapport d’achèvement d’activités : ici on suit l’atteinte des critères de complétion du cours entier (qui peuvent n’inclure que 3 activités clés sur 40), là-bas on suivait chaque activité individuellement.

7.2.7 Statistiques de cours (si activées)

Chemin : Cours → Rapports → Statistiques — visible uniquement si les statistiques legacy sont activées au niveau du site (voir section 7.6). Affiche des graphiques d’activité (vues et contributions) par rôle et par période pour ce cours. Nous détaillerons les limites de ce sous-système plus bas ; retenez qu’il est désactivé par défaut.

7.2.8 Les rapports du profil utilisateur

Depuis la page de profil d’un utilisateur (accédée depuis la liste des participants d’un cours pour un périmètre cours, ou globalement pour un admin), la section Rapports propose :

• Journaux d’aujourd’hui (Today’s logs) : les événements du jour de cet utilisateur, accompagnés d’un graphique de répartition horaire — idéal pour vérifier une affirmation du type « j’ai passé la matinée sur le quiz » ;
• Tous les journaux (All logs) : l’historique complet (dans la limite de rétention) ;
• Rapport résumé (Outline report) : pour chaque section du cours, la liste des activités avec nombre de consultations, note obtenue le cas échéant et date de dernier accès — la vue « parcours de l’étudiant » la plus lisible pour un entretien pédagogique ;
• Rapport complet (Complete report) : la même chose en version détaillée, présentée comme la page du cours annotée avec les données de l’étudiant (soumissions de devoirs, messages de forum…) ;
• Sessions de navigateur : les sessions actives de l’utilisateur (avec possibilité de déconnexion à distance) ;
• Aperçu des notes (Grades overview) : ses notes dans tous ses cours.

💡 Pour un dev React : les rapports Outline/Complete sont des vues dérivées : mêmes données (logs + notes + soumissions), projections différentes. C’est le pattern « une source, plusieurs sélecteurs » — comme plusieurs composants qui consomment le même store avec des sélecteurs différents. Moodle ne stocke pas « le rapport » ; il le recalcule à chaque affichage.

📚 Aller plus loin : si l’établissement veut donner aux étudiants un tableau de bord de leur propre progression, regardez le bloc « Achèvement de cours », la barre de progression des activités sur la page de cours (native depuis Moodle 4.0), et des plugins comme Completion Progress. Les rapports décrits ici restent des outils d’enseignant.

7.3 Les rapports natifs au niveau du site

Chemin général : Administration du site → Rapports. Passons en revue les entrées les plus utiles pour un administrateur.

7.3.1 Journaux et journaux en direct du site

Mêmes moteurs qu’au niveau cours (sections 7.2.1 et 7.2.2), mais avec un filtre supplémentaire : le cours (ou « Site » pour les événements hors cours : connexions, administration…). C’est ici que vous enquêtez sur les questions transverses : « qui s’est connecté cette nuit ? », « qui a modifié ce réglage d’administration ? », « d’où viennent ces échecs de connexion ? ». Les échecs de connexion disposent d’ailleurs d’un affichage dédié si vous avez activé la notification correspondante (chapitre 5).

Le rapport « Comptes rendus d’événements » — la liste des événements — mérite une mention : dans Administration du site → Rapports → Liste des événements (Events list), Moodle expose le catalogue complet de tous les événements que le système sait émettre (plusieurs centaines : \mod_quiz\event\attempt_submitted, \core\event\user_loggedin…), avec leur composant, leur niveau éducatif et les objets affectés. Ce n’est pas un rapport de données mais un référentiel : consultez-le avant de créer une règle de surveillance (7.3.6) ou un rapport de logs pointu, pour connaître le nom exact de l’événement à cibler.

7.3.2 Rapport de sauvegardes (Backups)

Chemin : Administration du site → Rapports → Sauvegardes.

Ce rapport liste l’exécution des sauvegardes automatiques de cours (configurées dans Administration du site → Cours → Sauvegardes → Configuration de la sauvegarde automatique) : pour chaque cours, l’heure de la dernière exécution, la prochaine planifiée et le statut — OK, Ignorée (cours inchangé), Erreur, Non terminée. Un tableau de synthèse en tête compte les succès et les échecs.

⚠️ Piège : ce rapport ne couvre que les sauvegardes automatiques de cours, pas les sauvegardes de la base de données ou du moodledata (qui relèvent de votre infrastructure, chapitre 5). Un rapport tout vert ici ne signifie pas que votre plan de reprise est sain — il signifie que les archives .mbz de cours se génèrent. Et surveillez les statuts « Non terminée » récurrents : ils signalent souvent un cours énorme qui fait exploser le temps ou la mémoire du cron.

7.3.3 Instances de questions (Question instances)

Chemin : Administration du site → Rapports → Instances de questions.

Un rapport d’apparence modeste mais précieux avant une migration ou un nettoyage : pour un type de question donné (choix multiple, appariement, type tiers…), il liste les contextes (cours, catégories) qui contiennent des questions de ce type, avec leur nombre. Cas d’usage : « puis-je désinstaller ce plugin de type de question tiers ? » — si le rapport montre 4 000 questions « Drag and drop » dans 60 cours, la réponse est non, pas sans plan de conversion.

7.3.4 Sécurité et performance : renvoi au chapitre 5

Sous Rapports figurent aussi Vérifications de sécurité (Security checks) et Aperçu de la performance (Performance overview) : des check-lists automatiques (HTTPS, exécutabilité de moodledata, mots de passe, mode développeur, cache, thème designer mode…) avec statut OK/Warning/Critical. Nous les avons détaillées au chapitre 5 (sécurité et maintenance) ; retenez simplement qu’elles habitent ici, dans le menu Rapports, et qu’une revue mensuelle est une bonne hygiène.

7.3.5 Aperçu des cours et statistiques de site

Le rapport « Aperçu des cours » (Course overview), disponible quand les statistiques legacy sont activées, affiche des palmarès : les N cours les plus actifs, les plus participatifs (ratio contributions/vues), les plus fréquentés. Utile pour un comité de pilotage… si les statistiques tournent (section 7.6). Sans elles, l’entrée n’apparaît pas ou reste vide.

7.3.6 Surveillance des événements (Event monitoring, tool_monitor)

Chemin : Administration du site → Rapports → Règles de surveillance des événements. La fonctionnalité doit d’abord être activée (un lien/réglage « Enable event monitoring » sur cette même page, réglage tool_monitor | enablemonitor).

Le principe : définir des règles du type « si l’événement X se produit N fois en Y minutes dans tel contexte, notifier les abonnés ». Une règle comporte :

• le contexte d’application (tout le site ou un cours) ;
• le composant source (cœur, un module d’activité…) et l’événement précis à surveiller (choisi dans le catalogue vu en 7.3.1) ;
• un seuil : nombre d’occurrences et fenêtre temporelle (« 5 fois en 10 minutes ») ;
• un message de notification avec des variables ({modulename}, {rulename}…).

Ensuite, chaque utilisateur y ayant droit (capability tool/monitor:subscribe) peut s’abonner à une règle depuis ses préférences (Préférences → « Abonnements aux règles de surveillance »), pour le site ou pour un cours donné. À chaque déclenchement, il reçoit une notification (web/mobile/email selon ses préférences de notification).

Exemples de règles réellement utiles : « suppression d’un cours » (alerter l’équipe admin), « tentative de quiz supprimée », « plus de 20 échecs de connexion en 5 minutes sur un compte », « un enseignant désinscrit un utilisateur ». C’est votre système d’alerting natif — rudimentaire mais fiable, car exécuté par le cron.

💡 Pour un dev React : Event monitoring = des webhooks internes avec throttling. La règle est un subscribe(eventName, {threshold, window}) et la notification est le callback. La limitation, c’est que le « callback » ne peut être qu’une notification à des humains — pas d’appel HTTP sortant ni d’action automatique. Pour du vrai webhook sortant, il faudra un plugin (partie développeur : les event observers).

⚠️ Piège : les règles de surveillance s’évaluent via les tâches planifiées (cron). Si votre cron est en panne ou espacé, les notifications arrivent en retard — ou par paquets. Et une règle trop bavarde (« consultation de cours, seuil 1 ») noiera vos admins sous les notifications au point qu’ils désactiveront tout. Réservez la surveillance aux événements rares et significatifs.

7.3.7 Insights : la porte d’entrée des analytics

L’entrée Insights du menu Rapports n’apparaît que lorsque des modèles d’analytique sont activés et ont produit des prédictions ; elle liste alors les aperçus générés (étudiants à risque, cours sans activité enseignante…). Nous y consacrons la section 7.5.

7.4 Le Report Builder : vos rapports sur mesure (section majeure)

7.4.1 Histoire et positionnement

Le Report Builder (générateur de rapports) est né dans Moodle Workplace, la déclinaison entreprise de Moodle, où le reporting RH est vital. Devant son succès, il a été reversé dans le cœur de Moodle LMS en version 4.0 (avril 2022) : d’abord les fondations et les rapports système (les listes d’administration comme la liste des utilisateurs sont elles-mêmes des rapports Report Builder), puis les rapports personnalisés (custom reports) avec éditeur graphique, audiences et planification. Chaque version 4.x puis 5.x a enrichi l’outil : nouvelles sources de données, nouveaux filtres, duplication de rapports, tags, agrégations supplémentaires. En Moodle 5.2, c’est un outil mûr, et c’est la réponse moderne à 80 % des besoins de reporting d’un établissement.

Chemin : Administration du site → Rapports → Générateur de rapports → Rapports personnalisés (Custom reports).

💡 Pour un dev React : le Report Builder est un query builder visuel posé sur des jointures prédéfinies. Une source = un modèle Prisma avec ses relations include déjà câblées ; les colonnes = les champs du select ; les filtres et conditions = le where ; les audiences = la couche d’ACL de partage du dashboard ; la planification = un cron d’envoi d’email avec le rendu attaché. Vous ne pouvez pas écrire de SQL libre — exactement comme un utilisateur de Metabase en mode « question simple » ne peut requêter que les modèles exposés.

7.4.2 Créer un rapport pas à pas : la source

Cliquez sur « Nouveau rapport ». Une fenêtre modale demande :

1. le Nom du rapport ;
2. la Source (Report source) : le jeu de données de départ ;
3. l’option « Inclure les colonnes par défaut » (pré-remplit le rapport avec les colonnes typiques de la source — laissez-la cochée pour démarrer) ;
4. éventuellement des tags pour classer vos rapports (améliorations 4.5+).

La source est le choix structurant : elle détermine l’entité principale et toutes les entités jointes disponibles. Les sources fournies par le cœur (liste enrichie au fil des versions 4.1 → 5.x, l’inventaire exact dépend de votre version et des plugins installés) :

Des plugins bien écrits ajoutent leurs propres sources (certains plugins d’activité, ou des plugins dédiés au reporting) : la liste s’allonge avec votre écosystème.

⚠️ Piège : on ne change pas de source après création. Si vous partez de « Utilisateurs » et réalisez qu’il vous fallait « Participants au cours » (parce que vous voulez une ligne par inscription, pas une ligne par personne), il faut recréer le rapport. Réfléchissez d’abord à la granularité : que représente une ligne ? Un utilisateur ? Une inscription ? Un fichier ? C’est la première question de tout travail de reporting — l’équivalent du choix de la table de faits en BI.

7.4.3 Le mode édition : colonnes

Le rapport s’ouvre dans l’éditeur : à gauche, l’aperçu en direct des données ; à droite, un panneau latéral à trois onglets — Colonnes, Filtres, Tri (et les réglages du rapport via l’icône d’engrenage). Tout est en drag and drop et l’aperçu se met à jour instantanément.

Dans le panneau, un champ de recherche liste toutes les colonnes disponibles, groupées par entité (Utilisateur : nom complet, email, ville, dernier accès… ; Cours : nom complet, catégorie… ; selon la source). Cliquez ou glissez pour ajouter. Pour chaque colonne, le menu contextuel (les trois points ou l’icône crayon) permet de :

• Renommer l’en-tête : cliquez sur le titre de colonne dans l’aperçu et saisissez votre libellé (« Email » au lieu de « Adresse de courriel ») — la mise en forme du rapport final ;
• Réordonner par glisser-déposer ;
• Supprimer la colonne ;
• définir une agrégation par colonne.

Les agrégations disponibles dépendent du type de donnée de la colonne :

Le comportement clé à comprendre : dès qu’au moins une colonne porte une agrégation, le rapport regroupe les lignes sur les colonnes non agrégées. Exemple avec la source « Participants au cours » : colonnes « Nom complet du cours » + « Nom complet de l’utilisateur » avec agrégation Count → vous obtenez une ligne par cours avec le nombre d’inscrits. Retirez l’agrégation → retour au détail ligne à ligne. C’est un GROUP BY implicite.

💡 Pour un dev React : colonnes = les props de votre composant de tableau, agrégation = un groupBy + reduce appliqué côté serveur. Le fait que l’ajout d’une agrégation change la granularité de TOUTES les lignes est le même mécanisme qu’en SQL : toute colonne non agrégée devient une clé de regroupement. Si le résultat vous surprend, demandez-vous « quelles sont mes clés de GROUP BY ? ».

7.4.4 Filtres vs conditions : la distinction fondamentale

C’est LE point que tout le monde confond au début, donc prenons le temps.

• Les conditions (Conditions, dans les réglages du rapport, icône engrenage → section Conditions) sont définies par le créateur du rapport, appliquées toujours, et invisibles pour le lecteur final. Elles font partie de la définition du rapport. Exemple : condition « Utilisateur suspendu = Non » et « Cohorte = Promotion 2026 » — le rapport ne contiendra jamais autre chose, et le lecteur ne peut pas les enlever.
• Les filtres (Filters, onglet Filtres du panneau) sont des contrôles interactifs offerts au lecteur : quand un utilisateur consulte le rapport, un bouton « Filtres » ouvre un panneau où il peut restreindre les données (par nom, date, cours…) selon les filtres que VOUS avez choisi d’exposer. Les valeurs saisies par chaque lecteur lui sont personnelles (mémorisées pour lui) et n’altèrent pas le rapport des autres.

La règle d’or : tout ce qui relève de la confidentialité ou du périmètre doit être une condition, jamais un filtre. Un filtre « Cohorte = Promo 2026 » peut être retiré par le lecteur, qui verra alors les autres promos.

⚠️ Piège : le piège exact que cette règle prévient — vous créez un rapport « emails des étudiants de la formation X » pour un responsable de formation, en mettant la formation en filtre au lieu de condition. Le responsable vide le filtre et récupère les emails de tout l’établissement. Faites l’exercice systématiquement : « si le lecteur enlève tous les filtres, que voit-il ? ». La réponse doit rester acceptable.

💡 Pour un dev React : conditions = le where codé en dur dans votre requête serveur ; filtres = les search params que l’UI expose (?cohort=2026) et que l’utilisateur peut manipuler. Vous ne mettriez jamais un contrôle d’accès dans un query param modifiable côté client ; même réflexe ici.

7.4.5 Tri, limite de lignes et réglages de présentation

• Tri par défaut : onglet Tri du panneau — activez le tri sur une ou plusieurs colonnes visibles, ordre croissant/décroissant, et priorisez-les par glisser-déposer. Le lecteur pourra ensuite cliquer sur les en-têtes pour re-trier, mais votre tri définit l’état initial.
• Limite de lignes : dans les réglages (engrenage), vous pouvez plafonner le nombre de lignes retournées — utile pour les palmarès (« top 50 des plus gros fichiers ») et pour protéger la base contre un rapport-fleuve.
• Renommage des en-têtes (vu en 7.4.3) et ordre des colonnes constituent la mise en forme ; le rendu (tableau paginé, tri cliquable) est standardisé — pas de graphiques natifs dans les rapports personnalisés du cœur à ce stade.
• L’aperçu de l’éditeur se limite volontairement à un échantillon ; le bouton « Afficher/masquer l’aperçu » et la sortie de l’éditeur (« Fermer l’éditeur ») montrent le rendu lecteur.

Une fois satisfait, votre rapport apparaît dans la liste des rapports personnalisés avec son nom, sa source, ses tags, son créateur et sa date de modification. Le menu d’actions par rapport permet de modifier, prévisualiser, dupliquer (pratique pour décliner un rapport par département — amélioration arrivée dans les versions 4.x), supprimer, et de gérer audiences et planifications — nos deux prochaines sections.

7.4.6 Audiences : qui peut voir le rapport

Par défaut, un rapport personnalisé n’est visible que de ses éditeurs. Pour le partager en lecture, ouvrez le rapport → onglet Audience. Une audience est un critère d’appartenance ; les types fournis par le cœur :

Vous pouvez ajouter plusieurs audiences au même rapport : elles se combinent en OU logique — il suffit d’appartenir à au moins une audience pour voir le rapport. Il n’existe pas de combinaison en ET (« membres de la cohorte X et ayant le rôle Y ») : si vous avez ce besoin, créez une cohorte dédiée en amont.

Côté lecteur, l’expérience est la suivante : tout utilisateur (avec moodle/reportbuilder:view, attribuée par défaut aux utilisateurs authentifiés) dispose d’une page « Rapports » listant les rapports auxquels ses audiences lui donnent accès. Elle est accessible via le menu utilisateur / la navigation (page /reportbuilder/index.php, la « Reports view list »). Le lecteur ouvre le rapport, joue avec les filtres exposés, trie, et télécharge la table (CSV, Excel, ODS, JSON, HTML, PDF) si l’export est permis.

Les audiences ont un second rôle, moins évident : elles définissent les destinataires possibles des planifications (section suivante).

💡 Pour un dev React : les audiences sont littéralement la boîte de dialogue « Partager » d’un Google Doc : des règles d’accès additives (OU), évaluées à la volée à chaque affichage — pas une copie du rapport par audience. Ajouter quelqu’un à la cohorte revient à l’ajouter au partage, sans toucher au rapport. C’est de l’ACL déclarative, pas de la duplication.

⚠️ Piège : l’audience « Tous les utilisateurs avec la capability » évalue la capability dans le contexte système. Un enseignant qui a report/log:view dans ses cours ne matche PAS une audience basée sur cette capability au niveau système. Pour cibler « tous les enseignants », la bonne pratique est une cohorte « Enseignants » alimentée (manuellement, par upload, ou par plugin de synchro), pas une capability de cours.

7.4.7 Planification (Schedules) : le rapport qui arrive tout seul

L’onglet Planifications (Schedules) d’un rapport automatise son envoi par email. Une planification définit :

• Nom de la planification ;
• Format du fichier joint : CSV, Excel (.xlsx), ODS, PDF, HTML — l’éventail exact a été complété au fil des versions 4.x ;
• Date/heure de début et récurrence : quotidienne, hebdomadaire, mensuelle, toutes les X heures/jours… ;
• Destinataires : les audiences du rapport (vous cochez celles à servir) et/ou des utilisateurs additionnels ;
• Sujet et corps du message de l’email ;
• l’option décisive : « Voir le rapport en tant que » (View report data as) — avec trois valeurs possibles : Créateur de la planification, Destinataire, ou Utilisateur choisi ;
• le comportement si le rapport est vide (envoyer quand même avec pièce jointe vide, ou ne pas envoyer).

L’envoi est exécuté par une tâche planifiée du cron, à l’heure dite dans le fuseau horaire configuré pour la planification — vérifiez ce point si vos destinataires sont multi-fuseaux : « tous les lundis 7h » s’entend dans le fuseau de la planification, pas celui de chaque destinataire.

L’option « Voir le rapport en tant que » mérite un arrêt complet. Si le rapport contient des données dont la visibilité dépend du lecteur, deux stratégies s’opposent :

• En tant que destinataire : chaque destinataire reçoit les données telles qu’il aurait le droit de les voir — plus sûr, mais chaque email peut différer ;
• En tant que créateur (ou utilisateur choisi) : tout le monde reçoit la même photographie, celle du créateur — cohérent, mais…

⚠️ Piège : … c’est le piège de confidentialité le plus sérieux du Report Builder. Une planification « en tant que créateur » envoyée à une audience large expédie par email des données que le créateur (souvent un admin, qui voit tout) est seul censé voir. L’email, lui, ne vérifie aucune permission : la pièce jointe part telle quelle, et un CSV transféré ne se « départage » pas. Règle maison recommandée : audiences larges ⇒ « voir en tant que destinataire » ; « en tant que créateur » réservé aux planifications vers un cercle restreint et habilité (direction, DPO). Documentez ce choix dans votre registre de traitements RGPD (chapitre 3).

7.4.8 Permissions et délégation : ouvrir le Report Builder sans ouvrir les vannes

Par défaut, seuls les administrateurs et les gestionnaires (via moodle/reportbuilder:editall) créent des rapports. Pour déléguer :

• attribuez moodle/reportbuilder:edit à un rôle système (par exemple un rôle « Analyste » créé sur mesure, chapitre 6) : ses détenteurs créent et gèrent leurs propres rapports, sans toucher à ceux des autres ;
• moodle/reportbuilder:editall donne la main sur tous les rapports — à réserver ;
• moodle/reportbuilder:viewall permet de consulter tous les rapports sans passer par les audiences (profil auditeur/DPO) ;
• le réglage customreportslimit (Administration du site → Rapports → Générateur de rapports → Paramètres) plafonne le nombre de rapports personnalisés par créateur (0 = illimité) — un garde-fou utile quand on délègue, car chaque rapport est une requête potentiellement lourde sur la base de production.
• au même endroit, « Live editing » (customreportsliveediting) contrôle si l’aperçu de l’éditeur se rafraîchit à chaque modification ; le désactiver soulage la base sur les très grosses instances.

N’oubliez pas que les personnes recevant reportbuilder:edit voient, via les sources, des données personnelles à l’échelle du site (une source « Utilisateurs » expose tous les comptes). La délégation du Report Builder est une décision de gouvernance, pas un simple clic.

7.4.9 Les limites du Report Builder core, et les alternatives

Soyons honnêtes sur ce que l’outil ne fait pas :

• Pas de SQL libre : vous êtes borné aux sources existantes et à leurs jointures. Impossible de croiser « tentatives de quiz » et « champs de profil » si aucune source ne propose cette jointure ;
• Pas de graphiques dans les rapports personnalisés (tableaux uniquement) ;
• Pas de jointures personnalisées ni de colonnes calculées par formule (au-delà des agrégations fournies) ;
• Granularité imposée par la source.

Les alternatives, par ordre croissant d’engagement :

1. Plugin report_customsql (Ad-hoc database queries, maintenu par The Open University) : écrire des requêtes SQL en lecture seule dans l’interface, avec paramètres, planification d’envoi et catégories de rapports. Puissance maximale, mais exige de connaître le schéma de la base et une discipline stricte (requêtes revues, LIMIT, index) — un SELECT mal écrit peut mettre la production à genoux ;
2. Plugin Configurable Reports (block_configurable_reports) : historique, très répandu, combine rapports SQL, rapports de cours/utilisateurs assistés et graphiques simples ; vérifiez sa compatibilité avec votre version 5.x avant d’y investir ;
3. Export vers un entrepôt externe : la voie BI sérieuse (section 7.7) ;
4. Créer vos propres sources Report Builder en PHP : la voie royale et pérenne — chaque source que vous développez profite de toute la machinerie (éditeur, audiences, planification). C’est l’objet d’un chapitre de la partie développeur.

📚 Aller plus loin : la documentation développeur du Report Builder sur moodledev.io (« Report builder API ») explique le modèle interne — entités, colonnes, filtres, jointures — et vaut la lecture même pour un profil fonctionnel avancé : elle éclaire pourquoi l’interface propose telles colonnes pour telle source. Gardez-la sous le coude pour la partie développeur de cette formation.

💡 Pour un dev React : la stratégie « source custom Report Builder plutôt que SQL ad hoc » est l’équivalent de « écrire un resolver GraphQL propre plutôt que d’exposer un endpoint SQL brut » : plus de travail initial, mais typé, réutilisable, sécurisé par construction, et tous les outils existants (audiences, exports, planifications) fonctionnent dessus gratuitement.

7.5 Learning Analytics : la couche prédictive native

7.5.1 Le concept

Chemin : Administration du site → Analytique (Analytics) → Modèles.

Là où les rapports décrivent le passé, l’analytique d’apprentissage de Moodle tente de prédire l’avenir : le système fournit des modèles (models) qui combinent une cible (target — ce qu’on veut prédire, ex. « l’étudiant risque d’abandonner ») et des indicateurs (indicators — les signaux calculés : fréquence de connexion, activité dans les forums, remises de devoirs, clics par rapport à la moyenne du cours…). Un backend de machine learning apprend sur les données historiques, puis produit des prédictions sur les cours en cours ; celles-ci sont livrées sous forme d’insights (aperçus) notifiés aux enseignants.

Les modèles fournis en standard :

Les modèles « statiques » sont de simples règles déterministes (pas d’apprentissage) ; le modèle phare, « étudiants à risque », est le seul véritablement prédictif.

7.5.2 Fonctionnement : entraînement, prédiction, insights

Le cycle de vie du modèle prédictif :

1. Activation : sur la page Modèles, chaque modèle a un interrupteur et un menu Actions (Modifier — pour choisir les indicateurs et l’horizon d’analyse —, Activer, Exporter, Journal d’évaluation) ;
2. Entraînement (training) : une tâche planifiée parcourt les cours terminés du site (il faut des dates de début ET de fin de cours fiables !) et apprend la corrélation entre indicateurs et résultat réel (a terminé / a abandonné) ;
3. Prédiction : la même machinerie évalue les cours en cours et calcule un score de risque par étudiant ;
4. Insights : les enseignants des cours concernés reçoivent une notification ; la page Insights liste les étudiants signalés, avec pour chacun les indicateurs qui pèsent dans la prédiction et des actions directes — envoyer un message à l’étudiant, voir son rapport résumé, marquer l’insight comme utile/inutile (acknowledge), ce retour servant à évaluer le modèle.

Le calcul est assuré par un backend ML configurable (Administration du site → Analytique → Réglages) : par défaut le backend PHP (aucune dépendance, mais lent et limité), ou le backend Python (paquet moodlemlbackend installé sur le serveur ou via Docker, s’appuyant sur TensorFlow/scikit-learn) — plus précis et plus rapide, recommandé dès que vous êtes sérieux sur le sujet. Le tout tourne via des tâches planifiées potentiellement très longues, à cantonner aux heures creuses.

7.5.3 Les limites, honnêtement

Il faut être franc : les Learning Analytics natifs sont peu utilisés en production, pour des raisons structurelles :

• Faim de données : le modèle apprend sur vos cours terminés et correctement datés. Un site jeune, ou dont les cours n’ont pas de dates de fin, ou dont les usages varient énormément d’un cours à l’autre, ne fournit pas un signal exploitable. Comptez plusieurs semestres de données homogènes avant des prédictions crédibles ;
• Qualité avant quantité : si vos enseignants n’utilisent Moodle que comme dépôt de PDF, les indicateurs d’engagement ne mesurent rien de pédagogique ; le modèle prédit alors surtout « qui ouvre les PDF » ;
• Coût opérationnel : backend Python à maintenir, tâches lourdes, réentraînements ;
• Enjeux éthiques et RGPD : profiler des étudiants « à risque » est un traitement de données à part entière — information des personnes, base légale, garde-fous contre les décisions automatisées (chapitre 3). Un insight doit déclencher un accompagnement humain, jamais une sanction.

En pratique, beaucoup d’établissements obtiennent 80 % de la valeur avec 5 % de l’effort via… le rapport de participation et la relance groupée (7.2.4), ou un rapport Report Builder planifié « étudiants sans accès depuis 14 jours ».

⚠️ Piège : activer le modèle « Students at risk » sur un site sans historique suffisant produit soit aucune prédiction, soit — pire — des prédictions arbitraires que les enseignants prendront au sérieux. Consultez systématiquement le journal d’évaluation du modèle (score de précision, recall) avant de laisser les insights partir vers les enseignants. Un modèle non évalué est un générateur de rumeurs.

💡 Pour un dev React : l’architecture indicateurs → cible → backend ML est un pipeline de feature engineering tout à fait classique : les indicateurs sont vos features normalisées entre -1 et 1, la cible est le label, l’« analysable » (le cours) est l’unité d’échantillonnage, et le backend Python est un service d’entraînement/inférence appelé par le job runner. Si vous avez déjà branché un scikit-learn derrière une API, vous pouvez lire le code de \core_analytics sans vertige — ce sera utile en partie développeur, où l’on peut écrire ses propres indicateurs.

7.5.4 Brickfield : l’accessibilité aussi a ses rapports

Mention obligatoire dans le paysage analytique : le Brickfield Accessibility Toolkit (starter kit intégré au cœur depuis Moodle 3.11, Administration du site → Plugins → Outils d’administration → Accessibilité, puis activation par cours). Il analyse le contenu des cours (HTML des étiquettes, pages, descriptions…) au regard de règles d’accessibilité (contrastes, images sans attribut alternatif, structure des titres, liens vides, tableaux sans en-têtes…) et produit des rapports d’erreurs par cours : synthèse par type d’erreur, liste des activités fautives, carte de chaleur. La version « starter » intégrée est limitée en volume de cours analysés et en fonctions de correction ; la version complète est un service commercial. Ce n’est pas de l’analytique d’apprentissage, mais c’est le même réflexe : instrumenter la plateforme pour objectiver la qualité.

📚 Aller plus loin : la documentation « Analytics » sur docs.moodle.org détaille chaque indicateur du modèle de risque d’abandon, et moodledev.io documente l’« Analytics API » pour créer modèles et indicateurs personnalisés. Sur Brickfield, la page « Accessibility toolkit » de docs.moodle.org décrit l’activation et l’interprétation des rapports — à croiser avec vos obligations RGAA/EN 301 549 si vous êtes un établissement public français.

7.6 Les statistiques legacy : l’ancêtre encore debout

Chemin d’activation : Administration du site → onglet Serveur (les versions récentes l’ont rangé là, historiquement sous « Avancé ») → Statistiques, réglage enablestats (« Activer les statistiques »), accompagné de réglages fins : période maximale de traitement par nuit, heure d’exécution, durée de rétention des données agrégées.

Le principe date des débuts de Moodle : chaque nuit, une tâche parcourt les logs et agrège l’activité (nombre de vues et de contributions) par cours, par rôle et par période (jour, semaine, mois) dans des tables dédiées (mdl_stats_daily, mdl_stats_weekly, mdl_stats_monthly et leurs variantes par utilisateur). Ces agrégats alimentent :

• le rapport Statistiques de chaque cours (graphique d’activité, tableaux par rôle) ;
• le rapport de site Aperçu des cours (palmarès des cours les plus actifs, vu en 7.3.5) ;
• des graphiques d’activité sur les profils.

Pourquoi ce système est-il désactivé par défaut et en voie de marginalisation ?

• le traitement nocturne est lourd : la première exécution doit rattraper tout l’historique de logs et peut tourner des nuits entières sur un gros site, en chargeant la base ;
• la granularité (vues/contributions par rôle) est pauvre comparée à ce qu’un rapport Report Builder ou un outil externe peut produire ;
• il fait double emploi avec les logs, qu’il relit pour produire moins d’information.

Recommandation pragmatique : ne l’activez que si quelqu’un demande précisément les graphiques qu’il produit (typiquement le rapport « Aperçu des cours » pour un comité). Sinon, couvrez le besoin avec le Report Builder, et gardez vos nuits de cron pour les sauvegardes et l’analytique.

⚠️ Piège : si vous activez les statistiques sur un site avec deux ans de logs, réglez impérativement « Période maximale de traitement » sur une valeur courte (une journée de logs par nuit, par exemple) : sinon la première nuit de rattrapage peut chevaucher les heures ouvrées et dégrader la production. Et souvenez-vous que les statistiques ne remontent jamais plus loin que vos logs conservés : rétention de logs de 90 jours = statistiques initiales limitées à 90 jours d’historique.

7.7 Stratégie de reporting d’établissement

Terminons en prenant de la hauteur : vous disposez maintenant de six outils (logs, rapports de cours, rapports de site, Report Builder, analytics, statistiques). Le travail d’un bon administrateur n’est pas de tous les utiliser, mais de router chaque besoin vers le bon outil.

7.7.1 Le tableau décisionnel

💡 Pour un dev React : ce tableau, c’est votre arbre de décision « useState vs Zustand vs React Query vs base de données » transposé au reporting : le réflexe de junior est de tout faire avec l’outil le plus puissant (ici, tout basculer en SQL ou tout exporter en BI) ; le réflexe d’expert est de résoudre chaque besoin avec l’outil le plus simple qui suffit. Un rapport de participation natif qui répond en deux clics bat un dashboard Superset qu’il faut maintenir.

7.7.2 Gouvernance : RGPD, minimisation, rétention

Le reporting est l’endroit où la tentation de « tout garder, tout voir » se heurte au droit. Rappels opérationnels (les fondements ont été posés aux chapitres 3 et 5) :

• Minimisation : chaque rapport personnalisé doit servir une finalité déclarée. Un rapport « tous les utilisateurs avec email, ville, dernier accès » diffusé à une audience large est une collecte excessive déguisée en commodité. Colonnes minimales, conditions restrictives, audiences étroites ;
• Rétention des logs : la durée de conservation du log store standard (loglifetime) est un réglage RGPD autant que technique. Alignez-la sur votre registre de traitements (souvent 6 à 12 mois pour les logs pédagogiques) — et acceptez la conséquence : les rapports fondés sur les logs deviennent amnésiques au-delà. Si le pilotage exige des séries longues, la réponse est l’agrégation anonymisée exportée vers l’entrepôt, pas l’allongement infini de la rétention nominative ;
• Planifications : inventoriez-les (qui reçoit quoi, à quelle fréquence, « en tant que » qui) et revoyez-les à chaque départ ou changement de fonction — un email planifié survit volontiers à la légitimité de son destinataire ;
• Exports : chaque bouton « Télécharger » crée une copie hors de tout contrôle d’accès Moodle. Sensibilisez les destinataires : un CSV d’étudiants sur un poste personnel est une violation en puissance ;
• Analytics : profilage ⇒ information des personnes concernées et intervention humaine dans la boucle.

⚠️ Piège : la fuite de données la plus fréquente d’un Moodle ne vient ni d’un pirate ni d’une faille : c’est un rapport planifié oublié, envoyé chaque lundi « en tant que créateur » à une liste de diffusion qui a grossi avec les années. Mettez la revue trimestrielle des planifications et des audiences dans votre check-list d’exploitation, au même rang que la revue des rôles du chapitre 6.

📚 Aller plus loin : croisez ce chapitre avec l’outil « Confidentialité et politiques » de Moodle (registre des finalités, durées de rétention par contexte, demandes d’export/suppression RGPD) vu au chapitre 3 : les durées que vous y déclarez doivent être cohérentes avec loglifetime, la rétention des statistiques et vos exports BI. La CNIL publie par ailleurs des référentiels sur la gestion des durées de conservation utiles pour arbitrer.

Résumé

Ce chapitre a cartographié tout l’appareil de mesure de Moodle 5.2 :

• Trois niveaux de rapports — site (Administration du site → Rapports), cours (onglet Rapports) et profil utilisateur — chacun borné par son contexte et gouverné par des capabilities (report/xxx:view, moodle/site:viewreports, famille moodle/reportbuilder:*).
• Les rapports de cours natifs couvrent l’essentiel du suivi pédagogique : Logs (événements bruts filtrables et exportables), Live logs (temps réel avec pause), Rapport d’activité (vues par contenu), Participation (matrice action/rôle/période avec relance groupée des non-participants — le rapport le plus actionnable de Moodle), Achèvement d’activités (matrice étudiants × activités, surcharge manuelle, export CSV/Excel) et Achèvement de cours (critères de complétion). Le profil offre journaux du jour, rapports résumé et complet.
• Au niveau site : logs globaux, catalogue des événements, rapport de sauvegardes automatiques, instances de questions, checks de sécurité/performance (chapitre 5), et la surveillance d’événements (tool_monitor) — vos alertes à seuil notifiées par abonnement.
• Le Report Builder (issu de Workplace, dans le cœur depuis 4.0, mûri en 4.x/5.x) est l’outil central : choisir une source (la granularité !), composer colonnes (avec agrégations count/sum/average/percent/group concat déclenchant un regroupement implicite), distinguer religieusement conditions (figées, invisibles, sécurité) et filtres (interactifs, contournables, confort), régler tri et limites, puis partager via des audiences combinées en OU (capability système, rôle système, cohorte, liste manuelle, admins) et automatiser via des planifications (format, fréquence, fuseau, et le choix critique « voir en tant que créateur/destinataire »). Permissions : edit vs editall vs viewall, plafond customreportslimit. Limites assumées : pas de SQL libre ni de graphiques — alternatives : report_customsql, Configurable Reports, entrepôt externe, ou sources custom (partie développeur).
• Learning Analytics : modèles natifs (« Students at risk of dropping out », no teaching, échéances proches), pipeline indicateurs → prédictions (backend PHP ou Python ML) → insights notifiés aux enseignants avec actions ; exigeants en données historiques datées, à évaluer avant d’y croire, et encadrés éthiquement. Brickfield complète le tableau côté accessibilité des contenus.
• Statistiques legacy (enablestats) : agrégats nocturnes vues/contributions par cours et rôle — lourdes, pauvres, désactivées par défaut, largement supplantées par le Report Builder.
• Stratégie : router chaque besoin vers l’outil minimal suffisant (logs pour le ponctuel, participation/complétion pour le pédagogique, Report Builder planifié pour le pilotage, entrepôt externe pour la BI), et gouverner l’ensemble — minimisation des colonnes, audiences étroites, rétention des logs alignée sur le registre RGPD, revue périodique des planifications.

Fin de la Partie 2

Avec ce septième chapitre s’achève la Partie 2 — Administration de la plateforme. Vous savez désormais installer, configurer, sécuriser, structurer les utilisateurs et les rôles, exploiter au quotidien et mesurer votre Moodle. Votre plateforme est une coquille solide, gouvernée et observable — mais une coquille encore vide.

La Partie 3 change de casquette : de l’administrateur, nous passons à l’ingénieur pédagogique. Au programme : la création et la gestion de cours — architecture des catégories et formats de cours, sections et activités, inscriptions et groupes en situation réelle, ressources et activités clés (devoir, quiz et sa banque de questions, forum, H5P), conditions d’accès et d’achèvement (celles-là mêmes qui alimentent les rapports de ce chapitre), notes et carnet de notes, sauvegarde/restauration et réutilisation de cours. Vous verrez que tout ce que vous venez d’apprendre sur le reporting prendra une autre dimension une fois que vous saurez concevoir les cours qui produisent ces données. Rendez-vous au chapitre 8.