Chapitre 2 — Le vocabulaire Moodle : construire votre modèle mental

Partie 1 : Découvrir Moodle — Chapitre 2/5 Objectif : maîtriser tout le lexique Moodle. Pour chaque terme : le libellé de l’interface française, le terme anglais (celui de la documentation et des forums), et le terme utilisé dans le code (noms de classes, de tables, de plugins). En fin de chapitre : un modèle mental complet pour développeur web.

Sommaire du chapitre

1. Pourquoi le vocabulaire est la moitié du travail
2. Le site et la page d’accueil
3. Catégories et cours
4. Sections et formats de cours
5. Activités et ressources : la distinction fondamentale
6. Les blocs
7. Tableau de bord et pages personnelles
8. Utilisateurs et profils
9. L’inscription (enrolment) : le concept le plus mal compris
10. Rôles, capacités et contextes : l’idée générale
11. Cohortes
12. Groupes et groupements
13. Le carnet de notes
14. Achèvement, restriction d’accès et progression
15. Badges
16. Compétences
17. Vocabulaire transverse : le reste de l’iceberg
18. Le grand tableau de correspondance FR / EN / code
19. Le modèle mental complet pour un développeur web
20. Synthèse

1. Pourquoi le vocabulaire est la moitié du travail

Moodle a 24 ans, une communauté mondiale, et une interface traduite en plus de 100 langues. Conséquence : chaque concept porte au moins trois noms — celui de l’interface française (qui a parfois changé au fil des versions de traduction), celui de l’interface anglaise (la référence de toute la documentation), et celui du code (tables SQL, classes PHP, noms de plugins), qui est parfois un troisième mot hérité de 2002.

Un exemple pour fixer les idées : ce que l’interface française appelle une « inscription » s’appelle enrolment en anglais, et dans le code vous manipulerez des plugins enrol_*, des tables enrol et user_enrolments, et une API enrol_get_users_courses(). Si vous cherchez « inscription » dans le code, vous ne trouverez rien ; si vous cherchez « registration », vous trouverez… la création de compte, qui est un tout autre sujet. Sans le triptyque FR/EN/code, on se noie.

Ce chapitre est conçu comme la référence que vous garderez ouverte pendant des mois. Prenez le temps de le lire entièrement une fois, puis revenez-y en dictionnaire.

💡 Pour un dev React : c’est l’équivalent d’apprendre le vocabulaire de Next.js (route segments, server components, middleware, ISR…) — sauf que le domaine est plus vaste et le vocabulaire trilingue. Investissement obligatoire, rentabilisé dès la première semaine.

2. Le site et la page d’accueil

2.1 Le site (site)

Une installation Moodle = un site. Un site a un nom complet (full site name), un nom abrégé (short name), une configuration globale (des milliers de réglages stockés dans les tables config et config_plugins) et un seul domaine (l’URL racine, $CFG->wwwroot, est fixée dans la configuration — la changer implique une procédure spécifique).

Détail architectural savoureux que vous devez connaître dès maintenant : le site lui-même est techniquement un cours — la ligne id = 1 de la table course. C’est un choix de 2002 qui a traversé les âges : la page d’accueil du site est implémentée comme un cours spécial (format site), ce qui lui permet d’accueillir des activités et des blocs comme n’importe quel cours. D’où la constante SITEID que vous croiserez partout dans le code : elle vaut 1 et sert à tester « suis-je dans un vrai cours ou au niveau du site ? ».

⚠️ Piège : Moodle LMS est mono-tenant : une installation = un site = une communauté d’utilisateurs, un thème principal, une configuration. Si un client veut « plusieurs portails de marque différents avec des utilisateurs isolés », les réponses honnêtes sont : plusieurs installations, ou Moodle Workplace (multi-tenant natif), ou des contorsions à base de cohortes/thèmes par catégorie qui n’offrent qu’une isolation cosmétique, pas une isolation de sécurité.

2.2 La page d’accueil (frontpage)

