Chapitre 3 — Les activités natives, une par une

Dans les chapitres précédents, nous avons construit la coquille : un cours, ses sections, ses ressources statiques. Il est temps de passer à ce qui fait réellement la valeur d’un LMS (Learning Management System, système de gestion de l’apprentissage) : les activités (activities). Contrairement aux ressources, qui sont des contenus que l’étudiant consomme passivement (fichier, page, URL), une activité est un module interactif : l’étudiant y produit quelque chose, y répond, y collabore, et Moodle en garde une trace exploitable — note, achèvement, journal d’événements.

💡 Pour un dev React : si les ressources sont des composants purement présentationnels (stateless), les activités sont des composants avec état persistant côté serveur : chaque activité est une instance d’un plugin de type mod (module d’activité), avec ses propres tables SQL, son API de notation, ses événements, et souvent son propre sous-système de permissions. Ajouter une activité à un cours revient à instancier un plugin mod_assign, mod_forum, etc., avec une configuration propre à cette instance. C’est le pattern « plugin instancié » que vous retrouverez partout dans Moodle.

Moodle 5.2 livre en standard une quinzaine de modules d’activité. Certains sont des piliers utilisés dans quasiment tous les cours (Devoir, Forum, Test), d’autres sont des outils spécialisés (Atelier, Base de données), d’autres encore sont des vestiges maintenus pour compatibilité (Chat, Survey). Ce chapitre les passe tous en revue, avec un accent très fort sur le Devoir, l’activité la plus utilisée et celle dont le paramétrage est le plus riche — d’autant que Moodle 5.2 y introduit une nouveauté majeure : la notation par évaluateurs multiples (multiple markers).

Panorama des activités natives

Le tableau suivant donne la vue d’ensemble. La colonne « Notée ? » indique si l’activité peut pousser une note vers le carnet de notes (gradebook) ; la colonne « Collaboration ? » indique si l’activité fait interagir les étudiants entre eux.

Deux remarques d’architecture avant de plonger dans le détail :

1. Tous ces modules partagent des réglages communs : restriction d’accès (restrict access), achèvement d’activité (activity completion), réglages de groupe, visibilité, tags, compétences. Ces réglages transverses sont traités au chapitre 6 de cette partie ; ici, nous nous concentrons sur ce qui est spécifique à chaque activité.
2. Chaque activité est un plugin comme un autre. Un administrateur peut en désactiver, en ajouter (il existe des centaines de modules tiers sur moodle.org/plugins), ou en masquer dans le sélecteur d’activités (activity chooser), refondu en Moodle 4.0 avec recherche, favoris et activités recommandées.

📚 Aller plus loin : la page docs.moodle.org/fr/Activités  recense toutes les activités avec leurs documentations respectives. Côté développeur, moodledev.io/docs/apis/plugintypes/mod  décrit l’anatomie d’un plugin d’activité.

3.1 Le Devoir (Assignment) — l’activité reine de l’évaluation

Le module Devoir (mod_assign) est l’activité d’évaluation la plus utilisée de Moodle. Son principe est simple — l’étudiant remet un travail, l’enseignant le note et donne un feedback — mais son paramétrage couvre une variété impressionnante de scénarios : dissertation en ligne, remise de PDF, projet de groupe, soutenance notée sans remise, correction anonyme, double correction, tentatives multiples jusqu’à réussite… Prenez le temps de maîtriser cette activité : c’est elle qui structure la relation d’évaluation entre enseignant et étudiants.

Pour créer un Devoir : mode édition activé, Ajouter une activité ou ressource → Devoir. Le formulaire de réglages qui s’ouvre est long ; nous le parcourons section par section.

3.1.1 Énoncé, instructions et fichiers supplémentaires

Le premier bloc contient le nom du devoir et deux zones de texte qu’il ne faut pas confondre :

• La Description : visible sur la page du devoir et, si vous cochez « Afficher la description sur la page de cours », directement dans la section du cours. C’est le lieu de la présentation générale : sujet, objectifs, critères.
• Les Instructions d’activité (activity instructions), introduites en Moodle 4.0 : ce texte n’est affiché à l’étudiant qu’au moment où il commence sa remise, sur la page de saisie. C’est l’endroit idéal pour les consignes opérationnelles (« nommez votre fichier NOM_Prenom.pdf », « une seule archive ZIP », « n’oubliez pas la page de garde »). La distinction évite de noyer la page de cours sous les détails pratiques.

Vous pouvez aussi joindre des fichiers supplémentaires (additional files) : sujet au format PDF, modèle de document à compléter, jeu de données. Ces fichiers apparaissent sous la description. Un réglage permet de choisir s’ils sont visibles en permanence ou seulement à partir de la date « Autoriser la remise dès ».

⚠️ Piège : beaucoup d’enseignants mettent le sujet complet dans la Description, qui est alors visible dès que le devoir est visible — y compris avant la date d’ouverture des remises si le devoir n’est pas masqué. Si le sujet doit rester secret jusqu’à une date précise, joignez-le en fichier supplémentaire avec l’option « Afficher seulement à partir de la date de remise », ou utilisez une restriction d’accès par date sur l’activité entière.

3.1.2 Types de remise

La section Types de remise (submission types) définit ce que l’étudiant peut déposer. Les deux types natifs principaux sont cumulables :

Quelques précisions importantes :

• Nombre maximum de fichiers : de 1 à 20. Si vous attendez un seul PDF, mettez 1 : cela évite les remises éclatées en douze fichiers.
• Taille maximale de remise : bornée par la limite du cours, elle-même bornée par la limite du site (paramètres PHP upload_max_filesize et post_max_size — l’administrateur ne peut pas dépasser la configuration du serveur, nous y reviendrons en Partie 2 sur l’administration).
• Types de fichiers acceptés : un sélecteur permet de restreindre par extension ou par groupe de types (« Documents », « Fichiers image », « Fichiers PDF »…). Fortement recommandé : exiger du PDF garantit que l’annotation dans le navigateur fonctionnera (voir 3.1.7), et vous évite de recevoir des .pages, .odt et autres formats que vous ne pourrez pas ouvrir.
• Ne cocher aucun type de remise est un cas d’usage parfaitement légitime : le devoir devient un simple réceptacle de note pour une prestation évaluée hors ligne (exposé oral, examen sur table, soutenance). Vous bénéficiez alors de toute l’interface de notation et de feedback de Moodle sans mécanique de dépôt.

Des plugins de type remise (submission plugins, assignsubmission_*) peuvent ajouter d’autres canaux : c’est une architecture extensible, exactement comme les types de feedback.

3.1.3 Remises de groupe

La section Réglages de remises en groupe transforme le devoir en projet collectif :

• Les étudiants remettent en groupe : une seule remise par groupe ; tout membre du groupe voit la remise et peut la modifier (sauf réglage contraire).
• Exiger que tous les membres du groupe valident : chaque membre doit cliquer sur « Envoyer le devoir » avant que la remise soit considérée comme définitive — utile pour matérialiser l’engagement de chacun.
• Groupement pour les remises (grouping) : indispensable dès que le cours contient plusieurs jeux de groupes (groupes de TD et groupes de projet, par exemple). Le groupement désigne quel jeu de groupes fait autorité pour ce devoir.

Côté notation, l’enseignant peut attribuer une note et un feedback au groupe entier en une opération (case « Appliquer les notes et feedback au groupe entier »), ou individualiser si un membre mérite un traitement différent.

⚠️ Piège : le piège le plus classique des remises de groupe est l’étudiant hors groupe. Un réglage (« Nécessite l’appartenance à un groupe pour remettre un devoir ») empêche les étudiants sans groupe de remettre ; sans lui, tous les étudiants sans groupe sont considérés comme membres d’un unique « groupe par défaut » fantôme, et leurs remises s’écrasent mutuellement. Vérifiez toujours que 100 % des étudiants sont dans un groupe du bon groupement avant l’ouverture des remises.

