Chapitre 6 — Achèvement, restrictions d’accès et groupes : le moteur de scénarisation de Moodle

Jusqu’ici, vous avez appris à créer un cours, à le structurer en sections et à y déposer des activités et des ressources. Mais un cours Moodle qui se contente d’empiler des contenus n’est qu’une bibliothèque : tout est visible, tout est accessible, dans n’importe quel ordre, pour tout le monde. Ce chapitre change radicalement la donne. Nous allons étudier les trois mécanismes qui, combinés, transforment cette bibliothèque en scénario pédagogique : le suivi d’achèvement (completion tracking), les restrictions d’accès (restrict access ou availability), et les groupes et groupements (groups and groupings).

Ces trois briques forment ce qu’on peut appeler le « moteur de scénarisation » de Moodle :

• L’achèvement répond à la question « où en est l’étudiant ? ». C’est le système d’état et d’événements de la plateforme : chaque activité peut être « non commencée », « achevée », « achevée avec réussite » ou « achevée avec échec », et le cours lui-même possède son propre état d’achèvement.
• Les restrictions d’accès répondent à la question « qui peut voir/faire quoi, et quand ? ». C’est le système de rendu conditionnel : chaque activité ou section peut être soumise à un arbre de conditions (dates, notes, achèvements, profil, groupes) combinées en ET/OU.
• Les groupes répondent à la question « avec qui ? ». Ils permettent de cloisonner ou de segmenter une même population d’étudiants au sein d’un cours unique, et servent aussi de critère pour les restrictions.

💡 Pour un dev React : si vous venez de Next.js/React/TypeScript, voici la carte mentale à garder pour tout ce chapitre. L’achèvement est une machine à états (state machine) alimentée par des événements (soumission, note obtenue, consultation…) — pensez XState ou un reducer Redux dont les actions sont les événements Moodle. Les restrictions d’accès sont du rendu conditionnel et des route guards : if (!conditions.evaluate(user)) return <Locked/> ou null;. L’arbre de conditions ET/OU est littéralement stocké en JSON dans la base (colonne availability de la table course_modules) — un AST de prédicats que le moteur évalue à chaque affichage. Enfin, les groupes sont un scoping de données, une forme de multi-tenancy léger à l’intérieur d’un cours : même code, même structure, mais chaque « tenant » (groupe) ne voit que ses propres données dans les activités configurées ainsi.

Ce chapitre est long, car ces trois mécanismes s’imbriquent constamment : une restriction d’accès peut dépendre d’un achèvement, un achèvement de cours peut dépendre d’activités elles-mêmes restreintes, et un groupe peut conditionner l’un et l’autre. Nous terminerons par une méthodologie complète de conception d’un parcours conditionnel, avec un fil rouge concret : un module d’onboarding en quatre étapes.

6.1 Le suivi d’achèvement (completion tracking)

6.1.1 À quoi sert l’achèvement ?

Le suivi d’achèvement (completion tracking) permet à Moodle de savoir — et de montrer — si un étudiant a « terminé » une activité, puis un cours entier. Concrètement, il alimente quatre usages majeurs :

1. Des jalons visuels pour l’étudiant. Depuis Moodle 4.0, chaque activité affiche sur sa « carte » (sur la page de cours et sur la page de l’activité) des badges d’état : « À faire » (To do), « Fait » (Done), « Réussi » (Done: passed) ou « Échoué » (Done: failed). L’étudiant voit d’un coup d’œil ce qui lui reste à faire. L’index de cours (le panneau latéral gauche introduit en 4.0) reprend ces états sous forme de pastilles.
2. Des conditions pour les restrictions d’accès. C’est le lien fondamental avec la section 6.4 : « l’activité B n’est accessible que si l’activité A est achevée » suppose que A ait un suivi d’achèvement configuré.
3. Des rapports pour l’enseignant. Le rapport d’achèvement d’activités (tableau croisé étudiants × activités) et le rapport d’achèvement de cours permettent de suivre la progression de toute une cohorte (section 6.6).
4. Des déclencheurs pour d’autres systèmes. L’achèvement d’un cours peut délivrer un badge (voir la partie consacrée aux badges), déclencher l’inscription à un autre cours (via certains plugins d’inscription), conditionner un certificat, ou alimenter des plans de formation (compétences, learning plans).

💡 Pour un dev React : l’achèvement est un système événementiel. Quand un étudiant soumet un devoir, le module mod_assign émet un événement ; le sous-système de complétion (lib/completionlib.php côté PHP) écoute, réévalue les conditions de l’activité et met à jour l’état dans la table course_modules_completion. C’est un pattern event → reducer → state : l’état n’est jamais écrit directement par l’UI, il est dérivé des événements. Retenez aussi que cet état est ensuite mis en cache et que certains recalculs (notamment l’achèvement de cours) sont asynchrones — nous y reviendrons, c’est un piège classique.

6.1.2 Activation à trois niveaux

Le suivi d’achèvement doit être activé en cascade, du site vers l’activité :

Le réglage de cours « Afficher les conditions d’achèvement » (Show activity completion conditions), apparu avec la refonte 4.0, contrôle si les conditions (« Consulter », « Recevoir une note »…) sont listées explicitement sur les cartes d’activité côté étudiant. Le laisser à « Oui » est presque toujours la bonne décision : l’étudiant sait exactement quoi faire pour valider chaque jalon.

⚠️ Piège : l’erreur numéro un du débutant — passer une heure à chercher la section « Achèvement » dans les réglages d’une activité… alors que le suivi d’achèvement est désactivé au niveau du cours. Vérifiez toujours Paramètres du cours → Suivi d’achèvement avant toute chose. Symptôme associé : les restrictions d’accès de type « Achèvement d’activité » ne proposent aucune activité dans leur menu déroulant, tout simplement parce qu’aucune activité du cours n’a de suivi configuré.

📚 Aller plus loin : la page de référence francophone est docs.moodle.org/fr/Achèvement_d’activité  ; côté développeur, l’API est documentée sur moodledev.io/docs/apis/subsystems/completion .

6.2 L’achèvement d’activité

6.2.1 Les trois modes

Pour chaque activité ou ressource, la section « Achèvement » propose trois modes :

En mode manuel, l’étudiant voit un bouton « Marquer comme terminé » sur la carte de l’activité ; un clic bascule l’état (et un second clic peut le décocher, ce qui a des conséquences si des restrictions en dépendent — voir 6.4). En mode automatique, le badge « À faire » liste les conditions et se transforme en « Fait » quand elles sont toutes remplies ; l’étudiant ne peut rien cocher lui-même.

