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

Au chapitre 1, nous avons disséqué la mécanique interne du système de permissions de Moodle : les contextes (contexts) organisés en arbre, les capacités (capabilities), les quatre valeurs de permission (Allow, Prevent, Prohibit, Not set), les dérogations (overrides) et les attributions (assignments). Ce chapitre monte d’un niveau d’abstraction : nous allons étudier les rôles eux-mêmes, c’est-à-dire les paquets nommés de permissions que Moodle livre en standard, puis apprendre à en créer, dupliquer, exporter et auditer via l’interface d’administration.

Un rôle, rappelons-le, n’est rien d’autre qu’une collection de permissions sur des capabilities, dotée d’un nom, d’une description et de quelques métadonnées (archétype, contextes d’assignation autorisés). Le rôle ne « fait » rien tant qu’il n’est pas attribué à un utilisateur dans un contexte. Cette distinction — définition du rôle d’un côté, attribution dans un contexte de l’autre — est le fil rouge de tout ce chapitre.

💡 Pour un dev React : si vous venez d’un monde Next.js avec une lib d’autorisation type CASL ou un RBAC maison, pensez au rôle Moodle comme à un objet de configuration sérialisé en base, pas comme à une constante codée en dur. En JS vous écririez const teacherRole = { can: ['grade:view', 'course:update'] } dans un fichier versionné ; dans Moodle, cette définition vit en base de données et s’édite entièrement via l’interface web, sans redéploiement. C’est à la fois une force (les admins fonctionnels sont autonomes) et un risque (aucune revue de code ne protège la production d’un clic malheureux).

1. Vue d’ensemble des rôles standards

Une installation neuve de Moodle 5.2 est livrée avec huit rôles standards. Vous les trouverez tous listés dans Administration du site > Utilisateurs > Permissions > Définition des rôles (Site administration > Users > Permissions > Define roles). Cette page est le point d’entrée de presque tout ce chapitre : elle affiche le tableau des rôles, leur description, leur nom court (shortname) et les boutons d’édition, de duplication et d’export.

Deux pièges de vocabulaire méritent d’être désamorcés immédiatement, car ils font trébucher tous les débutants :

1. Le nom court du rôle « Enseignant » est editingteacher, et celui de « Enseignant non éditeur » est teacher. Oui, vous avez bien lu : le shortname teacher désigne l’enseignant non éditeur. C’est un héritage historique (à l’origine, il n’existait qu’un seul rôle d’enseignant). Quand vous lirez de la documentation, des forums ou des exports de rôles, vérifiez toujours si l’on parle du nom affiché ou du shortname.
2. « Administrateur » n’apparaît pas dans ce tableau. Ce n’est pas un oubli : l’administrateur n’est pas un rôle, et c’est l’objet de la section suivante.

⚠️ Piège : le shortname d’un rôle est utilisé partout dans les mécanismes techniques de Moodle — inscriptions par fichier CSV (role1), web services, synchronisation de cohortes, restauration de sauvegardes. Il est modifiable dans l’UI, mais ne renommez jamais le shortname d’un rôle standard : vous casseriez silencieusement des intégrations qui s’attendent à trouver editingteacher ou student.

💡 Pour un dev React : la paire nom affiché / shortname fonctionne comme la paire label / value d’un <select> en React : le label est libre, localisable, cosmétique ; la value est la clé stable qui circule dans les API. On refactore un label sans risque, jamais une value déjà en production.

2. L’administrateur n’est PAS un rôle

C’est probablement le point conceptuel le plus important du chapitre, alors martelons-le : dans Moodle, « administrateur du site » n’est pas un rôle. Il n’existe aucune ligne « Administrator » dans la page « Définition des rôles ». Être administrateur est un statut, un drapeau porté par le compte utilisateur lui-même, indépendant de tout le système rôles/capabilities décrit au chapitre 1.

2.1 La liste des administrateurs du site

Les administrateurs sont gérés dans Administration du site > Utilisateurs > Permissions > Administrateurs du site (Site administrators). L’écran présente deux colonnes : à gauche, la liste des administrateurs actuels ; à droite, un champ de recherche et la liste des utilisateurs potentiels. Deux boutons « Ajouter » et « Supprimer » permettent de faire passer des comptes d’une colonne à l’autre, puis un bouton enregistre les modifications (une confirmation est demandée, car l’opération est sensible).

Un détail de cet écran : l’un des administrateurs est marqué comme administrateur principal (main administrator). C’est en général le compte admin créé pendant l’installation. L’administrateur principal ne peut pas être retiré de la liste via cette page (il faut d’abord désigner un autre compte comme administrateur principal). Ce garde-fou évite le scénario catastrophe d’un site sans plus aucun administrateur. Notons aussi qu’un administrateur ne peut pas se retirer lui-même de la liste dans certaines configurations — Moodle préfère toujours qu’un autre admin fasse l’opération.

2.2 Le bypass : presque tout, mais pas tout

Le statut d’administrateur court-circuite le système de permissions : lorsqu’une vérification de capability est effectuée pour un administrateur, Moodle répond « oui » sans même consulter les rôles, les contextes ou les overrides. Un Prohibit posé sur n’importe quel rôle n’affecte pas un administrateur, puisque l’administrateur n’a même pas besoin de rôle. C’est l’équivalent du superutilisateur root sous Unix.

Il existe cependant quelques exceptions, qu’il faut connaître pour ne pas être dérouté :

• Certaines vérifications désactivent explicitement le bypass. Le code de Moodle peut demander une vérification « stricte » qui ignore le statut d’administrateur. C’est rare et réservé à des cas précis (par exemple certaines protections autour de la fonctionnalité « Se connecter sous ce nom »), mais cela explique pourquoi, exceptionnellement, un admin peut se voir refuser une action.
• Être administrateur ne rend pas « membre » des cours. Le bypass concerne les permissions, pas les inscriptions (enrolments). Un administrateur peut entrer dans n’importe quel cours et tout y modifier, mais il n’apparaît pas dans la liste des participants, n’a pas de ligne dans le carnet de notes, ne reçoit pas les notifications du cours et n’est compté dans aucun groupe. Beaucoup de rapports et de fonctionnalités reposent sur l’inscription, pas sur les permissions.
• Les réglages ne sont pas des permissions. Si une fonctionnalité est désactivée globalement (par exemple les portfolios ou le suivi d’achèvement), l’administrateur ne la verra pas non plus : le bypass ne « réactive » pas des fonctions éteintes par configuration.

⚠️ Piège : tester une fonctionnalité pédagogique en étant connecté comme administrateur est le meilleur moyen de passer à côté des bugs de permissions. Puisque toutes les vérifications répondent « oui », vous ne verrez jamais les messages « Désolé, vous n’avez pas la permission… » que vos enseignants et étudiants rencontreront. Testez toujours avec un compte du rôle cible (voir la section « Prendre le rôle » et ses limites, plus bas).

2.3 Dangers et bonnes pratiques

Le compte administrateur est tout-puissant : il peut installer des plugins (donc exécuter du code arbitraire sur le serveur), modifier tous les mots de passe, lire tous les messages personnels, supprimer le site. Quelques règles d’hygiène s’imposent :