La frontpage est la page visible sur l’URL racine du site. Elle est configurable dans l’administration : on peut y afficher une liste de cours, des catégories, des annonces du site, une section de contenu libre, des blocs. Depuis Moodle 4.x, la navigation principale l’appelle « Accueil » (Home), par opposition au « Tableau de bord » (Dashboard) qui est la page personnelle de l’utilisateur connecté. Beaucoup de sites masquent presque tout de la frontpage et redirigent les utilisateurs connectés directement vers leur tableau de bord (réglage Start page for users / « Page d’accueil pour les utilisateurs »).

3. Catégories et cours

3.1 Les catégories de cours (course categories)

Les catégories forment un arbre hiérarchique (profondeur illimitée) qui range les cours : par exemple Université > UFR Sciences > Licence Informatique > L3 > Semestre 5. Une catégorie peut contenir des sous-catégories et des cours. Points importants :

• Les catégories sont un nœud de délégation : on peut attribuer des rôles au niveau d’une catégorie (par exemple, nommer un « gestionnaire » de l’UFR Sciences qui pourra administrer tous les cours en dessous). C’est le mécanisme central de la décentralisation administrative.
• Certains réglages et objets peuvent vivre au niveau catégorie : cohortes, banques de questions (via les contextes), référentiels de compétences, filtres.
• Chaque catégorie a un champ idnumber (identifiant externe libre) qui sert aux synchronisations avec le système d’information.

💡 Pour un dev React : pensez « arborescence de dossiers avec ACL héritées », comme les dossiers d’un Google Drive d’organisation : le droit accordé sur un dossier se propage à tout ce qu’il contient. La table utilise une colonne path matérialisée (du type /1/8/42) — un classique materialized path — pour requêter efficacement les sous-arbres.

3.2 Le cours (course)

Le cours est l’unité centrale de Moodle — l’espace où tout se passe. Un cours :

• appartient à une catégorie ;
• possède un nom complet (fullname), un nom abrégé (shortname, unique sur le site), un idnumber externe optionnel, des dates de début/fin, un résumé, une image de cours ;
• est découpé en sections (voir §4) contenant des activités et ressources (voir §5) ;
• a ses propres participants (via les inscriptions, §9), groupes (§12), carnet de notes (§13), banque de questions, badges, compétences ;
• a un format (thématique, hebdomadaire… §4.2) et des réglages d’apparence, d’achèvement, de fichiers.

Ne projetez pas trop vite vos intuitions : un « cours » Moodle peut représenter une UE universitaire sur un semestre, un module de formation professionnelle de deux heures, un espace collaboratif d’équipe pédagogique, un espace d’examen, ou un bac à sable. C’est un conteneur générique d’apprentissage avec inscriptions et suivi.

💡 Pour un dev React : le cours est à Moodle ce que le « project/workspace » est à Linear, Notion ou Slack : l’unité d’appartenance, de permissions et de contenu. Membership (inscription) + rôles par workspace (enseignant/étudiant) + contenu structuré (sections/activités) + activité trackée (logs, notes).

4. Sections et formats de cours

4.1 Les sections (course sections)

Une section est une tranche verticale de la page de cours : un bloc titré contenant une liste ordonnée d’activités et de ressources. La section 0 (« générale ») est particulière : elle apparaît en tête de cours et accueille traditionnellement les annonces et la présentation. Depuis Moodle 4.x, les sections peuvent être affichées « une par page » avec navigation linéaire (améliorée en 5.x, notamment la navigation entre activités), réordonnées par glisser-déposer dans l’index de cours, et depuis les versions 4.5/5.x on gère aussi des sous-sections (subsections, via le module mod_subsection introduit en 4.5) — une demande vieille de quinze ans.

4.2 Les formats de cours (course formats)

Le format détermine comment le cours est structuré et rendu. Formats du cœur :

Le format est un type de plugin à part entière : le répertoire de plugins regorge de formats tiers très populaires (Tiles, Grid, Collapsed Topics…) qui changent radicalement la présentation. C’est souvent la première demande de personnalisation d’un client. Depuis Moodle 4.0, l’API des formats (core_courseformat) a été refondue avec un rendu piloté par composants JavaScript et une réactivité de l’édition très supérieure — les vieux formats tiers non portés sur cette API sont à fuir.