💡 Pour un dev React : pensez la remise de groupe comme une ressource partagée avec verrouillage optimiste : la « remise » est une entité unique référencée par tous les membres, et la validation individuelle (« tous les membres doivent valider ») est un pattern de quorum — la transition d’état draft → submitted n’a lieu que lorsque tous les signataires ont approuvé.

3.1.4 Les quatre dates du Devoir

La section Disponibilité définit la fenêtre temporelle. Quatre dates, aux sémantiques bien distinctes :

La combinaison due date + cut-off couvre les politiques usuelles :

• Tolérance zéro : date butoir = date limite. Personne ne remet en retard.
• Retard toléré mais tracé : date butoir à J+3 par exemple. Les remises entre J et J+3 sont acceptées mais estampillées « en retard », et l’enseignant peut appliquer la pénalité de son choix.
• Pas de butoir : les retards sont acceptés indéfiniment (déconseillé : vous corrigerez au fil de l’eau pour toujours).

Depuis Moodle 4.5, un mécanisme de pénalités de retard (grade penalties) automatiques existe au niveau du site : l’administrateur peut activer une politique de pénalité (par exemple −10 % par jour de retard) appliquée automatiquement aux devoirs remis après la date limite. C’est une fonctionnalité encore en maturation ; vérifiez son état exact sur votre instance avant de vous y fier.

Les dérogations (voir 3.1.9) permettent d’accorder des dates différentes à un étudiant ou un groupe donné, sans toucher aux dates générales.

3.1.5 Notation : note, barème, catégorie, note pour passer

La section Note est commune à toutes les activités notées, mais c’est dans le Devoir qu’on la rencontre en premier :

• Type de note : Point (note numérique sur un maximum, 100 par défaut, personnalisable), Barème (scale : échelle qualitative, comme « Insuffisant / Passable / Bien / Excellent » — les barèmes se définissent au niveau du site ou du cours), ou Aucune (pas de note, feedback seul).
• Catégorie de note : dans quelle catégorie du carnet de notes la note atterrit (par exemple « Contrôle continu », pondérée à 40 %). L’organisation du carnet de notes est traitée en détail dans la partie consacrée à l’évaluation ; retenez simplement que ce choix se fait dès la création de l’activité.
• Note pour passer (grade to pass) : seuil de réussite. Ce seuil colore la note en vert/rouge dans le carnet, et surtout alimente l’achèvement d’activité conditionné à la réussite et les tentatives multiples « jusqu’à réussite » (voir 3.1.10).
• Notation anonyme / à l’aveugle et workflow : traités ci-dessous, tant ils méritent leur propre section.

3.1.6 Workflow de notation, attribution d’évaluateurs et — nouveauté 5.2 — évaluateurs multiples

Par défaut, dès que l’enseignant sauvegarde une note, l’étudiant la voit. Sur un devoir corrigé au fil de l’eau par plusieurs personnes, c’est intenable : les premiers corrigés connaissent leur note des semaines avant les derniers, et rien n’empêche une note d’être publiée avant harmonisation. Le workflow de notation (marking workflow) résout ce problème.

Une fois activé (« Utiliser les phases d’évaluation » : Oui), chaque copie porte un état de notation que l’évaluateur fait progresser :

1. Non noté / Brouillon (Not marked) — état initial ;
2. En cours de notation (In marking) — l’évaluateur travaille dessus ;
3. Notation terminée (Marking completed) — la note est posée, en attente de contrôle ;
4. En révision (In review) — un responsable vérifie/harmonise ;
5. Prêt à publier (Ready for release) — validé, en attente de publication ;
6. Publié (Released) — l’étudiant voit note et feedback.

Tant que l’état n’est pas « Publié », l’étudiant ne voit rien : ni note, ni feedback. La publication peut se faire copie par copie, ou en masse depuis le tableau de notation (sélectionner toutes les copies → action groupée « Régler l’état de notation » → Publié). C’est le mode opératoire recommandé : tout le monde reçoit sa note au même instant.

💡 Pour un dev React : le marking workflow est une machine à états finis (finite state machine) tout ce qu’il y a de plus classique — pensez XState. Chaque copie porte un état, les transitions sont contraintes (on ne « publie » pas depuis « brouillon » sans passer par les états intermédiaires, du moins dans l’usage prescrit), et l’état conditionne ce que chaque rôle peut voir : la note n’est « rendue » côté étudiant que dans l’état final. Si vous deviez modéliser ce système, vous écririez littéralement states: { notmarked, inmarking, markingcompleted, inreview, readyforrelease, released }.

L’attribution d’évaluateurs (marking allocation), activable uniquement si le workflow l’est, permet de désigner nominativement quel enseignant corrige quelle copie. Le tableau de notation gagne une colonne « Évaluateur attribué », filtrable ; l’attribution peut se faire copie par copie ou en masse. C’est l’outil des grandes cohortes corrigées par une équipe de correcteurs.

Nouveauté Moodle 5.2 : les évaluateurs multiples (multiple markers)

Jusqu’à Moodle 5.1, une copie ne pouvait porter qu’une seule note à la fois : si deux correcteurs devaient évaluer la même copie (double correction, harmonisation, examens à enjeu), il fallait bricoler — tableurs parallèles, plugins tiers, ou écrasement successif de la note. Moodle 5.2 introduit nativement la notation par évaluateurs multiples : plusieurs évaluateurs peuvent être affectés à une même copie et chacun saisit sa propre note et son propre feedback, indépendamment et sans voir écraser le travail des autres.

Le fonctionnement, dans les grandes lignes :

• Le réglage s’active dans les options de notation du devoir (en complément du workflow de notation, dont il est le prolongement naturel).
• Chaque évaluateur affecté à une copie dispose de son propre « emplacement » de notation : notes et feedbacks coexistent au lieu de s’écraser.
• Une étape d’agrégation/réconciliation produit la note finale à partir des notes individuelles — soit par une règle d’agrégation automatique (moyenne, par exemple), soit par arbitrage d’un évaluateur senior qui consulte les évaluations individuelles et arrête la note définitive avant publication.
• Le workflow de notation encadre le tout : la copie ne passe « Prêt à publier » qu’une fois la réconciliation faite, et l’étudiant ne voit que le résultat final publié.

Les cas d’usage sont ceux que réclamaient les universités depuis des années : double correction réglementaire des examens, modération inter-correcteurs, co-évaluation d’un mémoire par plusieurs membres d’un jury.

⚠️ Piège : « évaluateurs multiples » (5.2) et « attribution d’évaluateurs » (historique) sont deux choses différentes. L’attribution d’évaluateurs répartit les copies (une copie → un correcteur) ; les évaluateurs multiples font coexister plusieurs notes sur la même copie (une copie → plusieurs correcteurs, puis agrégation). Sur les détails fins de la fonctionnalité 5.2 (règles d’agrégation disponibles, granularité des permissions), vérifiez la documentation officielle de votre version : la fonctionnalité est récente et susceptible d’évoluer dans les versions suivantes.

📚 Aller plus loin : les notes de version de Moodle 5.2 sur docs.moodle.org détaillent la notation multi-évaluateurs ; le tracker Moodle (tracker.moodle.org) retrace l’historique du développement de cette fonctionnalité longtemps demandée.

3.1.7 Notation avancée : guide d’évaluation et grille d’évaluation (rubrique)

Par défaut, la « méthode de notation » est la notation simple directe : l’évaluateur tape une note. Deux méthodes de notation avancée (advanced grading) structurent l’évaluation critère par critère. Elles se choisissent dans la section « Note » du devoir (« Méthode d’évaluation »), puis se définissent via le menu du devoir → Notation avancée.

Le guide d’évaluation (marking guide) :

• Vous définissez une liste de critères, chacun avec une description pour l’étudiant, une description pour les évaluateurs, et une note maximale.
• L’évaluateur attribue à chaque critère un nombre de points libre entre 0 et le maximum, accompagné d’un commentaire.
• La note finale est la somme des points des critères, remise à l’échelle de la note maximale du devoir.
• Bonus appréciable : les commentaires fréquemment utilisés (frequently used comments), une banque de remarques réutilisables en un clic — un gain de temps énorme sur 200 copies qui font toutes la même erreur.

