Chapitre 4 — Inscriptions (enrolments) et cohortes

Dans les chapitres précédents, vous avez découvert la mécanique des contextes, des rôles et des capabilities (chapitres 1 et 2), puis la gestion des comptes utilisateurs et de l’authentification (chapitre 3). Vous savez donc désormais qui peut exister sur la plateforme et ce que chaque rôle permet de faire. Il reste une question centrale : comment un utilisateur entre-t-il concrètement dans un cours ? C’est tout l’objet de ce chapitre : le système d’enrolment (inscription), ses nombreuses méthodes, et l’outil qui le complète naturellement à grande échelle, les cohorts (cohortes).

C’est un chapitre dense, car le système d’inscription de Moodle est l’un des plus riches du marché : inscription manuelle, auto-inscription avec clé, synchronisation depuis un système d’information scolaire, paiement en ligne, fourniture de cours à d’autres plateformes via LTI… Chaque méthode a sa logique, ses réglages et ses pièges. Prenez le temps de bien assimiler la section conceptuelle : tout le reste en découle.

4.1 Concepts fondamentaux : inscription ≠ rôle

4.1.1 Ce qu’est réellement une inscription

Une enrolment (inscription) est un lien entre un utilisateur et un cours. C’est ce lien qui fait apparaître l’utilisateur dans la liste des participants, qui lui crée une ligne dans le carnet de notes, qui le rend destinataire des notifications du cours, et qui lui donne (sauf restriction) l’accès au contenu.

Le point crucial — et la source de confusion numéro un chez les débutants — est que l’inscription est distincte de l’attribution de rôle (role assignment). Ce sont deux enregistrements différents, gérés par deux sous-systèmes différents :

• L’inscription répond à la question : « cet utilisateur est-il membre de ce cours, via quelle méthode, avec quelles dates, et son inscription est-elle active ? »
• L’attribution de rôle répond à la question : « quelles capabilities cet utilisateur possède-t-il dans le contexte de ce cours ? »

Dans le cas nominal, les deux vont ensemble : quand vous inscrivez Alice comme « Student (Étudiant) » dans le cours Algèbre 101, Moodle crée simultanément une inscription (portée par la méthode d’inscription utilisée) et une attribution du rôle Étudiant dans le contexte du cours. Mais les deux peuvent exister séparément :

• Rôle sans inscription : c’est la fameuse page « Autres utilisateurs » (Participants > menu déroulant > Autres utilisateurs, ou Other users). On peut y attribuer un rôle à quelqu’un dans le contexte du cours sans l’inscrire. Exemple typique : un inspecteur académique ou un responsable qualité qui doit pouvoir consulter le cours sans apparaître comme participant, sans ligne dans le carnet de notes, sans recevoir les notifications. Attention : pour qu’il puisse réellement voir le cours sans être inscrit, son rôle doit posséder la capability moodle/course:view (c’est le cas du rôle Manager standard, pas du rôle Teacher).
• Inscription sans rôle : plus rare, mais possible. Un utilisateur peut être inscrit (il « compte » comme participant) sans avoir de rôle dans le cours — par exemple après certaines opérations de synchronisation configurées pour « retirer les rôles » sans désinscrire. Il n’aura alors quasiment aucune capability dans le cours.

💡 Pour un dev React : pensez à l’inscription comme à une ligne dans une table de jointure many-to-many user_course (avec des métadonnées : méthode, statut, dates), et à l’attribution de rôle comme à un claim dans un JWT scopé sur ce cours. Dans une app Next.js, vous pourriez très bien avoir un enregistrement membership sans permissions, ou des permissions accordées à un admin qui n’est pas « membre » de l’espace. Moodle sépare exactement ces deux notions, là où beaucoup de systèmes les fusionnent.

4.1.2 L’inscription est portée par une méthode

Deuxième idée structurante : une inscription n’existe jamais « dans le vide ». Elle est toujours rattachée à une instance de méthode d’inscription (enrol method instance) présente dans le cours. Chaque cours possède une liste d’instances de méthodes : typiquement « Inscription manuelle », « Accès anonyme », « Auto-inscription (Étudiant) », et éventuellement plusieurs instances de la même méthode (deux auto-inscriptions avec des clés différentes, trois synchronisations de cohortes différentes, etc.).

Conséquence pratique majeure : si vous supprimez ou désactivez l’instance de méthode, toutes les inscriptions qu’elle porte sont supprimées ou suspendues avec elle. Supprimer l’instance « Inscription manuelle » d’un cours désinscrit d’un coup tous les utilisateurs inscrits manuellement — avec les effets sur les données décrits en section 4.6.

Voici le modèle complet en schéma :

                         COURS "Algèbre 101" (contexte cours)
                         ┌─────────────────────────────────────────────┐
                         │                                             │
  ┌──────────┐           │  ┌────────────────────────────┐             │
  │ USER     │           │  │ INSTANCE DE MÉTHODE        │             │
  │ Alice    │           │  │ ex. "Auto-inscription"     │             │
  └────┬─────┘           │  │ (enrol method instance)    │             │
       │                 │  └──────────┬─────────────────┘             │
       │                 │             │ porte                         │
       │                 │             ▼                               │
       │   crée          │  ┌────────────────────────────┐             │
       ├────────────────►│  │ ENROLMENT (inscription)    │             │
       │                 │  │ user = Alice               │             │
       │                 │  │ statut = actif / suspendu  │             │
       │                 │  │ début / fin (optionnels)   │             │
       │                 │  └──────────┬─────────────────┘             │
       │                 │             │ s'accompagne (en général) de  │
       │                 │             ▼                               │
       │                 │  ┌────────────────────────────┐             │
       └────────────────►│  │ ROLE ASSIGNMENT            │             │
                         │  │ rôle = Student             │             │
                         │  │ dans le contexte du cours  │             │
                         │  └────────────────────────────┘             │
                         │                                             │
                         └─────────────────────────────────────────────┘

  Un même utilisateur peut cumuler PLUSIEURS inscriptions dans le même
  cours (une par méthode) et PLUSIEURS rôles dans le même contexte.

Un utilisateur peut donc être inscrit deux fois dans le même cours : une fois via la synchronisation de cohorte, une fois manuellement. Les deux inscriptions coexistent ; l’utilisateur a accès tant qu’au moins une inscription est active. C’est à la fois une souplesse (on peut « doubler » une inscription automatique par une inscription manuelle pour la protéger) et un piège (voir section 4.8 sur les sources de vérité).

4.1.3 Statut actif / suspendu

Chaque inscription possède un statut : active ou suspended (suspendue). Une inscription suspendue signifie :

• l’utilisateur ne peut plus entrer dans le cours ;
• mais il reste inscrit : ses notes, ses remises de devoirs, ses messages de forum, son appartenance aux groupes sont intégralement conservés ;
• il apparaît toujours dans la liste des participants (grisé, avec le statut « Suspendu »), et les enseignants peuvent toujours consulter ses données ;
• il ne compte généralement plus dans les activités (il est masqué par défaut du carnet de notes selon les réglages grade_report_showonlyactiveenrol).

La suspension est donc l’outil idéal pour retirer l’accès sans détruire de données — par exemple pour un étudiant qui n’a pas payé, ou en attendant de vérifier une situation administrative. La désinscription pure, elle, est plus destructrice (section 4.6).

⚠️ Piège : ne confondez pas les trois niveaux de « désactivation » possibles : (1) suspendre le compte utilisateur (chapitre 3) — l’utilisateur ne peut plus se connecter du tout ; (2) suspendre une inscription — il ne peut plus accéder à ce cours ; (3) désactiver une instance de méthode dans le cours — toutes les inscriptions portées par cette instance sont suspendues d’un coup. Les trois se ressemblent dans l’interface (icône œil, statut grisé) mais n’ont pas du tout la même portée.

💡 Pour un dev React : le statut actif/suspendu est l’équivalent d’un soft delete (deletedAt/isActive) sur votre table de jointure, par opposition au DELETE physique qu’est la désinscription. Comme dans vos apps, la règle d’or est la même : tant que vous n’êtes pas certain de vouloir perdre les données associées, préférez le soft delete.

4.2 Gestion des méthodes : au niveau du site et au niveau du cours

4.2.1 Gestion globale (Administration du site)

Rendez-vous dans Administration du site > Plugins > Inscriptions > Gérer les plugins d’inscription (Site administration > Plugins > Enrolments > Manage enrol plugins). Vous y trouvez un tableau listant tous les plugins d’inscription installés, avec pour chacun :