1. N’utilisez jamais le compte admin pour le travail quotidien. Créez-vous un compte nominatif avec un rôle Manager (voir section suivante) pour la gestion courante, et ne sortez le compte admin que pour les opérations qui l’exigent réellement (installation de plugins, mises à jour, configuration système).
2. Comptes nominatifs uniquement. Si trois personnes administrent le site, créez trois comptes administrateurs nominatifs plutôt que de partager le mot de passe du compte admin. Les journaux (logs) de Moodle tracent qui a fait quoi — un compte partagé anéantit cette traçabilité.
3. Activez l’authentification à deux facteurs (MFA) pour tous les comptes administrateurs. Depuis Moodle 4.3, le plugin MFA est intégré au cœur de Moodle (Administration du site > Plugins > Outils d’administration > Authentification multifacteur) ; en 5.2 il n’y a plus aucune excuse pour ne pas l’activer.
4. Réduisez la liste au strict minimum. Chaque administrateur supplémentaire est une surface d’attaque supplémentaire. La plupart des besoins « d’administration » quotidiens sont couverts par le rôle Manager.

💡 Pour un dev React : l’administrateur Moodle, c’est votre SUPABASE_SERVICE_ROLE_KEY ou votre accès root à la base de données de prod : indispensable, mais jamais utilisé dans le flux applicatif normal. Le rôle Manager, lui, correspond à un vrai rôle applicatif soumis aux règles d’autorisation — c’est lui que vous « montez » dans votre middleware, pas la clé service.

📚 Aller plus loin : la page « Site administrators » de la documentation officielle (docs.moodle.org) détaille aussi la variable de configuration $CFG->siteadmins qui, définie dans le fichier de configuration du serveur, verrouille la liste des administrateurs et grise l’écran correspondant — utile pour les hébergements mutualisés où l’on veut interdire toute modification via l’UI.

3. Les rôles standards en détail

Passons maintenant chaque rôle standard en revue. Pour chacun, nous verrons ses capabilities emblématiques, son contexte d’assignation habituel et ses cas d’usage. Vous pouvez suivre en parallèle dans votre Moodle : Administration du site > Utilisateurs > Permissions > Définition des rôles, puis cliquez sur le nom d’un rôle pour voir la liste complète de ses quelque 600 à 800 capabilities avec leur valeur.

3.1 Gestionnaire (Manager)

Le rôle Manager est l’outil de la délégation d’administration. Il possède la quasi-totalité des permissions utiles à la gestion pédagogique et administrative, sans être un administrateur : ses actions restent soumises au système de permissions, peuvent être restreintes par overrides, et il ne peut pas toucher à la configuration système ni installer de plugins.

Capabilities emblématiques (parmi des centaines) :

Contexte d’assignation : au niveau système (via Administration du site > Utilisateurs > Permissions > Attribution des rôles système, Assign system roles), le Manager gère tout le site. Attribué au niveau d’une catégorie de cours, il ne gère que cette branche de l’arbre — c’est le montage classique « responsable de département » : le Manager de la catégorie « Département Informatique » gère les cours, enseignants et inscriptions de sa catégorie, et rien d’autre.

Manager vs Administrateur, les différences concrètes : le Manager ne voit du menu « Administration du site » que les pages autorisées par ses capabilities (typiquement la gestion des utilisateurs et des cours) ; il ne peut pas installer de plugins, ne peut pas modifier la définition des rôles dont il ne détient pas la gestion, ne peut pas se voir répondre « oui » automatiquement à tout — et surtout, on peut le contraindre : un Prohibit l’arrête, alors que rien n’arrête un admin.

⚠️ Piège : un Manager assigné au niveau système peut, par défaut, attribuer le rôle Manager à d’autres (la matrice « Autoriser les attributions de rôles » le permet). Un Manager malveillant ou compromis peut donc « se multiplier ». Si vous déléguez largement ce rôle, ajustez la matrice d’attribution (section 7) pour que Manager ne puisse pas attribuer Manager.

3.2 Créateur de cours (Course creator)

Le rôle Course creator est minimaliste et remarquablement bien nommé : il permet de créer des cours, et presque rien d’autre. Ses capabilities significatives se comptent sur les doigts d’une main :

• moodle/course:create — créer un cours ;
• moodle/course:viewhiddencourses — voir les cours cachés (pour retrouver ses brouillons) ;
• moodle/role:assign (limité) — pour pouvoir devenir enseignant du cours créé.

Le comportement clé : lorsqu’un Course creator crée un cours, Moodle lui attribue automatiquement le rôle Enseignant dans ce nouveau cours (comportement réglable via le paramètre « Rôle par défaut lors de la restauration / création », dans Administration du site > Utilisateurs > Permissions > Réglages utilisateur, paramètre creatornewroleid). Le Course creator peut donc construire son cours, mais ne peut pas modifier les cours des autres — c’est la différence fondamentale avec le Manager.

Contexte d’assignation : système (peut créer des cours partout) ou, plus souvent, catégorie (peut créer des cours uniquement dans sa catégorie). Cas d’usage typique : dans une université, chaque enseignant-chercheur est Course creator sur la catégorie de son département et ouvre ses espaces de cours en autonomie, sans solliciter le service informatique.

Teacher vs Course creator, la différence subtile : un Enseignant est puissant à l’intérieur d’un cours existant mais ne peut pas en créer ; un Course creator peut créer des cours mais n’a aucun pouvoir dans les cours existants. Les deux rôles sont complémentaires et souvent cumulés sur la même personne (rappelez-vous du chapitre 1 : un utilisateur peut cumuler plusieurs rôles dans des contextes différents, et les permissions s’agrègent).

3.3 Enseignant (Teacher, shortname editingteacher)

Le rôle central de tout Moodle. L’Enseignant détient les pleins pouvoirs pédagogiques à l’intérieur de son cours :

Contexte d’assignation : le contexte cours, presque toujours via une méthode d’inscription (inscription manuelle, cohorte, etc. — nous y reviendrons au chapitre sur les inscriptions). Il est techniquement possible d’attribuer Enseignant au niveau d’une catégorie (la personne devient alors enseignante de tous les cours de la catégorie), mais c’est déconseillé : l’attribution en contexte catégorie ne crée pas d’inscription, et la personne n’apparaîtra pas dans les listes de participants des cours (même phénomène que pour l’admin, voir la section « Autres utilisateurs » en 9.4).

À noter : l’Enseignant peut aussi attribuer des rôles dans son cours — par défaut, il peut attribuer Enseignant non éditeur et Étudiant, mais pas Enseignant (c’est la matrice « Autoriser les attributions », section 7, qui régit cela).

💡 Pour un dev React : le couple contexte-cours / rôle-enseignant ressemble beaucoup au scoping d’une organisation dans une app SaaS multi-tenant : user.role = 'owner' dans organization_id = 42. La table de jointure role_assignments de Moodle est exactement votre table memberships(user_id, org_id, role) — sauf que le « tenant » est n’importe quel nœud d’un arbre de contextes, avec héritage vers les sous-nœuds (les activités du cours).

3.4 Enseignant non éditeur (Non-editing teacher, shortname teacher)

Copie affaiblie du précédent : l’Enseignant non éditeur peut voir et noter, mais pas construire. Il a mod/assign:grade, moodle/grade:viewall, l’accès aux activités cachées et aux rapports du cours… mais pas moodle/course:manageactivities ni moodle/course:update : le bouton « Activer le mode édition » ne lui est d’aucun secours, il ne peut ni ajouter ni modifier une activité.

Cas d’usage classiques :

• tuteurs et moniteurs qui corrigent des copies et animent les forums sans devoir toucher à la structure du cours ;
• assistants d’enseignement (teaching assistants) — c’est d’ailleurs le nom qu’on lui donne souvent ;
• enseignants observateurs d’une équipe pédagogique, qui suivent les notes sans intervenir ;
• point de départ idéal pour des rôles personnalisés de type « correcteur externe ».

Contexte d’assignation : cours, via inscription, comme l’Enseignant.

3.5 Étudiant (Student)

Le rôle Student est le pendant « consommateur » du système : il permet de participer aux activités. Ses capabilities emblématiques sont côté soumission :