La grille d’évaluation / rubrique (rubric) :

• Chaque critère est décliné en niveaux (levels) : chaque niveau porte une description explicite et un nombre de points fixé. Exemple pour un critère « Qualité de l’argumentation » : 0 pt « Aucun argument », 2 pts « Arguments présents mais non étayés », 4 pts « Arguments étayés par des sources », 6 pts « Argumentation rigoureuse et sourcée ».
• L’évaluateur clique sur un niveau par critère ; pas de saisie libre de points (mais un commentaire par critère est possible si l’option est activée).
• Le calcul de la note normalise le score obtenu : Moodle calcule (somme des points obtenus − somme des minima) / (somme des maxima − somme des minima), puis applique ce ratio à la note maximale du devoir. Conséquence contre-intuitive : le niveau le plus bas de chaque critère vaut 0 % de ce critère, même s’il porte des points non nuls.

⚠️ Piège : à cause de cette normalisation, une rubrique dont les niveaux vont de 1 à 4 ne donne pas 25 % à l’étudiant qui n’a que des niveaux 1 : elle lui donne 0 %. Si vous voulez qu’un « plancher » de points soit garanti, créez explicitement un niveau 0 en dessous, ou raisonnez en pourcentages dès la conception. Testez toujours votre rubrique sur une copie fictive avant la vraie session de correction — modifier une rubrique après avoir commencé à noter force Moodle à invalider ou re-calculer les évaluations existantes, avec un avertissement anxiogène à la clé.

Les deux méthodes supportent le partage de modèles (templates) : une rubrique aboutie peut être publiée comme modèle réutilisable dans d’autres devoirs (et par d’autres enseignants, selon permissions), ce qui est précieux pour harmoniser l’évaluation à l’échelle d’un diplôme. Côté étudiant, la rubrique est visible avant la remise (sur la page du devoir), ce qui en fait aussi un outil de transparence des attentes.

💡 Pour un dev React : une rubrique est un schéma de validation transformé en fonction de scoring : un tableau criteria[], chacun avec levels[] de {score, definition}, et une fonction pure (selections) => normalizedGrade. Le partage de modèles est l’équivalent d’un design system pour l’évaluation : on factorise la définition, on instancie partout. L’architecture sous-jacente (gradingform_rubric, gradingform_guide) est d’ailleurs un type de plugin à part entière — on peut développer sa propre méthode de notation avancée.

3.1.8 L’interface de notation : annotation PDF, feedback, notation à l’aveugle

Cliquer sur « Note » depuis la page du devoir ouvre l’interface de notation moderne : un écran unique avec la copie à gauche et le panneau de notation à droite, plus une navigation rapide d’étudiant en étudiant (avec filtres : « exiger une note », remises en retard, état de workflow, évaluateur attribué…).

Le composant vedette est l’annotation PDF dans le navigateur : toute remise convertible en PDF est affichée dans une visionneuse où l’évaluateur peut surligner, entourer, barrer, dessiner, apposer des tampons et des notes-commentaires directement sur les pages. L’étudiant récupère le PDF annoté avec son feedback. La conversion des documents (DOCX → PDF, etc.) dépend d’un convertisseur configuré côté serveur (Unoconv, Google Drive, ou un service dédié) — d’où l’intérêt d’exiger des remises en PDF natif pour ne dépendre de rien.

Les types de feedback (feedback plugins) cumulables :

La remise en mode aveugle (blind marking, notation anonyme) masque l’identité des étudiants aux évaluateurs : les copies apparaissent comme « Participant 1834… ». La levée de l’anonymat (« Révéler les identités ») est une action explicite, à faire après la notation et avant la publication des notes ; elle est irréversible pour l’activité. Notez que l’anonymat de Moodle est un anonymat d’interface : l’identité reste en base, et un gestionnaire disposant des permissions ad hoc peut la voir — ne le présentez pas comme une garantie cryptographique.

⚠️ Piège : le blind marking doit être activé avant toute remise ou notation ; une fois qu’une remise existe, le réglage est verrouillé. Et si vous révélez les identités trop tôt, impossible de re-anonymiser. Intégrez ces deux irréversibilités à votre check-list de création de devoir d’examen.

3.1.9 Dérogations et tentatives multiples

Les dérogations (overrides) — menu du devoir → Dérogations — permettent d’accorder à un utilisateur ou à un groupe des dates différentes (ouverture, limite, butoir) sans modifier le devoir pour tout le monde. C’est l’outil standard pour les aménagements (tiers temps, absence justifiée, groupe international sur un autre fuseau). Une dérogation utilisateur prime sur une dérogation de groupe. On retrouve exactement le même mécanisme dans le Test (avec, en plus, le temps supplémentaire).

Les tentatives multiples (section « Réglages de la remise des travaux ») permettent de rouvrir une remise notée :

• Réouverture des travaux remis : Jamais (défaut), Manuellement (l’enseignant clique « Autoriser une nouvelle tentative » sur une copie), ou Automatiquement jusqu’à réussite — la remise est rouverte tant que la note est sous la note pour passer (d’où l’importance de définir ce seuil, cf. 3.1.5).
• Nombre maximum de tentatives : borne le mécanisme (illimité possible).
• Chaque tentative conserve son historique : l’évaluateur voit les tentatives précédentes, leurs notes et leurs feedbacks. Le devoir devient alors un outil de maîtrise progressive (mastery learning) : remise → feedback → nouvelle version → validation.

Mentionnons enfin les réglages de validation de remise : « Exiger que les étudiants cliquent sur le bouton Envoyer » transforme le dépôt en deux temps (brouillon modifiable, puis envoi définitif), et « Demander aux étudiants d’accepter l’énoncé de remise » ajoute une case à cocher type déclaration anti-plagiat (« ce travail est le mien… »), dont le texte est configurable par l’administrateur.

3.1.10 Notifications

Trois réglages de notification, souvent mal compris :

• Informer les évaluateurs des travaux remis : chaque remise déclenche un message aux enseignants. À réserver aux petits effectifs, sous peine de spam.
• Informer les évaluateurs des travaux en retard : idem, seulement pour les remises hors délai — plus raisonnable.
• Réglage par défaut pour « Notifier les étudiants » : pré-coche (ou non) la case « Notifier l’étudiant » présente dans l’interface de notation. Avec le marking workflow, la notification part à la publication de la note, pas à sa saisie.

3.1.11 Détection de plagiat : une architecture de plugins

Moodle ne contient aucun détecteur de plagiat natif, mais expose une API de plagiat (Plagiarism API, plugins de type plagiarism_*) à laquelle se branchent des services tiers : Turnitin, Compilatio (très répandu en France), Ouriginal/Urkund, PlagScan, ou des solutions libres comme Moss pour le code. Le fonctionnement type :

1. L’administrateur installe le plugin, le connecte au service (clés d’API, abonnement payant chez l’éditeur) et l’active globalement (Administration du site → Plugins → Plagiat).
2. Une section « Plugin de détection de plagiat » apparaît alors dans les réglages de chaque devoir (et souvent du forum, de l’atelier, du test), où l’enseignant l’active pour cette activité et règle les options (montrer le score de similarité aux étudiants ou non, exclure la bibliographie et les citations, alimenter ou non la base documentaire de l’éditeur…).
3. À chaque remise, le document part vers le service, qui renvoie un score de similarité et un rapport détaillé, affichés dans l’interface de notation à côté de la copie.

⚠️ Piège : un score de similarité n’est pas un verdict de plagiat. Une similarité de 40 % peut être une bibliographie et des citations correctement attribuées ; 8 % peuvent cacher un paragraphe volé. Le rapport se lit, il ne se subit pas. Pédagogiquement, prévoyez aussi la question RGPD : envoyer les travaux des étudiants à un service tiers (parfois hors UE) requiert une base légale et une information des étudiants — c’est un sujet d’établissement, pas seulement un réglage Moodle.