5. Activités et ressources : la distinction fondamentale

C’est LE couple de termes à maîtriser absolument.

5.1 Définitions

5.2 Dans le code : tout est « module »

Voici le point crucial : dans le code, activités et ressources sont exactement la même chose — des modules d’activité (activity modules), c’est-à-dire des plugins de type mod :

La distinction activité/ressource n’est qu’une catégorie d’affichage dans le sélecteur d’ajout (chaque module déclare s’il se considère ressource ou activité via une constante de « purpose »/archétype). Architecturalement, mod_page (une ressource) et mod_quiz (l’activité la plus complexe de Moodle) sont deux plugins du même type.

5.3 Le « course module » : l’indirection à comprendre une fois pour toutes

Quand un enseignant ajoute un Test à son cours, Moodle crée deux enregistrements liés :

1. Une ligne dans la table du module (quiz) : l’instance métier, avec ses réglages propres (durée, notes, méthode de correction…).
2. Une ligne dans la table course_modules : le course module (abrégé partout cm), qui matérialise le placement de cette instance dans un cours — sa section, sa visibilité, ses restrictions d’accès, ses réglages d’achèvement, son mode de groupe.

L’ID que vous voyez dans l’URL (/mod/quiz/view.php?id=123) est l’ID du course module, pas celui du quiz. Cette dualité cmid / instanceid est le piège n° 1 du débutant Moodle, source d’innombrables bugs.

⚠️ Piège : ne confondez jamais cm->id (l’ID dans course_modules, celui des URLs) et cm->instance (l’ID dans la table quiz, assign, etc.). Les deux sont des entiers, les deux « marchent » parfois par coïncidence sur un site de dev fraîchement installé (quand les compteurs sont proches), puis tout explose en production. Chaque module a par ailleurs son propre contexte (CONTEXT_MODULE), troisième identifiant distinct.

💡 Pour un dev React : les modules d’activité sont les « apps » d’un store installées dans un workspace : le type (mod_quiz ≈ l’app), l’instance (ce quiz précis ≈ le document), le course module (son emplacement, sa visibilité, ses droits ≈ le nœud dans l’arborescence). Une normalisation relationnelle assez élégante, en fait.

5.4 Les modules d’activité standard de Moodle 5.2

Pour votre culture (chaque nom code = plugin mod_<nom>) : assign (Devoir), quiz (Test), forum (Forum), resource (Fichier), folder (Dossier), page (Page), book (Livre), url (URL), label (Zone texte et média), glossary (Glossaire), wiki (Wiki), workshop (Atelier), lesson (Leçon), choice (Sondage), feedback (Feedback), data (Base de données), scorm (Paquetage SCORM), imscp (Paquetage IMS), lti (Outil externe), h5pactivity (H5P), bigbluebuttonbn (BigBlueButton), subsection (Sous-section), chat (Chat, en voie de retrait), qbank (Banque de questions, module dédié depuis 4.5/5.x). Les anciens modules survey et chat ont été dépréciés/retirés dans les versions 4.x–5.x.

6. Les blocs

Un bloc est un widget rectangulaire placé en périphérie d’une page — depuis le thème Boost, essentiellement dans le tiroir de blocs (block drawer) qui s’ouvre à droite, et sur certaines pages comme le tableau de bord. Exemples : calendrier, événements à venir, derniers messages, HTML libre, progression, activités récentes.

Points de repère :

• Les blocs sont un type de plugin historique en perte d’importance : les thèmes modernes (Boost) les ont marginalisés visuellement, et le tableau de bord 5.2 en réduit encore le rôle. Ne concevez plus une fonctionnalité en pariant sur « l’utilisateur ajoutera le bloc » — beaucoup ne découvrent jamais le tiroir.
• Un bloc peut être placé à différents niveaux (site, catégorie, cours, page d’activité, tableau de bord) et sa visibilité paramétrée par page ; le placement est stocké dans block_instances avec le contexte parent.
• Le tableau de bord historique était entièrement fait de blocs (dont block_myoverview, « Vue d’ensemble des cours », et block_timeline) ; la refonte 5.2 recompose ces informations dans une page plus intégrée.