• Nom du plugin (Inscription manuelle, Auto-inscription, Accès anonyme, Synchronisation de cohorte, Fichier plat, Base de données externe, Inscription sur paiement, Publier comme outil LTI, Liaison méta-cours, etc.) ;
• Instances / inscriptions : le nombre d’instances existantes dans les cours et le nombre d’inscriptions portées — très utile pour auditer ce qui est réellement utilisé avant de désactiver quoi que ce soit ;
• Activer : l’icône œil pour activer/désactiver le plugin au niveau du site. Un plugin désactivé au niveau du site suspend immédiatement toutes les inscriptions qu’il porte, dans tous les cours ;
• Monter/Descendre : des flèches pour ordonner les plugins. Cet ordre détermine l’ordre d’affichage des méthodes proposées et, pour les méthodes interactives (auto-inscription, paiement, invité), l’ordre dans lequel elles sont présentées à l’utilisateur sur la page d’inscription au cours ;
• Réglages : le lien vers les paramètres par défaut du plugin (valeurs pré-remplies lors de la création d’une instance dans un cours, comportements globaux comme l’action de désinscription externe, les tâches de notification d’expiration, etc.) ;
• Tester les réglages pour certains plugins (base de données externe notamment) ;
• Désinstaller pour les plugins non protégés.

Chaque plugin possède en général deux familles de réglages dans sa page de configuration : les réglages globaux (qui s’appliquent partout, ex. « External unenrol action ») et les valeurs par défaut des instances (qui ne font que pré-remplir le formulaire de création d’instance dans les cours — les instances existantes ne sont pas modifiées rétroactivement).

⚠️ Piège : désactiver un plugin d’inscription au niveau du site n’est pas une opération anodine. Toutes les inscriptions portées par ce plugin passent en « suspendu » instantanément, sur l’ensemble de la plateforme. Vérifiez toujours la colonne « Instances / inscriptions » avant de toucher à l’œil. À l’inverse, réactiver le plugin réactive les inscriptions (sauf celles suspendues individuellement).

4.2.2 Gestion par cours

Dans un cours, la gestion se fait via Participants (onglet dans la navigation secondaire du cours), puis dans le menu déroulant en haut à gauche de la page, choisissez Méthodes d’inscription (Enrolment methods). Le chemin en toutes lettres : Cours > Participants > menu déroulant “Utilisateurs inscrits” > Méthodes d’inscription.

La page présente un tableau des instances présentes dans le cours :

Sous le tableau, un menu déroulant « Ajouter méthode » (Add method) permet de créer une nouvelle instance parmi les plugins activés au niveau du site. On peut ajouter plusieurs instances du même plugin : deux auto-inscriptions avec des clés et des rôles différents, plusieurs synchronisations de cohortes, etc.

Le fonctionnement des icônes :

• Œil ouvert/fermé : active ou désactive l’instance. Désactiver suspend toutes ses inscriptions (réversible). C’est le bon geste pour « geler » temporairement une méthode, par exemple fermer l’auto-inscription une fois la période d’inscription terminée sans perdre les inscrits.
• Corbeille : supprime l’instance et toutes ses inscriptions (avec suppression des rôles associés). Une confirmation est demandée, mais l’opération est destructrice — préférez presque toujours l’œil.
• Flèches : l’ordre des instances détermine l’ordre de présentation à l’utilisateur sur la page d’inscription du cours. Si un cours propose un accès invité et deux auto-inscriptions, l’utilisateur non inscrit qui clique sur le cours voit les options dans cet ordre. La première méthode « automatique » applicable peut aussi être tentée en priorité.

💡 Pour un dev React : le couple « plugin activé au niveau du site » / « instance configurée dans le cours » est exactement le pattern feature flag global + configuration par tenant. Le plugin est le composant générique ; l’instance est son instanciation avec des props spécifiques au cours. Et comme avec des props, deux instances du même composant peuvent avoir des comportements très différents.

4.3 Les méthodes d’inscription en détail

4.3.1 Manual enrolment (inscription manuelle)

Fonctionnement. C’est la méthode de base : un utilisateur disposant de la capability enrol/manual:enrol (enseignant, manager…) choisit des utilisateurs et les inscrit dans le cours, avec un rôle et des dates. Une instance d’inscription manuelle est créée par défaut dans chaque nouveau cours.

Pourquoi il faut toujours la garder activée. L’instance d’inscription manuelle sert de socle à plusieurs fonctionnalités qui ne lui semblent pas liées au premier abord :

• le bouton « Inscrire des utilisateurs » de la page Participants repose sur elle ;
• l’inscription via upload de fichiers CSV d’utilisateurs (outil « Déposer des utilisateurs », colonnes course1, role1) utilise l’instance manuelle du cours cible ;
• certaines restaurations de sauvegardes et opérations d’administration inscrivent via cette instance.

Si vous la supprimez ou la désactivez, ces fonctions échouent silencieusement ou affichent des erreurs déroutantes (« Vous ne pouvez pas inscrire d’utilisateurs dans ce cours »). La règle d’or : on ne supprime jamais l’instance d’inscription manuelle, même dans un cours entièrement synchronisé depuis un SIS.

Configuration de l’instance (engrenage). Champ par champ :

• Activer les inscriptions manuelles : oui/non (équivalent de l’œil).
• Rôle par défaut (Default role) : rôle pré-sélectionné dans le dialogue d’inscription (Student en général).
• Durée d’inscription par défaut (Default enrolment duration) : durée pré-remplie (ex. 365 jours). « Illimité » par défaut.
• Notifier avant l’échéance de l’inscription (Notify before enrolment expires) : Non / Uniquement la personne qui inscrit / La personne qui inscrit et l’utilisateur inscrit.
• Seuil de notification (Notification threshold) : combien de temps avant l’expiration envoyer la notification (par défaut 1 jour).

Interface d’inscription des participants. Depuis Participants, cliquez sur « Inscrire des utilisateurs » (Enrol users). Une fenêtre modale s’ouvre :

• Sélectionner des utilisateurs : champ de recherche avec autocomplétion (nom, email). On peut sélectionner plusieurs utilisateurs à la fois.
• Sélectionner des cohortes : on peut inscrire d’un coup tous les membres actuels d’une cohorte — attention, c’est une photographie à l’instant T, pas une synchronisation (les futurs membres de la cohorte ne seront pas inscrits ; pour cela, il faut la méthode Cohort sync, section 4.3.4).
• Attribuer le rôle : le rôle donné aux inscrits.
• Afficher plus… déplie les options avancées : Récupérer les anciennes notes si possible (Recover user’s old grades if possible, voir section 4.6), Début de l’inscription (aujourd’hui / début du cours / date personnalisée), Durée et Date de fin.

Inscription en masse. Trois voies principales : la sélection multiple dans la modale ci-dessus ; l’option « Sélectionner des cohortes » ; et l’outil d’upload CSV d’utilisateurs (Administration du site > Utilisateurs > Comptes > Déposer des utilisateurs) avec les colonnes course1, role1, group1, enrolperiod1, etc., qui crée/retrouve les comptes et les inscrit dans la foulée.

Cas d’usage : petits effectifs, formations ponctuelles, ajout d’exceptions (un étudiant arrivé en cours d’année), inscription des enseignants eux-mêmes.

⚠️ Piège : dans la modale « Inscrire des utilisateurs », l’option « Sélectionner des cohortes » n’est pas une synchronisation. Beaucoup d’administrateurs débutants l’utilisent en croyant que le cours suivra la cohorte, puis s’étonnent que les nouveaux arrivants de la cohorte n’apparaissent pas dans le cours. Pour un suivi dynamique, utilisez la méthode « Synchronisation de cohorte ».

4.3.2 Self-enrolment (auto-inscription)

Fonctionnement. L’utilisateur s’inscrit lui-même : quand il clique sur un cours où il n’est pas inscrit et où une instance d’auto-inscription active existe, une page « Options d’inscription » lui est présentée. Selon la configuration, il clique simplement sur « M’inscrire » ou doit d’abord saisir une enrolment key (clé d’inscription).

C’est la méthode reine pour la formation continue, les MOOC internes, les cours d’entreprise en libre-service.

Configuration de l’instance, champ par champ :