💡 Pour un dev React : le mode manuel est un simple useState<boolean> contrôlé par l’utilisateur ; le mode automatique est un état dérivé (derived state), calculé à partir d’autres sources de vérité (soumissions, notes, logs de consultation). Comme en React, mélanger les deux philosophies est source de bugs de conception : ne demandez jamais à un étudiant de « cocher » quelque chose que le système pourrait vérifier lui-même. Et comme tout état dérivé, l’achèvement automatique se recalcule quand ses dépendances changent — y compris à la baisse (une note modifiée sous le seuil peut faire repasser une activité de « Réussi » à « Échoué »).

6.2.2 Les conditions génériques (mode automatique)

Quatre conditions sont disponibles pour (presque) tous les modules :

1. Consulter l’activité (« L’étudiant doit consulter cette activité pour la terminer », Require view). Un simple affichage de la page de l’activité suffit. C’est la condition la plus faible : elle prouve un clic, pas une lecture. Pour les ressources (fichier, page, URL), c’est souvent la seule condition disponible.
2. Obtenir une note (« L’étudiant doit recevoir une note pour terminer cette activité », Require grade). L’activité est achevée dès qu’une note — n’importe laquelle, même 0 — est enregistrée dans le carnet de notes pour cet étudiant.
3. Note de passage (Passing grade). Si l’élément d’évaluation possède une note pour passer (grade to pass, définie dans les réglages de note de l’activité ou dans le carnet de notes), la condition d’achèvement peut exiger de l’atteindre. C’est ce réglage qui produit les états enrichis « achevée avec réussite » (completed, passed) et « achevée avec échec » (completed, failed) — deux états distincts que les restrictions d’accès savent différencier (section 6.4.2), ce qui est la clé des parcours de remédiation. Sur les cartes d’activité, l’étudiant voit alors « Réussi » ou « Échoué » au lieu d’un simple « Fait ».
4. Date d’achèvement attendue (Expect completed on). Attention, contre-intuitif : cette date ne bloque rien et ne complète rien. Elle est purement informative — elle alimente le rapport d’achèvement d’activités (les retards y apparaissent), le bloc Chronologie (Timeline) du tableau de bord et le calendrier. Ce n’est ni une date limite de remise (qui se règle dans l’activité elle-même), ni une restriction de date.

⚠️ Piège : ne confondez pas « Obtenir une note » et « Note de passage ». Avec la seule condition « obtenir une note », un étudiant qui a 2/20 à un quiz voit son activité marquée « Fait » — et toutes les restrictions en aval s’ouvrent. Si votre scénario exige la réussite, définissez impérativement une note pour passer dans les réglages de note de l’activité, puis cochez la condition de note de passage dans l’achèvement. Vérifiez aussi le carnet de notes : la note pour passer y est modifiable indépendamment, et une incohérence entre les deux endroits produit des états « Réussi/Échoué » incompréhensibles.

6.2.3 Les conditions spécifiques par module

C’est là que l’achèvement automatique devient réellement puissant : chaque module d’activité peut déclarer ses propres règles d’achèvement (custom completion rules), adaptées à sa nature. Le tableau suivant récapitule les principales dans Moodle 5.x :

La liste exacte évolue au fil des versions (BigBlueButton, notamment, a enrichi ses règles depuis son intégration au cœur de Moodle en 4.0) ; en cas de doute sur votre instance 5.2, ouvrez les réglages du module concerné : les conditions proposées dans la section « Achèvement » font foi.

💡 Pour un dev React : côté architecture de plugin, chaque module implémente une classe \mod_xxx\completion\custom_completion qui étend core_completion\activity_custom_completion — c’est l’équivalent d’une interface TypeScript que chaque module implémente pour exposer ses règles au moteur central : get_state(rule), get_defined_custom_rules(), get_custom_rule_descriptions(). Si un jour vous développez votre propre module d’activité, c’est ce contrat qu’il faudra honorer pour que vos conditions apparaissent dans l’UI et dans les rapports. Documentation : moodledev.io, « Activity completion ».

6.2.4 L’affichage côté étudiant depuis Moodle 4.0

La version 4.0 a profondément remanié l’expérience étudiant. Avant, l’achèvement se manifestait par de discrètes cases à cocher en marge droite des activités — que personne ne remarquait. Depuis 4.0 (et donc dans votre Moodle 5.2) :

• Chaque carte d’activité sur la page de cours affiche, sous le nom de l’activité, un badge d’état : « À faire » avec la liste des conditions (si « Afficher les conditions d’achèvement » est activé au niveau du cours), « Fait », « Réussi » ou « Échoué ».
• La même information apparaît en haut de la page de l’activité elle-même.
• L’index de cours (panneau latéral) affiche des pastilles colorées : cercle vide (à faire), cercle plein vert (fait), rouge (échoué).
• Le mode manuel affiche un bouton « Marquer comme terminé » cliquable directement depuis la page de cours, sans ouvrir l’activité.

Ce niveau de visibilité change la conception pédagogique : les conditions d’achèvement sont désormais un contrat explicite affiché à l’étudiant (« Recevoir une note de passage », « Faire des remises : 1 »). Rédigez-les en pensant qu’elles seront lues.

6.2.5 Valeurs par défaut d’achèvement par type d’activité

Configurer l’achèvement activité par activité devient vite fastidieux dans un cours de cinquante activités. Moodle propose des valeurs par défaut d’achèvement de cours (Default activity completion), accessibles depuis le menu du cours : Plus → Achèvement de cours → onglet « Valeurs par défaut d’achèvement » (le chemin exact peut varier légèrement selon le thème, mais la page fait partie de l’ensemble « Achèvement de cours »).

Sur cette page, vous sélectionnez un ou plusieurs types d’activité (Devoir, Quiz, Fichier…) et définissez le réglage d’achèvement qui s’appliquera automatiquement à chaque nouvelle instance de ce type créée dans ce cours. Exemple de politique cohérente :

Il existe aussi des défauts au niveau site (Administration du site → Cours → Course default settings et pages de défauts d’achèvement par activité), qu’un administrateur peut fixer pour toute la plateforme. Les défauts de cours priment sur les défauts de site ; le réglage manuel dans l’activité prime sur tout.

⚠️ Piège : les valeurs par défaut ne s’appliquent qu’aux activités créées après leur définition. Modifier les défauts ne change rien aux quarante activités existantes — pour elles, il faut passer par l’édition en masse (ci-dessous).

6.2.6 Édition en masse des réglages d’achèvement

Toujours dans l’ensemble « Achèvement de cours », l’onglet « Modifier en masse l’achèvement d’activités » (Bulk edit activity completion) affiche la liste de toutes les activités du cours avec des cases à cocher. Sélectionnez par exemple vos douze quiz, cliquez sur « Modifier », définissez une seule fois « Automatique + note de passage », enregistrez : les douze sont reconfigurés d’un coup. C’est l’outil indispensable pour normaliser un cours existant ou réparer un cours importé dont les réglages sont incohérents.