3.2 Le Forum — l’épine dorsale de la communication asynchrone

Le Forum (mod_forum) est l’activité de discussion asynchrone. Chaque cours en contient au moins un d’office : le forum des annonces. Mais le forum est bien plus qu’un canal d’annonces : débat noté, questions/réponses, journal de bord, entraide entre étudiants — tout dépend du type choisi.

3.2.1 Les cinq types de forum

Le type questions/réponses est le plus subtil pédagogiquement : il neutralise l’effet « je lis les réponses des autres avant d’écrire la mienne ».

💡 Pour un dev React : un forum Moodle, c’est structurellement un Discourse minimaliste : des discussions (threads) contenant des posts en arbre (réponses imbriquées), avec abonnement/notifications, épinglage, verrouillage et favoris. Depuis la refonte de Moodle 3.8, l’affichage des fils utilise des templates Mustache rendus côté serveur avec réponse « en ligne » sans rechargement — pas un SPA, mais une hybridation privilégiant le progressive enhancement, philosophie récurrente du frontend Moodle.

3.2.2 Abonnement et suivi des messages lus

L’abonnement (subscription) détermine qui reçoit les messages par notification (courriel et/ou notification web/mobile, selon les préférences de chacun) :

• Abonnement optionnel : chacun s’abonne ou non (défaut) ;
• Abonnement imposé (forced) : tout le monde est abonné, sans pouvoir se désabonner — c’est le mode du forum des annonces ;
• Abonnement automatique : tout le monde est abonné au départ, mais peut se désabonner ;
• Abonnement désactivé : personne ne peut s’abonner.

L’abonnement peut aussi se faire par discussion individuelle, pas seulement au forum entier. Le suivi des messages lus (read tracking), s’il est activé (« Facultatif » ou « Imposé »), surligne le nombre de messages non lus par forum et par discussion — indispensable sur un forum actif.

Deux réglages temporels utiles : le délai d’édition (par défaut 30 minutes après publication, configurable au niveau du site) pendant lequel l’auteur peut modifier son message avant l’envoi des notifications, et la publication différée (display period) qui programme l’affichage d’une discussion entre deux dates — pratique pour préparer les annonces de la semaine à l’avance.

3.2.3 Noter un forum : ratings et whole forum grading

Deux mécanismes de notation coexistent, et il faut les distinguer :

1. Les évaluations de messages (ratings) : l’enseignant (ou les étudiants, selon permissions) attribue une note à chaque message. Une règle d’agrégation (moyenne, maximum, minimum, somme, nombre de messages) produit la note d’activité envoyée au carnet. C’est le mécanisme historique, partagé avec le Glossaire et la Base de données.
2. La notation du forum entier (whole forum grading), introduite en Moodle 3.8 : l’enseignant évalue la contribution globale de chaque étudiant via une interface dédiée qui présente, étudiant par étudiant, tous ses messages regroupés — avec possibilité d’utiliser une rubrique ou un guide d’évaluation (la notation avancée du 3.1.7 s’applique ici aussi). C’est de loin la méthode la plus pratique pour noter « la participation au forum sur le semestre ».

Les deux peuvent techniquement coexister (produisant deux éléments d’évaluation distincts), mais dans la pratique choisissez-en un seul pour éviter la confusion.

3.2.4 Modération : verrouiller, épingler, seuils d’alerte

• Épingler (pin) une discussion la maintient en tête de liste — pour la FAQ ou le règlement du forum.
• Verrouiller (lock) une discussion la ferme aux nouvelles réponses ; un réglage du forum peut verrouiller automatiquement les discussions inactives depuis une durée donnée.
• Les seuils de messages pour bloquer (post threshold for blocking) limitent le flood : au-delà de N messages dans une fenêtre donnée (par exemple 10 messages par jour), l’étudiant est bloqué ; un seuil d’avertissement le prévient avant.
• Pièces jointes et taille maximale : nombre de fichiers joints par message et taille maximale, ainsi que l’option « affichage du nombre de mots ».

3.2.5 Le forum des annonces, un forum pas comme les autres

Le forum Annonces (anciennement « Forum des nouvelles »), créé automatiquement dans chaque cours, a des règles câblées : seuls les enseignants peuvent y poster, l’abonnement y est imposé, les réponses y sont impossibles par défaut, et ses messages alimentent le bloc « Dernières annonces ». Ne le supprimez pas pour le recréer à la main : vous perdriez ces comportements. Le nombre d’annonces affichées se règle dans les paramètres du cours (« Nombre d’annonces »).

Concernant les résumés générés par IA : Moodle intègre depuis la version 4.5 un sous-système d’IA (AI subsystem) avec des « placements » comme la génération et le résumé de texte dans l’éditeur et sur les pages de cours. À la date de rédaction, il n’existe pas de fonctionnalité native documentée de « résumé automatique de fils de forum » ; si votre établissement en dispose, elle provient vraisemblablement d’un plugin ou d’une configuration spécifique du sous-système IA. Prudence donc : vérifiez sur votre instance plutôt que de le promettre à vos utilisateurs.

⚠️ Piège : les notifications de forum partent après le délai d’édition (30 min par défaut) via une tâche planifiée (cron). Si les étudiants « ne reçoivent rien », le premier réflexe est de vérifier le cron et la configuration du courriel sortant côté administration — pas les réglages du forum.

3.3 Le Test (Quiz) — survol

Le Test (mod_quiz) est la seconde activité d’évaluation majeure : un questionnaire auto-corrigé puisant dans une banque de questions (question bank) riche d’une vingtaine de types natifs (choix multiple, appariement, numérique, glisser-déposer, réponse courte, composition corrigée manuellement…), avec gestion fine du temps, des tentatives, des feedbacks différés ou immédiats, du mélange aléatoire des questions et des dérogations. La banque de questions a été profondément refondue en Moodle 4.0+ (versionnage des questions, statuts brouillon/prêt) puis réorganisée en Moodle 5.0 autour de banques partageables entre cours.

Le Test est si riche — types de questions, comportements de question (question behaviours), statistiques psychométriques, sécurité d’examen — qu’il mérite un chapitre entier : c’est l’objet du chapitre 4 de cette partie, auquel nous vous renvoyons. Retenez à ce stade la ligne de partage avec le Devoir : le Test excelle dans l’évaluation automatisée et scalable (la machine corrige), le Devoir dans l’évaluation de productions complexes (l’humain corrige).

3.4 La Leçon (Lesson) — le contenu à embranchements

La Leçon (mod_lesson) est l’activité la plus ancienne de « contenu adaptatif » de Moodle : une séquence de pages où la navigation dépend des réponses de l’étudiant. Elle mélange deux types de pages :

• Pages de contenu (content pages) : du contenu + des boutons de navigation dont chacun pointe vers la page de votre choix. C’est le mécanisme d’embranchement : « Pour explorer la piste A, cliquez ici ; pour la piste B, là ».
• Pages de question : QCM, vrai/faux, réponse courte, numérique, appariement, composition. Chaque réponse définit sa propre destination (« saut », jump) : bonne réponse → page suivante ; mauvaise réponse → page de remédiation, retour en arrière, ou branche spécifique. Chaque réponse peut aussi porter un score, positif ou négatif.

S’y ajoutent les clusters (grappes) : des groupes de pages de question dont la Leçon tire des pages au hasard, pour varier les parcours d’un étudiant à l’autre, et les fins de branche (end of branch) qui ramènent au menu. La Leçon peut être notée (score cumulé des questions, avec ou non possibilité de refaire), chronométrée, et autoriser plusieurs tentatives.

Cas d’usage typiques : étude de cas à décisions (« vous êtes infirmier, le patient présente X, que faites-vous ? » — chaque choix mène à une suite différente), remédiation adaptative (l’étudiant qui échoue est redirigé vers une page d’explication puis re-testé), simulation d’entretien, escape game pédagogique.