• Nom personnalisé de l’instance : utile quand il y a plusieurs instances (« Auto-inscription salariés », « Auto-inscription partenaires »).
• Autoriser les auto-inscriptions existantes / Autoriser les nouvelles auto-inscriptions (Allow existing enrolments / Allow new enrolments) : le premier réglage sur « Non » suspend les inscrits actuels ; le second sur « Non » ferme la porte aux nouveaux tout en laissant les inscrits actuels tranquilles. C’est cette distinction qui permet de « fermer les inscriptions » proprement en fin de période.
• Clé d’inscription (Enrolment key) : mot de passe à saisir pour s’inscrire. Vide = inscription libre. L’icône œil permet de l’afficher en clair. Un réglage global (Administration du site > Plugins > Inscriptions > Auto-inscription) peut imposer une politique de complexité des clés et l’usage obligatoire d’une clé.
• Utiliser les clés d’inscription de groupe (Use group enrolment keys) : si activé, l’utilisateur peut saisir, au lieu de la clé du cours, la clé définie sur un groupe du cours (dans les réglages du groupe). Il est alors inscrit et placé automatiquement dans ce groupe. Redoutablement efficace pour ventiler des inscrits en groupes sans intervention : donnez la clé « TD-A-2026 » au groupe A, « TD-B-2026 » au groupe B, distribuez les bonnes clés aux bonnes personnes.
• Rôle attribué par défaut : Student en général.
• Durée d’inscription (Enrolment duration) : durée de validité de chaque inscription à compter du moment où l’utilisateur s’inscrit.
• Notifier avant l’échéance + Seuil de notification : comme pour l’inscription manuelle.
• Date de début / Date de fin (Start date / End date) : fenêtre pendant laquelle l’auto-inscription est possible. En dehors, la méthode n’est plus proposée.
• Désinscrire les inactifs après (Unenrol inactive after) : si l’utilisateur n’accède pas au cours pendant N jours, il est désinscrit automatiquement (pas suspendu !). Très utile pour purger les curieux qui s’inscrivent et ne reviennent jamais — mais voir le piège ci-dessous.
• Nombre maximum d’utilisateurs inscrits (Max enrolled users) : 0 = illimité. Au-delà, la méthode n’accepte plus personne (jauge de places).
• Seulement les membres de la cohorte (Only cohort members) : restreint l’auto-inscription aux membres d’une cohorte donnée. Combinaison très puissante : « seuls les membres de la cohorte Promo 2026 peuvent s’auto-inscrire, avec la clé X ». Cela fait de l’auto-inscription une méthode « opt-in contrôlé ».
• Envoyer un message de bienvenue au cours (Send course welcome message) : Non / Depuis l’adresse de contact du cours / Depuis la personne responsable de l’inscription / Depuis l’adresse no-reply. Suivi d’un champ Message de bienvenue personnalisé acceptant quelques placeholders (prénom, nom du cours, lien du profil).

Cas d’usage : catalogue de formation interne en libre-service, cours ouverts avec clé communiquée en présentiel, ventilation en groupes par clés de groupe.

⚠️ Piège : « Désinscrire les inactifs après » procède à une désinscription complète, pas une suspension. Les notes et contributions de l’utilisateur deviennent orphelines (voir 4.6). Sur un cours long où des participants peuvent légitimement s’absenter plusieurs semaines, un seuil trop court détruit des données. Vérifiez aussi que la valeur maximale proposée dépend d’un réglage global du plugin.

⚠️ Piège : la clé d’inscription n’est pas un secret robuste : elle circule par oral, par mail, par capture d’écran, et rien n’empêche un inscrit de la transmettre. Ne l’utilisez jamais comme mécanisme de sécurité pour du contenu sensible ; c’est un filtre de commodité. Pour un vrai contrôle, combinez avec « Seulement les membres de la cohorte » ou passez à une méthode synchronisée.

💡 Pour un dev React : l’auto-inscription avec clé, c’est le pattern invite code de vos SaaS : un code partageable qui court-circuite l’approbation manuelle, avec quota (max enrolled users), fenêtre de validité (start/end date) et TTL de session (unenrol inactive after ≈ purge des comptes dormants). Et la clé de groupe est un invite code avec payload : il encode à la fois l’accès et l’affectation à une équipe.

4.3.3 Guest access (accès anonyme / accès invité)

Ce n’est pas une inscription ! C’est le point essentiel. L’accès invité permet à un utilisateur — connecté ou non selon la configuration du site — de consulter un cours sans y être inscrit. Aucun enregistrement d’inscription n’est créé ; l’utilisateur reçoit temporairement, le temps de sa visite, les capabilities du rôle Guest (Invité) dans le cours.

Conséquences directes, à bien comprendre via le prisme des capabilities (chapitre 1) :

• l’invité peut voir les ressources (fichiers, pages, liens…) ;
• il ne peut participer à aucune activité : pas de message de forum, pas de tentative de quiz, pas de remise de devoir, pas de réponse au sondage. Le rôle Guest n’a pratiquement aucune capability d’écriture, et la plupart des modules vérifient en plus explicitement isguestuser() ;
• il n’a pas de carnet de notes, pas de suivi d’achèvement, n’apparaît pas dans les participants ;
• certaines activités refusent même la consultation à un invité (selon leurs réglages).

Configuration de l’instance :

• Autoriser l’accès anonyme : oui/non (équivalent de l’œil).
• Mot de passe (Guest access password) : optionnel. S’il est défini, le visiteur doit le saisir pour entrer. Même remarque de sécurité que pour la clé d’auto-inscription.

Au niveau du site, l’accès invité suppose que le bouton de connexion anonyme soit activé si l’on veut de vrais visiteurs non authentifiés (Administration du site > Plugins > Authentification > Gérer l’authentification > « Bouton de connexion anonyme »). Sans cela, l’accès invité reste utilisable par les utilisateurs authentifiés qui ne sont pas inscrits au cours (ils « visitent » le cours en tant qu’invités).

Cas d’usage : cours vitrine, catalogue consultable avant inscription, documentation interne en lecture seule, démonstration publique d’un cours.

⚠️ Piège : combiner accès invité et contenu sous droits d’auteur ou données personnelles. Un cours en accès invité sans mot de passe, sur un site où la connexion anonyme est activée, est public sur Internet — moteurs de recherche compris si le site n’est pas protégé. Auditez régulièrement quels cours ont l’œil ouvert sur l’accès invité.

💡 Pour un dev React : l’accès invité est un rendu en mode lecture seule sans session de membre — comme une page Next.js publique qui affiche les données d’un espace de travail via generateStaticParams, pendant que toutes les mutations (server actions) exigent une session. La distinction Moodle « voir ≠ participer » recouvre exactement votre distinction « GET public ≠ POST authentifié ».

4.3.4 Cohort sync (synchronisation de cohorte)

Fonctionnement. Cette méthode lie un cours à une cohorte (voir section 4.4) : tout membre de la cohorte est automatiquement inscrit au cours avec le rôle configuré, et la synchronisation est continue et bidirectionnelle dans le temps — quand quelqu’un rejoint la cohorte, il est inscrit ; quand il la quitte, son inscription est retirée ou suspendue selon le réglage global. La synchronisation est largement pilotée par événements (l’ajout d’un membre à la cohorte déclenche l’inscription quasi immédiatement), avec un rattrapage par le cron.

Configuration de l’instance :

• Nom personnalisé de l’instance ;
• Actif : oui/non ;
• Cohorte : la cohorte à synchroniser (parmi celles visibles dans le contexte : cohortes système + cohortes de la catégorie du cours) ;
• Attribuer un rôle (Assign role) : le rôle donné aux membres (souvent Student, mais on peut créer une instance « cohorte des tuteurs » avec le rôle Teacher sans droits d’édition) ;
• Ajouter au groupe (Add to group) : optionnellement, verser automatiquement les membres dans un groupe du cours, y compris via l’option « Créer un groupe » qui génère un groupe portant le nom de la cohorte. Idéal pour faire cohabiter plusieurs promotions dans un même cours tout en les séparant en groupes.

Que se passe-t-il quand un utilisateur quitte la cohorte ? C’est le réglage global crucial « External unenrol action » (Action de désinscription externe), dans Administration du site > Plugins > Inscriptions > Synchronisation de cohorte. Trois options :

Le choix par défaut (suspendre + retirer les rôles) est le plus sûr : aucune donnée n’est perdue, et un retour dans la cohorte restaure tout. Choisissez « Désinscrire » uniquement si votre source externe est fiable et si la politique de l’établissement assume la perte d’attache des données.