💡 Pour un dev React : les blocs sont les widgets d’un dashboard à la iGoogle/Notion — configurables, positionnables, avec instance et préférences par utilisateur. Si un client vous demande « un petit encart qui affiche X sur le tableau de bord », la réponse classique est un plugin block_*.

7. Tableau de bord et pages personnelles

Le tableau de bord est la page d’atterrissage personnelle de l’utilisateur connecté : vue de ses cours, échéances à venir (timeline), progression, événements. Il a été refondu en Moodle 5.2 (phase 1 d’un chantier pluri-versions) : présentation centrée sur les échéances et l’action immédiate, moins dépendante du système de blocs. Historiquement, chaque utilisateur pouvait personnaliser son tableau de bord (ajouter/déplacer des blocs) et l’administrateur définir un tableau par défaut, réinitialisable pour tous.

À distinguer de deux cousines :

• « Mes cours » (My courses, /my/courses.php) : page listant tous les cours de l’utilisateur, entrée dédiée de la navigation principale depuis Moodle 4.0.
• Le profil (voir §8) : la page publique/semi-publique décrivant l’utilisateur.

8. Utilisateurs et profils

Le compte utilisateur est global au site (rappel : mono-tenant). Chaque utilisateur a : identifiant de connexion (username), méthode d’authentification (plugin auth_* : manuelle, LDAP, CAS, SAML2, OAuth 2, etc. — l’authentification est un sujet distinct de l’inscription !), nom/prénom/courriel, préférences (langue, fuseau horaire, préférences de notification), avatar, et des champs de profil personnalisés définissables par l’administrateur (l’équivalent d’un schéma extensible clé-valeur).

La page de profil existe en deux saveurs : profil de site et profil « dans un cours » (accessible via les participants d’un cours, montrant les informations pertinentes à ce cours). La visibilité des champs est finement contrôlée.

⚠️ Piège : « créer un compte » (authentification) et « donner accès à un cours » (inscription) sont deux mécanismes totalement disjoints dans Moodle, gérés par deux familles de plugins différentes (auth_* vs enrol_*). Un utilisateur peut avoir un compte et n’être inscrit à aucun cours ; c’est l’état par défaut après création. Cette séparation, très propre conceptuellement, surprend tous les débutants qui cherchent « le » réglage d’accès.

9. L’inscription (enrolment) : le concept le plus mal compris

L’inscription est le lien d’appartenance entre un utilisateur et un cours : « Alice est inscrite au cours de Biologie ». C’est ce lien qui fait apparaître le cours dans « Mes cours » d’Alice, la rend visible dans les participants, lui crée une ligne de carnet de notes, etc. L’inscription est portée par des méthodes d’inscription (enrolment methods), qui sont des plugins :

Chaque inscription porte un statut (active/suspendue), des dates de début/fin éventuelles, et détermine avec quel rôle l’utilisateur entre dans le cours (le rôle par défaut de la méthode, typiquement « Étudiant »). Un même utilisateur peut être inscrit au même cours par plusieurs méthodes simultanément (cas réel : inscription SI + inscription manuelle), ce qui produit des situations subtiles lors des désinscriptions.

💡 Pour un dev React : user_enrolments est votre table de jointure memberships dans une app multi-workspace (user_id, workspace_id, status, via = invitation/SSO/import). La particularité Moodle : la provenance de l’appartenance est un plugin de plein droit, avec sa logique de synchronisation, ses tâches cron et son cycle de vie. C’est ce qui rend possible « brancher les inscriptions sur n’importe quel SI » sans toucher au cœur.

10. Rôles, capacités et contextes : l’idée générale