Soyons honnêtes sur les défauts : l’interface d’édition de la Leçon est notoirement complexe et datée — la logique de sauts se règle page par page, réponse par réponse, sans vue graphique du graphe de navigation, et le débogage d’un parcours se fait en le rejouant à la main. C’est l’activité native qui décourage le plus les nouveaux enseignants.

💡 Pour un dev React : une Leçon est un graphe orienté dont les nœuds sont des pages et les arêtes des sauts conditionnels — exactement ce que vous modéliseriez avec une state machine ou un moteur de dialogue de jeu vidéo. Le problème est que Moodle vous fait éditer la liste d’adjacence à la main, sans visualisation du graphe. D’où la popularité de l’alternative moderne : le type de contenu H5P Branching Scenario, qui offre un éditeur visuel du graphe d’embranchements, avec vidéos et interactions intégrées. Nous le traitons au chapitre 5 de cette partie ; pour un nouveau scénario à embranchements, évaluez d’abord H5P avant de vous engager dans une Leçon.

⚠️ Piège : dans une Leçon, l’ordre logique (les sauts) et l’ordre physique (l’ordre des pages dans l’éditeur) sont indépendants. Le saut « page suivante » suit l’ordre physique : réordonner les pages après coup peut donc casser silencieusement votre scénario. Cartographiez votre graphe sur papier (ou dans un outil de diagramme) avant de le saisir.

3.5 L’Atelier (Workshop) — l’évaluation par les pairs

L’Atelier (mod_workshop) orchestre un scénario pédagogique exigeant mais puissant : chaque étudiant remet un travail puis évalue les travaux de ses pairs selon des critères définis par l’enseignant. La recherche en pédagogie est constante sur ce point : évaluer le travail des autres est l’un des exercices les plus formateurs qui soient — à condition d’être bien encadré. C’est précisément ce que fait l’Atelier, au prix d’une orchestration en cinq phases strictement séquentielles.

3.5.1 Les cinq phases

Le passage d’une phase à l’autre est manuel par défaut (l’enseignant clique dans la planche de phases, très visuelle) ; des dates peuvent automatiser la bascule remise → évaluation. Une copie non remise en phase 2 ne peut plus l’être ensuite : la séquentialité est stricte, c’est le prix du modèle.

3.5.2 Les stratégies d’évaluation

Le formulaire d’évaluation que remplissent les étudiants-évaluateurs dépend de la stratégie de notation (grading strategy) choisie :

• Grille cumulative (accumulative grading) : plusieurs critères (aspects), chacun noté sur une échelle ou en points, avec commentaire ; la note est la moyenne pondérée.
• Commentaires (comments) : les évaluateurs commentent critère par critère mais ne notent pas — la note de remise est alors donnée autrement, mais l’exercice d’évaluation reste formateur.
• Nombre d’erreurs (number of errors) : liste d’assertions binaires (« le rapport contient une bibliographie : oui/non ») ; la note découle du nombre de « non » via une table de correspondance.
• Rubrique (rubric) : critères à niveaux descriptifs, comme la rubrique du Devoir, en un peu plus simple.

3.5.3 Attribution des copies et exemples de travaux

L’attribution (allocation) des copies aux évaluateurs se fait de trois manières : manuelle (l’enseignant décide qui évalue qui), aléatoire (Moodle distribue N copies par évaluateur, avec options : auto-évaluation autorisée ou non, les non-remettants peuvent-ils évaluer…), ou programmée (scheduled) — l’attribution aléatoire s’exécute automatiquement à la fin de la phase de remise, ce qui est indispensable quand la bascule de phase est automatisée.

Les exemples de travaux (example submissions) sont une option précieuse : l’enseignant fournit une copie exemple avec son évaluation de référence ; les étudiants doivent (ou peuvent) évaluer cet exemple avant d’évaluer leurs pairs, et comparer leur évaluation à celle de référence. C’est le mécanisme de calibration des évaluateurs.

3.5.4 Les deux notes

L’Atelier produit deux notes distinctes dans le carnet :

1. La note de la remise (sur 80 par défaut) : agrégation des évaluations reçues par la copie de l’étudiant.
2. La note de l’évaluation (sur 20 par défaut) : mesure la qualité du travail d’évaluateur de l’étudiant. Moodle la calcule en comparant chaque évaluation aux autres évaluations de la même copie : les évaluateurs « dans le consensus » ont une bonne note d’évaluation, les évaluateurs aberrants une mauvaise. Un paramètre de « comparaison des évaluations » (de « très laxiste » à « très stricte ») règle la sévérité de ce calcul, que l’enseignant peut relancer et ajuster en phase 4.

⚠️ Piège : l’Atelier est impitoyable avec les retardataires et les absents — un étudiant qui rate la phase de remise ne peut ni remettre ni, souvent, être évalué, et un évaluateur défaillant prive ses pairs de feedback. Prévoyez des marges, activez l’attribution programmée, et surveillez la phase d’évaluation pour réattribuer manuellement les copies orphelines. Ne lancez jamais un Atelier sur une cohorte sans avoir fait un essai à blanc : c’est l’activité native la plus complexe à piloter.

💡 Pour un dev React : la note d’évaluation calculée par comparaison au consensus est un algorithme de détection d’outliers appliqué à la notation — pensez « score de confiance inter-annotateurs » dans un pipeline de labellisation de données (inter-rater reliability). Et le cycle en cinq phases est un workflow séquentiel type pipeline CI : chaque étape a ses préconditions, et on ne rejoue pas une étape passée.

3.6 Le Glossaire — le dictionnaire collaboratif

Le Glossaire (mod_glossary) est une collection d’entrées (concept + définition + pièces jointes éventuelles), consultable par ordre alphabétique, par catégorie, par date ou par auteur. Sa force n’est pas l’outil « dictionnaire » en soi, mais deux mécanismes qui l’irriguent dans tout le cours : la contribution étudiante et l’auto-liaison.

Réglages et fonctionnalités clés :

• Qui contribue ? Par défaut, les étudiants peuvent créer des entrées — c’est tout l’intérêt pédagogique (constituer collectivement le lexique du cours, chaque étudiant définissant N termes).
• Approbation : si « Approuver par défaut » est sur Non, chaque entrée soumise reste invisible jusqu’à validation par l’enseignant — le contrôle qualité indispensable en contribution ouverte.
• Doublons, commentaires, catégories : autoriser ou non deux entrées pour le même concept ; ouvrir les commentaires sur les entrées ; organiser les entrées en catégories navigables. Chaque entrée peut aussi porter des termes associés (keywords, alias) qui déclenchent la même définition.
• Formats d’affichage : « Simple, style dictionnaire », « Continu sans auteur », « Complet avec/sans auteur », « Encyclopédie » (pièces jointes affichées en ligne), « FAQ » (concept affiché comme Question, définition comme Réponse), « Liste des entrées ».
• Évaluation des entrées : le même système de ratings que le forum (agrégation moyenne/somme/max…) permet de noter les contributions et d’envoyer le résultat au carnet de notes.
• Glossaire principal / secondaire : un cours peut avoir un seul glossaire principal (main glossary), dans lequel les enseignants peuvent importer les entrées des glossaires secondaires. Schéma classique : un glossaire secondaire par groupe ou par chapitre, consolidation dans le principal.
• Import/export XML : les entrées s’exportent dans un format XML propre à Moodle et se réimportent dans n’importe quel autre glossaire — le moyen standard de réutiliser un lexique d’une année sur l’autre.

Le mécanisme le plus spectaculaire est l’auto-liaison (auto-linking) : si le filtre « Liens automatiques du glossaire » est activé par l’administrateur (Administration du site → Plugins → Filtres) et que l’entrée coche « Lier automatiquement », alors chaque occurrence du terme dans le cours (pages, descriptions, messages de forum, questions de test…) devient un lien qui ouvre la définition en pop-up. Un lexique de 60 termes transforme ainsi tout le cours en hypertexte annoté.