Cas d’usage typique — les promotions d’étudiants. Créez une cohorte « L1-Info-2026 » alimentée par votre SIS (via upload CSV ou sync LDAP/base externe des cohortes). Ajoutez une instance « Synchronisation de cohorte » dans chacun des 12 cours du semestre. Résultat : l’arrivée d’un étudiant dans la promotion l’inscrit automatiquement aux 12 cours ; son départ l’en retire partout. Zéro gestion manuelle par cours.

À noter : la synchronisation de cohorte n’offre aucune action à l’utilisateur — il n’y a rien à cliquer, pas de page d’inscription. Si aucun utilisateur ne doit être ajouté à la main, c’est la garantie que la cohorte reste la source de vérité unique.

⚠️ Piège : « External unenrol action » est un réglage global au plugin, pas par instance. Vous ne pouvez pas avoir « suspendre » pour les cours de licence et « désinscrire » pour les cours de formation continue avec le même plugin. Réfléchissez à la politique une fois pour toute la plateforme.

💡 Pour un dev React : la synchronisation de cohorte est un état dérivé : l’inscription au cours est calculée depuis l’appartenance à la cohorte, comme un useMemo dérive une valeur d’une source. Corollaire familier : ne modifiez jamais l’état dérivé à la main. Inscrire manuellement quelqu’un dans un cours synchronisé « pour aller plus vite » au lieu de l’ajouter à la cohorte crée exactement le même type de bug qu’une mutation directe d’un state dérivé — l’incohérence resurgira à la prochaine synchronisation.

4.3.5 Flat file (fichier plat)

Fonctionnement. Le plugin enrol_flatfile lit périodiquement un fichier CSV déposé à un emplacement précis du serveur, exécute les inscriptions/désinscriptions qu’il décrit, puis supprime le fichier. C’est le mécanisme d’intégration « old school » mais toujours très efficace avec un système d’information scolaire (SIS) capable d’exporter des fichiers : le SIS dépose chaque nuit un fichier, Moodle le consomme.

Format du fichier. Une ligne par opération, champs séparés par des virgules :

opération, rôle, idnumber_utilisateur, idnumber_cours [, timestart [, timeend]]

• opération : add (inscrire) ou del (désinscrire) ;
• rôle : le shortname du rôle (student, teacher, editingteacher…) — ou un alias configuré dans les réglages du plugin (mapping des noms de rôles) ;
• idnumber_utilisateur : le champ idnumber (numéro d’identification) du profil utilisateur — pas le username, pas l’id interne de la base. C’est l’identifiant pivot avec le SIS, à renseigner sur chaque compte ;
• idnumber_cours : le champ idnumber du cours (réglages du cours, section « Numéro d’identification du cours ») ;
• timestart / timeend (optionnels) : timestamps Unix de début et de fin d’inscription.

Exemple concret :

add, student, 20260457, MATH-L1-S1
add, student, 20260458, MATH-L1-S1, 1767222000, 1782860400
add, teacher, ENS-00312, MATH-L1-S1
del, student, 20250112, MATH-L1-S1

Configuration (Administration du site > Plugins > Inscriptions > Fichier plat) :

• Emplacement du fichier (File location) : chemin absolu sur le serveur (ex. /var/moodledata/sync/enrolments.txt). Le répertoire doit être lisible et inscriptible par l’utilisateur système du serveur web/cron, puisque Moodle supprime le fichier après traitement ;
• Encodage du fichier (File encoding) : UTF-8 recommandé ; si votre SIS exporte en ISO-8859-1, réglez-le ici sous peine d’accents massacrés dans les logs ;
• Notifications : notifier par email l’administrateur, les enseignants et/ou les étudiants des inscriptions traitées ;
• Action de désinscription externe : comme pour cohort sync, comportement lors d’un del (désinscrire / suspendre) ;
• Mapping des rôles : correspondances entre les libellés du fichier et les rôles Moodle.

Tâche planifiée. Le traitement est effectué par la scheduled task (tâche planifiée) du plugin — « Traitement des inscriptions par fichier » (enrol_flatfile\task\flatfile_sync), visible et réglable dans Administration du site > Serveur > Tâches > Tâches planifiées. Par défaut elle passe à chaque cron ; le fichier est donc consommé quelques minutes après son dépôt.

Cas d’usage : intégration SIS sans accès direct à la base du SIS, échanges par SFTP nocturnes, migrations ponctuelles massives.

⚠️ Piège : le fichier est supprimé après traitement — c’est le signal de bonne exécution, mais cela signifie que vous perdez la trace de ce qui a été envoyé. Faites conserver une copie horodatée côté SIS. Autre classique : un fichier déposé en cours d’écriture au moment où le cron passe est traité tronqué ; déposez-le sous un nom temporaire puis renommez-le (opération atomique) une fois complet.

💡 Pour un dev React : flat file, c’est de l’ETL par fichier avec sémantique idempotente partielle — l’équivalent artisanal d’une queue de messages : chaque ligne est un événement add/del, consommé puis détruit. Les mêmes questions que pour un consumer Kafka/SQS s’appliquent : que se passe-t-il si le producteur écrit pendant la consommation ? si une ligne est invalide ? Réponse Moodle : dépôt atomique par rename, et lignes invalides ignorées avec log — à surveiller.

4.3.6 External database (base de données externe)

Fonctionnement. Le plugin enrol_database se connecte directement à une table ou vue SQL d’une base externe (celle de votre SIS, de votre ERP RH, d’un middleware) et synchronise les inscriptions : chaque ligne de la table = une inscription (utilisateur, cours, rôle optionnel). Contrairement au fichier plat (flux d’événements add/del), c’est une synchronisation d’état : la table externe décrit l’état cible complet, et Moodle converge vers cet état — inscrit ce qui manque, retire/suspend ce qui n’y figure plus.

Configuration (Administration du site > Plugins > Inscriptions > Base de données externe) :

Connexion :

• Type de base (Database driver) : mysqli, mariadb, pgsql, sqlsrv, oci… ;
• Hôte, nom de la base, utilisateur, mot de passe, options d’encodage et de setup SQL. Un bouton/une page « Tester les réglages » vérifie la connexion et affiche des lignes d’exemple — utilisez-le systématiquement.

Table des inscriptions (mapping des colonnes) :

• Table des inscriptions distante (Remote enrolment table) : nom de la table ou vue ;
• Champ cours distant (Remote course field) : colonne contenant l’identifiant du cours ;
• Champ utilisateur distant (Remote user field) : colonne contenant l’identifiant de l’utilisateur ;
• Champ rôle distant (Remote role field) : colonne contenant le shortname du rôle (optionnel — sinon rôle par défaut) ;
• Champ « autres utilisateurs » (Remote other user field) : pour attribuer des rôles sans inscription (les fameux « autres utilisateurs » du 4.1) ;
• côté Moodle, vous précisez à quoi correspondent ces identifiants : Champ local du cours (idnumber / shortname / id), Champ local de l’utilisateur (idnumber / username / email), Champ local du rôle (shortname / id). Le pivot le plus robuste est idnumber des deux côtés ;
• Rôle par défaut si la table ne fournit pas de rôle ;
• Action de désinscription externe : désinscrire / suspendre / suspendre et retirer les rôles — même logique que cohort sync, même importance.

Création automatique de cours (optionnelle) :

• Table des nouveaux cours (New course table) : une seconde table/vue décrivant les cours à créer automatiquement s’ils n’existent pas encore dans Moodle, avec mapping des colonnes fullname, shortname, idnumber, category et un cours modèle (template course) dont le contenu est copié dans chaque nouveau cours. Redoutable pour provisionner automatiquement 400 espaces de cours à chaque rentrée à partir de la maquette pédagogique.

Exécution :

• La synchronisation complète tourne via la tâche planifiée du plugin (« Synchronisation des inscriptions de base de données externe », enrol_database\task\sync_enrolments) — historiquement on utilisait le script CLI enrol/database/cli/sync.php, toujours disponible pour les lancements manuels avec l’option verbose ;
• en complément, une synchronisation à la connexion de l’utilisateur peut rafraîchir ses inscriptions individuelles dès qu’il se connecte, ce qui donne un ressenti « temps réel » sans attendre la synchro nocturne complète.

Cas d’usage : c’est LA méthode d’intégration SIS/ERP de référence quand vous avez un accès SQL (souvent une vue dédiée, en lecture seule, préparée par la DSI) : universités avec Apogée/Pégase, entreprises avec le SIRH, organismes de formation avec leur ERP métier.

