Projet Niveau 1 — Administrer une plateforme Moodle (sans code)
⏱️ TL;DR — Vous passez du rôle enseignant au rôle administrateur. Vous configurez une petite plateforme pour une organisation : arborescence de catégories, cohortes, import d’utilisateurs par CSV, méthodes d’inscription, un rôle personnalisé, une sauvegarde/restauration de cours. But : comprendre l’administration du site et le système de rôles & permissions — le socle de tout ce qui suit, y compris la sécurité de vos plugins.
🎯 Niveau & objectifs
- Niveau : 1 (débutant). Prérequis : Niveau 0 ; un compte administrateur sur l’instance.
- Durée indicative : 3–5 h.
- Vous allez pratiquer : administration du site, catégories de cours, cohortes, upload CSV, méthodes d’inscription, définition/attribution de rôles, capabilities (côté config), sauvegarde/restauration.
📋 Cahier des charges
Contexte — Une association de formation ouvre sa plateforme. Vous êtes l’admin : structurez-la et peuplez-la proprement pour plusieurs formateurs et groupes d’apprenants.
Objectif — Une plateforme organisée, avec des utilisateurs et cohortes réels, des inscriptions automatisées et un rôle métier adapté.
Périmètre inclus
- Une arborescence de catégories de cours à 2 niveaux (ex. « Photo » → « Débutant », « Avancé »).
- Au moins 10 utilisateurs créés via import CSV (
admin/tool/uploaduser). - 2 cohortes (ex. « Promo A », « Promo B ») peuplées.
- Inscription par cohorte (synchronisation cohorte) sur au moins un cours + une auto-inscription avec clé sur un autre.
- Un rôle personnalisé « Tuteur » (dérivé, avec un jeu de capabilities restreint : voir les notes, poster au forum, pas modifier le cours) et son attribution à un utilisateur.
- Une vérification de permissions effectuée avec l’outil « Vérifier les permissions ».
- Une sauvegarde d’un cours puis sa restauration dans une autre catégorie.
Périmètre exclu — Aucun plugin, aucun code, aucune configuration serveur (PHP, cron système). On reste dans l’interface d’administration.
Contraintes
- L’import CSV doit réussir sans erreur (colonnes correctes, encodage).
- Le rôle « Tuteur » doit être testé en « se connectant en tant que ».
- Documenter les capabilities choisies pour « Tuteur ».
Livrables
- La plateforme configurée (catégories, users, cohortes, rôle).
- Le fichier CSV utilisé + une note : « quelles capabilities pour Tuteur, et pourquoi ».
✅ Critères de réussite
- Les 10+ utilisateurs sont importés et peuvent se connecter.
- Les cohortes sont peuplées et synchronisent les inscriptions au cours.
- L’auto-inscription par clé fonctionne (testée avec un compte apprenant).
- Le rôle « Tuteur » donne exactement les droits prévus (ni plus, ni moins), vérifié à l’écran.
- « Vérifier les permissions » confirme le comportement attendu pour un cas donné.
- La restauration recrée le cours à l’identique dans la nouvelle catégorie.
🗺️ Endroits à visiter
| Endroit | Où | Pourquoi y aller |
|---|---|---|
| Administration du site | menu Admin | L’arbre complet des réglages : c’est ici que tout se pilote |
| Utilisateurs → Comptes → Upload | Admin → Utilisateurs | Import CSV en masse (tool_uploaduser) |
| Cohortes | Admin → Utilisateurs → Cohortes | Groupes transverses réutilisables pour inscrire en masse |
| Méthodes d’inscription | dans un cours → Participants | Manuelle, cohorte, auto-inscription : le « comment on entre » |
| Définir les rôles | Admin → Utilisateurs → Permissions → Définir les rôles | Créer/éditer un rôle et ses capabilities |
| Attribuer les rôles système | Admin → Utilisateurs → Permissions | Contextes d’attribution (site, catégorie, cours, activité) |
| Vérifier les permissions | dans un contexte → Permissions | Simuler « cet utilisateur peut-il faire X ici ? » |
| Sauvegarde / Restauration | dans un cours → (plus) | Le mécanisme backup/restore (que vos mod devront supporter, Niv. 3) |
💡 Pour un dev React — Le modèle rôles/capabilities × contextes de Moodle est plus fin que ce que vous connaissez côté web : une permission n’est pas globale, elle s’évalue dans un contexte (système → catégorie → cours → module) qui hérite. C’est exactement ce que vos plugins interrogeront avec
has_capability()(Niveaux 2–3). Comprendre l’héritage de contexte maintenant, par l’UI, vous évitera des failles de sécurité plus tard, dans le code.
⚠️ Piège — Ne modifiez jamais les rôles standards (Enseignant, Étudiant) pour un besoin ponctuel : créez un nouveau rôle ou une surcharge de permission dans le bon contexte. Toucher aux rôles par défaut a des effets globaux difficiles à retracer.
🚀 Étapes suggérées
- Créer l’arborescence de catégories.
- Préparer le CSV (colonnes
username,password,firstname,lastname,email…), importer. - Créer 2 cohortes, y placer les utilisateurs.
- Sur un cours : ajouter l’inscription par cohorte ; sur un autre : auto-inscription avec clé.
- Dupliquer le rôle « Enseignant non éditeur » → « Tuteur », ajuster les capabilities.
- Attribuer « Tuteur » et tester en « se connectant en tant que ».
- « Vérifier les permissions » sur un cas précis.
- Sauvegarder puis restaurer un cours ailleurs.
🎁 Bonus
- Créez une règle d’inscription avec durée + désinscription automatique.
- Explorez les champs de profil personnalisés (Admin → Utilisateurs → Champs de profil).
- Configurez une politique de mot de passe et une page de politique du site (RGPD).
🔗 Chapitres du cours liés
Projet suivant : Niveau 2 — Premier plugin (local + block).