• mod/assign:submit — remettre un devoir ;
• mod/quiz:attempt — passer un test ;
• mod/forum:replypost, mod/forum:startdiscussion — participer aux forums ;
• moodle/course:isincompletionreports — figurer dans les rapports d’achèvement (capability discrète mais structurante : c’est elle qui fait qu’un utilisateur « compte » dans le suivi d’achèvement) ;
• gradereport/user:view — consulter son propre carnet de notes (le rapport utilisateur), mais pas moodle/grade:viewall.

Contexte d’assignation : cours, quasi exclusivement via une méthode d’inscription (auto-inscription, inscription manuelle, synchronisation de cohorte, etc.).

Deux remarques importantes :

1. Le rôle Student est le rôle le plus dangereux à modifier globalement, précisément parce qu’il est attribué à des milliers d’utilisateurs dans des milliers de contextes. Nous y reviendrons dans les anti-patterns (section 10).
2. Beaucoup de comportements « étudiants » ne viennent pas du rôle mais de l’inscription : apparaître dans la liste des participants, dans le carnet de notes, recevoir les notifications. Rôle et inscription sont deux mécanismes distincts qui, dans le cas nominal, sont créés ensemble par la méthode d’inscription.

3.6 Visiteur anonyme (Guest)

Le rôle Guest est attribué automatiquement aux visiteurs non connectés (ou connectés via le bouton « Connexion anonyme » si l’authentification invitée est activée). C’est un rôle strictement en lecture — et une lecture très restreinte :

• il peut consulter les cours dont l’accès invité (guest access) est activé (paramètre du cours, éventuellement protégé par un mot de passe) ;
• il ne peut rien poster : pas de message de forum, pas de remise de devoir, pas de tentative de test enregistrée durablement, pas de message personnel ;
• il n’a pas de profil, pas de notes, pas de progression : Moodle ne peut rien mémoriser pour un utilisateur sans identité.

Techniquement, tous les visiteurs anonymes partagent un unique compte interne « guest ». C’est pour cela que rien ne peut être écrit en leur nom : toute donnée serait partagée entre tous les anonymes du monde. La plupart des capabilities d’écriture sont d’ailleurs marquées côté code comme interdites aux invités, si bien que même un override Allow ne suffit pas à autoriser un invité à écrire — le noyau refuse en amont.

⚠️ Piège : ne confondez pas le rôle Guest avec l’accès invité d’un cours (réglage du cours) ni avec l’authentification invitée (bouton de connexion anonyme, réglage global dans Administration du site > Plugins > Authentification). Les trois travaillent ensemble mais se configurent à trois endroits différents. Un cours peut avoir l’accès invité activé alors que le bouton de connexion anonyme est désactivé globalement : les utilisateurs connectés pourront alors entrer dans le cours en tant qu’invités, mais pas les anonymes.

3.7 Utilisateur authentifié (Authenticated user)

Voici le rôle le plus invisible et le plus fondamental : Authenticated user est attribué automatiquement à chaque utilisateur connecté, dans le contexte Système, dès la connexion. Vous ne pouvez ni retirer cette attribution, ni l’attribuer manuellement : elle est gérée par le noyau. La page « Attribution des rôles » ne la propose d’ailleurs pas.

Ce rôle constitue le socle de permissions de toute personne connectée, indépendamment de ses inscriptions :

• moodle/user:editownprofile — modifier son propre profil ;
• moodle/user:changeownpassword — changer son mot de passe ;
• moodle/blog:create — tenir son blog (si activé) ;
• moodle/badges:earnbadge — recevoir des badges ;
• diverses capabilities de messagerie personnelle, de calendrier, de gestion de ses fichiers personnels.

Comme il est attribué au contexte Système (la racine de l’arbre), ses permissions héritent partout : dans chaque catégorie, chaque cours, chaque activité. C’est pour cela qu’il faut le manipuler avec des pincettes : donner une capability Allow au rôle Authenticated user, c’est la donner à tout le monde, partout. À l’inverse, c’est parfois exactement l’outil qu’il faut : par exemple, autoriser moodle/badges:manageownbadges pour tous, ou au contraire retirer à tous la création de blog.

💡 Pour un dev React : Authenticated user est le layout racine de votre app Next.js — le code qui s’exécute pour toute session authentifiée, avant tout routage. Les autres rôles sont des layouts imbriqués qui ajoutent des permissions par segment de route. Et comme dans Next.js, tout ce que vous mettez dans le layout racine s’applique à l’intégralité de l’arbre : on y réfléchit à deux fois.

3.8 Utilisateur authentifié sur la page d’accueil (Authenticated user on frontpage)

Dernier rôle standard, et le plus anecdotique : Authenticated user on frontpage. Il faut savoir que la page d’accueil de Moodle (frontpage, aussi appelée « Site home ») est techniquement un cours un peu spécial — le cours d’identifiant 1 — qui peut contenir des activités et des ressources. Ce rôle est attribué automatiquement à tout utilisateur connecté, mais uniquement dans le contexte de ce cours « page d’accueil ».

Son utilité : régler ce que les utilisateurs connectés peuvent faire sur la page d’accueil sans toucher au rôle Authenticated user global. Exemple typique : vous placez un forum d’annonces générales sur la page d’accueil et vous voulez que tout utilisateur connecté puisse y répondre — vous ajustez ce rôle plutôt que d’inscrire tout le monde dans un pseudo-cours. Un réglage associé existe dans Administration du site > Page d’accueil > Réglages page d’accueil : « Rôle sur la page d’accueil » (frontpageroleid).

Dans la pratique, la page d’accueil est de moins en moins utilisée comme espace d’activités depuis l’arrivée du Tableau de bord (Dashboard) et de la page « Mes cours », et ce rôle reste le plus souvent dans sa configuration d’origine.

📚 Aller plus loin : la documentation « Standard roles » sur docs.moodle.org donne le détail rôle par rôle, et la page « Front page » explique les particularités du cours d’identifiant 1. Pour explorer les capabilities effectives de chaque rôle standard sur votre propre site, l’outil « Aperçu des capacités » (section 9.3) est plus fiable que toute documentation, car il reflète vos définitions, overrides compris.

4. Les archétypes (archetypes)

Chaque rôle — standard ou personnalisé — peut être rattaché à un archétype (archetype). L’archétype est une étiquette de parenté qui rattache votre rôle à l’un des huit modèles fondamentaux. La liste des archétypes est fixe et non extensible via l’UI :

manager ── coursecreator ── editingteacher ── teacher ── student ── guest ── user ── frontpage
                                  (+ « Aucun » : rôle sans archétype)

À quoi sert concrètement l’archétype ? À deux choses, et il est essentiel de bien les comprendre :

4.1 Valeurs par défaut lors de l’installation de plugins

Quand vous installez un nouveau plugin (une activité, un bloc, un rapport…), celui-ci déclare de nouvelles capabilities. Par exemple, un plugin de devoir amélioré pourrait déclarer mod/superassign:grade et mod/superassign:submit. Question : quelle valeur ces capabilities doivent-elles prendre dans vos 25 rôles existants, y compris vos rôles personnalisés que l’auteur du plugin ne connaît évidemment pas ?

Réponse : le plugin déclare des valeurs par défaut par archétype (« les archétypes editingteacher et manager reçoivent Allow sur grade ; l’archétype student reçoit Allow sur submit »), et Moodle applique ces défauts à tous les rôles portant l’archétype correspondant. Votre rôle personnalisé « Tuteur renforcé », s’il a l’archétype teacher, recevra automatiquement les permissions prévues pour les enseignants non éditeurs. Un rôle sans archétype (« Aucun ») ne reçoit rien : toutes les nouvelles capabilities restent à Not set, ce qui, comme vu au chapitre 1, équivaut à un refus tant que rien d’autre ne les accorde.