⚠️ Piège : la synchronisation complète peut être coûteuse (elle parcourt toutes les inscriptions) et surtout impitoyable : si votre vue SQL renvoie zéro ligne à cause d’un incident côté SIS (table vidée, jointure cassée), Moodle appliquera consciencieusement l’état cible… c’est-à-dire désinscrira ou suspendra tout le monde, selon votre « External unenrol action ». C’est l’argument massue pour choisir « suspendre » plutôt que « désinscrire » : un incident devient réversible. Demandez aussi à la DSI de garantir que la vue échoue en erreur plutôt que de renvoyer un résultat vide.

💡 Pour un dev React : fichier plat vs base externe, c’est exactement event sourcing vs réconciliation d’état déclarative — la différence entre une mutation Redux (dispatch({type: 'ADD'})) et le modèle React lui-même (« voici l’état cible, le moteur fait le diff »). La base externe est le virtual DOM des inscriptions : Moodle calcule le diff entre l’état déclaré et l’état réel, et applique le patch. Et comme en React, un état déclaré vide = un écran vide.

📚 Aller plus loin : la page « External database enrolment » sur docs.moodle.org détaille tous les réglages de connexion par driver, et le plugin frère auth_db (chapitre 3) permet de synchroniser aussi les comptes depuis la même base — le duo auth_db + enrol_database couvre l’intégration SIS complète sans écrire une ligne de code.

4.3.7 Inscription sur paiement : enrol_fee et les payment gateways

Architecture moderne des paiements. Depuis Moodle 3.11/4.0, Moodle intègre un sous-système de paiement générique découplé des méthodes d’inscription :

  Utilisateur ──► Méthode "Inscription sur paiement" (enrol_fee) dans le cours
                          │  prix, devise, compte de paiement
                          ▼
                  Payment account (compte de paiement)
                          │  configuré au niveau du site
                          ▼
                  Payment gateway(s) (passerelles) : PayPal, Stripe, ...
                          │
                          ▼
                  Prestataire de paiement externe

• enrol_fee (« Inscription sur paiement », dans le core) est la méthode d’inscription : elle affiche un prix sur la page d’inscription du cours et inscrit l’utilisateur une fois le paiement confirmé ;
• les payment gateways (passerelles de paiement) sont des plugins séparés qui gèrent la transaction : PayPal (via le plugin de passerelle), Stripe et d’autres via des plugins tiers du répertoire moodle.org ;
• les payment accounts (comptes de paiement) relient les deux : un compte regroupe une ou plusieurs passerelles configurées (identifiants API, mode sandbox/production).

Note historique importante : l’ancienne méthode enrol_paypal, qui embarquait directement l’intégration PayPal dans le plugin d’inscription, a été dépréciée dans Moodle 4.x puis retirée du core (elle reste disponible comme plugin additionnel pour les migrations, mais ne doit plus être utilisée pour de nouveaux projets). L’architecture cible est bien enrol_fee + passerelle. Si vous reprenez une plateforme migrée depuis Moodle 3.x, vérifiez qu’il ne traîne pas d’instances enrol_paypal.

Configuration, étape par étape :

1. Créer un compte de paiement : Administration du site > Général > Paiements > Comptes de paiement (Site administration > General > Payments > Payment accounts). Cliquez « Créer un compte de paiement », nommez-le (ex. « Compte formation continue »), puis sur la ligne du compte, configurez chaque passerelle disponible (pour PayPal : Client ID, Secret, marque, environnement sandbox/live ; pour Stripe via plugin tiers : clés API). Une passerelle non configurée sur le compte n’est pas proposée au payeur.
2. Activer enrol_fee : Administration du site > Plugins > Inscriptions > Gérer les plugins d’inscription > œil sur « Inscription sur paiement ».
3. Ajouter l’instance dans le cours : Participants > Méthodes d’inscription > Ajouter méthode > Inscription sur paiement. Champs :
   • Compte de paiement : le compte créé à l’étape 1 ;
   • Prix de l’inscription (Enrolment fee) et Devise (Currency) : le prix par cours — la devise proposée dépend des devises supportées par les passerelles du compte ;
   • Attribuer un rôle : Student en général ;
   • Durée d’inscription, date de début/fin : comme les autres méthodes — on peut donc vendre un accès de 6 mois.

Côté utilisateur : le cours affiche le prix sur sa page d’options d’inscription, le clic ouvre la fenêtre de choix de passerelle, le paiement se fait chez le prestataire, et l’inscription est créée au retour de confirmation.

Cas d’usage : organismes de formation vendant à l’unité, associations, universités d’été. Pour de la vente complexe (paniers, promotions, abonnements, factures), on sort du périmètre : regardez les plugins e-commerce dédiés ou un front de vente externe (WooCommerce + plugin d’intégration) qui pilote ensuite l’inscription.

⚠️ Piège : testez toujours en environnement sandbox de la passerelle avant la production, et vérifiez le comportement en cas de paiement interrompu (fermeture de l’onglet pendant la redirection). Vérifiez aussi la cohérence TVA/devise : Moodle affiche un prix brut, il ne fait ni facturation ni comptabilité — c’est à votre organisme d’assurer la conformité fiscale en aval.

📚 Aller plus loin : la documentation « Payment gateways » sur docs.moodle.org liste les passerelles officielles et tierces, et la page moodledev.io « Payment subsystem » décrit l’architecture (utile si un jour vous développez votre propre passerelle — c’est un des plugins les plus simples à écrire).

4.3.8 Publish as LTI tool (fournir le cours comme outil LTI)

Le sens du flux, d’abord. LTI (Learning Tools Interoperability) est le standard d’interconnexion des plateformes éducatives, et Moodle peut jouer les deux rôles :

Le plugin enrol_lti est donc une méthode d’inscription un peu particulière : quand un utilisateur de la plateforme distante lance l’outil, Moodle provisionne automatiquement un compte local (lié à l’identité LTI distante) et l’inscrit dans le cours via cette méthode. L’inscription matérialise la venue d’un utilisateur externe. Les notes peuvent être renvoyées à la plateforme d’origine (grade sync / Assignment and Grade Services).

LTI Advantage. Depuis Moodle 4.0, enrol_lti implémente LTI 1.3 / LTI Advantage : sécurité par OAuth2/JWT (fini le secret partagé OAuth1 de LTI 1.1), services de notes (AGS), provisioning des membres (NRPS), deep linking. La mise en place se fait par un enregistrement de plateforme : Administration du site > Plugins > Inscriptions > Publier comme outil LTI > Tool registration, où vous générez une URL d’enregistrement dynamique (ou saisissez manuellement les endpoints : issuer, client ID, clés publiques JWKS) à échanger avec l’administrateur de la plateforme consommatrice.

Configuration de l’instance dans le cours (Participants > Méthodes d’inscription > Ajouter méthode > Publier comme outil LTI) :

• Nom de l’outil publié ;
• Ce qui est publié : le cours entier ou une activité précise du cours ;
• Rôle des enseignants distants / Rôle des étudiants distants : mapping des rôles LTI entrants vers les rôles Moodle ;
• Nombre maximum d’utilisateurs, durée d’inscription ;
• Synchronisation des notes (Grade synchronisation) et synchronisation des utilisateurs (memberships) avec leurs tâches planifiées associées ;
• options d’authentification des comptes provisionnés.

Une fois l’instance créée, la page « Outils publiés » fournit les URL de lancement / identifiants à transmettre à la plateforme consommatrice.

Cas d’usage : mutualisation inter-établissements (une université « héberge » un cours de langue suivi par les étudiants de trois écoles partenaires, chacun restant connecté à SA plateforme), vente de contenu à des clients qui ont leur propre LMS, consortiums.

⚠️ Piège : ne confondez pas les deux directions LTI ! « Mon cours doit afficher un outil externe » = activité External tool (rien à voir avec l’inscription). « Une autre plateforme doit accéder à mon cours » = méthode d’inscription Publish as LTI tool. L’erreur de direction est la confusion la plus fréquente en support LTI. Notez aussi que LTI 1.1 est déprécié : tout nouveau projet doit être en LTI Advantage.

💡 Pour un dev React : LTI Advantage vous semblera familier : c’est essentiellement de l’OpenID Connect avec des claims éducatifs — launch = flow OIDC avec JWT signé, JWKS pour les clés, scopes pour les services (notes, membres). Si vous avez déjà branché NextAuth sur un IdP OIDC, vous avez fait 70 % du chemin conceptuel. Le provisioning automatique des comptes à la volée est l’équivalent du « sign in with… » qui crée l’utilisateur au premier login.