Le système de permissions de Moodle mérite (et aura) une partie entière de cette documentation. Ici, plantons seulement les trois concepts et le vocabulaire, car tout le reste du produit y fait référence.

10.1 Les trois briques

10.2 La phrase à retenir

On attribue un rôle à un utilisateur dans un contexte, et les permissions héritent le long de l’arbre des contextes. « Bob est Enseignant dans le cours de Chimie » ; « Carla est Gestionnaire dans la catégorie UFR Droit » (donc dispose de ses capacités dans tous les cours en dessous) ; « Diane est Administratrice au niveau système ». Il n’y a pas de rôle global intrinsèque : être « enseignant » n’existe pas dans l’absolu, on est enseignant quelque part. (Seul le compte administrateur principal échappe au système.)

💡 Pour un dev React : c’est un RBAC hiérarchique avec héritage et overrides — imaginez les permissions GitHub (org > team > repo) ou un système de policies avec scopes imbriqués, en plus granulaire. Le contexte est la clef de voûte de tout Moodle : chaque page, chaque fichier, chaque appel de permission est rattaché à un contexte. Intégrez dès maintenant le réflexe : « dans quel contexte suis-je ? » est la première question de tout développeur Moodle, comme « dans quel segment de route suis-je ? » en Next.js.

⚠️ Piège : le rôle « Administrateur » n’est pas un rôle comme les autres (c’est un statut à part, site administrators, qui court-circuite les vérifications), et le rôle affiché n’implique rien : les noms de rôles sont renommables librement. Ne codez jamais une logique du type « si le rôle s’appelle Teacher » ; on teste toujours des capacités, jamais des noms de rôles. Vous verrez cela en détail en Partie 2.

11. Cohortes

Une cohorte est un groupe d’utilisateurs au niveau du site ou d’une catégorie — indépendant de tout cours. Exemple : la cohorte « L3-Info-2026 » contient les 180 étudiants de la promotion. Usage principal : l’inscription par cohorte (enrol_cohort) — on synchronise la cohorte sur les 12 cours du semestre, et chaque ajout/retrait dans la cohorte se propage automatiquement. Les cohortes servent aussi aux dérogations de visibilité, à l’affectation d’audiences (tableaux de bord, plans de compétences) et aux règles dans divers plugins. Elles sont alimentées manuellement, par import CSV, ou automatiquement (LDAP, web services, plugins de synchronisation).

⚠️ Piège : ne confondez pas cohortes (niveau site/catégorie, servent surtout à inscrire en masse) et groupes (niveau cours, servent à séparer les participants à l’intérieur d’un cours, §12). C’est LA confusion classique. Moyen mnémotechnique : cohorte = « promo » (existe avant et en dehors des cours) ; groupe = « TD n° 3 » (n’a de sens que dans un cours donné).

12. Groupes et groupements

12.1 Les groupes (groups)

Un groupe vit à l’intérieur d’un cours et partitionne ses participants : « TD1 », « TD2 », « Équipe projet A ». Les activités et le cours ont un mode de groupe (group mode) :

Le mode peut être forcé au niveau du cours (il s’impose alors à toutes les activités) ou réglé activité par activité. Les groupes servent aussi aux devoirs de groupe (une remise pour toute l’équipe), à la restriction d’accès (« visible seulement par le groupe TD2 »), au filtrage du carnet de notes et des rapports.

12.2 Les groupements (groupings)

Un groupement est un ensemble de groupes (un groupe de groupes). Utilité : quand un cours a plusieurs systèmes de découpage simultanés. Exemple : le cours a les groupes TD1–TD6 et les équipes-projet A–H. On crée le groupement « TD » (contenant TD1–TD6) et le groupement « Projets » (contenant A–H) ; on peut alors dire « ce devoir fonctionne avec le groupement Projets » ou « cette activité n’est accessible qu’au groupement TD ». Sans groupements, les deux découpages se mélangeraient.

💡 Pour un dev React : groupes = tags de partition sur les membres d’un workspace ; groupements = namespaces de tags. C’est un système à deux niveaux, pas plus (pas de groupes de groupements).

