Chapitre 3 — Gestion des utilisateurs et authentification

Version de référence : Moodle 5.2 (PHP 8.3+, Bootstrap 5). Les chemins de navigation sont donnés en français, avec l’équivalent anglais entre parenthèses à la première occurrence lorsque c’est utile — l’interface d’administration de Moodle est intégralement traduite, mais la documentation officielle et les forums communautaires utilisent massivement les libellés anglais.

Dans les chapitres 1 et 2, vous avez découvert les fondations conceptuelles de Moodle : les contextes (system, catégorie, cours, module, bloc, utilisateur), les rôles (roles) et les capacités (capabilities). Ce chapitre s’attaque à la brique qui précède tout le reste : avant de pouvoir attribuer un rôle à quelqu’un dans un contexte, encore faut-il que ce « quelqu’un » existe dans la base et puisse prouver son identité. C’est tout l’objet de la gestion des utilisateurs et de l’authentification (authentication).

C’est aussi, en pratique, le premier gros chantier de tout administrateur Moodle : d’où viennent les comptes ? Qui les crée ? Comment les utilisateurs se connectent-ils ? Que fait-on quand quelqu’un part ? Que dit le RGPD ? Ce chapitre couvre l’intégralité de ces questions, exclusivement via l’interface web d’administration.

💡 Pour un dev React : si vous venez de l’écosystème Next.js, pensez à ce chapitre comme au moment où vous configurez NextAuth/Auth.js dans votre application : choix des providers (Credentials, Google, Azure AD, LDAP…), stratégie de session, callbacks de création de compte, mapping des attributs du profil. Moodle fait exactement la même chose, mais tout se configure dans l’interface web, sans toucher au code. Les « auth plugins » de Moodle sont l’équivalent conceptuel des providers d’Auth.js.

1. Le cycle de vie d’un compte utilisateur

1.1 Les trois questions que Moodle se pose

Avant d’entrer dans les écrans, il faut graver dans le marbre une distinction que Moodle applique rigoureusement et que les débutants confondent systématiquement :