📚 Aller plus loin : la page « Publish as LTI tool » de docs.moodle.org contient le pas-à-pas complet côté fournisseur ET côté consommateur (avec les écrans des deux plateformes) ; moodledev.io documente l’implémentation LTI 1.3 pour le jour où vous voudrez déboguer des JWT de launch.

4.3.9 Mentions rapides : meta-cours, catégorie, upload

enrol_meta — Course meta link (liaison méta-cours). Cette méthode inscrit automatiquement dans un cours (« parent ») tous les inscrits d’un ou plusieurs autres cours (« enfants »). Ajoutez dans le cours parent une instance « Liaison méta-cours », choisissez le ou les cours enfants, optionnellement un groupe de destination. Toute personne inscrite dans un enfant (quelle que soit la méthode, avec son rôle d’origine) est reflétée dans le parent, en continu. Cas d’usage : un « tronc commun » alimenté par les inscriptions de plusieurs parcours ; un espace « Vie du département » regroupant les inscrits de tous les cours du département. C’est en quelque sorte une synchronisation de cohorte où la « cohorte » est un autre cours. Le réglage global « External unenrol action » existe ici aussi.

enrol_category — inscription par catégorie (obsolète). Ce plugin historique inscrivait automatiquement dans tous les cours d’une catégorie les utilisateurs ayant un rôle « synchronisé » au niveau de la catégorie. Il est désactivé par défaut, considéré obsolète et très coûteux en performance. La réponse moderne à ce besoin est : cohorte + synchronisation de cohorte (éventuellement une instance par cours créée en masse via upload de cours). Ne l’activez pas sur un nouveau projet.

Upload d’inscriptions via CSV. Deux outils d’administration à connaître :

• Déposer des utilisateurs (Administration du site > Utilisateurs > Comptes > Déposer des utilisateurs) : les colonnes course1, role1, group1, enrolstatus1, enrolperiod1 (et course2… pour d’autres cours) permettent d’inscrire pendant la création/mise à jour des comptes. Les inscriptions passent par l’instance manuelle des cours cibles (encore une raison de ne jamais la supprimer) ;
• Déposer des cours (Administration du site > Cours > Déposer des cours) : permet, à la création de cours en masse, de définir leurs méthodes d’inscription via des colonnes dédiées (enrolment_1, enrolment_1_role, etc.) — pratique pour créer 200 cours avec chacun sa synchronisation de cohorte.

4.3.10 Tableau comparatif des méthodes

4.4 Les cohortes en profondeur

4.4.1 Définition et positionnement

Une cohort (cohorte) est un groupe d’utilisateurs défini à l’échelle du site ou d’une catégorie de cours — donc en dehors de tout cours. C’est un objet purement administratif : appartenir à une cohorte ne donne, en soi, aucun droit et aucun accès. La cohorte ne prend son sens que lorsqu’un autre mécanisme s’y réfère : une synchronisation d’inscription, une restriction d’accès, une audience de rapport.

Ne confondez pas avec les groups (groupes de cours), qui vivent à l’intérieur d’un cours. Le tableau suivant est à mémoriser :

Les deux se combinent d’ailleurs élégamment : la méthode « Synchronisation de cohorte » peut verser les membres d’une cohorte dans un groupe du cours (option « Ajouter au groupe »), faisant le pont entre les deux mondes.

💡 Pour un dev React : cohorte vs groupe, c’est la différence entre un segment d’utilisateurs global (dans votre table users, un tag segment: "promo-2026" exploitable partout) et un scope local à une ressource (la sous-collection teams d’un workspace). Le premier appartient à la couche d’administration de la plateforme, le second à la logique métier d’un espace donné.

4.4.2 Créer et gérer les cohortes

Chemin : Administration du site > Utilisateurs > Comptes > Cohortes (Site administration > Users > Accounts > Cohorts). La page présente plusieurs onglets : cohortes du contexte système, toutes les cohortes (y compris celles des catégories), ajout, et upload.

Création (« Ajouter une cohorte ») :

• Nom : libellé lisible (« Promo L1 Info 2026-2027 ») ;
• Contexte : Système (cohorte visible et utilisable partout) ou une catégorie de cours (cohorte gérée et utilisable dans cette branche — pratique pour déléguer la gestion aux responsables de composantes, via un rôle ayant moodle/cohort:manage sur la catégorie) ;
• Identifiant de cohorte (Cohort ID / idnumber) : l’identifiant technique pivot, indispensable pour les uploads CSV et les synchronisations. Mettez-y systématiquement un code stable de votre SI (« L1INFO2026 ») ;
• Visible : une cohorte cachée reste pleinement fonctionnelle pour les mécanismes déjà en place, mais n’est plus proposée aux enseignants/managers dans les sélecteurs des cours (par exemple lors de l’ajout d’une méthode de synchronisation ou de l’inscription par cohorte). C’est un moyen d’archiver des cohortes de promotions passées sans les supprimer ;
• Description : documentez ici la provenance (« Alimentée chaque nuit depuis Pégase — ne pas modifier à la main ») — votre futur vous dira merci.

Ajout de membres, quatre voies :

1. Manuel : sur la ligne de la cohorte, icône « Assigner » : double liste ajout/retrait avec recherche. Simple, mais ne passe pas à l’échelle ;

2. Upload de cohortes (onglet « Déposer des cohortes ») : un CSV crée les cohortes elles-mêmes en masse. Colonnes : name, idnumber, description, visible, category (ou category_id, category_idnumber, category_path pour choisir le contexte). Exemple :

   name,idnumber,visible,category_idnumber
   Promo L1 Info 2026,L1INFO2026,1,UFR-SCIENCES
   Promo L2 Info 2026,L2INFO2026,1,UFR-SCIENCES

3. Upload d’utilisateurs avec colonnes cohort : dans l’outil « Déposer des utilisateurs » (chapitre 3), les colonnes cohort1, cohort2… affectent chaque utilisateur aux cohortes indiquées par leur idnumber (d’où l’importance de l’avoir renseigné). C’est la méthode la plus courante pour peupler les cohortes à chaque rentrée :

   username,firstname,lastname,email,cohort1
   m.durand,Marie,Durand,marie.durand@univ.fr,L1INFO2026
   k.traore,Karim,Traoré,karim.traore@univ.fr,L1INFO2026

4. Synchronisation automatique : certains plugins d’authentification (LDAP) et des plugins tiers peuvent maintenir les cohortes depuis un annuaire ou une base externe — la cohorte devient alors elle-même un état dérivé du SI.

⚠️ Piège : dans les CSV, la colonne cohort1 attend l’idnumber de la cohorte, pas son nom. Si vous mettez le nom, selon les versions l’upload échoue ou — pire — crée silencieusement une nouvelle cohorte homonyme. Standardisez : idnumber obligatoire, unique et stable pour chaque cohorte, dès la création.

4.4.3 À quoi servent les cohortes : les usages

• Synchronisation d’inscription (cohort sync) : l’usage principal, détaillé en 4.3.4 — une cohorte, N cours synchronisés ;
• Inscription instantanée d’une cohorte : dans la modale « Inscrire des utilisateurs » (photographie non synchronisée, rappel du piège 4.3.1) ;
• Auto-inscription réservée à une cohorte : le réglage « Seulement les membres de la cohorte » (4.3.2) ;
• Restriction d’accès (availability) par cohorte : le système de restrict access (restriction d’accès) des activités et sections propose en standard des restrictions par date, note, groupe, profil… La restriction par cohorte est fournie par le plugin additionnel availability_cohort (très répandu) ; sans lui, on obtient un résultat proche en synchronisant la cohorte vers un groupe du cours (option « Ajouter au groupe ») puis en restreignant par groupe — pattern à retenir ;
• Audiences du Report Builder : le générateur de rapports (Administration du site > Rapports > Report builder), disponible depuis Moodle 4.x, permet de définir des audiences — qui a le droit de voir un rapport — dont l’un des types standard est « Membre d’une cohorte ». Idéal pour diffuser un tableau de bord de suivi à tous les tuteurs d’un dispositif ;
• Thèmes ou dashboards par cohorte : via des plugins tiers, on peut servir un thème, une page d’accueil ou des blocs différents selon la cohorte — utile en contexte multi-marques ou multi-clients ;
• Cible de messagerie et d’annonces pour certains outils de communication de masse (plugins).