Notez que l’édition en masse ne fonctionne que sur des activités de même type simultanément lorsqu’il s’agit de conditions spécifiques (on ne peut pas appliquer « remettre un devoir » à un forum) ; pour les conditions génériques, le mélange de types est possible tant que les conditions choisies existent partout.

6.2.7 Le verrouillage des réglages : le piège du « Déverrouiller »

Voici l’un des pièges les plus destructeurs de tout Moodle, et il mérite son propre encadré. Dès qu’au moins un étudiant possède des données d’achèvement pour une activité (il a coché la case, ou le système l’a marquée achevée), les réglages d’achèvement de cette activité sont verrouillés : les champs apparaissent grisés, avec un bouton « Déverrouiller les options d’achèvement » (Unlock completion settings) et un avertissement.

⚠️ Piège : cliquer sur « Déverrouiller » puis enregistrer les réglages supprime l’état d’achèvement enregistré pour tous les étudiants sur cette activité, afin que le moteur recalcule tout selon les nouvelles règles. Conséquences en cascade : les états manuels cochés par les étudiants sont perdus définitivement (le système ne peut pas les recalculer, puisqu’ils étaient déclaratifs) ; les restrictions d’accès qui dépendaient de cet achèvement se referment brutalement pour des étudiants qui avaient déjà progressé au-delà ; l’achèvement de cours peut être invalidé rétroactivement, y compris des badges déjà en jeu. Pour les conditions automatiques, Moodle recalcule ce qu’il peut (notes, remises existantes), donc les dégâts sont souvent réparés au recalcul suivant — mais « consulter l’activité » et le marquage manuel ne se reconstituent pas toujours fidèlement. Règle d’or : figez vos réglages d’achèvement avant l’arrivée des étudiants, et si vous devez absolument modifier en cours de route, faites une sauvegarde du cours avec données utilisateur au préalable, prévenez les étudiants, et vérifiez les restrictions en aval.

6.2.8 Le marquage manuel par l’enseignant (override)

Depuis Moodle 3.11, un enseignant peut forcer l’état d’achèvement d’un étudiant sur une activité, dans les deux sens (marquer achevé ou non achevé), depuis le rapport d’achèvement d’activités (section 6.6.1) : il suffit de cliquer sur la cellule correspondante du tableau croisé. Cet override est tracé : la cellule change d’apparence et le rapport indique « Défini par [nom de l’enseignant] ».

Ce marquage requiert la capacité moodle/course:overridecompletion, attribuée par défaut aux rôles enseignant et gestionnaire. Cas d’usage typiques : valider une activité réalisée hors ligne (présentation orale, TP en présentiel), débloquer un étudiant coincé par une condition techniquement défaillante (paquet SCORM capricieux), ou au contraire invalider un achèvement obtenu par erreur.

💡 Pour un dev React : l’override est l’équivalent d’une écriture directe dans le store qui court-circuite le reducer — puissant, mais à utiliser en connaissance de cause : au prochain événement pertinent, selon les cas, le recalcul automatique peut entrer en tension avec la valeur forcée. Moodle privilégie la valeur d’override tant qu’un nouvel événement « plus fort » ne survient pas, mais considérez l’override comme un correctif ponctuel, pas comme un mode de fonctionnement normal.

6.3 L’achèvement de cours

6.3.1 Principe et configuration

Au-delà des activités individuelles, le cours entier peut avoir ses propres conditions d’achèvement. La page de configuration se trouve dans le menu du cours : Plus → Achèvement de cours (Course completion), onglet « Réglages d’achèvement de cours ». Elle propose les familles de conditions suivantes :

6.3.2 L’agrégation : globale et par type

En tête de la page se trouve le réglage le plus important : « Conditions requises » — « Le cours est achevé lorsque TOUTES les conditions sont remplies » ou « … lorsque N’IMPORTE LAQUELLE des conditions est remplie ». Cette agrégation globale s’applique entre les familles de conditions.

À l’intérieur de certaines familles (activités terminées, autres cours, validation par rôle), une agrégation locale toutes/n’importe laquelle existe aussi. Vous pouvez donc exprimer : « (toutes les activités cochées) ET (note de cours ≥ 10) », ou « (activité finale terminée) OU (validation manuelle par l’enseignant) » — ce second exemple étant une excellente soupape pour les cas particuliers.

💡 Pour un dev React : c’est une expression booléenne à deux niveaux seulement — GLOBAL_OP(famille1_OP(...), famille2, ...) — bien moins expressive que l’arbre arbitrairement imbriqué des restrictions d’accès (section 6.4.4). Si votre logique d’achèvement de cours devient complexe, la bonne pratique est de la déporter : créez une activité « pivot » (par exemple un quiz final) dont l’accès est gouverné par un arbre de restrictions riche, puis faites dépendre l’achèvement de cours de cette seule activité. Vous retrouvez ainsi toute l’expressivité de l’AST des restrictions.

6.3.3 Suivi côté étudiant : le bloc « Statut d’achèvement du cours »

Le bloc « Statut d’achèvement du cours » (Course completion status) affiche à l’étudiant sa progression vis-à-vis des conditions de cours : « Statut : en cours », liste des conditions avec leur état, lien « Plus de détails » vers un rapport individuel. Pour l’enseignant, le même bloc offre un lien direct vers le rapport d’achèvement de cours de toute la cohorte. Si vous utilisez l’auto-achèvement, ajoutez aussi le bloc « Auto-achèvement » comme indiqué plus haut. Pensez à activer le mode édition pour ajouter ces blocs (et rappelez-vous que dans les thèmes récents, le tiroir de blocs est à droite).

L’achèvement de cours se reflète également dans l’écosystème personnel de l’étudiant : la page « Mes cours » et le tableau de bord affichent un pourcentage de progression sur les cartes de cours (calculé à partir des activités suivies), et les cours achevés peuvent être filtrés ; la Chronologie (Timeline) exploite quant à elle les dates d’achèvement attendues des activités.

6.3.4 Le cron et les délais de calcul

⚠️ Piège : contrairement à l’achèvement d’activité (recalculé de façon quasi immédiate au fil des événements), l’achèvement de cours est évalué par des tâches planifiées (scheduled tasks), exécutées par le cron de Moodle — typiquement les tâches core\task\completion_regular_task et core\task\completion_daily_task, qui tournent par défaut toutes les quelques minutes pour la première. Concrètement : un étudiant termine sa dernière activité, mais son cours ne passe à « achevé » que quelques minutes plus tard (voire bien plus si le cron du serveur est mal configuré ou surchargé). Conséquences pratiques : ne promettez jamais un badge ou un certificat « instantané » ; lors de vos tests, si l’achèvement de cours ne bascule pas, vérifiez d’abord que le cron tourne (Administration du site → Serveur → Tâches → Tâches planifiées, ou en observant la date de dernière exécution du cron sur la page de notifications admin) avant de soupçonner vos conditions. Sur un environnement de développement local, lancez le cron à la main : php admin/cli/cron.php.