⚠️ Piège : l’auto-liaison dépend d’un filtre désactivé par défaut sur beaucoup d’instances (il a un coût de performance : chaque texte affiché est scanné). Si vos entrées ne se lient pas, ce n’est pas un bug de votre glossaire : c’est le filtre qui n’est pas activé au niveau du site ou du cours. Pensez aussi à désactiver l’auto-liaison dans les tests (réglage du test/de la question ou balise <nolink>), sous peine d’offrir la définition en pop-up pendant l’examen…

💡 Pour un dev React : l’auto-liaison est un pipeline de transformation à l’affichage : le HTML de sortie traverse une chaîne de filtres (l’API Filter de Moodle) qui font du find-and-replace enrichi — une sorte de middleware de rendu, comparable à des plugins remark/rehype dans un pipeline MDX. Retenez ce concept de filtre : il resurgira pour LaTeX, les emojis, la lecture multimédia et H5P.

3.7 Le Wiki — l’écriture collaborative (avec ses limites)

Le Wiki (mod_wiki) permet de construire un ensemble de pages liées entre elles, éditables par les participants. Deux modes, choisis à la création et non modifiables ensuite :

• Wiki collaboratif : une seule instance partagée, tout le monde édite tout — le mode « vrai wiki » (compte rendu collectif, base de connaissances de promo, écriture à plusieurs mains).
• Wiki individuel : chaque étudiant a son propre wiki, invisible des autres (mais visible de l’enseignant) — utilisable comme journal de bord ou portfolio léger.

Le mode de groupe s’applique aussi : en groupes séparés, chaque groupe a son wiki ; en groupes visibles, chacun édite le sien et consulte ceux des autres.

Syntaxe et édition : le format par défaut est le HTML via l’éditeur riche standard de Moodle (TinyMCE en 5.x) ; les formats Creole (une syntaxe wiki standardisée, avec mini barre d’outils) et NWiki existent encore mais sont anecdotiques — restez en HTML. La création de pages suit la tradition wiki : on écrit un lien [[Nouvelle page]] dans une page existante ; le lien apparaît en rouge/italique tant que la page n’existe pas, et cliquer dessus la crée. C’est le seul moyen naturel de créer des pages, ce qui déroute au début.

Historique et comparaison : chaque page conserve un historique de versions ; l’onglet Historique liste les révisions avec auteur et date, permet de comparer deux versions côte à côte (diff visuel) et de restaurer une version antérieure. L’onglet Commentaires permet de discuter d’une page sans l’éditer.

Soyons clairs sur les limites, importantes pour vous qui venez du développement :

• Pas de vrai contrôle de version : le versionnage est linéaire, page par page. Pas de branches, pas de merge, pas de vue des changements sur l’ensemble du wiki, pas de blame consolidé. Deux étudiants qui éditent la même page simultanément se heurtent à un verrouillage rudimentaire (avertissement de conflit), pas à une fusion à trois voies.
• Pas de revue avant publication : toute sauvegarde est immédiatement publique (dans le périmètre du wiki).
• La contribution individuelle est laborieuse à évaluer : il faut éplucher les historiques page par page (des rapports tiers existent, mais rien de natif ne consolide « qui a écrit quoi »).
• Le wiki n’est pas noté nativement (pas de section Note) ; pour noter le travail wiki, on passe par une note manuelle dans le carnet ou un devoir « bilan ».

💡 Pour un dev React : si vous espériez « Git avec une interface web », révisez vos attentes : le wiki de Moodle est plus proche d’un Google Docs multi-pages avec historique linéaire que d’un dépôt Git. Pour un projet documentaire ambitieux avec vraie revue de contributions, certains établissements préfèrent un outil externe (HedgeDoc, GitLab Pages, Notion) intégré via URL ou LTI — quitte à perdre l’intégration native.

3.8 La Base de données (Database) — le CRUD pédagogique

La Base de données (mod_data) est l’activité la plus « développeur » de Moodle : l’enseignant définit une structure de champs, les participants créent des entrées conformes à cette structure, et des templates contrôlent l’affichage. C’est littéralement un mini-CRUD configurable.

3.8.1 Les champs

Chaque champ a un type, un nom et une description. Types disponibles : texte court, zone de texte (riche), nombre, date, menu déroulant, boutons radio, cases à cocher, URL, fichier, image, latitude/longitude (avec lien vers des services cartographiques). Les champs peuvent être marqués obligatoires. Une recherche et un tri sur les champs sont fournis d’office dans la vue liste.

3.8.2 Les templates : du HTML avec des balises ##tag##

Trois templates principaux définissent l’affichage, tous éditables en HTML avec des balises de substitution :

Dans ces templates, [[Nom du champ]] insère la valeur du champ, et des balises spéciales ##tag## insèrent les éléments fonctionnels : ##edit##, ##delete##, ##approve##, ##more## (lien vers la fiche), ##user## (auteur), ##timeadded##, ##comments##, etc. S’y ajoutent des templates secondaires (recherche avancée, RSS, CSS et JavaScript propres à l’activité). Un bouton « Réinitialiser » régénère un template par défaut à partir des champs — votre point de départ avant personnalisation.

Depuis Moodle 4.1, l’expérience de démarrage a été profondément améliorée : nouvelle page d’accueil « zéro état », gestion des préréglages (presets) mise en avant, aperçu avant import. Les presets sont des modèles complets (champs + templates) : Moodle en fournit quelques-uns (dont la classique « galerie d’images »), et vous pouvez exporter votre propre base comme preset (fichier ZIP, ou publication sur le site pour les autres cours) — le mécanisme de partage et de réutilisation par excellence.

3.8.3 Approbation, évaluation, quotas

• Approbation requise : les entrées des étudiants n’apparaissent qu’après validation par l’enseignant (avec option d’autoriser ou non l’édition d’une entrée approuvée).
• Évaluation : le système de ratings (comme forum et glossaire) note les entrées et alimente le carnet.
• Quotas : nombre d’entrées requises avant de pouvoir consulter celles des autres (le pendant du forum Q&A : contribuer avant de consommer), et nombre maximum d’entrées par participant.
• Commentaires sur les entrées, activables.

Cas d’usage qui justifient l’activité : galerie de projets étudiants (image + description + lien), collecte de terrain (observations géolocalisées), annuaire de ressources critiquées (URL + note de lecture + évaluation par les pairs), portfolio léger, recensement bibliographique collectif.

💡 Pour un dev React : la Base de données, c’est Airtable en miniature : un schéma de champs (vos colonnes), des enregistrements (les entrées), et des vues templatées. Les templates HTML à balises ##tag## sont un système de templating par interpolation — pensez Mustache dégradé — que vous éditez directement dans le navigateur. C’est aussi l’un des rares endroits de Moodle où l’enseignant peut injecter du CSS/JS scoped à une activité : les onglets CSS et JavaScript des templates sont un bac à sable de personnalisation apprécié des bidouilleurs.

⚠️ Piège : si vous ajoutez ou renommez un champ après avoir personnalisé les templates, vos templates ne sont pas mis à jour automatiquement — le nouveau champ n’apparaît nulle part tant que vous n’éditez pas les templates (ou ne les réinitialisez pas, perdant alors vos personnalisations). Stabilisez la structure des champs avant d’investir dans les templates.

3.9 Le Feedback — enquêtes et questionnaires non notés

L’activité Feedback (mod_feedback) crée des enquêtes personnalisées non notées : évaluation des enseignements, sondage de rentrée, auto-positionnement, recueil de besoins. À ne pas confondre avec le « feedback » que l’enseignant donne dans un devoir — collision de vocabulaire malheureuse mais installée.

Types de questions disponibles : choix multiple (une ou plusieurs réponses, présentation liste déroulante ou boutons), réponse courte, réponse longue, réponse numérique, ainsi que des éléments de structure (étiquette d’information, saut de page) et le captcha (utile si l’enquête est ouverte aux non-connectés, cas permis sur la page d’accueil du site).