📚 Aller plus loin : la page « Cohorts » de docs.moodle.org recense les champs exacts acceptés par « Upload cohorts », et le plugin availability_cohort est documenté dans le répertoire de plugins moodle.org — vérifiez sa compatibilité 5.2 avant installation, comme pour tout plugin tiers.

4.5 Désinscription : qui, comment, avec quels effets

4.5.1 Qui peut désinscrire qui

La désinscription est contrôlée par des capabilities propres à chaque plugin : enrol/manual:unenrol, enrol/self:unenrol, enrol/cohort:unenrol n’existe pas au sens utile (la cohorte se gère en amont), etc. Concrètement :

• un enseignant peut en général désinscrire les inscriptions manuelles (capability enrol/manual:unenrol dans le rôle Teacher par défaut) mais pas les inscriptions issues d’une synchronisation — l’icône corbeille n’apparaît tout simplement pas sur ces lignes dans la page Participants. C’est logique : la source de vérité est ailleurs, la resynchronisation annulerait le geste ;
• un utilisateur peut se désinscrire lui-même d’un cours en auto-inscription si le rôle Student conserve enrol/self:unenrolself (c’est le cas par défaut) — l’option « Me désinscrire de … » apparaît alors dans le menu du cours. Il n’existe pas d’équivalent pour les inscriptions manuelles ou synchronisées : l’étudiant doit demander ;
• un manager/admin peut désinscrire via la page Participants, y compris en masse (voir 4.7).

Dans la page Participants, la colonne Statut affiche pour chaque utilisateur sa ou ses méthodes d’inscription ; l’icône d’information détaille méthode, dates et statut, et les icônes corbeille/engrenage au bout de la ligne permettent respectivement de désinscrire et de modifier l’inscription (statut actif/suspendu, dates) — méthode par méthode si l’utilisateur en cumule plusieurs.

4.5.2 Effet sur les données : le point critique

Que deviennent les données quand on désinscrit ? Réponse nuancée :

• Conservé, mais orphelin : les notes du carnet, les remises de devoirs, les tentatives de quiz, les messages de forum ne sont pas supprimés — ils restent en base, attachés à l’utilisateur. Mais l’utilisateur n’apparaissant plus dans les participants, ces données deviennent invisibles dans la plupart des rapports du cours (le carnet de notes ne montre que les inscrits). Les messages de forum restent visibles publiquement, l’auteur apparaissant sans lien de profil actif dans le cours ;
• Supprimé : l’appartenance aux groupes du cours, les rôles dans le contexte du cours, les préférences liées au cours, et — selon la case cochée à la désinscription — potentiellement les notes elles-mêmes si l’on purge ;
• Récupérable au retour : si l’utilisateur est réinscrit, l’option « Récupérer les anciennes notes si possible » (Recover user’s old grades) restaure ses notes dans le carnet. Le comportement par défaut de cette case est piloté par le réglage recovergradesdefault (Administration du site > Notes > Réglages généraux > « Récupérer les notes par défaut »). Sur une plateforme où les allers-retours d’inscription sont fréquents (synchronisations SIS un peu nerveuses), activer ce défaut évite bien des tickets « mes notes ont disparu ». Les remises de devoirs et messages, eux, « réapparaissent » naturellement puisque jamais supprimés.

D’où la doctrine, déjà esquissée : suspension d’abord, désinscription ensuite (et seulement si assumée). La suspension conserve tout et se révoque en un clic ; la désinscription casse des liens (groupes, rôles) qu’aucune récupération automatique ne restaure entièrement.

⚠️ Piège : la suppression de l’instance de méthode (corbeille sur la page Méthodes d’inscription) désinscrit tous ses utilisateurs d’un coup, avec tous les effets ci-dessus, groupes compris. Confondre l’œil (désactiver = suspendre, réversible) et la corbeille (supprimer = désinscrire, destructif) sur cette page est l’accident classique de fin d’année. La confirmation demandée par Moodle est explicite — lisez-la vraiment.

💡 Pour un dev React : le trio suspension / désinscription / récupération des notes correspond à soft delete / hard delete des relations avec conservation des entités + restauration opportuniste. Les données de l’utilisateur sont comme des lignes avec une foreign key toujours valide vers users mais plus aucune ligne dans memberships : rien n’est cassé en base, mais toutes vos queries qui joignent sur memberships ne les voient plus. « Recover grades » est une migration de réconciliation lancée au re-join.

4.6 Durée, expiration et tâches planifiées

4.6.1 Durée et dates d’inscription

Presque toutes les méthodes portent trois paramètres temporels par inscription :

• Date de début (enrolment start) : avant elle, l’inscription existe mais ne donne pas accès ;
• Durée (enrolment duration) : appliquée à chaque nouvelle inscription pour calculer sa fin ;
• Date de fin : après elle, l’inscription est expirée.

Une inscription expirée n’est pas automatiquement supprimée : son sort dépend de l’expiry action.

4.6.2 Action à l’expiration (expiry action)

Dans les réglages globaux de chaque plugin concerné (inscription manuelle, auto-inscription…), le paramètre « Action lors de l’échéance de l’inscription » (Action when enrolment expires, expiredaction) offre selon les plugins tout ou partie de ces options :

Le traitement effectif est réalisé par les tâches planifiées d’expiration de chaque plugin — l’expiration n’est donc pas « instantanée à la seconde près » mais suit le passage du cron.

4.6.3 Notification d’expiration

Deux réglages par instance (manuelle, auto-inscription…) pilotent les alertes :

• Notifier avant l’échéance de l’inscription (Notify before enrolment expires) : « Non » / « Uniquement la personne ayant inscrit » (l’enseignant/manager reçoit un récapitulatif des inscriptions arrivant à échéance dans ses cours) / « Personne ayant inscrit et personne inscrite » (l’étudiant est aussi prévenu) ;
• Seuil de notification (Notification threshold) : l’anticipation (par défaut 1 jour ; mettez 7 à 30 jours pour laisser le temps de réagir ou de renouveler un paiement).

Un réglage global (« Heure d’envoi des notifications d’échéance », expirynotifyhour) fixe l’heure de la journée à laquelle la tâche de notification envoie ses messages.

4.6.4 Les tâches planifiées à connaître

Le système d’inscription vit au rythme du cron. Dans Administration du site > Serveur > Tâches > Tâches planifiées, repérez (et surveillez, via les logs de tâches) notamment :

Si « rien ne se passe » (fichier plat ignoré, expirations jamais appliquées, notifications muettes), le premier réflexe est toujours : le cron tourne-t-il, et la tâche du plugin est-elle activée ?

⚠️ Piège : sur un serveur où le cron est en panne depuis plusieurs jours, sa remise en route déclenche d’un coup tout le retard accumulé : rafales de notifications d’expiration, vagues de suspensions/désinscriptions différées. Avant de réparer un cron longtemps arrêté sur une plateforme de production, passez en revue les tâches d’enrolment et envisagez de désactiver temporairement les plus sensibles le temps de vérifier l’état des données.

💡 Pour un dev React : le cron de Moodle joue le rôle de vos jobs différés (cron Vercel, queues BullMQ, Inngest) : l’expiration d’inscription n’est pas un setTimeout posé à l’inscription, c’est un balayage périodique qui compare timeend < now(). Mêmes propriétés que chez vous : latence jusqu’au prochain passage, idempotence nécessaire, et effet d’avalanche au redémarrage après une panne.

📚 Aller plus loin : le chapitre 5 (administration du site) reviendra sur la configuration du cron et la supervision des tâches ; d’ici là, la page « Scheduled tasks » de docs.moodle.org explique comment ajuster les fréquences et lire l’historique d’exécution de chaque tâche.

4.7 La page Participants moderne

Depuis Moodle 4.x, la page Participants est devenue le centre de contrôle unifié des inscriptions d’un cours — et elle est remarquablement puissante. Points clés pour l’administrateur :

Filtres combinés. En haut de la liste, un constructeur de filtres permet d’empiler des conditions reliées par « Correspond à TOUTES / N’IMPORTE LAQUELLE / AUCUNE » (match all / any / none), chaque ligne portant sur :

• Mot-clé (nom, email…) ;
• Statut : Actif / Suspendu ;
• Rôle : y compris « Aucun rôle » — parfait pour détecter les inscriptions sans rôle évoquées en 4.1 ;
• Méthode d’inscription : par instance (on distingue deux instances d’auto-inscription) ;
• Groupe : y compris « Aucun groupe » ;
• Inactif depuis plus de : dernier accès au cours antérieur à N jours/semaines.