4.2 Le bouton « Réinitialiser » (Reset)

Sur la page d’édition d’un rôle (Définition des rôles > cliquer sur le rôle > « Réinitialiser »), un bouton permet de remettre le rôle aux valeurs par défaut de son archétype. Toutes vos modifications manuelles de capabilities sont écrasées. C’est la bouée de sauvetage quand un rôle standard a été bricolé au fil des ans et que plus personne ne sait ce qui a été changé — mais c’est aussi une opération destructrice à ne lancer qu’après avoir exporté la définition actuelle (section 6.2).

4.3 Archétype et création de rôle : deux choses distinctes

Au moment de créer un rôle (section 5), un menu déroulant propose « Utiliser un rôle ou un archétype » : il pré-remplit les permissions du nouveau rôle en copiant celles de l’archétype ou d’un rôle existant. Attention à ne pas confondre :

• la copie initiale des permissions (choix ponctuel au moment de la création, sans effet ultérieur) ;
• le champ « Archétype » du formulaire (lien permanent, qui pilote les défauts des futurs plugins et le bouton Réinitialiser).

Vous pouvez parfaitement créer un rôle en copiant les permissions de editingteacher tout en lui donnant l’archétype « Aucun » — ou l’inverse.

⚠️ Piège : un rôle personnalisé avec l’archétype « Aucun » ne recevra jamais aucune permission automatiquement lors des installations et mises à jour de plugins. Pour un rôle en lecture seule volontairement minimal (comme notre « Inspecteur académique » ci-dessous), c’est un choix judicieux et sécurisant. Mais pour un rôle de type « super-enseignant », c’est un piège à retardement : six mois plus tard, vous installez H5P ou un nouveau module, et vos super-enseignants ne peuvent rien y faire, sans qu’aucun message d’erreur n’explique pourquoi. Choisissez l’archétype en fonction de la famille fonctionnelle du rôle.

💡 Pour un dev React : l’archétype joue le rôle d’un extends dans un tsconfig.json ou d’un preset ESLint : quand une nouvelle règle (capability) apparaît dans une mise à jour, ceux qui étendent le preset la reçoivent avec la valeur recommandée ; ceux qui ont une config from scratch doivent la déclarer explicitement. Et le bouton « Réinitialiser », c’est supprimer toutes vos règles locales pour revenir au preset pur.

📚 Aller plus loin : pour les curieux qui iront plus tard vers le développement de plugins, les valeurs par défaut par archétype se déclarent dans le fichier db/access.php de chaque plugin (clé archetypes de chaque capability). La documentation développeur sur moodledev.io (« Roles and permissions ») décrit ce mécanisme — hors périmètre de ce chapitre fonctionnel, mais utile pour comprendre d’où « tombent » les défauts.

5. Créer un rôle personnalisé pas à pas

Passons à la pratique avec deux exemples complets, choisis parce qu’ils couvrent les deux grands cas de figure : un rôle assigné au niveau catégorie (l’inspecteur) et un rôle assigné au niveau utilisateur (le parent), ce dernier étant le plus contre-intuitif.

5.1 Le formulaire de création : tour d’horizon des champs

Rendez-vous dans Administration du site > Utilisateurs > Permissions > Définition des rôles, puis cliquez sur le bouton « Ajouter un nouveau rôle ». Le processus se déroule en deux écrans.

Écran 1 — point de départ. Un menu déroulant « Utiliser un rôle ou un archétype » propose de partir d’un archétype, d’un rôle existant (duplication de permissions) ou de rien. En dessous, une zone de dépôt de fichier permet d’importer un preset de rôle au format XML (voir section 6.2). Cliquez sur « Continuer ».

Écran 2 — le formulaire complet, avec les champs suivants :

Notez les petites icônes de risque affichées à côté de certaines capabilities (triangle d’avertissement) : XSS, confidentialité (privacy), spam, configuration, fuite de données personnelles (dataloss). Elles signalent les capabilities dont l’octroi imprudent expose le site — un tri par risque est d’ailleurs possible via l’outil « Aperçu des capacités ».

5.2 Exemple A — « Inspecteur académique » : lecture seule sur une catégorie

Besoin fonctionnel : le rectorat envoie un inspecteur qui doit pouvoir entrer dans tous les cours de la catégorie « Lycée Jean-Moulin », tout consulter (contenus, forums, notes), mais ne rien pouvoir modifier, ne rien poster, et ne rien voir en dehors de cette catégorie.

Étape 1 — création. Définition des rôles > Ajouter un nouveau rôle. Dans « Utiliser un rôle ou un archétype », choisissez « Aucun » : nous partons d’une feuille blanche, ce qui garantit qu’aucune permission d’écriture ne se glisse par héritage d’un modèle. Continuer.

Étape 2 — identité.

• Nom court : inspecteur
• Nom : « Inspecteur académique »
• Description : « Rôle en lecture seule pour les inspections. Attribué au niveau catégorie uniquement. Créé le 2026-07-08 par A. Lemia. Aucune capability d’écriture. »
• Archétype : Aucun — choix délibéré : nous ne voulons pas que les futurs plugins accordent quoi que ce soit à ce rôle par défaut ; la posture est « refus par défaut, pour toujours ».

Étape 3 — contextes d’assignation. Cochez uniquement Catégorie de cours (et éventuellement Cours, si vous voulez pouvoir cibler un cours isolé lors d’une inspection ponctuelle). Ne cochez ni Système, ni Utilisateur, ni Activité, ni Bloc. Personne ne pourra ainsi attribuer ce rôle à un mauvais niveau.

Étape 4 — capabilities. Passez à Allow les capabilities suivantes (utilisez le filtre pour les retrouver), toutes en lecture :

Tout le reste demeure à Not set — donc refusé, puisque l’inspecteur n’aura aucun autre rôle accordant quoi que ce soit dans ces cours. Il est inutile (et contre-productif) de mettre des Prevent partout : Not set suffit, comme vu au chapitre 1, et garde la définition lisible.

Cliquez sur « Créer ce rôle ».

Étape 5 — attribution au niveau catégorie. Naviguez vers la catégorie : Administration du site > Cours > Gérer les cours et catégories, cliquez sur « Lycée Jean-Moulin », puis dans la page de la catégorie ouvrez le menu (roue dentée ou onglet selon le thème) « Attribution des rôles » (Assign roles). L’écran liste les rôles attribuables dans ce contexte — votre rôle « Inspecteur académique » y figure puisque vous avez autorisé le contexte Catégorie. Cliquez dessus, cherchez le compte de l’inspecteur dans la colonne de droite, « Ajouter ». C’est terminé : par héritage de contexte (chapitre 1), le rôle s’applique à tous les cours présents et futurs de la catégorie et de ses sous-catégories.

Vérification. Utilisez « Vérifier les permissions » dans un cours de la catégorie (section 9.1) pour confirmer que l’inspecteur a bien moodle/course:view = Oui et moodle/course:update = Non ; puis demandez à l’inspecteur (ou testez via « Se connecter sous ce nom ») de constater : les cours de la catégorie apparaissent, il peut y entrer, aucun crayon ni menu d’édition n’est visible, et les cours des autres catégories lui restent invisibles.

⚠️ Piège : l’inspecteur, n’étant pas inscrit aux cours, ne les verra pas sur son Tableau de bord ni dans « Mes cours » — ces pages listent les inscriptions. Il devra passer par la page de la catégorie ou par la recherche de cours. Prévenez vos inspecteurs, sinon vous recevrez immanquablement un ticket « je ne vois aucun cours » alors que tout fonctionne.