13. Le carnet de notes

Le carnet de notes est le sous-système le plus redouté de Moodle — puissant et complexe. Chaque cours a le sien. Concepts :

• Élément d’évaluation (grade item, table grade_items) : une colonne du carnet. Créé automatiquement par chaque activité notable (un Test crée son grade item ; sa note s’y synchronise), ou manuellement (note de participation saisie à la main).
• Note (grade, table grade_grades) : la cellule — la note d’un utilisateur pour un item, avec note brute, note finale (après éventuel recalcul/surcharge), feedback, états caché/verrouillé/surchargé (overridden).
• Catégories de notes (grade categories) : arbre qui regroupe les items (« Contrôle continu », « Examen ») avec une méthode d’agrégation par catégorie : moyenne pondérée, moyenne simple, naturelle (somme), médiane, note la plus haute… et des options retorses (abandonner les n plus basses, exclure les notes vides…).
• Échelles (scales) : notations non numériques (« Insuffisant / Satisfaisant / Excellent »), définies au niveau site ou cours.
• Lettres (grade letters) : mapping pourcentage → lettre (A, B, C…).
• Barèmes avancés (advanced grading) : rubriques (rubrics) et guides d’évaluation pour noter les devoirs critère par critère (sous-système grading, distinct mais connecté).
• Rapports : vue Évaluateur (Grader report, le tableau complet), Utilisateur (ce que voit l’étudiant), Vue d’ensemble, export/import (CSV, XML, Excel).

Le flux à retenir : l’activité note → pousse vers le carnet → le carnet agrège → l’étudiant voit (selon les réglages de visibilité). La note « dans l’activité » et la note « dans le carnet » peuvent différer (surcharge dans le carnet, recalculs, verrouillages) — source infinie de tickets de support.

⚠️ Piège : si un enseignant modifie une note directement dans le carnet, elle devient surchargée (overridden) et l’activité ne peut plus la mettre à jour — le lien de synchronisation est rompu pour cette cellule. Des générations d’enseignants ont « perdu » des notes ainsi. En tant que dev, quand on vous signale « la note ne se met pas à jour », vérifiez d’abord le drapeau overridden.

14. Achèvement, restriction d’accès et progression

Trois mécanismes voisins souvent confondus :

Ensemble, achèvement + restrictions permettent de construire des parcours conditionnels (du séquençage pédagogique) sans une ligne de code. La progression affichée aux étudiants (pourcentages, barres) découle des données d’achèvement.

💡 Pour un dev React : la restriction d’accès est un moteur de règles déclaratif dont les conditions sont… des plugins (availability_*). Le JSON stocké ressemble à s’y méprendre à un arbre de conditions à la react-querybuilder. Si un client demande une condition exotique (« accessible seulement depuis le réseau du campus »), la réponse est un petit plugin availability — un des types de plugins les plus simples à écrire.

15. Badges

Les badges sont des reconnaissances numériques conformes au standard Open Badges (métadonnées vérifiables embarquées dans l’image du badge) : un visuel + un émetteur + des critères + une preuve. Deux niveaux : badges de site et badges de cours. Attribution manuelle (par rôle habilité) ou automatique sur critères : achèvement d’activités, achèvement de cours, compétence validée, champ de profil, autres badges obtenus, cohorte. Les utilisateurs peuvent exporter leurs badges vers des sacs à badges externes (backpacks) compatibles.

16. Compétences

Le sous-système de compétences (depuis Moodle 3.1) outille l’approche par compétences (CBE, Competency-Based Education) :

• Référentiel de compétences (competency framework) : arbre de compétences défini au niveau site/catégorie, avec échelles de maîtrise (« Non acquis / En cours / Acquis »).
• Compétences liées aux cours et activités : un cours déclare les compétences qu’il travaille ; une activité peut, à son achèvement, déclencher une action (attacher une preuve, demander une évaluation, valider la compétence).
• Plans de formation (learning plans) : ensemble de compétences assigné à un utilisateur ou une cohorte, suivi dans le temps, évaluable par des évaluateurs.
• Preuves d’apprentissage antérieur (prior learning evidence) : pièces jointes justifiant une maîtrise.