On combine donc en trois clics des requêtes comme « tous les étudiants inscrits par la synchronisation de cohorte L1INFO2026, suspendus » ou « participants sans aucun groupe, inactifs depuis plus de 30 jours ». C’est l’outil d’audit quotidien des inscriptions.

Colonne Statut. Pour chaque participant, un badge Actif/Suspendu par méthode ; l’icône ⓘ ouvre le détail : nom de la méthode (« Inscription manuelle », « Synchronisation de cohorte (L1INFO2026) »), date d’inscription, date de début, date de fin. L’engrenage adjacent édite l’inscription (statut, dates) quand la méthode le permet ; la corbeille désinscrit — ces icônes n’apparaissent que si vos capabilities et la nature de la méthode l’autorisent (une inscription par base externe ne s’édite pas à la main, et c’est voulu).

Actions en masse. Cochez des participants (ou « Tout sélectionner », qui respecte le filtre courant), puis le menu « Avec les utilisateurs sélectionnés… » propose : envoyer un message, ajouter une annotation, télécharger au format tableur, et surtout — par méthode — modifier les inscriptions (changer statut et dates de toutes les inscriptions manuelles sélectionnées d’un coup) et désinscrire les inscriptions de la méthode choisie. Le workflow d’audit type : filtrer « inactifs depuis plus de 90 jours » + « méthode = auto-inscription » → tout sélectionner → suspendre en masse.

💡 Pour un dev React : cette page est l’exemple canonique de la data table filtrable avec actions bulk que vous avez construite dix fois (TanStack Table + filtres composables + row selection). Retenez surtout que « Tout sélectionner » opère sur le résultat filtré, pas sur la page affichée — le même choix UX que vous devez faire entre selectAllOnPage et selectAllMatching.

4.8 Bonnes pratiques d’architecture des inscriptions

Pour clore ce chapitre, les principes qui séparent une plateforme saine d’un enfer de tickets :

1. Choisissez une source de vérité par population — et une seule. Pour chaque population (étudiants en formation initiale, salariés, clients externes), décidez explicitement qui fait foi : le SIS (→ base externe ou fichier plat), les RH (→ cohortes uploadées), l’utilisateur lui-même (→ auto-inscription), le paiement (→ enrol_fee). Documentez ce choix. Toute inscription « hors canal » (le collègue serviable qui inscrit à la main un étudiant que la synchro retirera la nuit suivante) doit être l’exception tracée, pas l’habitude.

2. Évitez les doubles méthodes contradictoires. Deux méthodes automatiques sur la même population (une synchro cohorte ET une base externe couvrant les mêmes cours) créent des états incompréhensibles : l’une inscrit, l’autre ignore ; l’utilisateur quitte une source mais pas l’autre ; qui a suspendu quoi ? Si une transition impose un chevauchement, planifiez la bascule et supprimez l’ancienne méthode à date connue.

3. « Suspendre » par défaut pour toutes les actions externes. Réglez les « External unenrol action » (cohorte, base externe, fichier plat, méta) sur la suspension tant que vous n’avez pas une confiance totale dans la source. Un incident de synchronisation devient alors un non-événement réversible au lieu d’une perte de données de groupe et de rôles.

4. Ne touchez jamais à l’instance d’inscription manuelle, même « pour faire propre » dans un cours entièrement synchronisé. Désactivez-la à la rigueur (œil), ne la supprimez pas.

5. Testez le cycle complet d’expiration avant de vous y fier. Créez un cours bac à sable, une inscription avec durée d’un jour, seuil de notification à un jour, et vérifiez sur 48 h : la notification part-elle ? à qui ? l’expiry action s’applique-t-elle ? que voit l’utilisateur ? Les surprises (notification jamais envoyée car le cron passe après expirynotifyhour, action différente de celle attendue) se découvrent en bac à sable, pas sur 3 000 inscrits.

6. Standardisez les idnumbers dès le premier jour. Utilisateurs, cours et cohortes doivent porter un idnumber stable issu du SI. C’est le pivot de toutes les méthodes automatisées (flat file, base externe, uploads) ; l’introduire après coup sur une plateforme vivante est un chantier pénible.

7. Auditez périodiquement. Une fois par semestre : page « Gérer les plugins d’inscription » (des plugins actifs à zéro instance ? des instances orphelines ?), filtre Participants « Aucun rôle », cours en accès invité sans mot de passe, cohortes cachées obsolètes, tâches planifiées en échec.

8. Documentez pour vos successeurs. La description de chaque cohorte, le nom personnalisé de chaque instance de méthode (« Sync SIS — ne pas modifier ») et une page interne décrivant les flux (qui alimente quoi, à quelle heure, contact côté SIS) coûtent une heure et économisent des semaines.

⚠️ Piège : le grand classique de l’été — « on remet les compteurs à zéro » en supprimant les méthodes d’inscription des cours pour la rentrée. Résultat : désinscriptions massives, groupes vidés, notes orphelines, et la découverte en septembre que la réinitialisation de cours (course reset) était l’outil prévu pour cela. Avant toute opération de masse sur les inscriptions, faites une sauvegarde et répétez l’opération sur une copie du cours.

📚 Aller plus loin : la page « Enrolments » de docs.moodle.org (et sa déclinaison FR sur docs.moodle.org/fr) constitue l’index de toutes les méthodes ; moodledev.io documente l’API Enrolment pour le jour — proche, vu votre profil — où vous écrirez ou auditerez un plugin d’inscription. Enfin, le forum « Moodle in English > General help » regorge de post-mortems de synchronisations ratées : lecture très formatrice.

Résumé

• Une inscription (enrolment) est un lien utilisateur↔cours, distinct de l’attribution de rôle : on est inscrit avec un rôle, mais un rôle sans inscription existe (« Autres utilisateurs ») et chaque inscription est portée par une instance de méthode — supprimer l’instance supprime ses inscriptions.
• Chaque inscription a un statut actif/suspendu et des dates ; la suspension conserve toutes les données, la désinscription les rend orphelines (récupérables en partie via « Recover grades », défaut recovergradesdefault).
• La gestion se fait au niveau du site (Administration du site > Plugins > Inscriptions : activation, ordre, défauts) et au niveau du cours (Participants > Méthodes d’inscription : instances, œil, flèches, engrenage).
• Méthodes à maîtriser : manuelle (à ne jamais supprimer), auto-inscription (clés de cours et de groupe, quotas, fenêtres, purge des inactifs), accès invité (consultation sans inscription ni participation), synchronisation de cohorte (état dérivé d’une cohorte, « External unenrol action »), fichier plat (flux CSV add/del consommé par tâche planifiée), base de données externe (réconciliation d’état depuis une vue SQL, création de cours optionnelle), paiement (enrol_fee + payment accounts + passerelles — enrol_paypal est retiré du core), Publish as LTI tool (fournir le cours à une autre plateforme, LTI Advantage), plus méta-cours et les uploads CSV.
• Les cohortes sont des groupes d’utilisateurs à l’échelle du site ou d’une catégorie — sans effet par elles-mêmes, elles alimentent la synchronisation d’inscription, les restrictions, les audiences de rapports. À ne pas confondre avec les groupes de cours. Pivot : l’idnumber.
• Expiration : durée + date de fin + expiry action (garder/suspendre/désinscrire) + notification (destinataires, seuil), le tout exécuté par les tâches planifiées du cron.
• La page Participants moderne offre filtres combinés (statut, méthode, rôle, groupe, inactivité), détail des méthodes par participant et actions en masse.
• Doctrine : une source de vérité par population, suspension plutôt que désinscription pour les actions externes, idnumbers standardisés, tests d’expiration en bac à sable, documentation.

Dans le prochain chapitre

Vous savez désormais faire entrer les bonnes personnes dans les bons cours, automatiquement et à grande échelle. Le chapitre 5 prend de la hauteur : l’administration du site elle-même. Nous explorerons l’arborescence complète d’Administration du site — réglages généraux et politiques, apparence et thèmes Bootstrap 5, gestion des plugins et de leurs mises à jour, configuration du cron et des tâches planifiées (dont vous avez vu ici l’importance), sécurité, maintenance, et les outils de supervision qui vous diront, avant vos utilisateurs, que quelque chose ne tourne pas rond. C’est le chapitre qui fera de vous l’administrateur que votre plateforme mérite.