💡 Pour un dev React : ce rôle est l’équivalent d’un token d’API read-only scoped : au lieu de créer un utilisateur « normal » et de bloquer chaque route d’écriture une à une (liste noire), vous partez de zéro et n’ouvrez que des routes GET (liste blanche). En sécurité, la liste blanche gagne toujours : une capability oubliée reste fermée, pas ouverte.

5.3 Exemple B — « Parent / Mentor » : un rôle dans le contexte utilisateur

Besoin fonctionnel : dans un établissement secondaire, les parents veulent suivre la scolarité de leur enfant : consulter son profil, ses notes, ses rapports d’activité. Ils ne doivent pas entrer dans les cours ni voir les autres élèves.

C’est le cas d’école du contexte Utilisateur (User context), le plus déroutant des context levels : chaque utilisateur possède son propre contexte, et on peut y attribuer des rôles. Attribuer le rôle « Parent » à Mme Dupont dans le contexte de l’élève Léo Dupont signifie : « Mme Dupont exerce les permissions du rôle Parent sur Léo ». Le détenteur du rôle agit sur la personne-contexte, exactement comme un Manager de catégorie agit sur sa catégorie.

Étape 1 — création du rôle. Définition des rôles > Ajouter un nouveau rôle > partir de « Aucun » > Continuer.

• Nom court : parent
• Nom : « Parent / Mentor »
• Description : « Suivi parental. À attribuer UNIQUEMENT dans le contexte utilisateur de l’enfant (profil de l’enfant > Préférences > Rôles > Attribution de rôles relatives à cet utilisateur). Créé le 2026-07-08. »
• Archétype : Aucun.
• Contextes d’assignation : cochez uniquement Utilisateur.

Étape 2 — capabilities. Passez à Allow :

Le mécanisme mérite explication : normalement, gradereport/user:view se vérifie dans le contexte d’un cours. Mais le code des rapports de notes et des pages de profil contient une vérification supplémentaire dans le contexte utilisateur de la personne consultée, précisément pour permettre ce montage parental. C’est pourquoi ce rôle « Parent » fonctionne sans donner au parent le moindre accès aux cours eux-mêmes.

Étape 3 — attribution dans le contexte de l’enfant. Ouvrez le profil de l’élève (par exemple via Administration du site > Utilisateurs > Comptes > Liste des utilisateurs, puis cliquez sur Léo Dupont). Dans la page de profil, section « Administration », cliquez sur « Préférences », puis dans le bloc « Rôles », « Attribution de rôles relatives à cet utilisateur » (Assign roles relative to this user). Le rôle « Parent / Mentor » apparaît (grâce à la case « Utilisateur » cochée). Sélectionnez-le, puis attribuez-le au compte de Mme Dupont. Répétez pour le second parent, et recommencez l’opération sur le profil de chaque enfant si Mme Dupont a plusieurs enfants scolarisés.

Étape 4 — le bloc Mentees. Pour que les parents trouvent facilement leurs enfants, ajoutez le bloc « Mentees » (traduit « Personnes sous tutorat » selon les packs de langue) sur le Tableau de bord par défaut : Administration du site > Présentation > Page par défaut du tableau de bord, activez le mode édition, ajoutez le bloc, puis « Réinitialiser le tableau de bord de tous les utilisateurs » si nécessaire. Le bloc affiche, pour chaque détenteur d’un rôle en contexte utilisateur, la liste cliquable de « ses » utilisateurs — les parents y verront leurs enfants et accéderont à leur profil en un clic.

Limites de cette approche — soyez transparent avec votre établissement avant de la déployer :

• Pas d’industrialisation native dans l’UI : chaque lien parent-enfant se crée à la main, profil par profil. Pour 800 élèves, il faudra passer par l’outil d’importation d’utilisateurs (le CSV d’upload d’utilisateurs sait créer des attributions en contexte utilisateur via les colonnes de type sysrole / champs mentor selon les versions) ou par un plugin dédié.
• Le parent ne voit pas l’intérieur des cours : ni les énoncés de devoirs, ni les forums complets, ni le calendrier du cours. Il voit des rapports sur l’enfant, pas la vie de la classe.
• Pas de notifications : le parent ne reçoit pas d’alerte quand une note tombe ; il doit venir consulter.
• Confidentialité et RGPD : vous donnez à un tiers l’accès aux données personnelles d’un utilisateur. Assurez-vous que le lien parent-enfant est juridiquement établi, et documentez le dispositif dans votre registre de traitements.
• Pour un vrai portail parents (notifications, multi-enfants, vie de classe), le marché des plugins offre des solutions plus riches ; le rôle Parent natif reste la solution simple, robuste et sans dépendance.

⚠️ Piège : n’attribuez jamais le rôle Parent au niveau système « pour aller plus vite » (d’ailleurs, si vous avez suivi l’étape 1, le contexte Système n’est pas coché et l’UI vous en empêchera — c’est exactement à cela que sert ce champ). Un rôle avec moodle/user:viewalldetails et moodle/grade:viewall attribué au niveau système donnerait au parent la vue sur les données personnelles et les notes de tous les utilisateurs du site. Le champ « contextes d’assignation autorisés » est votre ceinture de sécurité : bouclez-la à la création.

💡 Pour un dev React : le contexte utilisateur est une idée qu’on retrouve peu dans les RBAC web classiques, où les permissions portent sur des ressources (document:42). Ici, la ressource est un utilisateur : can(parent, 'grades:read', user:leo). Si vous avez déjà modélisé un système de délégation (« ce compte agit au nom de ce compte », impersonation scopée, OAuth act_as), c’est la même idée, en lecture seule et persistée en base.

📚 Aller plus loin : la page « Parent role » de docs.moodle.org est le tutoriel historique de ce montage et recense les capabilities conseillées ainsi que les discussions de la communauté sur ses limites. Cherchez aussi « Mentees block » pour les options d’affichage du bloc.

6. Dupliquer, exporter, importer, réordonner

6.1 Dupliquer un rôle existant

Sur la page Définition des rôles, chaque ligne de rôle comporte des icônes d’action ; ouvrez un rôle puis utilisez le bouton « Dupliquer le rôle » (une confirmation est demandée). Moodle crée une copie intégrale — permissions, archétype, contextes autorisés — avec un nom suffixé (« copie 1 ») que vous renommez ensuite via « Modifier ».

La duplication est la bonne pratique numéro un pour toute variation d’un rôle standard : besoin d’un « Enseignant sans sauvegarde/restauration » ? Dupliquez editingteacher, passez moodle/backup:backupcourse et moodle/restore:restorecourse à Prevent dans la copie, et laissez le rôle standard intact. Le rôle original reste la référence saine vers laquelle revenir.

6.2 Exporter et importer une définition de rôle (preset XML)

Sur la page de consultation d’un rôle (Définition des rôles > cliquer sur le nom du rôle), un bouton « Exporter » télécharge un fichier XML de preset contenant l’intégralité de la définition : shortname, noms, description, archétype, contextes autorisés, les quatre matrices Allow (assign/override/switch/view) et la valeur de chaque capability.

Ce fichier se réimporte à deux endroits :

• à la création d’un rôle : sur le premier écran de « Ajouter un nouveau rôle », déposez le fichier XML dans la zone de dépôt — le formulaire arrive pré-rempli à l’identique ;
• sur un rôle existant : en mode édition d’un rôle, une zone de dépôt permet d’écraser la définition courante par celle du fichier (l’écran vous montre alors un différentiel des changements avant validation — relisez-le attentivement).