Réglages clés :

• Anonymat : chaque Feedback est déclaré anonyme ou avec noms à la création. En mode anonyme, les réponses ne sont pas rattachées à l’utilisateur dans les résultats (avec les mêmes réserves d’honnêteté que pour le blind marking : c’est un anonymat applicatif, pas cryptographique — les journaux d’événements existent).
• Réponses multiples : autoriser ou non plusieurs soumissions par personne (pertinent surtout en anonyme).
• Afficher l’analyse aux étudiants : partager (ou non) les résultats agrégés avec les répondants.
• Notification des soumissions et message de conclusion affiché après envoi.
• Dépendances entre questions : chaque question peut dépendre de la réponse à une question antérieure (« Afficher cette question seulement si Q3 = Oui ») — la logique conditionnelle (branching) nécessite que les questions dépendantes soient séparées par un saut de page.

Analyse et export : l’onglet Analyse fournit les agrégats (moyennes, histogrammes par option), et l’export Excel/CSV des réponses individuelles permet l’analyse externe. Les modèles (templates) de Feedback permettent de réutiliser un questionnaire dans d’autres cours ; une instance peut même être déposée sur la page d’accueil du site pour des enquêtes transverses.

Feedback vs Sondage vs Survey — trois activités faciles à confondre :

⚠️ Piège : promettre l’anonymat exige de la rigueur. Si votre Feedback « anonyme » comporte une question « Quel est votre groupe de TD ? » sur un groupe de 8, l’anonymat est de facto brisé. Et on ne peut pas basculer un Feedback d’anonyme à nominatif après coup sans conséquences — décidez avant publication.

3.10 Le Sondage (Choice) — une question, un clic

Le Sondage (mod_choice) — Choice en anglais — est l’activité la plus simple de Moodle : une seule question, une liste d’options, chaque participant en choisit une (ou plusieurs si l’option « Autoriser le choix de plusieurs options » est activée). C’est le composant <RadioGroup> de Moodle, et son extrême simplicité est sa force : réponse en dix secondes, résultats immédiats.

Réglages clés :

• Limiter le nombre de réponses par option : chaque option porte un quota (par exemple 15 places par créneau) ; une option pleine devient indisponible. C’est LE mécanisme du « premier arrivé, premier servi ».
• Modifier son choix : autorisé ou non après validation.
• Publication des résultats : ne jamais publier / publier après la réponse de l’étudiant / publier après la fermeture / toujours publier — avec résultats anonymes ou nominatifs. La combinaison « après la réponse » évite le biais de conformité (voter comme la majorité).
• Afficher la colonne « Sans réponse », période d’ouverture/fermeture, aperçu des options avant ouverture, rappel automatique.

Cas d’usage : choix de créneaux de soutenance (avec quotas), choix de sujets d’exposé (une place par sujet), vote pour trancher une question de cours, mini-quiz d’amorçage en début de séance, recueil de consentement.

Un cas d’usage mérite mention : la constitution de groupes par choix des étudiants. Le Sondage natif enregistre un choix mais n’inscrit pas l’étudiant dans un groupe Moodle. C’est le rôle du plugin tiers très répandu Choix de groupe (Group choice, mod_choicegroup) : même ergonomie, mais chaque option est un groupe du cours et le choix inscrit réellement l’étudiant dans le groupe (avec quotas). Si votre scénario est « les étudiants forment leurs équipes eux-mêmes », demandez ce plugin à votre administrateur — c’est l’un des plugins tiers les plus installés au monde.

⚠️ Piège : avec des quotas serrés et une cohorte qui se rue à l’ouverture, le Sondage peut créer des frustrations (« il restait une place, elle a disparu pendant que je validais »). Les quotas sont appliqués à la validation, mais l’affichage n’est pas temps réel : annoncez l’ouverture à heure fixe et assumez le côté course. Pour des affectations équitables, préférez une répartition par l’enseignant.

3.11 Le Paquetage SCORM — l’e-learning standardisé (et vieillissant)

SCORM (Sharable Content Object Reference Model) est un standard d’interopérabilité e-learning des années 2000 : un module SCORM est un ZIP contenant du HTML/JS et un manifeste (imsmanifest.xml), produit par un outil auteur (Articulate Storyline, iSpring, Adobe Captivate, Genially…), et jouable dans n’importe quel LMS conforme — dont Moodle, qui supporte SCORM 1.2 (le plus répandu et le mieux supporté) et SCORM 2004 (support partiel : le séquencement avancé de SCORM 2004 n’est pas complètement implémenté dans Moodle, préférez exporter en 1.2 quand l’outil auteur le permet).

Mise en œuvre : Ajouter une activité → Paquetage SCORM → déposer le ZIP. Le contenu s’affiche dans la page ou dans une nouvelle fenêtre (réglages d’apparence : dimensions, navigation, table des matières). Le paquet communique avec Moodle via l’API JavaScript SCORM : il remonte le score, le statut (terminé/réussi/échoué), le temps passé et la progression, que Moodle enregistre.

Réglages clés :

• Nombre de tentatives (1 à illimité) et notation des tentatives : première tentative, dernière tentative, meilleure note, moyenne.
• Méthode d’évaluation : score le plus haut, situation des objets (learning objects), etc. — dépend de ce que le paquet remonte.
• Mode de tentative : forcer une nouvelle tentative à chaque lancement, ou reprendre où on en était.
• Le suivi alimente naturellement l’achèvement d’activité (exiger le statut « terminé » et/ou une note minimale) et le carnet de notes.

Les limites, sans détour : SCORM est une technologie datée. Le suivi s’arrête à « score + statut » (pas d’analytique fine des interactions en standard), le contenu est une boîte noire non éditable dans Moodle (toute correction passe par l’outil auteur et un ré-import), le rendu mobile dépend entièrement de la qualité du paquet, et la communication JS est fragile (pop-ups bloquées, sessions expirées en cours de module = suivi perdu). Les standards successeurs — xAPI/Tin Can et cmi5 — ne sont pas nativement supportés par Moodle (plugins requis). Pour du contenu interactif créé par vous, la voie moderne dans Moodle est H5P, traité au chapitre 5 de cette partie, où nous comparons précisément SCORM, H5P et xAPI. Réservez SCORM aux cas où il s’impose : contenu acheté sur étagère, module fourni par un organisme externe, ou chaîne de production institutionnelle déjà outillée en Storyline/Captivate.

⚠️ Piège : le ZIP doit contenir imsmanifest.xml à la racine. L’erreur archi-classique : zipper le dossier qui contient le module (le manifeste se retrouve dans mon-module/imsmanifest.xml) au lieu de zipper son contenu. Moodle refuse alors le paquet avec un message peu explicite. Autre piège : tester en tant qu’enseignant ne crée pas de vraies données de suivi — le mode « prévisualisation » ne remonte pas les scores comme le mode étudiant.

3.12 BigBlueButton — la classe virtuelle intégrée

Depuis Moodle 4.0, l’activité BigBlueButton (mod_bigbluebuttonbn) fait partie du cœur : Moodle intègre nativement un client vers BigBlueButton (BBB), la solution open source de classe virtuelle. C’est une reconnaissance de l’après-2020 : la visioconférence pédagogique est devenue une fonction de base d’un LMS.

Ce que BBB offre en séance : audio et webcams, partage d’écran, tableau blanc multi-utilisateurs (annotation collaborative sur des diapositives uploadées), chat public et privé, notes partagées, sondages instantanés, émoticônes de statut/lever la main, et surtout les salles de sous-groupes (breakout rooms) : le modérateur répartit les participants en petites salles temporaires puis les rappelle en plénière — l’outil des travaux de groupe synchrones.

