Partie 2 — Administration, rôles et permissions

Documentation Moodle 5.2 pour développeur web — Partie 2 sur N. Public : développeur expérimenté (Next.js / React / TypeScript) débutant totalement sur Moodle. Version de référence : Moodle 5.2 (avril 2026, PHP 8.3+, Bootstrap 5). Angle de cette partie : fonctionnel — tout se fait via l’interface d’administration. Le code (PHP, plugins, API) viendra dans les parties développeur.

Pourquoi cette partie est cruciale

Si vous venez du monde Next.js, vous avez l’habitude de systèmes d’autorisation que vous construisez vous-même : un middleware qui lit un JWT, quelques rôles (admin, user), peut-être une bibliothèque type CASL ou des policies maison. Moodle, lui, embarque un des systèmes RBAC contextuels les plus riches du monde open source : des centaines de capabilities, une hiérarchie de contextes à six niveaux, des overrides locaux, des rôles assignables n’importe où dans l’arbre.

Impossible de développer sérieusement pour Moodle — ni même de comprendre pourquoi « le bouton n’apparaît pas pour cet utilisateur » — sans maîtriser ce modèle. C’est l’objet de cette partie : après l’avoir lue, vous saurez administrer un site Moodle complet (utilisateurs, authentification, inscriptions, réglages, cron, notes, rapports) et vous aurez le socle conceptuel indispensable pour les parties développement.

Ordre de lecture recommandé : linéaire. Les chapitres 1 et 2 sont les fondations théoriques ; les chapitres 3 à 5 couvrent l’exploitation quotidienne ; les chapitres 6 et 7 les fonctionnalités pédagogiques transverses (évaluation, reporting).

Sommaire des chapitres

Chapitre 1 — Contextes, rôles et capabilities

LE chapitre fondamental de tout Moodle. Le modèle de permissions repose sur trois briques : les contextes (System → Course category → Course → Activity module → Block, plus le contexte User), organisés en arbre avec héritage descendant ; les rôles, qui sont des ensembles de capabilities (capacités) dotées chacune d’une permission (Allow / Prevent / Prohibit / Not set) ; et les assignations de rôles, toujours faites dans un contexte. On y détaille l’algorithme de résolution d’une permission pas à pas (avec trois exemples déroulés), les overrides (dérogations) locaux, et le fameux Prohibit non surchargeable. Schémas ASCII de l’arbre de contextes et du pipeline de décision, analogies ACL/RBAC, React Context et cascade CSS pour le dev web.

À l’issue : vous savez répondre à « pourquoi cet utilisateur peut-il (ou non) faire ceci, ici ? ».

Chapitre 2 — Les rôles standards et les rôles personnalisés

Tour complet des rôles livrés en standard : Manager, Course creator, Teacher, Non-editing teacher, Student, Guest, Authenticated user, Authenticated user on frontpage — et l’indispensable mise au point : l’administrateur n’est PAS un rôle (c’est une liste de comptes qui court-circuitent presque tout le système). Pour chaque rôle : capabilities emblématiques, contexte d’assignation typique, cas d’usage, différences subtiles (Manager vs Admin, Teacher vs Course creator). Puis la pratique : les archétypes, la création pas à pas de rôles personnalisés (deux études de cas complètes : « Inspecteur académique » en lecture seule et « Parent/Mentor » assigné dans le contexte utilisateur), la duplication et l’export de rôles, les matrices « Allow role assignments/overrides/switches », la fonction « Prendre le rôle… » (Switch role to) et ses limites, et les outils de vérification des permissions d’un utilisateur.

À l’issue : vous savez concevoir une politique de rôles propre et auditable pour un établissement.

Chapitre 3 — Gestion des utilisateurs et authentification

Le cycle de vie complet d’un compte (création → confirmation → activité → suspension → suppression) et la distinction clé authentification / inscription / rôle. Revue détaillée des méthodes d’authentification : comptes manuels, auto-inscription par email, LDAP, OAuth 2 (Google, Microsoft — configuration pas à pas des issuers), SAML 2 / SSO (Entra ID, fédérations), CAS, et l’authentification pour web services. Côté opérations : création en masse par CSV (format, options, pièges d’encodage), champs de profil personnalisés, politique de mots de passe, MFA natif (tool_mfa, intégré au core depuis Moodle 4.3 : facteurs TOTP, email, plage IP…), suspension vs suppression, et tout le volet RGPD côté admin : politiques de consentement, registre des données, demandes d’export et d’effacement (data requests), rôle du DPO.

À l’issue : vous savez brancher Moodle sur n’importe quel fournisseur d’identité et industrialiser la gestion des comptes.

Chapitre 4 — Inscriptions (enrolments) et cohortes