Autre subtilité temporelle : une fois qu’un étudiant a commencé à être suivi pour l’achèvement de cours, la modification des critères de cours n’est pas rétroactive de manière simple ; comme pour les activités, verrouillage et avertissements s’appliquent. Concevez les critères avant l’ouverture du cours.

📚 Aller plus loin : docs.moodle.org/fr/Achèvement_de_cours  pour la configuration, et docs.moodle.org/fr/Badges  pour la délivrance automatique de badges sur achèvement — nous y consacrons une partie dédiée.

6.4 Les restrictions d’accès (restrict access / availability)

Nous voici au cœur du réacteur. Les restrictions d’accès permettent de conditionner l’accès à toute activité, ressource ou section de cours par un arbre de conditions logiques. C’est le mécanisme qui transforme une liste plate de contenus en parcours.

6.4.1 Trois notions à ne jamais confondre : achèvement, restriction, visibilité

Beaucoup de confusion vient de là : masquer une activité n’est pas la restreindre (le masquage est inconditionnel), et l’achèvement ne verrouille rien (c’est la restriction qui verrouille, éventuellement en fonction d’un achèvement).

💡 Pour un dev React : visibilité = l’élément n’est pas dans le JSX du tout (retiré au build, pour tout le monde). Restriction = rendu conditionnel par utilisateur à l’exécution — soit disabled avec un tooltip explicatif (condition affichée grisée), soit return null (condition cachée, œil barré). Achèvement = une entrée dans le store, que les prédicats des autres composants peuvent lire. Et comme pour un guard de route Next.js (middleware), la restriction est vérifiée côté serveur : un étudiant qui forge l’URL directe d’une activité restreinte reçoit une page d’erreur/explication, pas le contenu. C’est une vraie barrière d’accès, pas un simple masquage cosmétique du DOM.

6.4.2 Les types de restrictions natives

Dans les réglages de toute activité ou section, la section « Restreindre l’accès » (Restrict access) commence vide (« Aucune »). Le bouton « Ajouter une restriction… » ouvre le choix des types. Moodle 5.2 fournit nativement :

Les restrictions Groupe et Groupement n’apparaissent dans la liste que s’il existe au moins un groupe/groupement dans le cours (ou si vous avez la capacité d’accéder à tous les groupes).

Le système est extensible : la restriction est un type de plugin (availability_xxx), et l’écosystème propose des plugins tiers répandus — restriction par niveau/langue (availability_language : afficher la version française ou anglaise d’une ressource selon la langue de l’interface de l’étudiant), par rôle (availability_role), par cohorte (availability_cohort), par appareil, par adresse IP, par nombre de mots dans le forum, etc. Vérifiez la compatibilité 5.2 avant installation, comme pour tout plugin.

📚 Aller plus loin : la liste des plugins de disponibilité est consultable sur moodle.org/plugins  (catégorie Availability conditions), et le guide de développement d’une condition personnalisée sur moodledev.io/docs/apis/plugintypes/availability  — c’est d’ailleurs l’un des types de plugins les plus simples à écrire, un excellent premier projet de développement Moodle.

6.4.3 L’œil ouvert et l’œil barré : condition grisée vs condition cachée

Chaque condition individuelle (et chaque jeu de conditions) porte une icône en forme d’œil, et ce petit pictogramme gouverne une différence UX majeure :

• Œil ouvert (par défaut) : quand la condition n’est pas remplie, l’activité apparaît sur la page de cours grisée, non cliquable, avec le motif affiché : « Non disponible à moins que : l’activité Quiz 1 soit marquée comme achevée ». L’étudiant sait que l’élément existe et ce qu’il doit faire pour y accéder. C’est motivant et transparent — idéal pour un parcours linéaire assumé.
• Œil barré : quand la condition n’est pas remplie, l’activité est totalement invisible — comme si elle n’existait pas. Aucun indice, aucun teaser. Indispensable quand révéler l’existence même de l’élément poserait problème : contenu de remédiation (inutile d’afficher « Non disponible sauf si votre note est inférieure à 50 % » aux étudiants qui ont réussi — c’est stigmatisant et confus), contenus réservés à un groupe (le Groupe B n’a pas à savoir que le Groupe A a d’autres ressources), surprises pédagogiques.

Le clic sur l’œil bascule l’état pour cette condition. Dans un ensemble ET, il suffit qu’une condition déterminante soit « œil barré » pour que l’élément entier soit caché lorsque cette condition échoue. Petite subtilité de restitution : quand plusieurs conditions à œil ouvert coexistent, Moodle compose un message explicatif complet (« Non disponible à moins que : … et … ») ; les conditions à œil barré sont simplement omises du message.

⚠️ Piège : dans les branches OU (« n’importe laquelle des conditions »), l’œil se règle au niveau du jeu entier et non condition par condition — c’est logique (dans un OU, expliquer une seule branche serait trompeur) mais surprend toujours la première fois. Autre piège : l’œil barré cache l’activité sur la page de cours, mais l’élément peut encore transparaître ailleurs si vous n’y prenez garde — notamment dans le carnet de notes (un élément noté restreint reste visible dans le carnet, colonne vide) et dans certains blocs. Pour une confidentialité totale d’un contenu noté, combinez restriction et réglages du carnet.

6.4.4 La logique combinatoire : ET, OU, négation, jeux imbriqués