Ces trois couches sont indépendantes et orthogonales. Un utilisateur peut être authentifié via Google OAuth2, inscrit à un cours via une cohorte synchronisée, et y détenir le rôle d’enseignant. Changer sa méthode d’authentification ne touche ni à ses inscriptions ni à ses rôles. C’est une architecture en pipeline :

                 PIPELINE DE CONNEXION D'UN UTILISATEUR MOODLE
                 =============================================

  ┌──────────────┐
  │  Navigateur   │  L'utilisateur arrive sur /login/index.php
  └──────┬───────┘  (ou clique sur un bouton SSO, ou est redirigé par l'IdP)
         │
         ▼
  ┌─────────────────────────────────────────────────────────────┐
  │ 1. AUTHENTIFICATION — « Qui es-tu ? »                        │
  │    Moodle interroge les plugins d'authentification ACTIVÉS,  │
  │    dans l'ORDRE défini par l'admin :                         │
  │      manual → ldap → oauth2 → saml2 → …                      │
  │    Le premier plugin qui reconnaît l'utilisateur gagne.      │
  │    ├─ Compte inexistant + plugin autorisant la création      │
  │    │  → création du compte (provisioning "just-in-time")     │
  │    └─ Échec partout → « Identifiant ou mot de passe erroné » │
  └──────┬──────────────────────────────────────────────────────┘
         │  session PHP créée (table mdl_sessions + cookie MoodleSession)
         ▼
  ┌─────────────────────────────────────────────────────────────┐
  │ 2. CONTRÔLES POST-LOGIN                                      │
  │    • compte suspendu ? → refus                               │
  │    • compte non confirmé ? → écran « confirmez votre email » │
  │    • politique à accepter (tool_policy) ? → écran consentement│
  │    • MFA exigée (tool_mfa) ? → parcours des facteurs         │
  │    • changement de mot de passe forcé ? → écran dédié        │
  │    • profil incomplet (champs requis) ? → édition du profil  │
  └──────┬──────────────────────────────────────────────────────┘
         ▼
  ┌─────────────────────────────────────────────────────────────┐
  │ 3. INSCRIPTIONS (enrolments) — « Où peux-tu entrer ? »       │
  │    Les plugins d'inscription déterminent la liste des cours  │
  │    visibles sur le tableau de bord. AUCUN lien avec l'auth.  │
  └──────┬──────────────────────────────────────────────────────┘
         ▼
  ┌─────────────────────────────────────────────────────────────┐
  │ 4. RÔLES & CAPACITÉS — « Que peux-tu faire ici ? »           │
  │    Évalués À CHAQUE PAGE, par contexte (cf. chapitres 1–2).  │
  └─────────────────────────────────────────────────────────────┘

💡 Pour un dev React : ce pipeline ressemble beaucoup à une chaîne de middleware Next.js : l’authentification joue le rôle du callback authorize() d’Auth.js, les contrôles post-login sont vos redirections conditionnelles dans middleware.ts, et l’évaluation des capacités à chaque page est l’équivalent d’un contrôle d’autorisation côté serveur dans chaque Server Component. Différence majeure : Moodle utilise une session serveur stateful (cookie MoodleSession pointant vers la table mdl_sessions), pas un JWT stateless. Il n’y a donc jamais de problème de « token pas encore expiré » : suspendre un compte ou fermer une session est effectif immédiatement.

1.2 Les étapes de vie d’un compte

Un compte utilisateur Moodle traverse typiquement les états suivants :

1. Création — par un admin (manuellement ou par CSV), par l’utilisateur lui-même (auto-inscription par email), ou automatiquement au premier login réussi via une source externe (LDAP, OAuth2, SAML2 : c’est le provisioning just-in-time).
2. Confirmation — certains modes (auto-inscription email, OAuth2 avec vérification d’email) créent le compte en état « non confirmé » : l’utilisateur doit cliquer un lien reçu par email. Un admin peut confirmer manuellement un compte bloqué à cette étape.
3. Complétion du profil — première connexion : Moodle peut forcer l’édition du profil si des champs obligatoires (standards ou personnalisés) sont vides.
4. Vie active — connexions, inscriptions aux cours, production de données (messages de forum, devoirs, notes, journaux d’événements).
5. Suspension — le compte est gelé : plus aucune connexion possible, mais toutes les données sont conservées. Réversible en un clic.
6. Suppression — le compte est anonymisé et marqué supprimé. Irréversible dans l’interface. Nous détaillerons les différences en section 9.

⚠️ Piège : dans Moodle, « supprimer un utilisateur » ne fait pas un DELETE FROM mdl_user. L’enregistrement reste en base avec un drapeau deleted = 1, le nom d’utilisateur est remplacé par une valeur dérivée de l’email et d’un horodatage, et la plupart des données personnelles sont vidées. Les traces pédagogiques (messages de forum, notes) peuvent subsister sous une identité anonymisée. Si votre objectif est la conformité RGPD, la suppression « bouton corbeille » ne suffit pas : utilisez le workflow de demandes de suppression de tool_dataprivacy (section 10), qui purge réellement les données selon le registre de rétention.

2. Naviguer dans l’administration des utilisateurs

Tout part de Administration du site > Utilisateurs (Site administration > Users). Vous y trouvez trois grands blocs : Comptes (Accounts), Permissions (vu aux chapitres 1–2) et Confidentialité et politiques (Privacy and policies, section 10).

2.1 La liste des utilisateurs

Administration du site > Utilisateurs > Comptes > Liste des utilisateurs (Browse list of users).

L’écran présente un tableau paginé : nom complet, adresse de courriel, ville, pays, dernier accès, et une colonne d’actions par ligne :

• icône crayon : modifier le profil (y compris changer la méthode d’authentification du compte via le menu déroulant « Choisir une méthode d’authentification » de la page d’édition — très utile pour migrer un compte manual vers oauth2, par exemple) ;
• icône œil : suspendre / réactiver le compte ;
• icône corbeille : supprimer le compte (avec écran de confirmation) ;
• icône cadenas (si présente) : déverrouiller un compte bloqué après trop d’échecs de connexion.

Au-dessus du tableau, un panneau « Nouveau filtre » permet de filtrer par nom, prénom, email, méthode d’authentification, date de dernière connexion, statut suspendu/confirmé, cohorte, rôle système, valeur d’un champ de profil personnalisé, etc. Les filtres sont cumulables (ET logique) et l’ensemble des filtres actifs s’affiche avec des boutons pour en retirer un ou tout réinitialiser. Depuis Moodle 4.x, la présentation est plus compacte, mais la logique n’a pas changé en 5.2.

💡 Pour un dev React : ces filtres sont l’équivalent d’un query builder au-dessus de la table mdl_user — pensez Prisma where: { AND: [...] } avec une UI générée. Notez que le filtre « dernier accès » est votre meilleur ami pour l’hygiène des comptes : « ne s’est jamais connecté » ou « inactif depuis 2 ans » sont des requêtes à lancer régulièrement.

2.2 Les actions en masse

Administration du site > Utilisateurs > Comptes > Actions en lot sur les utilisateurs (Bulk user actions).

Cet écran fonctionne en trois temps :

1. Filtrer : le même panneau de filtres que ci-dessus construit une liste « Utilisateurs disponibles ».
2. Sélectionner : vous déplacez des utilisateurs (ou « Tout ajouter ») vers la liste « Utilisateurs sélectionnés ».
3. Agir : un menu déroulant « Avec les utilisateurs sélectionnés… » propose :

⚠️ Piège : « Forcer le changement de mot de passe » n’a de sens que pour les comptes dont le mot de passe est géré par Moodle (manual, email). Pour un compte LDAP, OAuth2 ou SAML2, le mot de passe vit chez le fournisseur d’identité : Moodle ne peut ni le lire ni le forcer à changer. L’action sera silencieusement sans effet ou produira une erreur selon le plugin — vérifiez la méthode d’authentification avant vos opérations de masse.

2.3 Ajouter un utilisateur à la main

Administration du site > Utilisateurs > Comptes > Ajouter un utilisateur (Add a new user).

Le formulaire regroupe :

• Identifiant (username) : en minuscules par défaut (un réglage de sécurité, « Caractères étendus dans les identifiants », permet d’assouplir — à éviter) ;
• Méthode d’authentification : menu déroulant listant les plugins activés — c’est ici qu’on décide si ce compte se connectera par mot de passe Moodle, LDAP, OAuth2, etc. ;
• Mot de passe, avec deux cases importantes : « Générer le mot de passe et notifier l’utilisateur » (Moodle génère un mot de passe temporaire et envoie un email de bienvenue) et « Forcer le changement de mot de passe » ;
• Compte suspendu : permet de créer un compte inactif à l’avance ;
• Champs d’identité (prénom, nom, email, ville, pays, fuseau horaire, langue), description, avatar, noms alternatifs, et les champs de profil personnalisés (section 6).

3. Les méthodes d’authentification

Chaque méthode est un plugin d’authentification (auth plugin). On les gère depuis Administration du site > Plugins > Authentification > Gérer l’authentification (Manage authentication) — écran détaillé en section 4. Passons en revue chaque méthode importante.

3.1 Comptes manuels (manual)

Cas d’usage : la méthode par défaut, toujours activée (elle ne peut pas être désactivée : le compte admin principal en dépend). Les comptes sont créés par un administrateur — à la main ou par import CSV — et le mot de passe est stocké dans Moodle (hash bcrypt, renforcé par les peppers, cf. section 7).

Configuration : Administration du site > Plugins > Authentification > Comptes manuels. Les réglages sont minimes :

• Durée de validité du mot de passe (expiration) : désactivée par défaut ; on peut imposer une rotation (ex. 90 jours) avec seuil de notification avant expiration ;
• Verrouillage des champs de profil : pour chaque champ standard (prénom, nom, email…), trois valeurs — « Déverrouillé », « Déverrouillé si vide », « Verrouillé ». Verrouiller l’email empêche par exemple les utilisateurs de le modifier eux-mêmes.

Avantages : contrôle total, aucune dépendance externe, idéal pour les comptes de service, les comptes de test et les petites structures. Limites : aucun self-service (l’admin crée tout), pas de SSO, gestion des mots de passe à votre charge (support « j’ai oublié mon mot de passe » — heureusement, la réinitialisation par email est en libre-service).

💡 Pour un dev React : manual est exactement le Credentials Provider d’Auth.js : couple identifiant/mot de passe vérifié contre votre propre base. Et comme avec Credentials Provider, la recommandation est la même : réservez-le aux cas où aucun fournisseur d’identité externe n’est possible, car toute la charge de sécurité (force des mots de passe, réinitialisations, MFA) repose sur vous.

3.2 Auto-inscription par email (email)

Cas d’usage : sites ouverts au grand public (MOOC interne, association, formation continue) où l’on veut que les visiteurs créent eux-mêmes leur compte.

Fonctionnement : un bouton « Créer un compte » apparaît sur la page de connexion. Le visiteur remplit un formulaire (identifiant, mot de passe, email, prénom, nom, ville, pays + éventuels champs de profil personnalisés marqués « affiché sur la page d’inscription »), reçoit un email de confirmation, et son compte n’est actif qu’après clic sur le lien.

Configuration en deux endroits :

1. Sur Gérer l’authentification (paramètres communs, section 4) : le menu déroulant « Auto-inscription » (Self registration) doit être positionné sur « Auto-inscription par courriel ». Activer le plugin ne suffit pas — c’est ce menu qui fait apparaître le bouton « Créer un compte ». C’est aussi sur cette page que se saisissent les clés reCAPTCHA (clé de site et clé secrète, obtenues sur le service reCAPTCHA de Google).
2. Sur Administration du site > Plugins > Authentification > Auto-inscription par courriel : case « Activer l’élément reCAPTCHA », et verrouillage des champs de profil.

Complétez avec les réglages de domaines (également sur Gérer l’authentification) :

• Domaines de courriel autorisés (Allowed email domains) : liste blanche, ex. univ-exemple.fr entreprise.com — seuls ces domaines peuvent s’inscrire ;
• Domaines de courriel interdits (Denied email domains) : liste noire, ex. yopmail.com mailinator.com ;
• Restreindre les domaines lors du changement d’adresse : applique la liste blanche aussi quand un utilisateur existant modifie son email.

Avantages : zéro travail de création de comptes, parfait pour l’ouverture au public. Limites et risques : c’est la méthode la plus attaquée. Sans reCAPTCHA ni restriction de domaine, un site Moodle ouvert en auto-inscription se fait remplir de comptes de spam (bots qui créent des comptes pour poster des liens dans les profils et forums) en quelques jours. Les mesures indispensables : reCAPTCHA activé, restriction de domaines si votre public le permet, vérification de l’âge de consentement numérique (section 10.4), et une purge régulière des comptes jamais confirmés (le réglage « Suppression des comptes non confirmés » dans Administration du site > Serveur > Nettoyage fixe le délai avant purge automatique).

⚠️ Piège : ne laissez jamais l’auto-inscription par email activée « pour tester » sur un site de production accessible publiquement. C’est la première cause de sites Moodle transformés en fermes à spam. Si vous en avez besoin temporairement, combinez systématiquement reCAPTCHA + domaines autorisés, et vérifiez le réglage « Empêcher la création de comptes lors de l’authentification » quand vous ne voulez pas de nouveaux comptes du tout.

📚 Aller plus loin : la page « Email-based self-registration » sur docs.moodle.org détaille les gabarits d’emails de confirmation (personnalisables via Administration du site > Langue > Personnalisation de la langue, composant auth_email) et les stratégies anti-spam complémentaires (question de sécurité via plugins tiers, modération manuelle par confirmation admin).

3.3 LDAP (ldap)

Cas d’usage : entreprises et établissements disposant d’un annuaire LDAP (Lightweight Directory Access Protocol) — le plus souvent Active Directory (AD) de Microsoft, parfois OpenLDAP. Moodle vérifie le mot de passe directement contre l’annuaire : les utilisateurs gardent leur mot de passe « bureau/Windows ».

Fonctionnement : à la soumission du formulaire de connexion, Moodle effectue un bind LDAP avec l’identifiant/mot de passe fournis. Si le bind réussit, l’utilisateur est authentifié ; si le compte Moodle n’existe pas encore, il est créé à la volée avec les attributs de l’annuaire.

Configuration — Administration du site > Plugins > Authentification > Serveur LDAP. Les blocs principaux :

• Paramètres du serveur : URL (ldap://ad.exemple.fr ou mieux ldaps://ad.exemple.fr:636 pour le chiffrement TLS), version du protocole (3), encodage.
• Paramètres de liaison (bind settings) : le compte de service (« Distinguished name » + mot de passe) que Moodle utilise pour chercher les utilisateurs dans l’annuaire avant le bind. Créez dans votre AD un compte dédié en lecture seule (ex. CN=svc-moodle,OU=Services,DC=exemple,DC=fr) — jamais un compte d’admin de domaine.
• Paramètres de recherche d’utilisateurs (user lookup) : les contextes (branches de l’annuaire où chercher, ex. OU=Etudiants,DC=exemple,DC=fr; OU=Personnel,DC=exemple,DC=fr), la recherche en sous-arborescence, et surtout l’attribut utilisateur : sAMAccountName pour Active Directory, uid pour OpenLDAP. Le « type d’utilisateur » (MS ActiveDirectory / posixAccount / etc.) préconfigure des valeurs cohérentes.
• Mapping d’attributs (data mapping) : pour chaque champ de profil Moodle (prénom, nom, email, département, téléphone… et champs personnalisés), vous indiquez l’attribut LDAP source (ex. givenName, sn, mail, department) et trois comportements :
  • Mise à jour locale : « À la création » seulement, ou « À chaque connexion » (l’annuaire écrase le profil Moodle à chaque login) ;
  • Mise à jour externe : autoriser Moodle à écrire vers LDAP (rare, nécessite des droits d’écriture — généralement « Jamais ») ;
  • Verrouillage : verrouiller le champ côté Moodle pour que l’annuaire reste la source de vérité.
• Expiration de mot de passe et changement forcé : LDAP peut informer Moodle de l’expiration côté annuaire.

Synchronisation planifiée : le login crée les comptes à la volée, mais pour créer les comptes en avance et surtout pour détecter les départs, activez la tâche planifiée de synchronisation : Administration du site > Serveur > Tâches > Tâches planifiées, cherchez « Tâche de synchronisation des utilisateurs » du composant auth_ldap (désactivée par défaut ; planifiez-la par exemple chaque nuit). Le réglage « Utilisateurs supprimés dans LDAP » (Removed ext user) détermine le sort des comptes disparus de l’annuaire : Conserver interne (le compte devient utilisable en interne — dangereux), Suspendre (recommandé : réversible si l’utilisateur réapparaît dans l’annuaire) ou Supprimer complètement.

NTLM SSO, en bref : le plugin LDAP propose un mode « SSO NTLM » historique permettant aux postes Windows joints au domaine de se connecter sans saisir de mot de passe, via une négociation entre le navigateur et le serveur web. C’est une technologie vieillissante (configuration serveur délicate, NTLM déprécié par Microsoft au profit de Kerberos puis des protocoles web modernes) : en 2026, si vous voulez du SSO avec un environnement Microsoft, la voie royale est OAuth2 ou SAML2 vers Entra ID (sections 3.4 et 3.5), pas NTLM.

Avantages : mot de passe unique avec le SI existant, provisioning et dé-provisioning automatiques, mapping riche des attributs. Limites : ce n’est pas du SSO web (l’utilisateur retape son mot de passe dans Moodle), nécessite une connectivité réseau directe Moodle → annuaire (pare-feu, LDAPS), et le module PHP ldap doit être installé sur le serveur.

💡 Pour un dev React : LDAP joue ici le rôle d’une base d’utilisateurs externe interrogée par un Credentials Provider : Moodle relaie le couple login/mot de passe vers l’annuaire au lieu de vérifier un hash local. Le « bind user » est l’équivalent de la connection string de service avec des droits en lecture seule. Et la tâche de synchronisation nocturne, c’est votre cron job de réconciliation — le pattern classique « source of truth externe + réplique locale rafraîchie périodiquement ».

⚠️ Piège : après un changement de mot de passe du compte de service dans l’AD (rotation de sécurité…), plus personne ne peut se connecter à Moodle via LDAP — et le message d’erreur vu par les utilisateurs est un banal « identifiant ou mot de passe erroné ». Documentez ce compte de service et testez la connexion via le bouton « Test des paramètres » de la page de configuration LDAP après toute modification.

3.4 OAuth 2 (oauth2) — Google, Microsoft et fournisseurs génériques

Cas d’usage : le SSO web moderne et le plus simple à mettre en place. « Se connecter avec Google » pour un établissement sous Google Workspace, « Se connecter avec Microsoft » pour un tenant Microsoft 365/Entra ID, ou tout fournisseur compatible OpenID Connect (Keycloak, Okta, Authentik…).

Architecture Moodle : contrairement aux autres méthodes, OAuth2 se configure en deux étages :

1. Les services OAuth 2 (issuers) : Administration du site > Serveur > Services OAuth 2 (OAuth 2 services). C’est ici qu’on déclare les fournisseurs, leurs client ID/secret et leurs endpoints. Ces services sont réutilisés ailleurs dans Moodle (dépôts de fichiers Google Drive/OneDrive, SMTP OAuth…), pas seulement pour le login.
2. Le plugin d’authentification OAuth 2 : Administration du site > Plugins > Authentification > OAuth 2, qu’il faut activer sur la page « Gérer l’authentification » pour que les boutons apparaissent sur la page de connexion.

Créer le service côté Moodle

Sur la page Services OAuth 2, des boutons de création rapide préconfigurent les fournisseurs connus : Google, Microsoft, Facebook, Nextcloud, ainsi qu’un bouton « Personnalisé » (custom) pour tout fournisseur OpenID Connect (il suffit alors de renseigner l’URL de base du service : Moodle interroge le document de découverte .well-known/openid-configuration et remplit automatiquement les endpoints — authorization, token, userinfo — et les mappings de champs). Pour chaque service, vous renseignez :

• Nom (affiché sur le bouton de connexion) ;
• Identifiant client (Client ID) et Secret client (Client secret), obtenus chez le fournisseur (voir ci-dessous) ;
• Afficher sur la page de connexion : « Services de connexion et services internes » pour que le bouton apparaisse au login ;
• Optionnel : logo du bouton, portées (scopes) supplémentaires, restriction aux comptes d’un domaine (« hosted domain » pour Google, très utile pour n’accepter que @monlycee.fr).

Chaque service dispose ensuite de deux liens de gestion fine : Configurer les points d’accès (endpoints — visibles et éditables, utile pour les fournisseurs exotiques) et Configurer les correspondances des champs utilisateur (user field mappings : quel champ de la réponse userinfo alimente quel champ de profil Moodle — ex. given_name → firstname, email → email).

Créer les identifiants côté Google Cloud Console (pas à pas)

1. Sur console.cloud.google.com, créez (ou sélectionnez) un projet.
2. Menu « API et services > Écran de consentement OAuth » : configurez le nom de l’application, le logo, le type (interne si Google Workspace — recommandé, car cela restreint automatiquement au domaine — sinon externe).
3. Menu « API et services > Identifiants > Créer des identifiants > ID client OAuth » : type Application Web.
4. Dans « URI de redirection autorisés », ajoutez exactement : https://votre-moodle.fr/admin/oauth2callback.php — c’est l’URI de callback unique de Moodle pour tous les services OAuth2.
5. Copiez l’ID client et le secret dans le service Google côté Moodle.

Créer les identifiants côté Microsoft Entra ID (Azure) (pas à pas)

1. Sur portal.azure.com (ou entra.microsoft.com), ouvrez Microsoft Entra ID > Inscriptions d’applications (App registrations) > Nouvelle inscription.
2. Nom : « Moodle », types de comptes : généralement « Comptes dans cet annuaire d’organisation uniquement » (mono-tenant).
3. URI de redirection : type Web, valeur https://votre-moodle.fr/admin/oauth2callback.php.
4. Dans « Certificats et secrets », créez un secret client (attention à la durée de vie : notez la date d’expiration dans votre calendrier d’exploitation !).
5. Dans « API autorisées » (API permissions), vérifiez les permissions déléguées Microsoft Graph : openid, profile, email, User.Read.
6. Copiez l’« ID d’application (client) » et le secret dans le service Microsoft côté Moodle.

⚠️ Piège : les secrets client Entra ID expirent (6, 12 ou 24 mois maximum). Le jour de l’expiration, tous les logins Microsoft échouent d’un coup avec une erreur cryptique. Mettez un rappel avant l’échéance et renouvelez le secret dans Azure puis dans Moodle. Même vigilance pour l’écran de consentement Google en mode « externe » non publié : les tokens de test expirent.

Création de comptes et liaison de comptes (account linking)

Au premier clic sur le bouton, si aucun compte Moodle ne correspond :

• si le réglage « Empêcher la création de comptes lors de l’authentification » (page Gérer l’authentification) est désactivé, Moodle crée le compte. Le plugin OAuth 2 propose l’option « Exiger la vérification de l’adresse de courriel » (activée par défaut) : le compte reste non confirmé jusqu’au clic dans l’email — désactivez-la seulement si vous faites entièrement confiance aux emails du fournisseur (cas d’un tenant d’entreprise) ;
• s’il existe déjà un compte Moodle avec la même adresse email, Moodle propose la liaison : après vérification (par email), le login OAuth2 est rattaché au compte existant. Chaque utilisateur peut aussi gérer cela lui-même dans Préférences > Comptes liés (Linked logins) : un même compte Moodle peut ainsi accepter le login par mot de passe et par Google.

Avantages : mise en place en une heure, SSO véritable (si la session Google/Microsoft est ouverte, un clic suffit), sécurité déléguée au fournisseur (qui gère MFA, détection d’anomalies…), standard OpenID Connect. Limites : mapping de profil limité aux claims exposés par le userinfo ; pas de dé-provisioning automatique (un compte désactivé dans Google ne sera pas suspendu dans Moodle — prévoyez une revue périodique ou une synchronisation par un plugin dédié comme auth_oidc/local_o365 de Microsoft pour l’écosystème 365).

💡 Pour un dev React : c’est l’Authorization Code Flow OAuth2/OIDC classique que vous connaissez par cœur avec Auth.js : redirection vers l’authorization endpoint, retour sur l’unique callback admin/oauth2callback.php (l’équivalent de /api/auth/callback/[provider]), échange du code contre les tokens au token endpoint, appel userinfo, puis session locale. Le bouton « Personnalisé » avec découverte .well-known/openid-configuration correspond exactement à l’option wellKnown d’un provider OIDC générique dans Auth.js. La « liaison de comptes » est le pendant du allowDangerousEmailAccountLinking d’Auth.js — sauf que Moodle sécurise la liaison par une confirmation email au lieu de vous laisser assumer le danger.

📚 Aller plus loin : la page « OAuth 2 services » sur docs.moodle.org et la documentation moodledev.io sur l’API OAuth2 décrivent les system accounts (comptes système connectés, nécessaires pour les dépôts Google Drive/OneDrive mais pas pour le simple login) et le rafraîchissement des tokens. Pour un couplage profond avec Microsoft 365 (sync des utilisateurs, Teams, OneDrive), regardez l’ensemble de plugins de Microsoft (auth_oidc + local_o365), plus riche que l’OAuth2 cœur.

3.5 SAML 2 — auth_saml2 et la fédération d’identité

Cas d’usage : SSO institutionnel avec un IdP (Identity Provider, fournisseur d’identité) SAML : Entra ID, ADFS, Keycloak, Shibboleth IdP… C’est le protocole roi de l’enseignement supérieur, notamment via les fédérations d’identité comme RENATER (fédération Éducation-Recherche française) : un étudiant de n’importe quel établissement membre peut s’authentifier sur votre Moodle avec les identifiants de son établissement.

Concepts clés :

• IdP (Identity Provider) : le serveur qui détient les comptes et authentifie (l’université, Entra ID…) ;
• SP (Service Provider, fournisseur de services) : votre Moodle, qui consomme les assertions d’identité ;
• Métadonnées (metadata) : deux documents XML échangés une fois pour toutes — les métadonnées de l’IdP (URL de connexion, certificat de signature) importées dans Moodle, et les métadonnées du SP (générées par Moodle) déclarées côté IdP ;
• Assertions et attributs : à chaque login, l’IdP envoie une assertion signée contenant des attributs (mail, givenName, eduPersonPrincipalName…) que Moodle mappe vers le profil.

Le plugin à utiliser : Moodle a historiquement embarqué un plugin SAML natif rudimentaire, mais la communauté utilise massivement le plugin tiers auth_saml2 (maintenu par Catalyst IT), qui embarque sa propre pile SimpleSAMLphp : installation sans dépendance externe, configuration 100 % dans l’interface. C’est le choix recommandé en 2026. Installation : Administration du site > Plugins > Installer des plugins (depuis le répertoire officiel moodle.org/plugins).

Configuration type (auth_saml2) — Administration du site > Plugins > Authentification > SAML2 :

1. Métadonnées IdP : collez l’URL des métadonnées de l’IdP (ex. l’URL de fédération Entra ID, ou l’URL de métadonnées de la fédération RENATER) ; le plugin les télécharge et les rafraîchit périodiquement.
2. Récupérez les métadonnées SP de votre Moodle à l’adresse indiquée par le plugin (/auth/saml2/sp/metadata.php) et déclarez-les côté IdP (dans Entra ID : « Applications d’entreprise > Nouvelle application > Créer votre propre application > SSO SAML », en renseignant Identifier/Entity ID et Reply URL/ACS depuis ces métadonnées ; dans une fédération RENATER : dépôt des métadonnées SP auprès de la fédération).
3. Mode de connexion (Dual login) : « Non » redirige tout le monde vers l’IdP dès l’arrivée sur la page de login ; « Oui » affiche la page de login Moodle classique avec en plus un lien/bouton IdP — indispensable tant que vous avez des comptes manuels (dont l’admin !) ;
4. Mapping : quel attribut SAML sert d’identifiant de correspondance (souvent l’email ou eduPersonPrincipalName) et le mapping des attributs vers les champs de profil, avec les mêmes options « à la création / à chaque connexion » que LDAP ;
5. Création automatique de comptes (auto-create) : activer pour le provisioning just-in-time ; on peut restreindre par expression sur un attribut (ex. n’accepter que les affiliations student ou staff).

Avantages : SSO complet, standard universel en éducation, fédérations multi-établissements, l’IdP garde la main sur MFA et les politiques de sécurité. Limites : la mise en route exige une coordination avec l’équipe IdP (échange de métadonnées, choix des attributs libérés — dans une fédération, l’IdP décide quels attributs il « libère » vers votre SP, et c’est une négociation classique) ; le débogage SAML (horloges désynchronisées, certificats expirés, attributs manquants) est plus rugueux qu’OAuth2.

⚠️ Piège : en mode « Dual login : Non » (redirection forcée vers l’IdP), si l’IdP tombe ou si la configuration casse, plus personne ne peut se connecter, pas même l’admin. Le plugin auth_saml2 prévoit une porte de sortie : l’URL de login avec paramètre de contournement (/login/index.php?saml=off, protégeable par un mot de passe de configuration). Notez cette URL dans votre documentation d’exploitation avant d’activer la redirection forcée.

💡 Pour un dev React : SAML est l’ancêtre vénérable d’OpenID Connect — mêmes idées (redirections, assertions signées, claims), mais en XML signé plutôt qu’en JWT, et avec un échange de métadonnées statique au lieu de la découverte dynamique .well-known. Si vous avez déjà branché Auth.js sur un provider BoxyHQ SAML ou utilisé @node-saml, vous connaissez la douleur des certificats et du clock skew. Retenez : OAuth2/OIDC quand vous contrôlez les deux bouts, SAML quand vous entrez dans un monde institutionnel fédéré qui l’exige.

3.6 CAS (cas)

Cas d’usage : CAS (Central Authentication Service), protocole SSO développé à Yale et très répandu dans les universités françaises (souvent via les serveurs CAS d’Apereo adossés aux ENT). Si votre établissement a déjà un serveur CAS, ce plugin offre un SSO web simple.

Fonctionnement : l’utilisateur est redirigé vers la page de login du serveur CAS ; après authentification, il revient vers Moodle avec un ticket que Moodle valide auprès du serveur.

Configuration — Administration du site > Plugins > Authentification > Serveur CAS (SSO) : nom d’hôte du serveur CAS, URI de base, port, version du protocole (CAS 2.0/3.0), mode « multi-authentification » (affiche le choix entre CAS et login classique, l’équivalent du dual login SAML), et logout partagé. Particularité notable : le plugin CAS embarque toute la section de configuration LDAP — car CAS n’authentifie que l’identifiant, sans fournir d’attributs riches ; le plugin va donc typiquement chercher prénom/nom/email dans l’annuaire LDAP de l’établissement pour remplir le profil.

Avantages : SSO simple, mature, bien connu des DSI universitaires françaises. Limites : protocole en perte de vitesse au profit d’OIDC/SAML ; dépendance à un annuaire LDAP annexe pour les attributs de profil.

3.7 Shibboleth (mention)

Le plugin Shibboleth historique de Moodle s’appuie sur un Service Provider Shibboleth natif installé sur le serveur web (module Apache mod_shib) : c’est l’approche SAML « à l’ancienne », où l’authentification est faite par le serveur web avant même que PHP ne s’exécute, Moodle lisant les attributs dans les variables d’environnement. C’est robuste et c’est la façon historique de rejoindre la fédération RENATER, mais la configuration est entièrement hors interface Moodle (fichiers du SP Shibboleth, configuration Apache). En 2026, sauf exigence d’infrastructure, préférez auth_saml2 qui rend le même service intégralement depuis l’interface web. Retenez simplement l’existence de ce plugin pour comprendre les installations existantes que vous pourriez reprendre.

3.8 Pas de connexion (nologin)

Faux plugin, vrai outil d’administration : « Pas de connexion » (No login) n’authentifie jamais personne. Affecter cette méthode à un compte (via la page d’édition du profil, menu « Choisir une méthode d’authentification ») interdit toute connexion sur ce compte sans le suspendre : le compte reste « actif » (visible normalement dans les cours, dans les listes, il peut recevoir des notifications selon les réglages) mais nul ne peut s’y connecter — pas même avec le bon mot de passe. Cas d’usage : geler un compte litigieux le temps d’une enquête, verrouiller un compte de service qui ne doit jamais servir au login interactif, ou neutraliser l’ancien compte d’un utilisateur migré. Différence avec la suspension : la suspension est un état du compte (drapeau, réversible, visible dans les filtres « suspendu »), nologin est une méthode d’authentification (le compte paraît normal, seul le login est impossible).

3.9 Utilisateurs des services web (webservice)

Méthode dédiée aux comptes techniques qui n’accèdent à Moodle que via les services web (API REST). Un compte en méthode webservice peut obtenir des jetons et appeler l’API, mais ne peut pas se connecter à l’interface web. C’est la bonne pratique pour les intégrations machine-à-machine (synchronisation SIS, application mobile maison, connecteurs) : créez un compte de service dédié, méthode webservice, avec un rôle sur mesure ne portant que les capacités nécessaires aux fonctions appelées — jamais un compte admin. La création des jetons se fait dans Administration du site > Serveur > Services web > Gérer les jetons (nous y reviendrons dans le chapitre consacré aux services web).

💡 Pour un dev React : le jeton de service web Moodle est l’équivalent d’une API key de service account — pas d’un JWT de session utilisateur. Il ne périme pas par défaut (une date de validité est configurable à la création), n’emporte aucun scope en lui-même (les droits viennent du rôle du compte), et se passe en paramètre de requête. Traitez-le comme un secret d’infrastructure : coffre-fort, rotation, un jeton par intégration.

3.10 Tableau comparatif des méthodes

📚 Aller plus loin : le répertoire des plugins (moodle.org/plugins, catégorie Authentication) recense des dizaines d’autres méthodes : auth_oidc (Microsoft, plus intégré que l’OAuth2 cœur), auth_lenauth, authentification par lien magique (auth_magic), etc. Avant d’installer un plugin tiers, vérifiez toujours sa compatibilité déclarée avec Moodle 5.2, la date de dernière mise à jour et l’activité du dépôt GitHub — un plugin d’authentification abandonné est un risque de sécurité majeur.

4. Gérer l’authentification : ordre et paramètres communs

Administration du site > Plugins > Authentification > Gérer l’authentification (Manage authentication) est le tableau de bord central. Il comporte deux zones.

4.1 Le tableau des plugins

Chaque plugin d’authentification y apparaît avec :

• le nombre d’utilisateurs rattachés (précieux avant de désactiver quoi que ce soit !) ;
• l’icône œil pour activer/désactiver ;
• les flèches haut/bas pour changer l’ordre ;
• le lien Réglages vers sa page de configuration.

L’ordre a une vraie importance fonctionnelle : quand un utilisateur soumet le formulaire identifiant/mot de passe, Moodle interroge les plugins dans l’ordre affiché et retient le premier qui valide. Pour les comptes existants, le plugin propriétaire du compte est essayé en priorité ; l’ordre joue surtout pour les identifiants inconnus (quel plugin a le droit de créer le compte) et pour les comptes dont le plugin d’origine échoue. Règle pratique : placez la méthode qui gère le plus d’utilisateurs en premier, et ne laissez activé que ce que vous utilisez réellement — chaque plugin actif est une surface d’attaque.

⚠️ Piège : désactiver un plugin d’authentification bloque immédiatement la connexion de tous les comptes rattachés à ce plugin (ils ne sont ni suspendus ni supprimés, juste incapables de se connecter). La colonne « Utilisateurs » est là pour vous éviter de désactiver « ce vieux plugin LDAP qui ne sert plus » et de découvrir que 3 000 comptes en dépendaient. Avant toute désactivation : filtrez la liste des utilisateurs par méthode d’authentification et migrez les comptes (édition du profil, ou champ auth dans un import CSV de mise à jour).

4.2 Les paramètres communs

Sous le tableau, une longue liste de réglages transversaux. Les plus importants :

⚠️ Piège : l’URL de connexion alternative est le réglage le plus dangereux de cette page. Si vous y mettez une URL cassée, la page de login normale devient inaccessible et vous êtes enfermé dehors. Solution de secours à connaître avant l’accident : la page de login standard reste accessible en forçant https://votre-moodle.fr/login/index.php (le paramètre de contournement documenté selon la configuration), et en dernier recours le réglage se vide via la ligne de commande. Testez toujours l’URL alternative dans un navigateur en session privée avant de valider.

5. Création en masse : l’import CSV (« Upload users »)

Administration du site > Utilisateurs > Comptes > Importation d’utilisateurs (Upload users). C’est l’outil à tout faire de l’administrateur : créer, mettre à jour, suspendre, supprimer, inscrire à des cours et à des cohortes — le tout par fichier plat. À maîtriser absolument.

5.1 Format du fichier

• Encodage : UTF-8 (sans BOM de préférence — voir les pièges) ; le formulaire propose un menu « Encodage » si votre fichier vient d’Excel en Latin-1.
• Délimiteur : virgule par défaut ; le formulaire propose aussi le point-virgule (choix d’Excel en locale française !), les deux-points et la tabulation. Le menu « Délimiteur CSV » doit correspondre à votre fichier.
• Première ligne = en-têtes, noms de colonnes en anglais et en minuscules.

Colonnes obligatoires pour une création :

Colonnes optionnelles les plus utiles :

5.2 Exemple complet commenté

username,firstname,lastname,email,idnumber,auth,password,cohort1,course1,role1,profile_field_promo
mdupont,Marie,Dupont,marie.dupont@univ-exemple.fr,20260042,manual,changeme,L1-INFO,PROG101,student,2026
jmartin,Jules,Martin,jules.martin@univ-exemple.fr,20260043,manual,changeme,L1-INFO,PROG101,student,2026
sbernard,Sophie,Bernard,s.bernard@univ-exemple.fr,E00317,saml2,,PERSONNEL,PROG101,editingteacher,
svc-reporting,Service,Reporting,svc-reporting@univ-exemple.fr,,webservice,,,,,"

Lecture ligne à ligne :

• Lignes 2–3 : deux étudiantes en méthode manual, mot de passe initial changeme (combinez avec l’option « Forcer le changement de mot de passe » !), ajoutées à la cohorte d’idnumber L1-INFO, inscrites comme étudiantes au cours de nom court PROG101, champ personnalisé promo = 2026.
• Ligne 4 : une enseignante en méthode saml2 — la colonne password est vide, ce qui est normal : son mot de passe vit chez l’IdP. Elle est inscrite au même cours avec le rôle editingteacher (nom court du rôle, pas son libellé français).
• Ligne 5 : un compte technique en méthode webservice, sans cohorte ni cours.

Autre motif fréquent, la génération de mots de passe : mettez la valeur littérale changeme dans la colonne password ou, mieux, utilisez l’option de formulaire « Mot de passe des nouveaux utilisateurs » = « Créer un mot de passe si nécessaire et l’envoyer par courriel » : Moodle génère alors un mot de passe temporaire et envoie l’email de bienvenue à chaque nouveau compte (l’envoi est étalé par la tâche cron). Dans les anciennes versions on utilisait la valeur spéciale createpassword dans la colonne ; l’option de formulaire est aujourd’hui la voie propre.

5.3 Les options du formulaire d’import

Après le dépôt du fichier, un écran de prévisualisation montre les premières lignes interprétées et les options :

• Type d’importation :
  • Ajouter seulement de nouveaux utilisateurs, ignorer les existants (le mode sûr par défaut),
  • Tout ajouter, avec un numéro ajouté aux identifiants en doublon (à éviter, crée des doublons),
  • Ajouter les nouveaux et mettre à jour les existants (le mode « synchronisation »),
  • Mettre à jour uniquement les utilisateurs existants ;
• Détails de l’utilisateur existant (en mode mise à jour) : ne pas modifier / écraser avec le CSV / écraser seulement les champs vides ;
• Mot de passe existant : conserver ou écraser ;
• Forcer le changement de mot de passe : non / oui pour tous / seulement ceux ayant un mot de passe faible ;
• Autoriser les renommages / les suppressions / les suspensions : verrous de sécurité des colonnes oldusername, deleted, suspended ;
• Standardiser les identifiants : force la mise en minuscules et le nettoyage des username ;
• Sélectionner pour des opérations en masse : injecte les utilisateurs traités dans l’écran « Actions en lot » (pratique pour enchaîner import + envoi de message).

Le rapport final liste ligne par ligne le résultat (créé, mis à jour, erreur) avec le détail des erreurs : gardez-en une copie.

5.4 Erreurs fréquentes

⚠️ Piège : en mode « Ajouter les nouveaux et mettre à jour les existants » avec « Détails de l’utilisateur existant : écraser », la correspondance se fait sur le username. Si votre SI a réattribué un identifiant, vous écraserez le profil d’une autre personne sans aucun avertissement. Avant tout import de mise à jour massif : sauvegarde de la base, test sur 3 lignes, et vérification que username (ou votre clé de réconciliation idnumber) est stable dans le temps côté SI.

💡 Pour un dev React : pensez cet écran comme un endpoint d’upsert idempotent : create only = INSERT ... ON CONFLICT DO NOTHING, add and update = upsert complet. La bonne pratique DevOps s’applique : scriptez la génération du CSV depuis votre source de vérité (SIRH, scolarité) plutôt que de le maintenir à la main, versionnez les fichiers importés, et faites tourner l’import sur une instance de préproduction d’abord. Pour l’industrialisation totale, il existe aussi tool_uploaduser en ligne de commande et les services web core_user_create_users / core_user_update_users — même logique, sans clic.

6. Champs de profil personnalisés (custom profile fields)

Le profil standard (nom, email, ville…) ne suffit jamais : numéro de promotion, service RH, statut, consentement photo… Les champs de profil personnalisés étendent le profil sans toucher au code.

Administration du site > Utilisateurs > Comptes > Champs de profil utilisateur (User profile fields).

6.1 Catégories et types

Les champs s’organisent en catégories (simples intercalaires visuels dans le formulaire de profil : « Scolarité », « RH »…) que vous créez, ordonnez et renommez sur ce même écran. Le bouton « Créer un nouveau champ de profil » propose les types :

6.2 Les réglages transverses de chaque champ

Quel que soit le type, chaque champ porte :

• Nom court (shortname) : la clé technique — c’est lui qu’on retrouve dans les colonnes CSV profile_field_<shortname> et dans les mappings d’authentification. Choisissez-le court, en minuscules, sans accent, et ne le changez plus jamais ;
• Nom : le libellé affiché ;
• Champ requis ? : si oui, l’utilisateur est bloqué sur l’édition de profil à la connexion tant qu’il n’a pas renseigné le champ ;
• Champ verrouillé ? : l’utilisateur voit la valeur mais ne peut pas la modifier (indispensable quand la valeur vient d’une source externe) ;
• Valeur unique ? : refuse les doublons entre utilisateurs (parfait pour un matricule) ;
• Affiché sur la page d’inscription ? : ajoute le champ au formulaire d’auto-inscription par email (3.2) ;
• Visibilité : « Invisible » (seuls les admins le voient — bon pour les données internes), « Visible pour l’utilisateur » (lui et les admins), « Visible par tous » (apparaît sur le profil public), et l’option « Visible par les enseignants » dans les versions récentes (visible des enseignants des cours de l’utilisateur).

6.3 À quoi servent ces champs concrètement ?

• Import/export CSV : colonne profile_field_<shortname> en lecture comme en écriture (l’action « Télécharger » des actions en masse exporte les champs personnalisés) ;
• Filtres : le filtre « Champ de profil » de la liste des utilisateurs et des actions en masse permet de cibler « tous les promo = 2026 » ;
• Mapping avec les authentifications externes : dans les pages de configuration LDAP, CAS, SAML2 et dans les correspondances de champs OAuth2, les champs personnalisés apparaissent en bas de la liste de mapping — vous pouvez donc alimenter automatiquement profile_field_service depuis l’attribut department de l’AD, en le verrouillant côté Moodle ;
• Cohortes dynamiques : le cœur de Moodle ne crée pas de cohortes par règle, mais le plugin tiers très répandu tool_dynamic_cohorts (Catalyst) construit des cohortes alimentées automatiquement par des conditions sur les champs de profil, standards ou personnalisés (« tous les statut = Personnel ») — combiné à la synchronisation de cohortes (chapitre 4), c’est le chaînon qui automatise les inscriptions de bout en bout ;
• Restriction d’accès dans les cours : la restriction « Profil utilisateur » des activités peut conditionner l’accès à une valeur de champ.

💡 Pour un dev React : c’est un schéma extensible en EAV (entity–attribute–value) au-dessus de la table utilisateur — l’équivalent d’un champ metadata: Json sur votre modèle User Prisma, mais avec validation, UI de saisie, visibilité et unicité gérées par la plateforme. Le « nom court » est la clé du JSON : traitez-le avec la même rigueur qu’un nom de colonne — le renommer casserait silencieusement vos imports CSV et vos mappings d’authentification.

📚 Aller plus loin : depuis Moodle 4.x, un cadre analogue de champs personnalisés existe aussi pour les cours (Administration du site > Cours > Champs personnalisés pour les cours) et s’étend progressivement à d’autres entités. La logique (catégories, types, visibilité) est la même : ce que vous apprenez ici se réutilise.

7. Politique de mots de passe et verrouillage de comptes

Administration du site > Sécurité > Politiques du site (Site security settings). Cette page mélange plusieurs sujets de sécurité ; concentrons-nous sur les mots de passe.

7.1 La politique

Une fois la case « Politique de mot de passe » activée, vous réglez :

S’y ajoute « Vérifier le mot de passe lors de la connexion » (recontrôle de conformité au login, pour rattraper les comptes créés avant un durcissement de la politique) et, côté plugin manual, l’expiration périodique (3.1). Gardez en tête la doctrine moderne : la rotation forcée systématique est déconseillée (elle produit Motdepasse1, Motdepasse2…) ; préférez longueur + MFA.

La politique s’applique uniquement aux mots de passe gérés par Moodle (manual, email, et les changements faits dans Moodle). Les mots de passe LDAP/OAuth2/SAML2 relèvent de la politique du fournisseur d’identité.

7.2 Verrouillage de compte après échecs

Sur la même page, le bloc de verrouillage de compte (account lockout) :

• Seuil de verrouillage (Account lockout threshold) : nombre d’échecs consécutifs avant blocage (désactivé par défaut ; une valeur classique : 5–10) ;
• Fenêtre d’observation (Lockout observation window) : durée pendant laquelle les échecs s’additionnent (défaut 30 min) ;
• Durée du verrouillage (Lockout duration) : défaut 30 min.

Un compte verrouillé reçoit un email avec un lien de déverrouillage, et l’admin peut déverrouiller depuis la liste des utilisateurs. Complétez par la surveillance des échecs : Administration du site > Rapports > Journaux (événement « Échec de connexion ») et le réglage de notification des échecs répétés aux admins.

7.3 Les « password peppers » (Moodle 4.3+)

Depuis Moodle 4.3, les hashs de mots de passe peuvent être renforcés par un pepper (« poivre ») : une chaîne secrète stockée hors base de données, dans la configuration du serveur, combinée au mot de passe avant hachage. Ainsi, même une fuite complète de la base ne permet pas d’attaquer les hashs sans posséder aussi le secret du serveur. C’est un réglage d’infrastructure (défini dans le fichier de configuration de la plateforme par l’équipe d’exploitation, avec un mécanisme de rotation par peppers numérotés — les hashs migrent au fil des connexions) : en tant qu’administrateur fonctionnel, sachez qu’il existe, demandez à l’hébergeur s’il est en place, et retenez qu’il complète — sans le remplacer — le hachage bcrypt standard.

💡 Pour un dev React : le pepper est le même concept que dans n’importe quelle stack : hash(password + PEPPER) où PEPPER vit dans une variable d’environnement/un vault, jamais en base — exactement comme votre AUTH_SECRET d’Auth.js ne doit jamais finir dans la table de sessions. Sel (par hash, en base) ≠ pepper (global, hors base) : Moodle utilise les deux, bcrypt gérant le sel nativement.

7.4 Forcer un changement de mot de passe

Trois voies : la case « Forcer le changement de mot de passe » sur la fiche d’un utilisateur (ou à la création), l’action en masse du même nom (2.2), et l’option d’import CSV (5.3). Dans tous les cas, l’utilisateur est redirigé vers l’écran de changement à sa prochaine connexion, sans pouvoir y échapper.

8. MFA : l’authentification multifacteur (tool_mfa)

Depuis Moodle 4.3, l’authentification multifacteur est native, via l’outil d’administration tool_mfa (issu du plugin de Catalyst intégré au cœur). En Moodle 5.2, c’est un composant standard, désactivé par défaut.

Activation : Administration du site > Plugins > Outils d’administration > Authentification multifacteur (Multi-factor authentication) — cochez « MFA activée » (Enable MFA plugin), puis gérez la liste des facteurs (factors), chacun avec son interrupteur, ses réglages, son ordre et ses points.

8.1 Le système de points

Originalité de tool_mfa : chaque facteur validé rapporte des points, et l’utilisateur doit atteindre 100 points pour entrer. Cela permet des politiques nuancées :

• TOTP = 100 points → une app d’authentification suffit seule ;
• Email = 100 points → le code par email suffit seul (politique faible mais simple) ;
• Plage IP = 100 points → sur le réseau du campus, aucun facteur supplémentaire n’est demandé ; à l’extérieur, il faut le TOTP ;
• Combinaisons : IP = 50 + Email = 50 → il faut être sur site et valider le code email, etc.

Les facteurs sont présentés à l’utilisateur dans l’ordre configuré jusqu’à atteindre 100 points. Certains facteurs sont « transparents » (évalués sans interaction : plage IP, période de grâce, type d’authentification, rôle), d’autres « actifs » (saisie d’un code).

8.2 Les facteurs disponibles

8.3 Politique type de déploiement

Un déploiement raisonnable pour un établissement :

1. Activer MFA avec Période de grâce = 100 points pendant 30 jours + TOTP = 100 points : personne n’est bloqué, chacun est invité à enrôler son application ;
2. Communiquer, surveiller le taux d’enrôlement (le rapport du plugin liste les facteurs configurés par utilisateur) ;
3. Réduire puis désactiver la période de grâce ; ajouter Plage IP = 100 si vous voulez épargner les postes sur site ;
4. Exempter les comptes SSO via le facteur Type d’authentification si l’IdP impose déjà sa MFA (éviter la double MFA, source de ras-le-bol) ;
5. Pour les comptes à privilèges, exiger TOTP sans exemption IP.

8.4 Procédure de secours : « j’ai perdu mon téléphone »

C’est LE cas de support à préparer avant l’activation :

• L’utilisateur qui a encore accès par un autre facteur (email…) peut gérer ses facteurs dans Préférences > Authentification multifacteur : supprimer l’ancien TOTP, en enrôler un nouveau ;
• Sinon, un administrateur peut réinitialiser les facteurs de l’utilisateur depuis l’administration MFA (réinitialisation du facteur pour un compte donné, ou via l’outil en ligne de commande côté exploitation) ; l’utilisateur repasse alors par l’enrôlement, éventuellement couvert par la période de grâce ;
• En dernier recours, l’admin peut temporairement désactiver un facteur globalement — à éviter, car cela affaiblit tout le monde ;
• Établissez une procédure de vérification d’identité avant toute réinitialisation (rappel téléphonique, pièce d’identité au guichet) : la réinitialisation MFA « sur simple email au support » est le vecteur classique des attaques par ingénierie sociale.

⚠️ Piège : testez toujours votre configuration MFA avec un second navigateur/une session privée en restant connecté en admin dans le premier. Une combinaison de facteurs mal pensée (ex. seul facteur actif = plage IP, et vous testez depuis chez vous) peut verrouiller tout le monde dehors, y compris vous. La documentation du plugin décrit le paramètre de contournement d’urgence côté configuration serveur — sachez qu’il existe avant d’en avoir besoin.

💡 Pour un dev React : le système de points de tool_mfa est une jolie généralisation de ce que vous coderiez à la main avec Auth.js + un provider TOTP : au lieu d’un booléen mfaVerified, une somme pondérée de signaux (possession, réseau, rôle, fraîcheur d’enrôlement) contre un seuil — conceptuellement proche du conditional access d’Entra ID ou d’un moteur de règles d’authentification adaptative.

📚 Aller plus loin : la page « Multi-factor authentication » sur docs.moodle.org tient à jour la liste des facteurs par version, et le dépôt GitHub de tool_mfa documente la création de facteurs personnalisés (si un jour vous repassez côté code : un facteur = un sous-plugin factor_xxx).

9. Suspension vs suppression : bien choisir

Récapitulons rigoureusement la différence — c’est une question d’entretien d’admin Moodle classique, et surtout une décision aux conséquences très différentes.

Règle d’or : suspendez d’abord, supprimez plus tard (voire jamais, en dehors du circuit RGPD). Une politique saine : suspension automatique au départ (via la sync LDAP ou un import CSV suspended=1), délai de quarantaine de 6–12 mois, puis traitement conforme au registre de rétention.

⚠️ Piège : la suppression via l’icône corbeille conserve l’enregistrement anonymisé en base, notamment pour empêcher la réutilisation de l’identifiant et préserver l’intégrité référentielle. Conséquence contre-intuitive : recréer un compte avec le même username que le compte supprimé fonctionne, mais l’historique de l’ancien compte ne lui sera pas rattaché — c’est un utilisateur neuf. Si quelqu’un « revient », il fallait le suspendre, pas le supprimer.

10. RGPD côté administrateur : confidentialité et politiques

Moodle embarque depuis la version 3.5 une panoplie RGPD complète, regroupée sous Administration du site > Utilisateurs > Confidentialité et politiques (Privacy and policies). Quatre briques : les réglages de confidentialité, les politiques à consentir (tool_policy), le registre des données (tool_dataprivacy — data registry) et les demandes des personnes (data requests).

10.1 Politiques et consentements (tool_policy)

Confidentialité et politiques > Gestion des politiques (Manage policies). Vous y rédigez des documents versionnés : politique de confidentialité, conditions d’utilisation, charte cookies, autres chartes internes. Pour chacun :

• type (politique du site, de confidentialité, tierce partie…), audience (tous, utilisateurs authentifiés, invités) ;
• contenu en deux volets : résumé (affiché en premier) et texte complet ;
• statut : brouillon / actif ; chaque modification substantielle crée une nouvelle version, et vous choisissez si elle exige un re-consentement de tous ou s’applique silencieusement (version mineure).

À la première connexion (et à chaque nouvelle version majeure), l’utilisateur traverse un écran de consentement bloquant, case par politique. L’écran Consentements (User agreements) liste qui a accepté quoi et quand — c’est votre preuve d’accountability — et permet à un admin de consigner un consentement donné « sur papier » au nom d’un utilisateur (mineurs, cf. 10.4).

Le réglage préalable qui gouverne tout : dans Confidentialité et politiques > Réglages des politiques, le « Gestionnaire de politiques » (Site policy handler) doit être positionné sur « Politiques (tool_policy) » — sinon Moodle utilise l’ancien mécanisme d’URL de charte unique.

10.2 Le registre des données (data registry)

Confidentialité et politiques > Registre des données. C’est la déclinaison Moodle du registre des traitements : pour chaque type de contexte (site, catégorie, cours, module d’activité, bloc, utilisateur), vous définissez :

• des catégories de données (ex. « Données pédagogiques », « Données d’identité ») ;
• des finalités (purposes) : base légale RGPD (consentement, contrat, intérêt légitime, mission publique…), catégories de données sensibles éventuelles, et surtout une durée de rétention (ex. « 5 ans après la fin du cours ») avec l’option « inclut les données des utilisateurs supprimés » ;
• l’association contexte → catégorie + finalité, avec héritage : un réglage par défaut au niveau « tous les cours », affinable cours par cours ou module par module.

Ce registre n’est pas décoratif : il pilote la purge automatique. Une tâche planifiée identifie les contextes dont la rétention est expirée et les propose à la suppression (validable manuellement ou automatiquement selon vos réglages). Il alimente aussi la « fiche descriptive » que chaque utilisateur peut consulter (« Résumé de conservation des données » en pied de page).

10.3 Les demandes de données (data requests) et le rôle de DPO

Confidentialité et politiques > Demandes de données. Deux types de demandes, que l’utilisateur peut déposer lui-même depuis son profil (« Confidentialité et politiques ») ou qu’un admin/DPO peut créer au nom de quelqu’un :

• Export (le SAR — Subject Access Request, droit d’accès) : Moodle interroge tous les plugins via son API de confidentialité et produit une archive téléchargeable (HTML navigable + données) de tout ce que la plateforme sait de la personne, contexte par contexte ;
• Suppression (droit à l’effacement) : purge réelle des données personnelles dans tous les plugins, en respectant le registre (certaines données peuvent être conservées si une base légale le justifie).

Le workflow : demande déposée → statut « En attente d’approbation » → le DPO (Délégué à la protection des données / Data Protection Officer) approuve ou rejette (avec motif) → traitement asynchrone par les tâches planifiées → notification et téléchargement (les exports expirent après un délai configurable). Les réglages de la section (Confidentialité et politiques > Réglages de confidentialité) permettent l’approbation automatique des exports et/ou suppressions, la durée de validité des exports, et le contact affiché.

Qui est DPO ? Par défaut, l’admin. Proprement : créez un rôle « DPO » assignable au contexte système, portant la capacité tool/dataprivacy:managedatarequests (et ses voisines tool/dataprivacy:managedataregistry, tool/dataprivacy:requestdeleteforotheruser…), puis désignez ce rôle dans le réglage « Rôle du délégué à la protection des données ». Le lien « Contacter le délégué à la protection des données », activable dans les réglages, ouvre un canal de demande directement depuis le profil de chaque utilisateur.

10.4 Âge de consentement numérique

Dans Réglages de confidentialité, la vérification de l’âge de consentement numérique (Digital age of consent verification) ajoute au formulaire d’auto-inscription une question âge + pays : en dessous de l’âge légal du pays (base configurable : 15 ans en France, 16 par défaut RGPD, 13 dans certains pays), l’auto-inscription est bloquée et l’écran invite à faire créer le compte par un adulte/l’établissement (l’admin consignant alors le consentement du titulaire de l’autorité parentale via l’écran des consentements). Le tableau des âges par pays est éditable dans le même réglage.

⚠️ Piège : l’export et la suppression RGPD reposent sur l’implémentation de l’API de confidentialité par chaque plugin. Un plugin tiers mal écrit peut déclarer « je ne stocke aucune donnée personnelle » à tort : ses données échapperont aux exports comme aux purges. Le rapport Administration du site > Utilisateurs > Confidentialité et politiques > Registre des plugins (Plugin privacy registry) liste la conformité déclarée de chaque plugin installé — à vérifier avant toute installation, et à auditer avant de répondre « nous avons tout effacé » à la CNIL.

💡 Pour un dev React : l’API de confidentialité de Moodle résout élégamment un problème que vous connaissez en microservices : « où sont les données de cet utilisateur ? ». Chaque plugin (≈ chaque service) implémente un contrat provider qui sait déclarer, exporter et purger ses données — puis un orchestrateur central fait le fan-out. C’est le pattern à copier si vous devez implémenter le RGPD dans une app Next.js multi-bases : un contrat par module, un orchestrateur, un registre.

📚 Aller plus loin : docs.moodle.org, pages « Policies », « Data registry », « Data requests » et « GDPR » ; côté juridique français, les référentiels CNIL sur la gestion scolaire et la durée de conservation dans l’éducation vous donneront les valeurs à mettre dans vos finalités de rétention.

11. Divers utiles au quotidien

11.1 « Se connecter sous » (Log in as)

Depuis le profil d’un utilisateur (dans un cours : Participants > cliquer l’utilisateur), le lien « Se connecter sous ce nom » (Log in as) vous fait voir la plateforme exactement comme lui — l’outil de support numéro un (« je ne vois pas le devoir ! »). Points clés :

• gouverné par la capacité moodle/user:loginas ; au contexte système elle est réservée à l’admin, mais accordée dans un contexte de cours elle limite la vision au cours en question ;
• la session « sous couvert » remplace votre session : en ressortant (déconnexion), vous devez vous reconnecter ;
• tout est journalisé (événement « Connexion sous le nom d’un autre utilisateur ») — heureusement, car c’est un pouvoir considérable ;
• certaines actions sont bloquées sous emprunt d’identité (changement de mot de passe, etc.), et la MFA ne se déclenche pas pour la cible.

⚠️ Piège : ne donnez jamais moodle/user:loginas au contexte système à un rôle non-admin « pour aider le support ». Cette capacité équivaut à un accès total aux comptes, messages privés compris. Si le support en a besoin, accordez-la au niveau des cours concernés, et rappelez que chaque usage est tracé et opposable.

11.2 Préférences utilisateur et valeurs par défaut

Chaque utilisateur dispose d’une page Préférences (menu utilisateur en haut à droite) : édition du profil, changement de mot de passe, langue préférée, préférences de forum, d’éditeur, de calendrier, préférences de notification (matrice canal × événement : web/mobile/email), comptes liés OAuth2, facteurs MFA. Côté admin, vous fixez les valeurs par défaut et pouvez verrouiller certains choix dans Administration du site > Messagerie (réglages de notification par défaut) et Administration du site > Utilisateurs > Permissions > Politiques utilisateur (User policies) — cette dernière page contenant aussi des réglages transverses précieux : rôle des visiteurs, affichage de l’identité des utilisateurs (quels champs — email, idnumber, département — les enseignants voient dans les listes de participants), format des noms complets.

11.3 Avatars et Gravatar

Les utilisateurs téléversent leur avatar dans leur profil (recadrage automatique). Deux réglages d’admin à connaître, dans Administration du site > Sécurité > Politiques du site : « Autoriser Gravatar » (enablegravatar) fait chercher un avatar sur le service Gravatar à partir du hash de l’email pour les comptes sans photo (pensez implications de confidentialité : le hash de l’email part vers un tiers), et la possibilité d’interdire la modification de l’image via le verrouillage du champ ou la capacité correspondante. Pour les établissements scolaires, beaucoup désactivent les avatars personnalisés (droit à l’image des mineurs) via les capacités moodle/user:editownprofile/champs verrouillés.

11.4 Sessions : timeout et politique

Administration du site > Serveur > Gestion des sessions (Session handling) :

• Durée de vie de la session (Timeout) : durée d’inactivité avant déconnexion (défaut 8 heures ; descendez à 1–2 h sur les plateformes avec postes partagés en libre-service) ;
• « Se souvenir de l’identifiant » : pré-remplissage du champ username via cookie persistant (à distinguer d’une session persistante : Moodle ne fait pas de « remember me » de session longue durée en standard) ;
• côté sécurité, dans Politiques du site : cookies sécurisés (secure cookies, à activer dès que le site est en HTTPS — c’est-à-dire toujours), et « Cookie HTTP uniquement » (HttpOnly) contre le vol de cookie par script.

💡 Pour un dev React : la session Moodle est un cookie opaque + état serveur, révocable instantanément — le modèle « database session » d’Auth.js, pas le modèle JWT. Corollaires : l’admin peut tuer toutes les sessions (la purge de la table des sessions déconnecte tout le monde), la charge de la table de sessions se surveille sur les gros sites (backends Redis/memcached configurables côté exploitation), et il n’y a pas de problème de « claims périmés dans le token » puisque tout est relu en base à chaque requête.

11.5 Hygiène des comptes de test

Tout admin crée des comptes de test (« etudiant-test », « prof-test ») pour vérifier les parcours. Bonnes pratiques :

• nommage explicite et normé (zz-test-etudiant1) pour les retrouver d’un filtre et les exclure des rapports ;
• email plausible mais maîtrisé : utilisez des sous-adresses de votre propre boîte (admin+test1@votre-domaine.fr) pour recevoir réellement les notifications à tester — jamais d’email inventé sur un domaine réel tiers ;
• méthode manual, mot de passe fort (un compte de test compromis est un vrai compte compromis), suspension hors période de test ;
• ne les inscrivez jamais dans les cours réels en production avec des rôles élevés ; préférez un cours bac à sable dédié ;
• revue trimestrielle : le filtre « identifiant contient test » + action en masse « suspendre » prend trente secondes ;
• et rappelez-vous que « Se connecter sous » (11.1) remplace avantageusement le compte de test dans la majorité des cas de support.

📚 Aller plus loin : pour générer des volumes de données de test réalistes sur un environnement de développement, Moodle fournit des générateurs (outil de génération de cours de test et behat/phpunit generators, côté ligne de commande) — hors périmètre de ce chapitre fonctionnel, mais bon à savoir avant de créer 200 comptes de test à la main : un import CSV généré par script fait très bien l’affaire aussi.

Résumé

• Moodle sépare strictement authentification (qui es-tu — plugins d’auth), inscription (à quels cours — plugins d’enrolment) et rôles/capacités (que peux-tu faire — par contexte). Le pipeline de connexion enchaîne : auth → contrôles post-login (confirmation, politiques, MFA, mot de passe forcé) → inscriptions → capacités.
• Le compte utilisateur a un cycle de vie : création (manuelle, CSV, auto-inscription, provisioning just-in-time), confirmation, vie active, suspension (gel réversible, données intactes) et suppression (anonymisation irréversible — préférez le circuit RGPD).
• L’administration quotidienne passe par Administration du site > Utilisateurs > Comptes : liste filtrable, actions en masse (confirmer, suspendre, supprimer, forcer le mot de passe, télécharger, ajouter à une cohorte, message) et import CSV (« Upload users ») — l’outil d’upsert universel, avec ses colonnes username/firstname/lastname/email, auth, cohort1, course1/role1, profile_field_xxx, et ses pièges (BOM, délimiteur, doublons, clé de correspondance).
• Côté méthodes : manual (défaut, contrôle total), email (self-service à sécuriser impérativement : reCAPTCHA + domaines), LDAP (annuaire d’entreprise, mapping et sync nocturne, dé-provisioning), OAuth2/OIDC (SSO moderne Google/Microsoft/générique, callback unique oauth2callback.php, liaison de comptes), SAML2 via auth_saml2 (fédérations, RENATER, Entra ID), CAS (universités françaises), plus les utilitaires nologin et webservice. Tout se pilote depuis Gérer l’authentification : activation, ordre, et paramètres communs (auto-inscription, bouton invité, URLs alternatives, domaines).
• Les champs de profil personnalisés (catégories, six types, visibilité/verrouillage/unicité/page d’inscription) irriguent les imports, les filtres, les mappings d’auth externes et les cohortes dynamiques.
• Sécurité des accès : politique de mots de passe (longueur, classes de caractères, réutilisation, verrouillage après échecs) renforcée par les peppers (4.3+), et MFA native (tool_mfa, 4.3+) avec son système de facteurs à points (TOTP, email, IP, grâce, type d’auth, rôle…) et sa procédure de secours à préparer.
• RGPD : tool_policy (politiques versionnées et consentements tracés), registre des données (catégories, finalités, durées de rétention pilotant la purge), demandes d’export/suppression avec workflow validé par un DPO (tool/dataprivacy:managedatarequests), et vérification de l’âge de consentement numérique.
• Au quotidien : « Se connecter sous » pour le support (tracé, à ne pas distribuer au niveau système), préférences et politiques utilisateur, Gravatar, timeout de session, et une hygiène stricte des comptes de test.

Dans le prochain chapitre

Vous savez désormais faire exister et authentifier vos utilisateurs — mais un utilisateur connecté qui n’est inscrit nulle part contemple un tableau de bord vide. Le chapitre 4 s’attaque à la deuxième question du pipeline : « à quels cours as-tu accès ? ». Au programme : les méthodes d’inscription (enrolment methods — inscription manuelle, auto-inscription avec clef, accès invité, inscription par lien méta-cours), la puissance des cohortes (création, remplissage manuel/CSV/automatique, synchronisation de cohorte pour inscrire des promotions entières en une règle), les inscriptions par fichier plat et par base de données externe, ainsi que les stratégies de désinscription et de fin de période. C’est là que les cohortes dynamiques et les champs de profil vus dans ce chapitre révèlent tout leur potentiel d’automatisation.