L’inscription (enrolment) est le lien utilisateur ↔ cours, distinct du rôle qui l’accompagne. Revue méthode par méthode : manual (à toujours laisser activée), self-enrolment avec clé d’inscription et clé de groupe, guest access (qui n’est pas une vraie inscription), cohort sync, flat file CSV, base de données externe (connexion à un SI scolaire), paiement (enrol_fee + passerelles de paiement — l’ancien enrol_paypal a quitté le core), LTI (publier un cours comme outil pour une autre plateforme), méta-cours (enrol_meta). Puis les cohortes : création, alimentation (manuelle, CSV), différence cohorte vs groupe de cours, usages (sync d’inscription, audiences, restrictions). Enfin la fin de vie : désinscription et sort des données (notes récupérables au ré-enrôlement), durées, expiration et notifications d’expiration, et la vue Participants moderne avec ses filtres combinés.

À l’issue : vous savez choisir la bonne source de vérité des inscriptions et automatiser leur cycle de vie.

Chapitre 5 — Administration du site : réglages, plugins, cron et exploitation

Le tour du propriétaire de la zone « Administration du site » : réglages essentiels post-installation (nom du site, page d’accueil, politiques de site, fuseaux horaires, packs de langue FR et personnalisation des chaînes), gestion des plugins (types, installation depuis le répertoire officiel ou un ZIP, mise à jour, désinstallation propre, critères d’évaluation d’un plugin tiers), et surtout les tâches planifiées et le cron — le système nerveux de Moodle, sans lequel emails, synchronisations et notifications s’arrêtent (scheduled vs adhoc tasks, planification, Run now, logs de tâches, diagnostic d’un cron cassé). Également : mode maintenance (UI et CLI), architecture des notifications/messaging (email SMTP, popup, push mobile via l’app Moodle), logs et logstores (rétention, rapports de logs, live logs), sécurité de base (HTTPS, curl allowed hosts anti-SSRF, IP blocker, rapport de vérifications de sécurité) et environment checks (exigences PHP/BDD de la 5.2). Checklist d’exploitation en clôture.

À l’issue : vous savez faire tourner un Moodle sain en production, au quotidien.

Chapitre 6 — Carnet de notes, badges et compétences

Les trois systèmes transverses d’évaluation. Le gradebook (carnet de notes) d’abord : éléments et catégories de notes, vues enseignant (Grader report, Single view) et étudiant (User report), méthodes d’agrégation expliquées avec exemples chiffrés (naturelle, moyennes pondérées, médiane…), poids et crédit supplémentaire, échelles et lettres, calculs par formule (=average([[quiz1]],[[devoir1]])), import/export, verrouillage, masquage et le piège des notes surchargées (overridden). Ensuite les badges Open Badges : critères d’attribution (manuel, complétion d’activité/cours, cohorte, autres badges…), expiration, et liaison à un backpack. Enfin les compétences : référentiels (frameworks), échelles de compétence, liaison aux cours et activités, preuves et évaluation, et plans de formation (learning plans) assignés individuellement ou par cohorte. Tableau d’articulation notes/badges/compétences/complétion.

À l’issue : vous savez modéliser n’importe quelle politique d’évaluation dans Moodle.

Chapitre 7 — Rapports natifs, Report Builder et analytics

Où trouver les données : rapports natifs de cours (logs, live logs, activité, participation avec relance des non-participants, achèvement d’activités et de cours) et de site (event monitoring, sécurité, performance). Le morceau central : le Report Builder (rapports personnalisés dans le core depuis Moodle 4.0, enrichi en 4.x/5.x) — sources, colonnes avec agrégations, distinction filtres vs conditions, audiences (à qui le rapport est visible), et planification d’envoi automatique par email avec le piège « view as user ». Ses limites (pas de SQL libre) et les alternatives (Configurable Reports, ad-hoc queries). Enfin les learning analytics natifs (modèle « étudiants à risque de décrochage », indicateurs et prédictions, exigences de données historiques, limites honnêtes) et les statistiques legacy. Tableau décisionnel « quel besoin → quel outil » pour bâtir une stratégie de reporting d’établissement.

À l’issue : vous savez extraire, automatiser et distribuer les indicateurs dont un établissement a besoin.

Fils rouges de la partie

Conventions de la partie

• Les chemins d’interface sont donnés sous la forme : Administration du site > Utilisateurs > Permissions > Définition des rôles (libellés FR du pack de langue officiel, libellé anglais entre parenthèses quand utile).
• Encadrés récurrents : > ⚠️ **Piège** (erreurs classiques), > 💡 **Pour un dev React** (analogies JS/Next.js), > 📚 **Aller plus loin** (docs.moodle.org / moodledev.io).
• Quand une fonctionnalité a évolué récemment, la version d’apparition est précisée (ex. « MFA natif depuis 4.3 », « Report Builder custom depuis 4.0 »).

Fichiers de la partie