Rôles : l’activité distingue modérateur (gère la séance, les droits, l’enregistrement, peut exclure) et participant (assiste et interagit). Le mapping se règle dans l’activité : typiquement, enseignants → modérateurs, étudiants → participants — mais vous pouvez promouvoir des étudiants modérateurs (exposés, classes inversées). Un lien invité (guest access, selon version et configuration) permet de convier un intervenant extérieur sans compte Moodle. L’activité peut être une salle pérenne (« salle du cours », réutilisée chaque semaine) ou une session datée qui s’affiche dans le calendrier ; on peut aussi imposer une salle d’attente (« les étudiants ne peuvent entrer qu’une fois un modérateur présent »).

Enregistrements : une séance peut être enregistrée (si le modérateur lance l’enregistrement) ; les enregistrements sont traités par le serveur BBB puis listés dans l’activité même (ou dans une activité de type « enregistrements seuls »), consultables en lecture web. Prévenez toujours les participants (obligation légale en Europe, au-delà de la courtoisie).

Le point crucial — le serveur : BigBlueButton est un logiciel serveur lourd (traitement audio/vidéo temps réel) que Moodle ne fait que piloter à distance. Par défaut, l’activité pointe vers un serveur d’essai gratuit opéré par Blindside Networks (la société créatrice de BBB), soumis à des limitations volontaires : durée de session plafonnée (de l’ordre de 60 minutes), nombre de participants limité (de l’ordre de 25), enregistrements conservés brièvement (environ 7 jours) et marqués d’un filigrane. C’est parfait pour essayer, intenable pour enseigner. En production, l’établissement doit soit héberger son propre serveur BBB (ou un cluster avec répartiteur de charge type Scalelite), soit souscrire une offre hébergée (Blindside Networks ou autres). C’est une décision d’infrastructure, détaillée dans la partie administration.

Face aux plugins tiers Zoom, Teams ou Webex (qui existent et sont répandus), BBB garde trois atouts : open source et auto-hébergeable (souveraineté des données — argument décisif pour les établissements publics européens), intégration native sans licence par utilisateur, et conception pédagogique (tableau blanc, breakout rooms et sondages pensés pour la classe, pas pour la réunion d’entreprise).

💡 Pour un dev React : l’intégration Moodle↔BBB est une intégration d’API distante classique : Moodle appelle l’API REST du serveur BBB (create, join, getRecordings…) avec des requêtes signées par un secret partagé (checksum), et redirige l’utilisateur vers l’URL de session. Le client BBB lui-même est… une application React communiquant en WebRTC. Vous êtes en terrain connu.

3.13 L’Outil externe (External tool / LTI) — survol

L’activité Outil externe (mod_lti) intègre dans un cours une application tierce conforme au standard LTI (Learning Tools Interoperability, norme de 1EdTech, ex-IMS Global) : plateforme d’exercices (WIMS, Wooclap, myLab…), laboratoire virtuel, autre LMS, simulateur, outil de programmation en ligne. Le principe : l’étudiant clique sur l’activité, Moodle le connecte automatiquement à l’outil distant en transmettant son identité et son contexte (cours, rôle) — pas de second compte, pas de seconde authentification — et l’outil s’affiche, typiquement dans un cadre embarqué ou une nouvelle fenêtre.

Deux générations du standard cohabitent : LTI 1.1 (héritée, signatures OAuth 1.0a, dépréciée) et LTI 1.3 / LTI Advantage (actuelle : OAuth 2.0, JWT signés, et trois services clés — Deep Linking pour choisir un contenu précis dans l’outil depuis Moodle, Assignment and Grade Services pour le retour des notes de l’outil vers le carnet Moodle, et Names and Role Provisioning pour la synchronisation des inscrits). Utilisez systématiquement LTI 1.3 pour toute nouvelle intégration. La configuration se fait idéalement au niveau du site par l’administrateur (l’outil devient alors sélectionnable en un clic par les enseignants) ; Moodle sait aussi être fournisseur LTI (publier ses propres cours vers d’autres plateformes).

💡 Pour un dev React : LTI 1.3, c’est OpenID Connect + JWT appliqué à l’éducation : l’établissement enregistre l’outil (client) auprès de la plateforme (issuer), le lancement est un flux OIDC avec un id_token JWT portant des claims normalisés (utilisateur, cours, rôle, ressource), et l’outil renvoie les notes via une API REST authentifiée en client credentials. Le Deep Linking est l’équivalent d’un « picker » OAuth (comme le sélecteur Google Drive). Si vous savez implémenter « Sign in with Google », vous savez conceptuellement implémenter LTI.

Nous n’allons pas plus loin ici : le paramétrage complet (enregistrement dynamique, clés, placements, débogage des lancements) et le développement d’un outil LTI sont traités en Partie 10, consacrée aux intégrations et à l’interopérabilité.

3.14 Les activités héritées : Chat et Survey

Deux activités subsistent dans le code pour compatibilité, mais ne devraient plus apparaître dans un nouveau cours :

Le Chat (mod_chat) : salon de discussion textuelle synchrone, avec sessions planifiables et archivage des conversations. Il date d’une époque sans visioconférence intégrée ni messagerie instantanée : son interface est archaïque et son usage résiduel. Il est désactivé par défaut dans les installations neuves des versions récentes de Moodle (l’administrateur peut le réactiver si un besoin spécifique l’exige). Pour du synchrone, préférez BigBlueButton (qui inclut un chat) ou la messagerie personnelle de Moodle ; pour de l’écrit asynchrone, le forum.

Le Survey (mod_survey) : propose trois enquêtes préconstruites et non modifiables issues de la recherche en pédagogie des années 1990-2000 — COLLES (perception de l’environnement d’apprentissage constructiviste en ligne), ATTLS (attitudes d’apprentissage) et « Incidents critiques ». On ne peut ni ajouter ni modifier une question : c’est tout l’inverse du Feedback. Lui aussi est désactivé par défaut sur les installations récentes. Sauf projet de recherche utilisant précisément ces instruments validés, utilisez Feedback. (Le paquetage IMS Content Package, autre héritage, est dans le même cas : remplacé en pratique par Fichier/SCORM/H5P.)

⚠️ Piège : lors de la restauration d’un vieux cours (sauvegarde datant de Moodle 2.x/3.x), vous pouvez retomber sur des Chats, Surveys ou paquetages IMS. Si le module est désactivé sur l’instance cible, l’activité restaurée sera invisible ou signalée manquante. Profitez de la migration pour remplacer ces reliques par leurs équivalents modernes plutôt que de demander leur réactivation.

3.15 Conclusion : quelle activité pour quel objectif ?

Vous disposez maintenant de la carte complète des activités natives. La question de l’enseignant n’est jamais « quelle activité est la meilleure ? » mais « quel est mon objectif pédagogique ? » — l’activité en découle. Le tableau suivant sert d’aide à la décision :

Trois principes pour finir :

1. La sobriété paie. Un cours efficace utilise trois à cinq types d’activités bien maîtrisés, pas quatorze. Chaque nouveau type d’activité a un coût cognitif pour les étudiants (apprendre l’interface) et pour vous (apprendre les pièges).
2. Les réglages transverses font la moitié du travail. Groupes, restrictions d’accès, achèvement d’activité : ces mécanismes communs (chapitre 6) transforment des activités isolées en parcours structuré.
3. Testez toujours en tant qu’étudiant. La fonction « Prendre le rôle… » ou, mieux, un vrai compte de test, vous évitera 90 % des mauvaises surprises (dates mal comprises, consignes invisibles, quotas mal réglés).

Au prochain chapitre, nous plongeons dans l’activité que nous n’avons fait qu’effleurer ici, et qui est à elle seule un sous-système complet de Moodle : le Test et sa banque de questions — types de questions, comportements, notation adaptative, paramétrage d’examen et analyse statistique des résultats.

📚 Aller plus loin : chaque activité a sa page de référence sur docs.moodle.org/fr  (Devoir, Forum, Atelier…), avec les « réglages » exhaustifs et les FAQ. Pour comprendre comment ces modules sont construits — et un jour écrire le vôtre —, le tutoriel officiel moodledev.io/docs/apis/plugintypes/mod  est le point d’entrée.