C’est un module apprécié en formation professionnelle et dans le secondaire ; dans le supérieur français, son adoption progresse avec l’approche par compétences des maquettes.

17. Vocabulaire transverse : le reste de l’iceberg

Termes que vous rencontrerez dès la première semaine, à connaître au moins de nom :

18. Le grand tableau de correspondance FR / EN / code

La table de référence à imprimer :

⚠️ Piège de traduction : la traduction française officielle a évolué au fil des versions (« étiquette » → « zone de texte et média », « paramètres » ↔ « réglages », « salle des profs » pour certains forums historiques…). Quand vous cherchez de l’aide, cherchez toujours avec le terme anglais : les forums anglophones et la documentation développeur sont 20 fois plus fournis, et le terme anglais est stable. Réflexe : interface FR → basculer son propre compte en anglais (préférences > langue) pour retrouver le libellé canonique.

19. Le modèle mental complet pour un développeur web

Assemblons tout. Voici Moodle traduit en concepts de votre monde :

19.1 Le mapping global

19.2 Les quatre axes qui organisent tout

Pour ne jamais vous perdre, retenez que toute donnée/fonctionnalité Moodle se positionne sur quatre axes :

1. L’axe structurel : Site → Catégories → Cours → Sections → Course modules. C’est l’arbre du contenu.
2. L’axe des permissions : l’arbre des contextes (Système → Catégorie → Cours → Module/Bloc), calqué sur le premier, où se résolvent rôles et capacités.
3. L’axe des personnes : Utilisateurs → (cohortes) → inscriptions → (groupes/groupements). Qui est là, comment il est arrivé, comment il est partitionné.
4. L’axe du suivi : événements/logs → achèvement → notes → badges/compétences. Ce que les gens ont fait et ce que ça vaut.

Chaque fois que vous découvrirez une nouvelle fonctionnalité, posez ces quatre questions : où vit-elle dans l’arbre ? dans quel contexte s’évaluent ses permissions ? quels utilisateurs voit-elle et via quoi ? quelles traces produit-elle ? Vous aurez compris 80 % de la fonctionnalité avant d’avoir lu sa doc.

20. Synthèse

• Chaque concept Moodle a trois noms (interface FR, anglais, code) : travaillez toujours avec le terme anglais comme pivot.
• Le site est mono-tenant et — bizarrerie fondatrice — est lui-même le cours id 1 (SITEID).
• Catégories (arbre, délégation) > cours (le workspace central) > sections > activités/ressources, qui sont dans le code une seule et même chose : des plugins mod_*, placés dans les cours via les course modules (dualité cmid/instanceid — le piège n° 1).
• Authentification (auth_*) ≠ inscription (enrol_*) : entrer dans le site ≠ appartenir à un cours.
• Rôles + capacités + contextes : on attribue un rôle dans un contexte ; les permissions héritent le long de l’arbre. On teste des capacités, jamais des noms de rôles.
• Cohortes (niveau site, inscription en masse) ≠ groupes (niveau cours, partition interne) ; les groupements sont des ensembles de groupes.
• Le carnet de notes agrège les notes poussées par les activités ; une note surchargée à la main ne se synchronise plus.
• Achèvement + restrictions d’accès = parcours conditionnels sans code ; badges et compétences couronnent le suivi.
• Le modèle mental en quatre axes : structure, permissions, personnes, suivi.

📚 Aller plus loin :

• Glossaire officiel : https://docs.moodle.org/en/Glossary_of_common_terms 
• Documentation des concepts (gérer un cours, groupes, cohortes, notes) : https://docs.moodle.org/fr/  (documentation francophone)
• Types de plugins : https://moodledev.io/docs/apis/plugintypes 

Chapitre suivant : 03 — Visite guidée de l’interface 5.2, où nous mettons des images mentales sur tous ces mots : connexion, tableau de bord refondu, page de cours, mode édition, navigation et administration.