Les cas d’usage sont exactement ceux que vous imaginez en tant que développeur :

• Promotion entre environnements : définir le rôle sur l’instance de test, l’exporter, l’importer en production. C’est le plus proche d’un « déploiement de configuration » que l’UI de Moodle offre pour les rôles.
• Sauvegarde avant modification : exportez toujours un rôle avant de le modifier ou de le réinitialiser — c’est votre git stash de pauvre.
• Partage communautaire : la communauté Moodle échange des presets de rôles (Parent, Inspecteur, Correcteur…) sous forme de fichiers XML.

⚠️ Piège : le preset XML référence les capabilities par leur nom. Si le site de destination n’a pas les mêmes plugins que le site source, les capabilities inconnues sont ignorées à l’import (et celles du site cible absentes du fichier restent inchangées ou à Not set selon le mode). Après un import inter-sites, passez systématiquement en revue le différentiel proposé, puis contrôlez le résultat avec l’« Aperçu des capacités ».

💡 Pour un dev React : le couple export/import XML est votre package-lock.json de rôles : un instantané exact, versionnable. Rangez ces fichiers XML dans un dépôt Git avec un commit par modification de rôle en production — Moodle ne fournit aucun historique des définitions de rôles ; ce dépôt sera votre seul audit trail et votre seul moyen de « rollback ».

6.3 Réordonner les rôles

Toujours sur la page Définition des rôles, des flèches haut/bas permettent de réordonner la liste. Ce n’est pas que cosmétique : cet ordre détermine l’ordre d’affichage des rôles dans tous les menus d’attribution, dans les listes de participants, et l’ordre des colonnes dans les pages de permissions. Convention utile : ordonnez du plus puissant au moins puissant (Manager en haut, Guest en bas) et insérez vos rôles personnalisés à leur « niveau de pouvoir », pour que les écrans d’attribution restent intuitifs pour vos gestionnaires.

L’ordre influence aussi l’affichage du rôle dominant d’un utilisateur dans certains écrans (quel libellé apparaît sous son nom dans un cours quand il cumule plusieurs rôles).

7. Les quatre matrices « Autoriser… » (Allow assign / override / switch / view)

Nous arrivons au mécanisme de méta-permission le plus important pour déléguer sans perdre le contrôle. La page Définition des rôles comporte quatre onglets, chacun présentant une matrice rôles × rôles :

1. Autoriser les attributions de rôles (Allow role assignments) — qui peut attribuer quoi ;
2. Autoriser les dérogations de rôles (Allow role overrides) — qui peut créer des overrides sur quoi ;
3. Autoriser les changements de rôle (Allow role switches) — qui peut « prendre le rôle » de quoi (section 8) ;
4. Autoriser l’affichage des rôles (Allow role to view) — qui peut voir les détenteurs de quel rôle dans les listes.

Lecture de la matrice : les lignes représentent le rôle détenu par la personne qui agit, les colonnes le rôle cible de l’action. Une case cochée à l’intersection (Enseignant, Étudiant) dans la matrice d’attribution signifie : « un utilisateur détenant le rôle Enseignant peut attribuer le rôle Étudiant » (dans les contextes où il détient son rôle et où il possède par ailleurs la capability moodle/role:assign).

Extrait de la matrice d’attribution par défaut :

                        RÔLE CIBLE (colonnes)
                 Manager  Creator  Ens.  Ens.NE  Étudiant
RÔLE DÉTENU
Manager            [x]      [x]    [x]    [x]      [x]
Course creator     [ ]      [ ]    [x]    [ ]      [ ]
Enseignant         [ ]      [ ]    [ ]    [x]      [x]
Ens. non éditeur   [ ]      [ ]    [ ]    [ ]      [ ]
Étudiant           [ ]      [ ]    [ ]    [ ]      [ ]

On lit ainsi les règles par défaut : un Manager peut tout attribuer (y compris Manager — relire le piège de la section 3.1) ; un Enseignant peut recruter des enseignants non éditeurs et des étudiants dans son cours, mais pas un autre Enseignant ni se promouvoir ; un Course creator peut nommer l’Enseignant du cours qu’il crée.

Pourquoi c’est crucial. La capability moodle/role:assign répond à la question « peut-il attribuer des rôles ? » ; la matrice répond à « lesquels ? ». Sans la matrice, tout délégataire du droit d’attribution pourrait s’auto-promouvoir en attribuant un rôle plus puissant que le sien : c’est le classique problème d’escalade de privilèges. Même logique pour les overrides : la matrice de dérogation empêche un Enseignant, autorisé à faire des overrides dans son cours (s’il a moodle/role:override ou moodle/role:safeoverride), de modifier les permissions du rôle Manager dans ce cours.

Quand vous créez un rôle personnalisé, pensez aux deux directions de la matrice :

• le nouveau rôle comme ligne : que pourra-t-il attribuer/déroger/endosser/voir ? (Pour notre Inspecteur : rien, aucune case.)
• le nouveau rôle comme colonne : qui pourra l’attribuer ? Si vous ne cochez pas la case (Manager → Inspecteur), seuls les administrateurs pourront attribuer le rôle Inspecteur. Selon votre organisation, c’est un bug ou une fonctionnalité.

La quatrième matrice (« Autoriser l’affichage ») est plus récente (introduite dans Moodle 3.x) et plus discrète : elle contrôle la visibilité des détenteurs de rôles — par exemple, permettre aux Étudiants de voir qui est Enseignant dans la liste des participants, sans leur montrer les autres rôles. Elle affine la confidentialité des listes plutôt que le pouvoir d’action.

⚠️ Piège : après création d’un rôle personnalisé, le symptôme numéro un signalé est « le rôle n’apparaît pas dans le menu d’attribution ». Trois causes possibles, à vérifier dans l’ordre : (1) le contexte courant n’est pas coché dans « contextes d’assignation autorisés » du rôle ; (2) la personne qui attribue n’a pas la case cochée dans la matrice d’attribution (sa ligne × votre colonne) ; (3) elle n’a pas la capability moodle/role:assign dans ce contexte. Les trois verrous sont cumulatifs — il faut les trois clés.

💡 Pour un dev React : ces matrices sont des méta-permissions — des permissions sur le système de permissions, comme la distinction entre un token qui accède à une API et un token qui peut créer d’autres tokens (et avec quels scopes maximum). Si vous avez utilisé AWS IAM : c’est l’équivalent des permissions boundaries qui empêchent un rôle de créer un rôle plus large que lui-même.

📚 Aller plus loin : cherchez « Allow role assignments » dans docs.moodle.org pour les matrices par défaut complètes, et « Risks » pour comprendre la différence entre moodle/role:override et moodle/role:safeoverride (ce dernier ne permet de déroger que des capabilities sans risque XSS/config — c’est lui qu’on donne aux enseignants).

8. « Prendre le rôle… » (Switch role to)

8.1 Fonctionnement

Dans un cours, ouvrez le menu utilisateur (votre avatar, en haut à droite) et choisissez « Prendre le rôle… » (Switch role to…). Un écran propose la liste des rôles que vous êtes autorisé à endosser (matrice « Autoriser les changements de rôle » + capability moodle/role:switchroles). Choisissez « Étudiant » : la page se recharge, une notification indique le rôle simulé, et vous naviguez désormais dans le cours avec les permissions du rôle Étudiant appliquées à votre session, dans ce contexte et ses enfants. Le menu utilisateur affiche alors « Revenir à mon rôle normal » (Return to my normal role).

C’est l’outil de vérification rapide par excellence pour un enseignant : « les étudiants voient-ils cette section cachée ? le devoir est-il bien fermé ? le crayon d’édition a-t-il disparu ? ».