Dès qu’il y a deux conditions ou plus, un sélecteur apparaît en tête : « L’étudiant doit / ne doit pas remplir toutes les conditions / n’importe laquelle des conditions suivantes ». Vous disposez donc de : ET (toutes), OU (n'importe laquelle), et de la négation globale (ne doit pas), soit NON(ET(…)) et NON(OU(…)).

Pour aller au-delà d’un seul niveau, le type « Jeu de restrictions » insère un sous-ensemble avec son propre opérateur. On peut imbriquer des jeux dans des jeux, sans limite pratique, et exprimer n’importe quelle formule booléenne. Exemple concret — « accessible aux étudiants du Groupe A ayant réussi le quiz, OU à tout le monde après le 1er décembre » :

Restreindre l'accès :
  L'étudiant doit remplir N'IMPORTE LAQUELLE des conditions :
  ├── Jeu de restrictions (toutes les conditions) :
  │     ├── Groupe : Groupe A
  │     └── Achèvement : « Quiz certificatif » doit être achevée avec note de réussite
  └── Date : à partir du 1 décembre 2026, 00:00

Et un exemple avec négation — « caché aux étudiants qui ont déjà validé le module équivalent » :

Restreindre l'accès :
  L'étudiant NE DOIT PAS remplir la condition :
  └── [œil barré] Achèvement : « Test de positionnement » doit être achevée avec note de réussite

💡 Pour un dev React : sous le capot, tout cet arbre est sérialisé en JSON dans le champ availability de la table course_modules (ou course_sections). Un exemple réel ressemble à :

\{"op":"|","c":[
  \{"op":"&","c":[
    \{"type":"group","id":12\},
    \{"type":"completion","cm":345,"e":2\}
  ],"showc":[true,true]\},
  \{"type":"date","d":">=","t":1764547200\}
],"show":true\}

op est l’opérateur (&, |, !&, !|), c le tableau d’enfants (récursif — un enfant peut être lui-même un {"op":...}), e l’état d’achèvement attendu (1 = achevé, 2 = achevé avec réussite, 3 = achevé avec échec, 0 = non achevé), et show/showc encodent l’œil (grisé vs caché). C’est exactement un AST de prédicats JSON, évalué côté PHP par les classes du sous-système core_availability (tree.php, pattern Composite). Si un jour vous générez des cours par script ou par API, c’est ce JSON que vous écrirez.

6.4.5 Restrictions au niveau d’une section entière

Les restrictions ne se limitent pas aux activités : chaque section de cours possède sa propre zone « Restreindre l’accès » (Modifier la section → Restreindre l’accès). Une section restreinte verrouille — ou cache, selon l’œil — toutes les activités qu’elle contient, d’un coup.

Les règles d’interaction sont simples mais essentielles :

• Les restrictions de section et d’activité se cumulent en ET : pour accéder à une activité, l’étudiant doit satisfaire les conditions de la section et celles de l’activité. Il n’y a pas de « surcharge » possible : une activité ne peut pas être plus permissive que sa section.
• Il ne s’agit pas d’un héritage copié dans chaque activité, mais d’une évaluation en cascade : modifier la restriction de section affecte immédiatement tout son contenu.
• Cas d’usage roi : le déblocage hebdomadaire — une restriction de date « à partir de » sur chaque section thématique, plutôt que sur chacune de ses quinze activités. Ou encore : une section entière réservée à un groupement (section 6.5.4).

⚠️ Piège : avec le format de cours « une section par page » ou les nouveaux formats à sous-sections (les sous-sections/subsections sont arrivées en Moodle 4.5 comme délégation de section), vérifiez le comportement de vos restrictions sur les sections imbriquées : la restriction d’une section parente s’applique à ses sous-sections, et l’empilement peut devenir difficile à déboguer. Documentez votre logique en dehors de Moodle (un simple diagramme) dès que vous dépassez deux niveaux de conditions.

6.4.6 Recettes de parcours conditionnels (adaptive learning)

Voici quatre recettes complètes, prêtes à adapter. Elles supposent le suivi d’achèvement activé au niveau du cours.

Recette (a) — Parcours linéaire strict

Objectif : chaque activité ne s’ouvre que lorsque la précédente est terminée.

1. Pour chaque activité de la chaîne, configurez un achèvement automatique avec une condition significative (remise pour un devoir, note de passage pour un quiz, « consulter » à la rigueur pour une ressource).
2. Sur l’activité 2 : Restreindre l’accès → Achèvement d’activité → « Activité 1 doit être marquée comme achevée ». Œil ouvert (l’étudiant voit la suite grisée : effet « escalier » motivant).
3. Sur l’activité 3 : condition sur l’activité 2. Et ainsi de suite — chaque activité ne dépend que de la précédente (inutile de conditionner l’activité 5 aux activités 1 à 4 : la transitivité fait le travail, et l’arbre reste maintenable).
4. Optionnel : l’achèvement de cours = « toutes les activités » ou simplement la dernière (là encore, la transitivité suffit si la chaîne est stricte).

⚠️ Piège : si l’une des activités de la chaîne est en achèvement manuel, un étudiant peut décocher son achèvement après coup — et toutes les activités en aval se referment instantanément, alors qu’il y a peut-être déjà travaillé (ses données ne sont pas perdues, mais l’accès est coupé). Préférez l’achèvement automatique partout dans une chaîne stricte, ou acceptez cette souplesse en connaissance de cause.

Recette (b) — Remédiation par note

Objectif : après un quiz diagnostic, orienter automatiquement — remédiation si moins de 50 %, parcours standard entre 50 et 80 %, contenu avancé à partir de 80 %.

1. Créez le Quiz diagnostic : achèvement automatique, condition « obtenir une note » (toute note suffit : c’est le fait d’avoir passé le diagnostic qui compte, pas de le réussir).
2. Section ou activités « Remédiation » : Restreindre l’accès → toutes les conditions → Achèvement : « Quiz diagnostic doit être marquée comme achevée » ET Note : « Quiz diagnostic doit être < 50 % ». Œil barré sur la condition de note (les bons étudiants n’ont pas à voir ce contenu, et les étudiants en remédiation n’ont pas besoin qu’on leur rappelle leur note en gris sur chaque ressource).
3. Contenus « Standard » : Note ≥ 50 % (et, si vous voulez les réserver strictement à la tranche intermédiaire, ajoutez « < 80 % » — mais il est souvent pédagogiquement préférable de laisser le tronc commun accessible à tous ceux qui ont ≥ 50 %).
4. Contenus « Avancés » : Note ≥ 80 %, œil barré ou ouvert selon que vous voulez ou non « teaser » l’existence du contenu bonus.
5. Bouclage : à la fin de la remédiation, placez un quiz de repêchage ; les contenus standard peuvent alors être ouverts par un OU — « (Note diagnostic ≥ 50 %) OU (repêchage achevé avec note de réussite) » — via un jeu de restrictions.

Pourquoi « achevée » ET « note < 50 % », et pas la note seule ? Parce qu’absence de note = condition de note non remplie dans les deux sens : avant de passer le quiz, l’étudiant ne satisfait ni « ≥ 50 » ni « < 50 »… sauf que « < 50 % » est vrai pour une note nulle selon la manière dont la note vide est traitée à l’affichage — le comportement des notes vides dans les conditions a des subtilités. La condition d’achèvement explicite lève toute ambiguïté : rien ne s’ouvre avant que le diagnostic ait été réellement passé.

Recette (c) — Parcours au choix de l’étudiant

Objectif : l’étudiant choisit son parcours (par exemple « Débutant » ou « Confirmé ») et ne voit que le sien.

Variante 1 — avec l’activité Sondage (Choice) et le plugin de choix de groupe :

1. Créez deux groupes « Parcours débutant » et « Parcours confirmé » (section 6.5).
2. Le plus élégant est le plugin tiers très répandu Sélection de groupe (Group choice, mod_choicegroup) : l’étudiant choisit et est automatiquement inscrit dans le groupe correspondant. Avec l’activité Sondage native, le choix n’inscrit dans aucun groupe — il faudrait inscrire à la main, ce qui ne passe pas à l’échelle.
3. Sur chaque section de parcours : Restreindre l’accès → Groupe → le groupe correspondant, œil barré.

Variante 2 — sans plugin, avec un champ de profil : si l’information de parcours existe déjà dans le SI (filière, campus…), synchronisez-la dans un champ de profil personnalisé et restreignez directement par « Champ de profil ». Zéro action étudiante requise.

Variante 3 — 100 % native mais rustique : deux clés d’inscription de groupe (section 6.5.2) communiquées aux deux populations ; le choix se fait à l’inscription au cours.

Recette (d) — Déblocage par date pour cohortes échelonnées

Objectif : le même cours sert plusieurs vagues d’inscription (session de janvier, session de mars), chacune avec son calendrier de déblocage.

1. Créez un groupe par vague : « Session janvier », « Session mars » (alimenté par une clé d’inscription de groupe, une synchronisation de cohorte, ou un import CSV).
2. Sur chaque section hebdomadaire, utilisez un jeu de restrictions par vague :

La section « Semaine 2 » : n'importe laquelle des conditions —
  ├── Jeu (toutes) : Groupe « Session janvier » ET Date ≥ 12 janvier 2026
  └── Jeu (toutes) : Groupe « Session mars »  ET Date ≥ 9 mars 2026

3. Œil barré sur les conditions de groupe pour que chaque vague ne voie que son propre calendrier.

C’est verbeux (deux jeux par section), mais cela évite de dupliquer le cours — et donc de maintenir deux exemplaires du contenu. Au-delà de trois ou quatre vagues, envisagez plutôt la duplication de cours ou, sur les offres commerciales, des mécanismes de « relative dates » (le mode dates relatives de Moodle, encore expérimental, calcule les dates par rapport à la date de début de cours de l’étudiant — vérifiez son statut sur votre 5.2 avant de vous y fier en production).

Avantages et limites face aux vrais moteurs adaptatifs

Ce que ce système fait très bien : des parcours déterministes basés sur des règles explicites (notes, achèvements, dates, attributs), transparents, auditables, sans dépendance externe. Pour 90 % des besoins de scénarisation d’une formation en ligne, c’est amplement suffisant.

Ce qu’il ne fait pas : de l’adaptation fine et dynamique au sein d’un contenu (les règles s’appliquent entre activités, pas à l’intérieur — à l’exception de la Leçon, dont les branchements internes sont un mini-moteur adaptatif à elle seule) ; de la recommandation statistique ou par apprentissage automatique (pas de « les étudiants comme vous ont réussi avec… ») ; de la modélisation de connaissance (knowledge tracing) ; et la maintenance devient coûteuse au-delà d’une vingtaine de règles — chaque condition est éparpillée dans les réglages de chaque activité, sans vue d’ensemble native de l’arbre global du cours. Si votre projet exige un vrai moteur adaptatif, Moodle s’interface avec des outils externes via LTI (voir la partie intégrations) ; mais commencez toujours par épuiser les possibilités natives, dont le rapport puissance/complexité est excellent.

6.5 Groupes et groupements

6.5.1 Les concepts

• Un groupe (group) est un ensemble d’utilisateurs au sein d’un cours. Les groupes n’existent qu’à l’échelle du cours (pour des ensembles transversaux au site, ce sont les cohortes, gérées par l’administrateur, qui peuvent d’ailleurs se synchroniser vers des groupes de cours via la méthode d’inscription « synchronisation de cohorte »).
• Un groupement (grouping) est un ensemble de groupes. Là où le groupe contient des utilisateurs, le groupement contient des groupes. Son utilité : appliquer une logique à une famille de groupes d’un coup — typiquement « restreindre cette activité aux membres du groupement Projets » ou « cette activité en groupes séparés n’utilise que les groupes du groupement TP », quand le cours contient plusieurs découpages simultanés (classes administratives ET équipes projet ET binômes de TP).
• Un participant peut appartenir à plusieurs groupes simultanément — c’est même la norme dès qu’il y a plusieurs découpages. C’est pour arbitrer entre ces découpages que les groupements existent.

La gestion se fait dans Participants → menu déroulant → Groupes (onglets Groupes / Groupements / Vue d’ensemble).

💡 Pour un dev React : un groupe est un scope de données — pensez multi-tenancy léger : une seule instance de cours (un seul « déploiement »), mais les requêtes des activités group-aware sont filtrées par groupid, comme un WHERE tenant_id = ? injecté automatiquement. Le groupement, lui, est une collection nommée de scopes, un peu comme un tag qui sélectionne quel jeu de tenants une feature doit considérer. Et l’appartenance multiple ressemble aux rôles composables : l’utilisateur porte plusieurs scopes, et chaque activité déclare lequel elle regarde (via son groupement associé) ou les regarde tous.

6.5.2 Créer et peupler les groupes

Plusieurs méthodes, du plus artisanal au plus industriel :

1. Création manuelle : bouton « Créer un groupe » — nom, description (affichée sur la page des participants selon configuration), image/photo de groupe (affichée notamment à côté des messages de forum en mode groupe et sur la page des participants), et deux réglages notables :
   • la clé d’inscription de groupe (group enrolment key) : si la méthode d’inscription « auto-inscription » du cours a une clé activée, un étudiant qui saisit à la place la clé du groupe est inscrit au cours et placé dans ce groupe, en une seule opération. C’est le moyen le plus simple de router des étudiants vers le bon groupe sans aucune manipulation enseignante — distribuez une clé différente à chaque classe. (Attention : la clé de groupe requiert que l’auto-inscription du cours ait elle-même une clé définie, sinon l’option est inopérante.)
   • la messagerie de groupe (group messaging) : active une conversation de groupe dans la messagerie Moodle pour tous les membres. Ensuite, « Ajouter/retirer des utilisateurs » pour peupler.
2. Auto-création (Auto-create groups) : générez N groupes d’un coup — soit par nombre de groupes (« créez-moi 6 groupes »), soit par nombre de membres (« des groupes de 4 »), avec répartition aléatoire ou alphabétique (par prénom/nom), schéma de nommage (Groupe @ donne Groupe A, B, C… ; Groupe # donne Groupe 1, 2, 3…), possibilité de ne prendre que les utilisateurs d’un rôle donné (étudiants), d’éviter le dernier petit groupe orphelin (« empêcher un dernier groupe trop petit »), et d’affecter directement les groupes créés à un groupement (nouveau ou existant). Un aperçu est proposé avant validation.
3. Import CSV : « Importer des groupes » crée des groupes (et groupements) depuis un CSV ; et l’outil d’import d’inscriptions ou admin/tool/uploaduser peut placer les utilisateurs dans des groupes via les colonnes group1, course1… C’est la voie industrielle pour synchroniser des classes depuis un SI scolaire (souvent supplantée, en production, par la synchronisation de cohortes ou des plugins d’inscription spécifiques).
4. Choix par l’étudiant : via le plugin Group choice évoqué en recette (c).

6.5.3 Les modes de groupe sur les activités

Le mode de groupe (group mode) est le réglage qui rend une activité « consciente » des groupes. Trois valeurs, réglables dans les « Réglages courants » (Common module settings) de chaque activité — et, en 4.x+, directement depuis l’icône dédiée sur la carte d’activité en mode édition :

Le réglage de cours « Imposer le mode de groupe » (Force group mode, dans les paramètres du cours, section Groupes) écrase le mode de toutes les activités par le mode défini au niveau cours — pratique pour un cours entièrement cloisonné par classes, mais brutal : plus aucune activité ne peut y déroger. Le réglage de cours définit aussi un simple défaut (non forcé) pour les nouvelles activités.

L’effet concret varie sensiblement selon le module — c’est là qu’il faut être précis :

⚠️ Piège : le mode de groupe ne restreint pas l’accès à l’activité — il en cloisonne le contenu. Un étudiant sans aucun groupe accède quand même à un forum en groupes séparés (il n’y voit alors, selon les cas, que les discussions « tous participants », et ne peut généralement pas y écrire, ce qui génère des tickets de support incompréhensibles). Si vous voulez réserver l’accès à certains groupes, c’est une restriction d’accès de type Groupe qu’il faut, en complément ou à la place. Vérifiez systématiquement, via la Vue d’ensemble des groupes, qu’aucun étudiant n’est orphelin de groupe quand le cours repose sur ce mécanisme.

6.5.4 Groupement lié à une activité et « réservé aux membres du groupement »

Dans les « Réglages courants » d’une activité en mode groupes séparés/visibles, le champ « Groupement » désigne quel groupement fournit les groupes que l’activité doit considérer. Cas typique : le cours a 6 groupes-classes et 12 groupes-projets ; le forum de classe est lié au groupement « Classes », le wiki de projet au groupement « Projets ». Sans cela, le sélecteur de groupes de chaque activité mélangerait les 18 groupes — inutilisable.

Lier un groupement ne restreint pas l’accès : un étudiant hors du groupement voit encore l’activité (avec un contenu possiblement vide pour lui). Pour réserver réellement l’activité, ajoutez une restriction d’accès de type Groupement. Historiquement, une case « Réservé aux membres du groupement » (Available for group members only) faisait ce travail directement dans les réglages courants, mais elle a été supprimée il y a longtemps au profit du système de restrictions, plus général : dans Moodle 5.2, la restriction d’accès est la seule voie, et c’est tant mieux (une seule mécanique à comprendre).

6.5.5 Cas d’usage récapitulatifs

1. Plusieurs classes dans un seul cours. Un cours « Mathématiques Terminale », trois classes TA/TB/TC. Groupes par classe (peuplés par cohortes ou CSV), mode de groupe séparés forcé au niveau cours si le cloisonnement doit être total, ou activité par activité sinon. Chaque enseignant est lui-même membre de sa classe… ou pas : voir le point 3.
2. Travaux d’équipe. Groupes « Équipe 1..N » (auto-création par 4, aléatoire), rassemblés dans un groupement « Équipes S1 ». Devoir en remise de groupe pointant ce groupement ; wiki en groupes séparés lié au même groupement ; forum d’équipe idem. Au semestre 2, nouveau tirage : groupement « Équipes S2 », sans toucher aux classes.
3. Enseignants filtrant leurs propres étudiants. Ajoutez chaque enseignant dans le(s) groupe(s) de ses classes. Dans le carnet de notes, le rapport de l’évaluateur (comme le tableau de notation du Devoir, le rapport d’achèvement, la liste des participants…) offre alors un sélecteur de groupe ; en mode groupes séparés, un enseignant non-éditeur sans la capacité moodle/site:accessallgroups ne voit que ses groupes — cloisonnement réel, pas seulement un filtre de confort. Les enseignants éditeurs, qui possèdent par défaut accessallgroups, voient tout mais profitent du filtre. C’est l’interaction groupes × capacités × carnet de notes qui fait tenir les grands cours mutualisés.
4. Cohortes échelonnées et parcours différenciés : recettes (c) et (d) de la section 6.4.6 — les groupes comme matière première des restrictions.

📚 Aller plus loin : docs.moodle.org/fr/Groupes  et docs.moodle.org/fr/Groupements  ; pour l’API développeur (manipulation de groupes par web services ou en PHP : groups_add_member(), web services core_group_*), voir moodledev.io  — utile le jour où vous synchroniserez les groupes depuis une app Next.js d’administration via l’API REST de Moodle.

6.6 Le suivi côté enseignant : rapports et pilotage

Scénariser ne sert à rien sans instrumentation. Voici le tableau de bord de l’enseignant.

6.6.1 Le rapport d’achèvement d’activités

Cours → Rapports → Achèvement d’activités (Activity completion). C’est le rapport le plus utile au quotidien : un tableau croisé — une ligne par étudiant, une colonne par activité suivie — avec dans chaque cellule l’icône d’état : case vide (non achevé), coche bleue (achevé manuellement par l’étudiant), coche verte (achevé automatiquement), coche verte « réussite », croix rouge « échec », et les états forcés par un enseignant signalés distinctement.

Fonctionnalités clés :

• Filtres par groupe (voir 6.5.5), par première lettre du nom/prénom, et selon les versions par type d’activité et par état (« en cours », etc.).
• Marquage manuel : cliquer sur une cellule bascule l’état (override, capacité moodle/course:overridecompletion, section 6.2.8).
• Export : boutons « Télécharger au format tableur (UTF-8 .csv) » et « … compatible Excel » en bas du rapport. Le CSV alimente sans friction un notebook, un Google Sheet de suivi ou votre propre dashboard.
• Les retards par rapport aux dates d’achèvement attendues y sont repérables.

6.6.2 Le rapport d’achèvement de cours

Cours → Rapports → Achèvement de cours (Course completion) : une ligne par étudiant, une colonne par critère d’achèvement de cours (groupées par famille), plus la colonne finale « Cours achevé ». C’est ici que les rôles habilités effectuent la validation manuelle (critère « validation par rôle », section 6.3.1) : une colonne par rôle valideur, avec des cases cliquables. Export CSV/Excel également disponible.

6.6.3 Les autres instruments

💡 Pour un dev React : tous ces rapports sont des projections en lecture du même état sous-jacent (course_modules_completion, course_completions, logs dans logstore_standard_log). Si les rapports natifs ne suffisent pas, deux voies : le constructeur de rapports (Report builder) intégré depuis Moodle 4.x pour des rapports personnalisés sans code, et les web services (core_completion_get_activities_completion_status, core_completion_get_course_completion_status) pour brancher un dashboard Next.js maison sur les données d’achèvement.

6.7 Méthodologie : concevoir, vérifier, éviter les pièges

6.7.1 Fil rouge — un module d’onboarding en quatre étapes

Mettons tout ensemble. Cahier des charges : un cours « Onboarding nouveaux collaborateurs » en quatre étapes strictement séquentielles, quiz final avec 80 % requis, attestation délivrée uniquement en cas de réussite, deux vagues d’arrivants (janvier/mars) avec tuteurs distincts.

Étape 0 — Fondations.

1. Paramètres du cours : « Activer le suivi d’achèvement des activités » = Oui ; « Afficher les conditions d’achèvement » = Oui.
2. Groupes « Vague janvier » / « Vague mars » (clés d’inscription de groupe distinctes sur l’auto-inscription), chacune avec son tuteur membre du groupe ; mode de groupe séparés par défaut (non forcé).
3. Valeurs par défaut d’achèvement du cours : Page/Fichier → consulter ; Quiz → note de passage ; Feedback → envoyer ses réponses.

Étape 1 — Les quatre sections.

• Section 1 « Bienvenue » : vidéo (Page, achèvement : consulter), charte à lire (Fichier, consulter), Feedback « Faisons connaissance » (achèvement : envoyer ses réponses).
• Section 2 « Votre environnement » : restriction de section — jeu OU par vague comme en recette (d) si les vagues démarrent à des dates différentes ; sinon simple restriction : « toutes les activités de la section 1 achevées » — en pratique, une seule condition sur la dernière activité de la section 1 si la section 1 est elle-même linéaire, ou trois conditions en ET sinon. Œil ouvert (l’effet escalier est voulu).
• Section 3 « Vos outils » : restriction sur l’achèvement de la section 2 (même technique).
• Section 4 « Validation » : contient le Quiz final — note maximale 100, note pour passer 80 (réglée dans les réglages de note du quiz), 3 tentatives, méthode de notation « note la plus haute » ; achèvement automatique : « note de passage requise ou toutes les tentatives épuisées ». Restriction de section : achèvement de la section 3.

Étape 2 — L’attestation conditionnée.

• Activité de type certificat (plugin Custom certificate, standard de fait — vérifiez la compatibilité 5.2) ou, à défaut, une Page « Attestation » : Restreindre l’accès → Achèvement : « Quiz final doit être achevée avec note de réussite ». Œil barré (ceux qui ont échoué n’ont pas à voir une attestation verrouillée).
• Section « Remédiation » (œil barré) : Restriction = « Quiz final achevée avec note d’échec » — donc visible uniquement de ceux qui ont épuisé leurs 3 tentatives sans atteindre 80 %. Contenu : ressources de révision + consigne de contacter son tuteur (qui, grâce aux groupes séparés, ne voit que sa vague dans les rapports).

Étape 3 — Achèvement de cours et badge.

• Achèvement de cours : condition unique « Activités terminées : Quiz final » (agrégation sans objet avec une seule condition). La transitivité des restrictions garantit que tout le reste a été fait avant.
• Badge de cours « Onboarding validé », critère : achèvement du cours (voir partie badges). Bloc « Statut d’achèvement du cours » ajouté sur la page.

Étape 4 — Recette (au sens test logiciel). Voir la checklist ci-dessous — et souvenez-vous du cron : le badge tombera quelques minutes après la réussite du quiz, pas à la seconde.

6.7.2 Checklist de vérification avant ouverture

1. Le suivi d’achèvement est activé au niveau du cours (la cause de 50 % des « ça ne marche pas »).
2. Chaque activité impliquée dans une restriction a un achèvement configuré et pertinent (pas de « consulter » là où il faut une réussite).
3. Les activités à note de passage ont bien la note pour passer définie (réglages de l’activité et cohérence carnet de notes).
4. Chaque condition a le bon œil (grisé motivant vs caché discret) — passez-les en revue une par une.
5. Aucune activité n’est masquée alors qu’elle devrait être « restreinte » (voir erreurs classiques ci-dessous).
6. Aucun étudiant sans groupe si le cours repose sur les groupes (Participants → Groupes → Vue d’ensemble, ligne « Pas de groupe »).
7. Le cron tourne (achèvement de cours, badges, notifications).
8. Test en conditions réelles : la fonction « *Prendre le rôle… » (switch role → Étudiant) donne un premier aperçu, mais elle a des limites sérieuses avec ce chapitre : vous conservez votre propre profil, vos groupes, et surtout aucun historique d’achèvement d’étudiant — vous verrez donc le parcours à l’état initial, mais vous ne pouvez pas « dérouler » la progression (vos actions en rôle étudiant ne créent pas toujours des données d’achèvement fiables, et certaines restrictions — profil, groupe — s’évaluent sur vos attributs, pas ceux d’un étudiant type). La seule vérification fiable : un ou deux vrais comptes de test étudiants, inscrits au cours, placés dans les groupes voulus, avec lesquels vous jouez le scénario de bout en bout — y compris le cas d’échec au quiz. Sur un gros enjeu, testez une « persona » par branche du parcours.

⚠️ Piège : ne testez jamais un parcours conditionnel avec votre compte enseignant sans bascule de rôle : la plupart des restrictions ne s’appliquent pas aux détenteurs de la capacité moodle/course:ignoreavailabilityrestrictions (et l’enseignant voit les éléments restreints avec la mention des conditions). Tout vous semblera ouvert — normal, mais trompeur.

6.7.3 Les erreurs classiques

6.7.4 Transition

Vous disposez désormais du moteur de scénarisation complet : des états (achèvement), des règles (restrictions) et des périmètres (groupes). Mais vous avez remarqué que la moitié de nos conditions les plus intéressantes — note de passage, plages de pourcentage, remédiation — reposent sur les notes. Il est temps d’ouvrir le capot du système d’évaluation : le prochain chapitre est consacré au carnet de notes (Gradebook) — barèmes, catégories, agrégations, notes pour passer, et la manière dont tout cela s’articule précisément avec l’achèvement et les restrictions que vous venez d’apprendre à manier.

📚 Aller plus loin : pour consolider ce chapitre, trois lectures : docs.moodle.org/fr/Restriction_d’accès , docs.moodle.org/fr/Achèvement_d’activité  et docs.moodle.org/fr/Groupes  ; côté architecture, les pages Availability API et Completion API de moodledev.io  vous donneront la vue développeur des mécanismes décrits ici — un excellent réinvestissement de votre culture TypeScript, tant ces API sont proches d’un moteur de règles JSON que vous pourriez écrire vous-même.