8.2 Les limites — et elles sont sérieuses

Le switch role est une simulation de permissions, pas une simulation d’identité. Il remplace vos permissions par celles du rôle cible, mais vous restez vous-même : même compte, mêmes inscriptions, mêmes données. D’où une liste de divergences bien connues avec l’expérience d’un vrai étudiant :

• Groupes : vous n’êtes pas membre des groupes du cours. Toutes les activités en mode « groupes séparés » (forums, devoirs de groupe, restrictions d’accès par groupe) se comporteront différemment pour vous que pour un étudiant réellement groupé.
• Données d’activité : vous n’avez ni tentatives de quiz, ni remises de devoirs, ni notes, ni progression d’achèvement. Vous voyez les écrans « vides » d’un étudiant qui n’aurait encore rien fait — jamais l’état « après remise » ou « note publiée ».
• Restrictions d’accès (restrict access) basées sur le profil, une note ou l’appartenance à un groupe : évaluées sur vos données, pas sur celles d’un étudiant type.
• Inscription : vous n’êtes pas inscrit comme étudiant ; certaines listes et certains rapports fondés sur l’inscription ne se comportent pas à l’identique.
• Tableau de bord, notifications, messagerie : hors périmètre — le switch ne s’applique qu’au contexte du cours et à ses enfants, pas à l’expérience globale de la plateforme.
• Historiquement, divers bugs cosmétiques ont accompagné cette fonction (blocs affichés différemment, éléments de navigation résiduels) : n’en tirez jamais de conclusion définitive.

8.3 Les alternatives fiables

1. Un vrai compte de test. Créez un utilisateur « Étudiant Test », inscrivez-le au cours, mettez-le dans un groupe. Connectez-vous avec dans une fenêtre de navigation privée (ou un autre navigateur) pour comparer côte à côte la vue enseignant et la vue étudiant. C’est la seule simulation fidèle à 100 %, y compris tentatives de quiz et remises de devoirs.
2. « Se connecter sous ce nom » (Log in as) : depuis le profil d’un participant, le lien « Se connecter sous ce nom » (capability moodle/user:loginas, réservée par défaut aux administrateurs — et aux managers dans le contexte cours) transforme votre session en session de cet utilisateur réel, avec ses groupes et ses données. Puissant pour le support (« je vois exactement ce que voit Léo »), mais lourd de conséquences : vous agissez en son nom (l’action est journalisée comme telle, avec mention du login-as dans les logs), et la session se termine par une déconnexion complète. À réserver au diagnostic, jamais pour « faire à la place de », et à encadrer par une politique interne — c’est une capacité marquée à risque de confidentialité.

⚠️ Piège : ne validez jamais un dispositif d’examen (quiz sommatif, dates de remise, restrictions par groupe) uniquement avec « Prendre le rôle » : les restrictions liées aux groupes et aux données individuelles ne sont pas simulées. La demi-heure investie dans un compte de test correctement groupé est votre assurance contre un examen inaccessible le jour J devant 200 étudiants.

💡 Pour un dev React : « Prendre le rôle », c’est modifier la valeur d’un contexte d’autorisation côté client pour prévisualiser l’UI — un <PermissionsProvider value={studentPerms}> de Storybook : le rendu conditionnel change, mais le state serveur (données, appartenances) reste le vôtre. « Se connecter sous ce nom », c’est de l’impersonation de session complète, l’équivalent de forger le cookie de session d’un autre utilisateur — d’où son cantonnement aux admins et sa journalisation renforcée.

9. Vérifier les permissions : les outils d’audit

Créer des rôles, c’est bien ; prouver qu’ils font ce qu’on croit, c’est mieux. Moodle offre quatre outils complémentaires, du plus local au plus global.

9.1 « Vérifier les permissions » (Check permissions) dans un contexte

Disponible dans tout contexte. Dans un cours : page Participants, puis dans le menu déroulant en haut de page (celui qui liste « Utilisateurs inscrits », « Groupes », « Permissions »…), choisissez « Vérifier les permissions » (Check permissions). Sélectionnez un utilisateur : Moodle affiche la liste complète des capabilities avec, pour chacune, Oui ou Non — le résultat effectif du calcul complet décrit au chapitre 1 (tous rôles cumulés, héritage, overrides, résolution des conflits).

C’est l’outil de la question « pourquoi Mme Martin ne peut-elle pas faire X ici ? » : la réponse est binaire et définitive, sans avoir à dérouler mentalement l’algorithme. Le même outil existe au niveau catégorie (page de la catégorie > menu > Vérifier les permissions), au niveau d’une activité (menu de l’activité > Permissions > icône/onglet de vérification) et au niveau système (Administration du site > Utilisateurs > Permissions > Vérifier les permissions système).

9.2 La page « Permissions » d’un cours ou d’une activité

Dans un cours : Participants > menu déroulant > « Permissions ». Cette page liste chaque capability avec, en face, les rôles qui la détiennent dans ce contexte, et des icônes « + / − » pour ajouter ou retirer un rôle — c’est l’interface conviviale des overrides vus au chapitre 1 (chaque +/− crée une dérogation locale). Un champ de filtre permet de chercher une capability. Les capabilities ayant fait l’objet d’un override dans ce contexte sont signalées, ce qui en fait aussi un outil d’audit des dérogations locales : avant de diagnostiquer un comportement bizarre dans un cours, vérifiez toujours cette page — un prédécesseur y a peut-être laissé des overrides oubliés.

9.3 Le rapport « Aperçu des capacités » (Capability overview report)

Le grand angle : Administration du site > Utilisateurs > Permissions > Aperçu des capacités (Capability overview). Vous choisissez une capability (avec autocomplétion) et un ou plusieurs rôles, puis le rapport affiche un tableau : pour chaque rôle sélectionné, la valeur de la capability dans la définition du rôle et dans chaque contexte où elle est dérogée, avec un lien vers chaque contexte concerné.

C’est l’outil des questions transversales : « qui, sur tout le site, peut voir toutes les notes ? », « dans quels cours quelqu’un a-t-il dérogé mod/forum:startdiscussion ? ». C’est aussi l’arme de l’audit de sécurité périodique : passez en revue les capabilities à risque (celles marquées XSS et configuration) et vérifiez qu’aucun rôle inattendu ni aucun override sauvage ne les accorde.

9.4 « Attribution des rôles » vs « Autres utilisateurs » dans un cours

Deux écrans d’un cours prêtent à confusion :

• Participants > Utilisateurs inscrits : les utilisateurs inscrits au cours, avec leurs rôles. L’inscription crée l’appartenance (notes, groupes, complétion, notifications) ; le rôle donne les permissions. C’est ici qu’on gère le cas nominal.
• Participants > menu déroulant > « Autres utilisateurs » (Other users) : les utilisateurs qui détiennent un rôle dans le contexte du cours sans y être inscrits — soit par attribution directe non inscrivante dans le cours via cet écran, soit par héritage d’un rôle attribué plus haut (notre Inspecteur académique de la section 5.2 apparaît ici dans chaque cours de sa catégorie, tout comme un Manager de catégorie).

La distinction éclaire d’un coup la différence conceptuelle rôle ≠ inscription : les « autres utilisateurs » ont des permissions dans le cours mais n’en sont pas membres. Ils n’apparaissent pas dans le carnet de notes, ne comptent pas dans les rapports d’achèvement et ne reçoivent pas les annonces.

⚠️ Piège : attribuer le rôle Étudiant via « Autres utilisateurs » (ou au niveau catégorie) ne crée pas d’inscription : la personne pourra entrer dans le cours (si le rôle donne moodle/course:view… ce que Student ne donne pas !) mais n’aura ni carnet de notes ni suivi. Si votre but est d’ajouter un étudiant, passez toujours par Utilisateurs inscrits > Inscrire des utilisateurs. Symétriquement, si un utilisateur « fantôme » a des pouvoirs dans un cours sans être dans la liste des participants, c’est dans « Autres utilisateurs » (ou dans les attributions de la catégorie parente) qu’il faut chercher.

💡 Pour un dev React : « Vérifier les permissions » est votre console.log(computedPermissions) sur un utilisateur donné ; la page « Permissions » du cours est l’inspecteur du state local (les overrides du contexte, comme les props surchargées d’un composant) ; l’« Aperçu des capacités » est la recherche globale dans le code (grep -r "grade:viewall") qui trouve toutes les occurrences, définition et surcharges comprises. Trois altitudes, trois outils.

📚 Aller plus loin : pour aller au-delà de l’UI, le plugin d’administration très répandu « Admin bench­mark » n’est pas le sujet, mais explorez plutôt les rapports intégrés Administration du site > Rapports (notamment « Journaux » filtrés sur les événements de type role assigned / unassigned / capability overridden) : chaque modification de rôle et chaque attribution est un événement journalisé — c’est votre piste d’audit après incident.

10. Bonnes pratiques et anti-patterns

Terminons par la synthèse des règles d’or, dont plusieurs ont été semées au fil du chapitre.

10.1 Ne jamais modifier un rôle standard pour un besoin local

L’anti-pattern numéro un, responsable de la majorité des sites Moodle « hantés » : un enseignant demande que ses étudiants puissent évaluer les forums dans son cours, et l’administrateur passe mod/forum:rate à Allow dans la définition globale du rôle Student. Résultat : les étudiants de tous les cours du site peuvent désormais noter les forums, et personne ne s’en apercevra avant des mois. Comme vu au chapitre 1, la réponse à un besoin local est l’override dans le contexte concerné (page Permissions du cours ou de l’activité), jamais la modification de la définition globale.

Règle de décision simple :

10.2 Autres règles d’or

1. Dupliquez plutôt que modifier : toute variante d’un rôle standard doit être une copie ; le rôle standard reste l’étalon.
2. Limitez les Prohibit au strict nécessaire. Rappel du chapitre 1 : un Prohibit ne peut être annulé par aucun override plus bas dans l’arbre — c’est un veto absolu. Réservez-le aux interdictions de sécurité non négociables (ex. : interdire moodle/site:sendmessage à un rôle « comptes partagés »), jamais aux réglages pédagogiques courants : un Prohibit posé « pour être sûr » se paie des mois plus tard en heures de diagnostic, car il gagne silencieusement contre tous les Allow.
3. Liste blanche pour les rôles restrictifs : partez de « Aucun » et n’accordez que le nécessaire (notre Inspecteur), plutôt que de partir d’un rôle puissant et de retirer.
4. Verrouillez les contextes d’assignation à la création de chaque rôle : un rôle qui ne peut techniquement pas être attribué au mauvais niveau est un accident évité.
5. Pensez aux quatre matrices après chaque création de rôle : qui pourra l’attribuer, le déroger, l’endosser, le voir ?
6. Documentez dans le champ Description : auteur, date, ticket, intention, contexte d’assignation prévu. C’est le seul « commentaire de code » disponible dans l’UI, et votre successeur vous bénira.
7. Exportez avant de modifier, versionnez les exports : un dépôt Git de presets XML est votre historique et votre plan de rollback.
8. Auditez périodiquement : « Aperçu des capacités » sur les capabilities à risque, page Permissions des cours sensibles, revue de la liste des administrateurs du site et des attributions système (Administration du site > Utilisateurs > Permissions > Attribution des rôles système).
9. Testez avec des comptes réels de chaque rôle, pas seulement avec « Prendre le rôle », et jamais en tant qu’admin.
10. Moins de rôles, mieux nommés : chaque rôle personnalisé a un coût de maintenance perpétuel (à chaque installation de plugin, à chaque montée de version, à chaque audit). Avant de créer un rôle, vérifiez qu’un override ou une combinaison de rôles existants ne suffit pas.

⚠️ Piège : les modifications de définitions de rôles sont immédiates et globales — pas de brouillon, pas de bouton « publier », pas d’annulation. Chaque case cochée dans l’éditeur de rôle est en production dès l’enregistrement. D’où l’importance vitale du réflexe « exporter avant de toucher » et, pour les changements lourds, d’une répétition sur un environnement de test.

💡 Pour un dev React : la maintenance des rôles personnalisés ressemble à celle d’un fork de librairie : tant que vous suivez l’upstream (archétype cohérent, documentation, exports versionnés), les mises à jour passent ; si vous forkez sauvagement (archétype « Aucun » sur un rôle riche, zéro doc, zéro export), chaque montée de version de Moodle devient une chasse aux régressions de permissions.

📚 Aller plus loin : docs.moodle.org propose une collection de recettes sous « Creating custom roles » (rôles Parent, Demo teacher, Forum moderator, Gallery viewer, etc.) : d’excellents points de départ à importer puis adapter, plutôt que de réinventer chaque matrice de capabilities.

10.3 Tableau récapitulatif final

Résumé

Ce chapitre a cartographié la couche « rôles » du système de permissions de Moodle 5.2. Les huit rôles standards couvrent le cycle pédagogique complet — Manager pour la gestion déléguée, Course creator pour l’ouverture de cours, les deux Enseignants pour la construction et l’animation, Student pour la participation, Guest pour la consultation anonyme, et les deux rôles automatiques Authenticated user (socle système de tout connecté) et sa variante frontpage. Point cardinal : l’administrateur n’est pas un rôle mais un statut qui court-circuite le système de permissions, à réserver aux opérations qui l’exigent et à protéger (MFA, comptes nominatifs, liste minimale).

Les archétypes rattachent chaque rôle à une famille, pilotent les permissions par défaut des capabilities apportées par les futurs plugins et alimentent le bouton « Réinitialiser ». La création de rôles personnalisés s’appuie sur un formulaire dont trois champs sont des garde-fous : l’archétype, les contextes d’assignation autorisés, et les quatre matrices « Autoriser » (attributions, dérogations, changements de rôle, affichage) qui empêchent l’escalade de privilèges lors des délégations. Nos deux exemples — l’Inspecteur académique en lecture seule sur une catégorie, le Parent/Mentor dans le contexte utilisateur de l’enfant — illustrent la démarche liste blanche et l’usage du contexte le moins intuitif de Moodle. Enfin, les outils d’exploitation au quotidien : duplication et presets XML (à versionner !), « Prendre le rôle » et ses limites (préférer un compte de test ou « Se connecter sous ce nom » pour valider), et le trio d’audit Vérifier les permissions / page Permissions / Aperçu des capacités. La règle d’or transversale : un besoin local se traite par un override local, jamais en modifiant la définition globale d’un rôle standard.

Dans le prochain chapitre

Les rôles ne servent à rien sans utilisateurs à qui les attribuer. Le chapitre 3 s’attaque au cycle de vie des comptes utilisateurs et à l’authentification : création manuelle et importation en masse par CSV, champs de profil personnalisés, les méthodes d’authentification (manuelle, e-mail avec auto-inscription, LDAP, OAuth 2 — et comment brancher un SSO d’entreprise), les politiques de mots de passe, la suspension et la suppression de comptes face au RGPD, et la frontière — que vous savez désormais tracer — entre authentification (« qui es-tu ? ») et autorisation (« que peux-tu faire ? »), dont les rôles de ce chapitre sont la seconde moitié.