Chapitre 4 — Le Quiz et la Banque de questions

Le Quiz (Test) est, sans conteste, le moteur d’évaluation le plus puissant de Moodle — et probablement l’un des systèmes d’évaluation en ligne les plus sophistiqués du marché open source. Là où beaucoup de plateformes proposent un simple QCM chronométré, Moodle offre un véritable moteur d’évaluation : une vingtaine de types de questions natifs, des comportements de questions configurables (feedback différé, interactif avec indices, mode adaptatif, notation par degré de certitude), un système de versions de questions, des statistiques psychométriques (indice de facilité, indice de discrimination), la re-notation rétroactive, des dérogations individuelles, et une intégration native avec Safe Exam Browser pour les examens surveillés.

Cette puissance repose sur un choix d’architecture fondamental, qu’il faut comprendre avant tout clic : les questions ne vivent pas dans le quiz. Elles vivent dans une banque de questions (question bank), gérée par un composant distinct appelé le moteur de questions (question engine). L’activité Quiz n’est qu’un consommateur de ce moteur : elle sélectionne des questions dans la banque, orchestre les tentatives des étudiants, et agrège les notes. D’autres composants consomment le même moteur — l’activité Leçon en partie, le filtre « Embed questions », certains plugins tiers.

Cette séparation a des conséquences très concrètes pour vous :

• Une question corrigée dans la banque peut être re-notée rétroactivement dans tous les quiz qui l’utilisent.
• Une même question peut être partagée entre dix quiz — et, depuis Moodle 5.0, entre dix cours, grâce aux banques de questions partagées (activité mod_qbank).
• Depuis Moodle 4.0, les questions sont versionnées : chaque modification crée une nouvelle version, et chaque quiz choisit de suivre « toujours la dernière version » ou de figer une version précise.

💡 Pour un dev React : pensez à la banque de questions comme à un registre npm privé. Les questions sont des packages versionnés (v1, v2, v3…). Chaque quiz est un projet avec son package.json : il déclare des dépendances vers des questions, soit en « latest » (toujours la dernière version), soit épinglées (pinned) sur une version précise. Le quiz ne contient jamais le code source des questions — il les résout au moment de la tentative. Toute la Partie 4 de ce chapitre développera cette analogie.

Ce chapitre est long, car le sujet le mérite. Il couvre l’architecture, tous les réglages du quiz (avec un accent sur les deux sections les plus mal comprises : les comportements de questions et les options de relecture), la construction du quiz, la banque de questions moderne issue des refontes 4.0 → 5.x, chacun des types de questions natifs, les formats d’import/export (GIFT, Moodle XML, Aiken), et l’exploitation des statistiques. Il se termine par une checklist « examen sécurisé » directement utilisable.

1. Architecture : banque, moteur, activité

1.1 Les trois couches

Moodle sépare strictement trois responsabilités :

La conséquence pratique la plus importante : créer une question et l’ajouter à un quiz sont deux opérations distinctes. Vous pouvez créer des questions pendant des semaines sans jamais créer de quiz ; vous pouvez construire un quiz en dix minutes si la banque est déjà remplie. Les équipes efficaces travaillent presque toujours ainsi : la banque d’abord, les quiz ensuite.

1.2 Vocabulaire indispensable

Ce vocabulaire revient partout dans l’interface, les rapports et la documentation développeur ; fixons-le une fois pour toutes.

💡 Pour un dev React : la distinction question / question attempt est exactement celle entre un composant et une instance montée avec son état. La question en banque est la définition du composant (props par défaut, logique de rendu) ; la tentative de question est l’instance montée pour un utilisateur donné, avec son state local (réponse en cours, historique des soumissions). Le behaviour, lui, est un pattern Strategy injecté à l’instance : le même composant question se comporte différemment selon la stratégie de feedback qu’on lui passe — comme un reducer différent branché sur le même UI.

1.3 Le cycle de vie d’une tentative

Pour ancrer les concepts, voici ce qui se passe quand un étudiant passe un quiz :

1. Démarrage : Moodle crée une tentative de quiz (quiz attempt). Pour chaque emplacement (slot) du quiz, il résout la question à utiliser (version épinglée ou dernière version ; tirage au sort si l’emplacement est une « question aléatoire ») et crée une tentative de question.
2. Interaction : l’étudiant navigue, répond. Chaque enregistrement (automatique ou manuel) ajoute une étape (step) à l’historique de chaque tentative de question. Selon le comportement, l’étudiant peut recevoir du feedback en cours de route (mode interactif, feedback immédiat) ou rien du tout (feedback différé).
3. Soumission : à « Tout envoyer et terminer » (ou à l’expiration du temps), le moteur note chaque question selon son type et son comportement (pénalités éventuelles), agrège selon les barèmes du quiz, et calcule la note de la tentative.
4. Agrégation : si plusieurs tentatives existent, la méthode de notation du quiz (plus haute, moyenne, première, dernière) détermine la note finale envoyée au carnet de notes.
5. Relecture : l’étudiant revoit sa copie selon la matrice des options de relecture (section 2.5) — ce que l’enseignant a choisi de montrer, et quand.

📚 Aller plus loin : l’architecture du question engine est documentée en détail pour les développeurs sur moodledev.io (rubrique « Question engine »), avec les diagrammes de classes des types, comportements et usages. Côté utilisateur, docs.moodle.org/fr → « Test » et « Banque de questions ».

2. Les réglages du quiz, section par section

Créez un quiz : dans votre cours, mode édition, « Ajouter une activité ou ressource » → Test (c’est le nom français de l’activité Quiz). Le formulaire de réglages est long ; parcourons-le section par section. Comme pour toute activité, les champs de base (nom, description, disponibilité, achèvement, restrictions d’accès) suivent les principes vus au chapitre 2 ; nous nous concentrons ici sur les sections propres au quiz.

2.1 Temps (Timing)

Le réglage « Lorsque le temps imparti échoit » mérite un arrêt, car c’est lui qui décide du sort des copies non soumises à la fin du chrono :

1. La tentative en cours est envoyée automatiquement (défaut) : les réponses déjà enregistrées sont soumises telles quelles. C’est le choix sûr : l’étudiant ne perd pas son travail.
2. Un délai supplémentaire est donné pour envoyer, sans pouvoir modifier les réponses : la « période de grâce » (grace period). L’étudiant a X minutes pour cliquer « Envoyer », mais ne peut plus rien changer. Utile si votre institution exige un acte de soumission explicite.
3. La tentative doit être envoyée avant l’échéance, sinon elle n’est pas comptabilisée : la copie non soumise à temps est perdue. À réserver à des contextes réglementaires très stricts.

L’interaction entre limite de temps et date de fermeture est une source classique de confusion : si un étudiant commence 20 minutes avant la fermeture d’un quiz limité à 60 minutes, son chrono est tronqué à 20 minutes. La fermeture du quiz prime toujours. Prévoyez donc une fenêtre d’ouverture au moins égale à la limite de temps plus une marge.

⚠️ Piège : les réponses sont enregistrées automatiquement à intervalle régulier (autosave, par défaut toutes les 60 secondes) et à chaque changement de page. Mais si un étudiant perd sa connexion dans la dernière minute et que l’option 3 (« sinon elle n’est pas comptabilisée ») est active, sa tentative entière est invalidée. Sauf obligation, gardez la soumission automatique.

2.2 Note (Grade)

Les quatre méthodes de notation, quand plusieurs tentatives existent :

2.3 Mise en page (Layout)

⚠️ Piège : la navigation séquentielle est brutale : l’étudiant qui passe à la page suivante ne peut jamais revenir corriger une réponse, même s’il lui reste du temps. Beaucoup d’enseignants l’activent en croyant « sécuriser » l’examen et découvrent les réclamations après coup. Pour limiter la triche, préférez le mélange des questions et les questions aléatoires — pas la navigation séquentielle.

Notez que la pagination définie ici est un défaut ; elle se raffine ensuite question par question dans l’écran d’édition du quiz (section 3).

2.4 Comportement des questions (Question behaviour) — la section clé

C’est le réglage le plus structurant du quiz : il définit la stratégie d’interaction entre l’étudiant et chaque question. Le réglage principal est « Comment se comportent les questions » (How questions behave).

Trois comportements méritent un développement.

Interactif avec essais multiples. Chaque question affiche un bouton « Vérifier ». Si la réponse est fausse, l’étudiant reçoit un indice (hint, défini dans la question, section « Tentatives multiples ») et peut réessayer, moyennant une pénalité (penalty, définie elle aussi dans la question — typiquement 33,33 % par essai). Le nombre d’essais est égal au nombre d’indices définis, plus un. Une question sans indice ne donne qu’un seul essai, même en mode interactif : pensez à rédiger vos indices ! La note finale de la question est : note obtenue − (pénalité × nombre d’essais infructueux).

CBM — Certainty-Based Marking (notation par degré de certitude). L’étudiant doit accompagner chaque réponse d’un degré de certitude (faible / moyen / élevé). Une bonne réponse sûre rapporte plus (jusqu’à ×3) ; une mauvaise réponse donnée avec grande certitude coûte cher (jusqu’à −6). L’objectif pédagogique est de lutter contre la réponse au hasard et de développer la métacognition. Puissant, mais exigeant : ne l’utilisez qu’avec des étudiants préparés au principe, sinon l’incompréhension des notes négatives génère beaucoup de frustration.

Chaque tentative complète la précédente (Each attempt builds on the last). Ce n’est pas un comportement dans la liste, mais un réglage séparé de cette même section (sous « Afficher plus »). Activé, chaque nouvelle tentative de quiz pré-remplit les réponses de la tentative précédente : l’étudiant repart de sa copie antérieure et l’améliore. Combiné à « plusieurs tentatives » + « note la plus haute », cela crée un excellent dispositif de maîtrise progressive. Il exige que le quiz tire toujours les mêmes questions (attention aux questions aléatoires, qui re-tirent à chaque tentative — le report ne fonctionne alors que pour les questions identiques).

On trouve aussi dans cette section « Mélanger les éléments des questions » (Shuffle within questions, défaut : Oui) : mélange l’ordre des choix à l’intérieur des questions (les propositions d’un QCM, les paires d’un appariement), pour les questions dont le réglage individuel le permet. À ne pas confondre avec le mélange de l’ordre des questions, qui se règle dans l’écran d’édition du quiz (section 3.4).

💡 Pour un dev React : les comportements sont littéralement un pattern Strategy : le moteur de questions délègue à un objet qbehaviour_* la machine à états de la question (quels boutons afficher, quelles transitions autoriser, comment calculer la note à chaque étape). Changer « deferred » pour « interactive » revient à brancher un autre reducer sur le même state : mêmes actions possibles côté UI (saveAnswer, submit), mais transitions et effets différents. Et comme en Redux, tout l’historique des étapes est conservé — c’est de l’event sourcing : la note est recalculable en rejouant les étapes, ce qui rend possible la re-notation rétroactive (section 7.4).

2.5 Options de relecture (Review options) — la grille incomprise

Voici la section la plus mal comprise de tout Moodle, à l’origine d’innombrables tickets « mes étudiants voient les réponses ! » ou, à l’inverse, « mes étudiants ne voient pas leur note ! ». Prenons le temps de la décortiquer.

La grille croise quatre moments (colonnes) et sept informations (cases à cocher). Chaque case cochée signifie : « cette information est visible à ce moment-là ».

Les quatre moments :

Les sept informations :

Scénarios types :

Examen sommatif : tout décocher dans « Immédiatement après » et « Plus tard », sauf éventuellement « Points ». Cocher ce que vous voulez dans « Après la fermeture » — les étudiants verront la correction une fois que plus personne ne peut composer. Cela impose de mettre une date de fermeture.

Quiz formatif : cocher généreusement « Immédiatement après » et « Plus tard » (la tentative, si correcte, points, feedbacks, réponse juste) pour que l’étudiant apprenne de ses erreurs.

⚠️ Piège n°1 : cocher « Réponse juste » dans « Immédiatement après » ou « Plus tard » alors que le quiz reste ouvert plusieurs jours et autorise une seule tentative : le premier étudiant qui termine peut transmettre les corrigés à ceux qui n’ont pas encore composé. Pour tout quiz à enjeu, la réponse juste ne doit apparaître qu’« Après la fermeture ».

⚠️ Piège n°2 : « mes étudiants ne voient pas leur note après l’examen » — cause classique : les cases sont cochées dans « Après la fermeture »… mais le quiz n’a pas de date de fermeture, donc ce moment n’existe pas. Ajoutez une date de fermeture, ou cochez dans « Plus tard ».

💡 Pour un dev React : cette grille est une matrice de permissions temporelles — exactement le genre de logique que vous coderiez comme canView(info, phase) avec phase dérivé de now, submittedAt et closeDate. La règle des 2 minutes pour « Immédiatement après » est un seuil codé en dur ; « Après la fermeture » est un état inatteignable si closeDate === null. Une fois vue comme une fonction pure (info, phase) → boolean, la grille perd tout son mystère.

2.6 Apparence (Appearance)

2.7 Restrictions supplémentaires sur les tentatives (Extra restrictions on attempts)

Ces réglages relèvent de la sécurisation des tentatives :

Safe Exam Browser est un navigateur verrouillé open source (Windows, macOS, iOS) qui empêche de quitter l’application, d’ouvrir d’autres programmes, de faire des captures d’écran, etc. Son support est intégré nativement à Moodle depuis la version 3.9 : le réglage « Exiger l’utilisation de Safe Exam Browser » propose plusieurs modes — configuration manuelle dans Moodle (Moodle génère le fichier de configuration SEB et les clefs), téléversement d’un fichier de configuration SEB existant, ou simple vérification de la clef d’examen (Config Key / Browser Exam Key) pour valider que le client est bien un SEB configuré comme prévu. C’est le dispositif à utiliser pour un examen sur postes non maîtrisés.

⚠️ Piège : SEB sécurise le poste, pas la personne. À distance, rien n’empêche un second appareil ou un souffleur hors champ. La sécurité d’un examen est toujours un empilement : SEB + fenêtre temporelle courte + questions aléatoires + mélange + surveillance (humaine ou proctoring). Aucune brique seule ne suffit.

2.8 Feedback global (Overall feedback)

Le feedback global est le message affiché à l’étudiant à la fin de sa tentative, en fonction de sa note finale, par paliers. Vous définissez des limites de note (en pourcentage ou en points) et un texte par intervalle :

Les bornes hautes sont incluses, les bornes basses excluses (un 80 % tombe dans « ≥ 80 % »). C’est un outil de remédiation très simple et très efficace : donnez dans chaque palier des liens directs vers les ressources à revoir. Son affichage est contrôlé par la ligne « Feedback global » de la grille de relecture (section 2.5).

2.9 Dérogations utilisateur et groupe (Overrides)

Les dérogations (overrides) permettent d’accorder à un utilisateur ou à un groupe des conditions différentes du reste de la classe, sans dupliquer le quiz. Accessibles depuis la page du quiz → onglet « Plus » → « Dérogations » (dans les versions 4.x/5.x, la navigation par onglets secondaires de l’activité).

On peut déroger sur : dates d’ouverture/fermeture, limite de temps, nombre de tentatives, mot de passe. Les cas d’usage canoniques :

• Tiers temps : un groupe « Aménagements » avec limite de temps majorée d’un tiers. Utilisez une dérogation de groupe plutôt que N dérogations individuelles — un seul réglage à maintenir.
• Rattrapage : dérogation utilisateur avec une fenêtre d’ouverture spécifique pour l’étudiant absent.
• Session décalée (fuseaux horaires, seconde session) : dérogation de groupe avec d’autres dates et éventuellement un autre mot de passe.

En cas de conflit, une dérogation utilisateur prime sur une dérogation de groupe ; entre plusieurs dérogations de groupe, Moodle retient la plus favorable (par exemple la date de fermeture la plus tardive).

⚠️ Piège : une dérogation ne contourne pas les restrictions d’accès (section « Restreindre l’accès ») ni la visibilité de l’activité. Si le quiz est caché ou restreint à un autre groupe, votre étudiant en rattrapage ne le verra pas, dérogation ou non. Vérifiez toujours la chaîne complète : visible → accessible → dérogation.

3. Construire le quiz : l’écran d’édition

Le quiz créé, sa page affiche « Aucune question n’a encore été ajoutée ». Le bouton « Ajouter une question » ouvre l’écran d’édition du quiz — refondu dans les versions 4.x pour être plus clair (en-tête avec total des points, pagination visuelle, menus d’action par question) et encore amélioré dans les versions 5.x.

3.1 Les trois façons d’ajouter des questions

Le menu « Ajouter » en bas de chaque page du quiz propose :

1. « une question » : créer une nouvelle question à la volée. Elle sera quand même stockée dans la banque (dans la catégorie par défaut liée au quiz), pas « dans » le quiz — souvenez-vous de l’architecture. Pratique pour démarrer, mais désorganise vite la banque si on ne range pas.
2. « de la banque de questions » : sélectionner des questions existantes. Un sélecteur s’ouvre avec filtres par catégorie, tag, texte. C’est la voie royale quand la banque est bien tenue.
3. « une question aléatoire » (a random question) : insérer un emplacement qui, à chaque tentative, tirera au hasard une question dans une catégorie donnée (avec ou sans ses sous-catégories) ou, depuis les versions 4.x, parmi les questions portant certains tags. C’est l’outil central des examens individualisés : « 10 questions aléatoires de la catégorie Chapitre 3 » donne à chaque étudiant un sujet différent.

⚠️ Piège : pour que des questions aléatoires soient équitables, la catégorie source doit contenir des questions de difficulté homogène. Si votre catégorie mélange questions triviales et questions redoutables, deux étudiants auront des sujets de difficulté très différente. Structurez vos catégories par objectif et par niveau de difficulté (ou utilisez des tags de difficulté), et tirez séparément dans chaque niveau.

3.2 Sections du quiz

L’écran d’édition permet de créer des sections (un titre inséré avant une question) pour structurer un long quiz : « Partie A — Connaissances », « Partie B — Analyse »… Chaque section peut avoir sa propre option « Mélanger » (shuffle) : l’ordre des questions est alors aléatoire à l’intérieur de la section, à chaque tentative. On peut aussi verrouiller la progression entre sections avec la navigation séquentielle.

3.3 Pagination

Les traits « Page 1 », « Page 2 »… matérialisent la pagination. Le bouton « Repaginer » applique globalement « N questions par page » ; les petites icônes entre deux questions permettent d’insérer ou de supprimer un saut de page ponctuellement. Rappel : chaque changement de page enregistre les réponses — une raison de plus de ne pas tout mettre sur une seule page pour un examen.

3.4 Mélanger l’ordre des questions

La case « Mélanger » en haut de l’écran d’édition (ou par section) mélange l’ordre des questions à chaque tentative. À distinguer, encore une fois, de « Mélanger les éléments des questions » (réglages du quiz, section 2.4) qui mélange les choix internes d’une question. Les deux combinés, plus des questions aléatoires, rendent la copie de voisin à voisin nettement moins rentable.

3.5 Barèmes : note maximale vs somme des notes

Deux nombres coexistent en haut de l’écran d’édition, et leur relation déroute souvent :

• Total des points (Total of marks) : la somme des notes par défaut de chaque question (chaque question a une « note par défaut », default mark, définie dans la question, modifiable par quiz dans l’écran d’édition — cliquez sur le crayon à côté de la note de la question).
• Note maximale (Maximum grade) : la note sur laquelle le quiz est rapporté dans le carnet de notes.

Moodle applique une simple règle de trois : note finale = (points obtenus / total des points) × note maximale. Vous pouvez donc avoir un quiz de 47 points ramené sur 20 sans toucher aux questions. Pour repondérer une question (la faire compter double, par exemple), modifiez sa note dans l’écran d’édition du quiz : ce réglage est local au quiz et n’affecte pas la question en banque ni les autres quiz qui l’utilisent.

💡 Pour un dev React : la note par défaut de la question est la prop par défaut définie dans le composant ; la note dans le quiz est la prop passée à l’instance, qui l’emporte. Et la note maximale du quiz est une normalisation en sortie — un scale() appliqué au résultat agrégé, indépendant des poids internes.

3.6 Versions de questions dans le quiz (depuis 4.0)

Dans l’écran d’édition, chaque question affiche un sélecteur de version : « Toujours la dernière » (Always latest, le défaut) ou « v1 », « v2 »… Épinglez une version précise pour un examen dont le sujet est validé et ne doit plus bouger ; laissez « Toujours la dernière » pour les quiz formatifs qui doivent profiter des corrections. Nous détaillons le versionnage en section 4.2.

⚠️ Piège : modifier une question déjà tentée par des étudiants ne modifie pas leurs tentatives : chaque tentative reste liée à la version utilisée au moment où elle a démarré. Pour répercuter une correction de barème sur les copies existantes, il faut passer par la re-notation (section 7.4). Une nouvelle version ne re-note rien toute seule.

3.7 Aperçu enseignant

Le bouton « Aperçu » (Preview) vous fait passer le quiz comme un étudiant, sans créer de tentative comptabilisée. Deux réflexes : prévisualiser chaque question dès sa création (icône loupe dans la banque, qui permet en plus de tester différents comportements), et prévisualiser le quiz entier avant ouverture — c’est le seul moyen de repérer un mélange qui casse l’ordre logique, une image manquante, ou une question aléatoire qui tire dans la mauvaise catégorie.

4. La Banque de questions moderne (refonte 4.x → 5.x)

Cette section est la plus importante du chapitre pour quiconque vise l’expertise : la banque de questions a connu deux révolutions récentes — le versionnage en 4.0 et les banques partagées en 5.0 — et beaucoup de documentation en ligne décrit encore l’ancien monde.

4.1 Un peu d’histoire : avant Moodle 4.0

Historiquement, la banque de questions n’était pas une entité visible : c’était un simple écran (« Banque de questions » dans l’administration du cours) listant les questions rattachées au contexte du cours, organisées en catégories. Chaque cours avait sa banque implicite ; les catégories pouvaient aussi vivre au niveau d’une catégorie de cours ou du site pour un partage limité. Modifier une question la modifiait en place, sans historique : si un quiz d’examen passé l’utilisait, les copies déjà rendues pouvaient devenir incohérentes avec la nouvelle rédaction. Le partage entre cours passait par des exports/imports manuels, sources de duplication et de divergence.

4.2 La refonte 4.0 : versions, statuts, commentaires, statistiques

Moodle 4.0 (2022) a rebâti la banque autour d’un principe : une question est un objet versionné avec un cycle de vie. Techniquement, la refonte a introduit la notion d’« entrée de banque de questions » (question bank entry) qui regroupe toutes les versions d’une même question — et une architecture en sous-plugins qbank_* (colonnes, filtres, actions de la banque sont désormais des plugins, donc extensibles).

Les versions de questions. Chaque enregistrement d’une modification crée une nouvelle version (v1 → v2 → v3…). Les anciennes versions restent en base : toute tentative passée continue de pointer vers la version qu’elle a réellement utilisée — l’intégrité des copies est garantie par construction. Côté quiz, chaque emplacement choisit sa politique : « Toujours la dernière » (le quiz suit les mises à jour ; les nouvelles tentatives utiliseront la nouvelle version) ou une version figée.

💡 Pour un dev React : c’est du semver de registre npm, littéralement. L’entrée de banque = le package ; les versions = les publications ; « Toujours la dernière » = "question": "latest" ; une version figée = un lockfile. Et comme avec npm, la règle d’or est la même : en production (examen validé), on épingle ; en développement (formatif), on suit latest. Différence notable : Moodle n’a pas de distinction majeure/mineure — toute édition incrémente, il n’y a pas de « breaking change » déclaré, à vous de juger si une v2 change le sens de la question.

Les statuts. Chaque version porte un statut : Brouillon (Draft) ou Prêt (Ready). Une question en brouillon n’est pas proposée dans les sélecteurs d’ajout au quiz ni dans les tirages aléatoires : cela permet un vrai workflow de rédaction — l’auteur rédige en brouillon, un relecteur valide et passe la question en « Prêt ».

Les commentaires. Un fil de commentaires est attaché à chaque question (colonne dédiée dans la banque) : les enseignants d’une équipe peuvent y discuter une reformulation, signaler une ambiguïté, tracer les décisions. C’est l’équivalent de la revue de code pour les questions.

Les colonnes de statistiques d’usage. La banque affiche pour chaque question : le nombre de quiz qui l’utilisent (colonne « usage », cliquable pour voir lesquels), et des indicateurs psychométriques agrégés sur les usages passés — indice de facilité (facility index, pourcentage moyen de réussite) et indice de discrimination (discriminative efficiency / discrimination index, corrélation entre réussir cette question et réussir le reste du test). Nous expliquons ces indices en section 7.3 ; retenez qu’ils remontent désormais jusque dans la banque, ce qui permet de repérer d’un coup d’œil les questions défaillantes de tout un référentiel.

« Besoin de vérification ». Sur la base de ces statistiques, Moodle signale les questions dont les indicateurs sortent des plages attendues (facilité extrême, discrimination faible ou négative) comme méritant vérification (mention du type « needs checking » dans la colonne de statut/statistiques). Combiné à l’historique des versions et aux commentaires, cela outille un vrai processus d’amélioration continue de la banque : détecter → commenter → corriger (nouvelle version) → re-noter si nécessaire.

4.3 Moodle 5.0 : les banques deviennent des activités partagées (mod_qbank)

Moodle 5.0 (2025) franchit l’étape suivante : la banque de questions n’est plus un appendice caché du cours, c’est une instance d’activité à part entière, de type « Banque de questions » (mod_qbank). Concrètement :

• Les questions vivent désormais dans des instances de banque. Un cours peut contenir plusieurs banques (une par module thématique, par exemple), chacune avec son arborescence de catégories. La page « Banque de questions » du cours liste les banques disponibles au lieu d’afficher directement les questions.
• Banque par défaut du cours. Pour la continuité, chaque cours dispose d’une banque « par défaut » (créée à la demande) qui joue le rôle de l’ancienne banque de cours ; lors des mises à jour depuis 4.x, les questions existantes des contextes de cours y sont transférées. Les questions qui vivaient dans des contextes de catégorie de cours ou de site sont également migrées vers des banques dédiées — vérifiez ce point après toute mise à niveau, c’est là que les surprises se logent.
• Partage entre cours. C’est le grand gain : une activité Banque de questions étant une activité, elle peut être placée dans un cours « référentiel » auquel plusieurs enseignants sont inscrits, et les quiz d’autres cours peuvent puiser dedans (le sélecteur de questions permet de choisir la banque source, sous réserve des permissions). Fini les exports/imports pour partager un référentiel entre les six groupes d’un même enseignement : une seule banque, maintenue une fois, consommée partout. La duplication cède la place à la référence.
• Conséquence organisationnelle : on peut désormais organiser les questions par programme ou par discipline plutôt que par cours. Le pattern recommandé : un cours (souvent caché aux étudiants) « Référentiel de questions — Mathématiques L1 » contenant les banques officielles, maintenu par l’équipe pédagogique ; les cours d’enseignement n’hébergent, eux, que des questions locales et jetables.

Les versions 5.1 et 5.2 poursuivent le polissage de ce chantier : filtrage et tri améliorés dans la banque, actions en masse plus riches (déplacement, changement de statut, suppression groupée), meilleure gestion du transfert de questions entre banques. Le détail exact varie selon la version mineure — consultez les notes de version pour votre installation précise.

⚠️ Piège : « partagé » ne veut pas dire « public ». L’accès à une banque suit les permissions du contexte où vit l’activité qbank : un enseignant ne peut utiliser les questions d’une banque d’un autre cours que s’il y détient les capacités adéquates (typiquement via une inscription au cours-référentiel avec un rôle approprié). Si un collègue « ne voit pas la banque partagée », c’est presque toujours un problème d’inscription/rôle sur le cours qui héberge la banque.

💡 Pour un dev React : le passage de 4.x à 5.0 est une migration de « state local par cours » vers un store partagé importable — l’équivalent d’extraire des composants dupliqués dans chaque application vers un design system publié sur un registre interne. Les mêmes bénéfices (une seule source de vérité, corrections propagées) et les mêmes défis (gouvernance : qui a le droit de publier une nouvelle version dans la banque commune ? processus de revue via statuts brouillon/prêt et commentaires).

4.4 Catégories de questions

À l’intérieur d’une banque, les questions sont rangées dans des catégories hiérarchiques (arborescence à profondeur libre). Bonnes pratiques :

• Calquez l’arborescence sur votre référentiel pédagogique (chapitres, objectifs d’apprentissage), pas sur vos quiz : « Chapitre 3 / Objectif 3.2 / Niveau facile » plutôt que « Questions du partiel 2026 ».
• Les questions aléatoires tirent dans une catégorie (± sous-catégories) : votre arborescence détermine donc directement la granularité possible des tirages.
• Chaque catégorie a un nom, une description (« info ») et un numéro d’identification optionnel (utile pour les imports scriptés).

Avant 5.0, les catégories pouvaient être créées dans différents contextes (module quiz, cours, catégorie de cours, système) — c’était le mécanisme de partage. Depuis 5.0, ce rôle est repris par les instances de banque ; l’arborescence de catégories vit dans chaque banque.

4.5 Tags

Chaque question peut porter des tags (étiquettes libres, transversales aux catégories) : difficile, calcul, objectif-3.2, session-2026. Les tags complètent les catégories (classement unique) par une taxonomie à facettes (multi-appartenance). Depuis les versions 4.x, on peut tirer des questions aléatoires par tags — combiné aux catégories, cela permet des tirages fins : « une question de la catégorie Chapitre 3 portant le tag difficile ». La banque se filtre également par tags.

4.6 Droits : les capacités qbank

L’accès à la banque est gouverné par des capacités dédiées (préfixe moodle/question: — nous approfondirons le système de capacités dans la partie Administration). Les plus utiles à connaître :

Le duo editall/useall vs editmine/usemine permet des schémas fins : un vacataire peut utiliser les questions du référentiel sans pouvoir les modifier.

4.7 Transfert et partage : en pratique

Pour déplacer des questions entre banques (par exemple consolider dans un cours-référentiel après migration 5.0) : sélection en masse dans la banque → action « Déplacer vers » en choisissant banque et catégorie cibles ; ou export/import (section 6) quand on change de plateforme. Attention aux questions en cours d’usage : Moodle protège les questions utilisées par des tentatives existantes (elles ne peuvent être supprimées ; leur déplacement est possible mais réfléchissez aux permissions résultantes pour les quiz consommateurs).

📚 Aller plus loin : docs.moodle.org/fr → « Banque de questions » (guide utilisateur) ; moodledev.io → « Question bank plugins » pour l’architecture qbank_* introduite en 4.0, et les notes de version 5.0 pour la spécification complète du passage à mod_qbank.

5. Les types de questions natifs, un par un

Moodle 5.2 livre en standard une vingtaine de types (qtype_*). Pour chacun : principe, options clés, notation, cas d’usage, piège. Le formulaire de création commence toujours pareil : catégorie, nom de la question (invisible des étudiants — nommez pour vous : « CH3-QCM-derivee-01 »), texte de la question, note par défaut, feedback général, puis les options du type.

5.1 Choix multiple (Multiple choice)

Principe : le QCM classique — un énoncé, des propositions, l’étudiant coche.

Options clés :

• Une seule réponse ou réponses multiples : radio vs checkboxes.
• Mélanger les réponses possibles : oui par défaut (actif seulement si le quiz mélange, cf. 2.4).
• Numéroter les choix : a., 1., i., ou aucun.
• Chaque proposition reçoit une note en pourcentage (grade) : 100 % pour la bonne réponse (mode réponse unique) ; en mode réponses multiples, répartissez les pourcentages positifs entre bonnes réponses (total = 100 %) et affectez des pourcentages négatifs aux mauvaises.
• Feedback par proposition + feedbacks combinés (pour toute réponse correcte / partiellement correcte / incorrecte).
• Pénalité pour chaque essai incorrect (utilisée par les comportements interactif/adaptatif) et indices (hints).

Notation : somme des pourcentages cochés × note de la question, plancher à 0 (jamais négatif au total, sauf CBM).

Cas d’usage : vérification de connaissances, questions de compréhension avec distracteurs travaillés.

⚠️ Piège : en mode « réponses multiples », si vous ne mettez pas de pourcentages négatifs sur les mauvaises réponses, la stratégie gagnante est de tout cocher (les bonnes rapportent, les mauvaises ne coûtent rien). Règle pratique : mauvaise réponse = −(100 % / nombre de mauvaises réponses), ou au moins un négatif dissuasif.

5.2 Vrai/Faux (True/False)

Principe : un énoncé, deux boutons. Options : la bonne réponse, un feedback pour chaque cas. Notation : tout ou rien ; pas de pénalité configurable (en mode interactif, un seul essai a du sens puisqu’il n’y a que deux réponses). Cas d’usage : échauffement, vérification rapide de lecture. Piège : 50 % de réussite au hasard — n’en faites jamais l’essentiel d’une évaluation sommative ; préférez un QCM à 4 choix ou compensez par le nombre.

5.3 Appariement (Matching)

Principe : associer chaque élément d’une liste (sous-questions) à une réponse choisie dans un menu déroulant commun.

Options : au moins 2 sous-questions et 3 réponses ; on peut ajouter des réponses supplémentaires sans sous-question (distracteurs) en laissant la sous-question vide ; mélange des paires.

Notation : proportionnelle — chaque paire correcte vaut 1/N de la note.

Cas d’usage : vocabulaire ↔ définition, œuvre ↔ auteur, symptôme ↔ pathologie.

⚠️ Piège : sans distracteur supplémentaire, la dernière association se déduit par élimination. Ajoutez toujours une ou deux réponses en trop.

5.4 Appariement aléatoire à réponse courte (Random short-answer matching)

Principe : hybride curieux — Moodle construit automatiquement une question d’appariement en piochant N questions de type Réponse courte dans la même catégorie, et en utilisant leurs énoncés comme sous-questions et leurs réponses comme choix. Options : nombre de questions à piocher, inclure les sous-catégories. Cas d’usage : recycler une catégorie de réponses courtes en exercice d’association auto-renouvelé. Piège : exige suffisamment de questions Réponse courte dans la même catégorie, avec des réponses non ambiguës entre elles ; peu utilisé en pratique — considérez-le comme une curiosité plus qu’un pilier.

5.5 Réponse courte (Short answer)

Principe : l’étudiant tape une réponse libre courte, comparée à une liste de réponses acceptées.

Options clés :

• Sensibilité à la casse : oui/non.
• Plusieurs réponses acceptées, chacune avec son pourcentage : Paris → 100 %, paris intra-muros → 50 %…
• Le joker * (wildcard) remplace n’importe quelle suite de caractères : *photosynth* accepte « photosynthèse », « la photosynthese »… Pour accepter un astérisque littéral, échappez-le : \*.

Notation : le pourcentage de la première réponse acceptée qui correspond (l’ordre de déclaration compte : mettez les motifs les plus spécifiques d’abord).

Cas d’usage : termes précis, dates, formules courtes — quand la reconnaissance ne demande pas de sémantique.

⚠️ Piège : la comparaison est textuelle et exacte (hors jokers) : « les Alpes » ≠ « Alpes », « 1 789 » ≠ « 1789 », accent oublié = faux. Anticipez les variantes avec des jokers (*Alpes*) et testez avec l’aperçu ; sinon, préparez-vous à re-noter après coup (section 7.4).

5.6 Numérique (Numerical)

Principe : réponse numérique comparée avec une tolérance (erreur acceptée) : réponse 9,81, tolérance 0,05 → tout ce qui est dans [9,76 ; 9,86] est correct.

Options clés : plusieurs réponses acceptées (avec pourcentages et tolérances propres — utile pour créditer partiellement un résultat « proche ») ; gestion des unités : les ignorer (défaut), les noter (avec pénalité si unité fausse ou absente), les proposer en menu ; définition des unités acceptées avec leur multiplicateur (m = 1, cm = 0,01…) pour que « 981 cm » soit accepté pour 9,81 m.

Cas d’usage : sciences, calculs avec valeur unique attendue.

⚠️ Piège : le séparateur décimal. Les étudiants francophones tapent « 9,81 » (virgule) ; le traitement dépend de la langue et du navigateur. Indiquez explicitement le format attendu dans l’énoncé, et testez. Et n’oubliez pas la tolérance : une tolérance à 0 exige l’exactitude binaire, cruelle pour les arrondis.

5.7 Calculée, Calculée simple, Calculée à choix multiple (Calculated)

Principe : la famille « calculée » génère des variantes numériques d’une même question grâce à des variables (wild cards) notées {a}, {b} dans l’énoncé, remplacées à chaque tirage par des valeurs issues d’un jeu de données (dataset). La formule de correction est écrite avec ces variables : énoncé « Un rectangle mesure {l} m sur {L} m ; quelle est son aire ? », formule de réponse {l}*{L}, tolérance relative 1 %.

Les trois variantes :

Notation : comme Numérique (tolérances), ou comme QCM pour la variante multichoice.

Cas d’usage : exercices d’application en sciences où chaque étudiant doit avoir ses valeurs (anti-copie structurel).

⚠️ Piège : générez et inspectez les jeux de données : des plages mal bornées produisent des cas dégénérés (division par un nombre proche de zéro, discriminant négatif, résultats absurdes physiquement). Vérifiez une dizaine de tirages dans l’aperçu avant de publier. Pour des besoins mathématiques avancés (variables liées, conditions, graphiques), regardez le plugin tiers Formulas ou STACK (section 5.17).

5.8 Essai / Composition (Essay)

Principe : réponse longue en texte libre — la seule question native non notée automatiquement : elle attend une correction manuelle (via « Notation manuelle » dans les résultats du quiz).

Options clés : format de réponse (éditeur HTML, texte brut, ou aucun texte — cas où l’étudiant ne rend qu’un fichier) ; fichiers joints autorisés (nombre, types acceptés, obligatoires ou non) ; taille du champ ; modèle de réponse (response template) pré-rempli dans l’éditeur — parfait pour imposer un plan ; information pour les correcteurs (grader information) : votre grille de critères, visible des seuls correcteurs ; et depuis les versions 4.x, des limites de mots minimale et maximale (min/max word limit) appliquées à la soumission.

Cas d’usage : analyse, argumentation, mini-cas pratique au sein d’un quiz. Pour un vrai travail long avec workflow d’évaluation avancé, préférez l’activité Devoir (chapitre suivant).

⚠️ Piège : tant que les essais ne sont pas corrigés manuellement, la note du quiz affichée à l’étudiant est incomplète (les essais comptent 0 ou « requiert notation »). Prévenez les étudiants, et masquez « Points » dans les options de relecture jusqu’à la fin de la correction si nécessaire.

5.9 Cloze / Réponses intégrées (Embedded answers, type « multianswer »)

Principe : plusieurs sous-questions incrustées dans un texte, à la manière d’un texte à trous enrichi. Il n’y a pas de formulaire visuel : on écrit une syntaxe spéciale directement dans le texte de la question.

La syntaxe générale : {poids:TYPE:réponses} où les réponses sont séparées par ~, la bonne réponse préfixée par =, les crédits partiels par %50%, et les feedbacks ajoutés avec #.

Types de sous-questions disponibles :

Exemple complet commenté :

La capitale de l'Australie est {2:SHORTANSWER:=Canberra#Bravo !
~%50%Camberra#Orthographe approximative, mais c'est l'idée
~Sydney#Non : Sydney est la plus grande ville, pas la capitale}.

Elle compte environ {1:NUMERICAL:=460000:20000#Correct (± 20 000)} habitants.

L'Australie se trouve dans l'hémisphère {1:MULTICHOICE:=sud#Oui
~nord#Non, regardez un globe} et c'est {1:MCV:=à la fois un pays et un continent
~seulement un pays~seulement un continent}.

Décodage : {2:SHORTANSWER:...} — sous-question de poids 2 (elle compte double par rapport aux poids 1) ; =Canberra réponse exacte, %50%Camberra créditée à moitié, ~Sydney fausse ; chaque #... est le feedback de la réponse qui le précède. {1:NUMERICAL:=460000:20000} : 460 000 avec tolérance ± 20 000. MULTICHOICE s’affiche en menu déroulant dans la phrase, MCV en boutons radio verticaux sous la phrase.

Notation : chaque sous-question est notée puis pondérée par son poids ; le total fait la note de la question.

Cas d’usage : textes à trous linguistiques, énoncés de problème à réponses multiples enchaînées, analyse guidée d’un document.

💡 Pour un dev React : le cloze, c’est un template literal avec interpolations typées : le texte est la partie statique, chaque {poids:TYPE:...} est une expression interpolée qui se compile en un mini-composant de saisie (input, select, radios) avec son validateur embarqué. Comme pour un template literal complexe, l’erreur de syntaxe est vite arrivée : le bouton « Décoder et vérifier le texte de la question » du formulaire est votre linter — utilisez-le systématiquement.

⚠️ Piège : les caractères spéciaux de la syntaxe (}, #, ~, =, {) présents dans vos réponses doivent être échappés avec \. Et si vous rédigez dans l’éditeur riche, gare aux balises HTML que l’éditeur insère au milieu de votre syntaxe (un <br> dans un {...} casse le parsing) : pour les cloze complexes, passez l’éditeur en mode HTML/source.

5.10 Glisser-déposer sur une image (Drag and drop onto image)

Principe : l’étudiant fait glisser des éléments (textes ou images) vers des zones cibles prédéfinies sur une image de fond. Options : image de fond ; éléments déplaçables (avec option « infini » pour un élément réutilisable plusieurs fois, et groupes limitant quelles zones acceptent quels éléments) ; définition des zones (cliquer sur l’image positionne la zone). Notation : proportionnelle au nombre de zones correctement remplies. Cas d’usage : légender un schéma (anatomie, architecture réseau, carte). Piège : l’image de fond a une taille maximale recommandée (au-delà, elle est réduite) ; testez le rendu sur mobile — une image dense en petites zones est très pénible au doigt.

5.11 Glisser-déposer sur un texte (Drag and drop into text)

Principe : texte à trous où les trous [[1]], [[2]]… se remplissent en glissant des étiquettes proposées. Options : les choix numérotés correspondent aux trous ; choix groupés (chaque groupe a sa couleur, un trou n’accepte que son groupe) ; choix supplémentaires comme distracteurs ; « infini » pour réutiliser une étiquette. Notation : proportionnelle. Cas d’usage : grammaire, textes lacunaires où voir les réponses possibles fait partie de l’exercice (plus guidé qu’un cloze SHORTANSWER). Piège : c’est de la reconnaissance, pas du rappel — plus facile qu’une réponse tapée ; calibrez la difficulté (et le barème) en conséquence.

5.12 Marqueurs à glisser-déposer (Drag and drop markers)

Principe : variante « experte » du glisser-déposer sur image : l’étudiant place des marqueurs sur une image, mais les zones cibles ne sont pas visibles — il doit savoir où pointer. Les zones (cercle, rectangle, polygone) sont définies par coordonnées par l’enseignant. Notation : proportionnelle aux marqueurs bien placés. Cas d’usage : « placez la gare sur la carte », « pointez la faille dans ce code affiché en image ». Piège : dessinez des zones généreuses — une zone de 10 pixels transforme la question en épreuve de précision de souris, pas de connaissance.

5.13 Sélectionner les mots manquants (Select missing words)

Principe : même logique que « glisser-déposer sur texte » (trous [[n]], groupes, distracteurs) mais les trous sont des menus déroulants au lieu d’étiquettes à glisser. Cas d’usage : identique, avec deux avantages : rendu plus sobre pour de longs textes, et meilleure accessibilité (les menus déroulants se manipulent intégralement au clavier et au lecteur d’écran, là où le drag and drop reste délicat malgré les alternatives clavier). Piège : aucun spécifique — c’est souvent le meilleur choix par défaut entre les deux.

5.14 Ordering / Remise en ordre (natif depuis 4.5)

Principe : remettre des éléments dans le bon ordre par glisser-déposer. Longtemps plugin tiers très populaire (qtype_ordering), il a été intégré au cœur de Moodle en 4.5 — sur les versions antérieures, il fallait l’installer.

Options clés : la liste des éléments dans le bon ordre (Moodle les mélange à l’affichage) ; mise en page horizontale ou verticale ; taille du sous-ensemble affiché (montrer par exemple 6 éléments tirés parmi 10) ; stratégie de notation : tout ou rien, ou crédit partiel selon les positions absolues correctes, ou selon les positions relatives (paires d’éléments consécutifs bien ordonnées, et autres variantes).

Cas d’usage : chronologies, étapes d’un protocole, ordre des lignes d’un algorithme (un grand classique pour évaluer la lecture de code, dans l’esprit des « Parsons problems »).

⚠️ Piège : la notation par positions absolues est très punitive — un seul élément décalé en tête décale tout et fait chuter la note alors que l’ordre relatif est presque parfait. Pour des séquences longues, préférez une notation par positions relatives.

5.15 Description

Principe : ce n’est pas une question — aucun champ de réponse, aucune note. C’est un bloc de contenu (texte, image, consigne) inséré dans le flux du quiz. Cas d’usage : afficher un document, un texte ou des consignes communes avant une série de questions qui s’y rapportent (« Lisez le texte ci-dessous, puis répondez aux questions 4 à 9 »). Piège : avec le mélange des questions activé, la description peut se retrouver séparée des questions qu’elle introduit. Parade : placez description et questions liées dans une section sans mélange.

5.16 Tableau récapitulatif des types natifs

5.17 Types tiers à connaître

L’écosystème qtype_* tiers est riche ; trois plugins dominent :

• STACK : questions de mathématiques avec évaluation symbolique des réponses via le moteur de calcul formel Maxima — l’étudiant tape une expression algébrique, STACK vérifie l’équivalence mathématique (pas l’égalité textuelle), avec arbres de réponse et feedback adaptatif. La référence absolue pour les maths dans le supérieur.
• CodeRunner : questions de programmation — l’étudiant écrit du code (Python, C, Java, SQL, JavaScript…) exécuté et testé contre des jeux de tests dans un bac à sable (serveur Jobe). Si vous, développeur, devez un jour enseigner le code sur Moodle, c’est l’outil incontournable : pensez « quiz avec tests unitaires intégrés », l’expérience est étonnamment proche d’un kata sur une plateforme d’exercices de code.
• Formulas : le chaînon manquant entre Numérique et STACK — questions numériques multi-parties avec variables aléatoires, unités et notation fine, sans nécessiter Maxima.

📚 Aller plus loin : chaque type natif a sa page sur docs.moodle.org/fr (« Types de questions ») ; les plugins tiers sont sur moodle.org/plugins (vérifiez la compatibilité annoncée avec 5.2 avant installation). Pour développer votre propre type, moodledev.io → « Question type plugins ».

6. Import et export de questions

Créer 200 questions au clic est un supplice ; les générer ou les migrer via un format texte est un jeu d’enfant. Moodle importe et exporte plusieurs formats — un terrain où le développeur que vous êtes a un avantage décisif.

6.1 GIFT : le format texte de prédilection

GIFT (General Import Format Template) est un format texte concis conçu pour Moodle : lisible, éditable dans n’importe quel éditeur, idéal pour rédiger vite ou générer par script. Un fichier .txt en UTF-8, une question par bloc, blocs séparés par une ligne vide.

Syntaxe complète par l’exemple :

// Un commentaire commence par //. Ligne suivante : nom de la question.
::CH1-QCM-01::Quelle balise HTML crée un lien hypertexte ? {
    =<a>          // = introduit la bonne réponse
    ~<link>       // ~ introduit une mauvaise réponse
    ~<href>       // (échappez les caractères spéciaux ~ = # { } : avec \)
    ~<url>
}

// QCM à crédit partiel et feedbacks (# après la réponse) :
::CH1-QCM-02::Quels langages s'exécutent nativement dans le navigateur ? {
    ~%50%JavaScript      # Oui, et c'est même le seul historique.
    ~%50%WebAssembly     # Oui, depuis 2017.
    ~%-50%PHP            # Non : PHP s'exécute côté serveur.
    ~%-50%Python         # Non (hors solutions transpilées).
}

// Vrai/Faux : {T}, {F}, {TRUE} ou {FALSE}
::CH1-VF-01::HTTP est un protocole avec état (stateful). {F
    # Faux. # Exact : HTTP est sans état ; les sessions le contournent.
}
// Après T/F : premier # = feedback si réponse fausse, second # = si juste.

// Réponse courte : uniquement des = (plusieurs réponses acceptées)
::CH1-SA-01::Quel mot-clef déclare une constante en JavaScript ? {
    =const
    =%50%let   # let déclare une variable réassignable, pas une constante.
}

// Numérique : préfixe #, tolérance après :
::CH1-NUM-01::Quelle est la valeur de 2 puissance 10 ? {#
    =1024:0
    =%50%1000:24   # Ordre de grandeur correct, valeur inexacte.
}

// Appariement : paires =sous-question -> réponse
::CH1-MATCH-01::Associez chaque code HTTP à sa signification. {
    =200 -> OK
    =301 -> Redirection permanente
    =404 -> Ressource non trouvée
    =503 -> Service indisponible
}

// Question à trou : la bonne réponse au milieu de la phrase
::CH1-GAP-01::La commande {=git clone} copie un dépôt distant en local.

// Essai : accolades vides
::CH1-ESSAY-01::Expliquez la différence entre authentification
et autorisation. {}

// Feedback général (affiché à tous) : ####
::CH1-QCM-03::Quel port par défaut utilise HTTPS ? {
    =443 ~80 ~22 ~8080
    ####Le port 80 est celui de HTTP ; 22 celui de SSH.
}

Points d’attention : l’encodage doit être UTF-8 (sans BOM de préférence) ; les caractères de contrôle (~ = # { } :) dans le texte doivent être échappés \~ ; on peut fixer la catégorie cible depuis le fichier avec une ligne $CATEGORY: $course$/top/Chapitre 1 avant les questions concernées.

6.2 Moodle XML : le format complet

Moodle XML est le format natif : il représente tout (tous les types, images encodées en base64, feedbacks, indices, pénalités, tags, jeux de données des calculées) — c’est le format de l’export, donc celui des migrations et sauvegardes de banques. Structure minimale d’un QCM :

<?xml version="1.0" encoding="UTF-8"?>
<quiz>
  <!-- Une question de type "category" positionne la catégorie cible
       pour les questions suivantes -->
  <question type="category">
    <category>
      <text>$course$/top/Chapitre 1/Fondamentaux</text>
    </category>
  </question>
 
  <question type="multichoice">
    <name><text>CH1-QCM-01</text></name>
    <questiontext format="html">
      <text><![CDATA[<p>Quelle balise HTML crée un lien hypertexte ?</p>]]></text>
    </questiontext>
    <generalfeedback format="html">
      <text><![CDATA[<p>La balise a (anchor) avec son attribut href.</p>]]></text>
    </generalfeedback>
    <defaultgrade>1.0</defaultgrade>
    <penalty>0.3333333</penalty>
    <single>true</single>
    <shuffleanswers>true</shuffleanswers>
    <answernumbering>abc</answernumbering>
    <answer fraction="100" format="html">
      <text><![CDATA[&lt;a&gt;]]></text>
      <feedback format="html"><text>Correct.</text></feedback>
    </answer>
    <answer fraction="0" format="html">
      <text><![CDATA[&lt;link&gt;]]></text>
      <feedback format="html">
        <text>Non : link référence des ressources externes (CSS...).</text>
      </feedback>
    </answer>
    <tags><tag><text>html</text></tag></tags>
  </question>
</quiz>

Cas d’usage : migration entre plateformes, sauvegarde fine d’une banque, et surtout génération programmatique — le XML étant verbeux mais totalement spécifié, c’est le format cible idéal pour un script.

💡 Pour un dev React : GIFT et Moodle XML sont deux formats de sérialisation du même modèle, avec l’arbitrage classique DX/complétude : GIFT ≈ YAML (concis, humain, couverture partielle des types), Moodle XML ≈ JSON exhaustif (verbeux, machine-first, fidélité totale). Réflexe de dev à cultiver : stockez vos questions en GIFT/XML dans un dépôt Git — revue par pull request, diff lisibles, historique — et importez dans Moodle comme étape de « déploiement ». La banque versionnée de Moodle gère les versions dans la plateforme ; Git gère la collaboration en amont. Et pour la génération assistée par LLM : demandez la sortie directement en GIFT (format compact que les modèles connaissent bien), faites une passe de validation syntaxique, importez sur un cours bac à sable, relisez humainement chaque question (les distracteurs plausibles-mais-faux sont précisément là où les LLM hallucinent), puis transférez dans la banque officielle avec le statut Brouillon → relecture → Prêt.

6.3 Aiken : le minimalisme pour QCM

Aiken ne sait faire qu’une chose : des QCM à réponse unique — mais avec une syntaxe si simple qu’un non-technicien la maîtrise en une minute :

Quel protocole sécurise HTTP ?
A. TLS
B. FTP
C. SMTP
D. DHCP
ANSWER: A

Contraintes strictes : question sur une ligne, choix A. à Z. (ou A)), ligne ANSWER: X en majuscules. Pas de feedback, pas de crédit partiel, pas d’images. Parfait pour convertir rapidement un stock de QCM Word ; insuffisant pour tout le reste.

6.4 Autres formats et workflow d’import

Moodle importe aussi : Blackboard (fichiers .dat/pool V6+, pour migrer depuis Blackboard), Embedded answers (Cloze) (un fichier contenant des questions au format cloze de la section 5.9), Missing word et « WebCT » selon les versions (formats hérités, en voie d’extinction — vérifiez leur présence dans votre 5.2). À l’export, vous disposez de Moodle XML (complet), GIFT et XHTML (lecture seule).

Le workflow d’import (Banque de questions → Importer) :

1. Choisir le format du fichier.
2. Généralités : la catégorie cible (et deux cases : « obtenir la catégorie à partir du fichier » et « obtenir le contexte à partir du fichier » — cochées, elles laissent les directives $CATEGORY/<question type="category"> du fichier primer sur votre choix).
3. Correspondance des notes (matching grades) : les crédits partiels du fichier doivent correspondre à la liste des pourcentages valides de Moodle (100, 90, 83,333, 80, 75, 70, 66,666, 60, 50, 40, 33,333…). « Erreur si la note n’est pas listée » rejette le fichier ; « Point le plus proche si la note n’est pas listée » arrondit silencieusement. Un %37% dans votre GIFT deviendra 33,333 % en mode « point le plus proche ».
4. Téléverser, prévisualiser le rapport d’import (les erreurs indiquent le numéro de bloc fautif), corriger, réimporter.

⚠️ Piège : l’import crée toujours de nouvelles questions — il ne met pas à jour les existantes, même à nom identique. Réimporter un fichier corrigé duplique tout. Pour corriger en masse des questions déjà en banque, corrigez à la source puis supprimez/réimportez avant toute utilisation dans des tentatives, ou éditez dans Moodle (ce qui crée proprement des versions v2).

📚 Aller plus loin : docs.moodle.org/fr → « Format GIFT », « Format XML Moodle », « Importer des questions » ; la grammaire GIFT exhaustive (options [html], [markdown], réponses numériques par intervalle =1..5) y est documentée.

7. Statistiques et amélioration continue

Un quiz passé n’est pas une fin : c’est un jeu de données. Moodle fournit trois rapports (page du quiz → onglet « Résultats ») et un mécanisme de re-notation.

7.1 Le rapport « Notes » (Grades)

La table de toutes les tentatives : étudiant, état, dates, durée, note globale et note par question (cliquables pour ouvrir la copie). Filtres par groupe et par état, re-notation en masse, suppression de tentatives, export (Excel/CSV/ODS) et graphique de distribution des notes. C’est aussi ici que vous repérez les tentatives « En cours » abandonnées et que vous les clôturez au besoin.

7.2 Le rapport « Réponses détaillées » (Responses)

Même structure, mais affiche le texte des réponses données question par question. Indispensable pour les réponses courtes/numériques : vous y découvrez les variantes légitimes non prévues (« mitose » vs « la mitose ») qui justifient d’ajouter une réponse acceptée puis de re-noter.

7.3 Le rapport « Statistiques » : la psychométrie

Le rapport Statistiques calcule, pour le quiz entier et pour chaque question, des indicateurs psychométriques. Les trois à savoir lire :

Le rapport donne aussi, pour le test entier, un coefficient de cohérence interne (de type alpha de Cronbach) et, par question, la fréquence de chaque réponse — de quoi identifier les distracteurs jamais choisis (donc inutiles) d’un QCM. Depuis 4.0, rappelons-le, facilité et discrimination remontent aussi comme colonnes dans la banque de questions, agrégées sur les usages : l’amélioration continue ne se fait plus quiz par quiz mais à l’échelle du référentiel, avec le signalement « besoin de vérification » pour prioriser.

Le circuit vertueux complet : statistiques → question suspecte identifiée → discussion en commentaires de la question → correction (nouvelle version, statut Prêt après relecture) → re-notation des tentatives impactées.

7.4 Re-noter après correction d’une question

Cas vécu : après l’examen, vous découvrez qu’un QCM avait la mauvaise réponse marquée correcte, ou qu’une réponse courte légitime manquait. Procédure :

1. Corrigez la question dans la banque (nouvelle version) — ou, pour certains cas, modifiez la note de la question dans le quiz.
2. Dans le rapport Notes, sélectionnez les tentatives (ou toutes) et lancez « Tout re-noter » (Regrade all) — ou « Re-noter à sec » (dry run) d’abord, qui simule et affiche les notes qui changeraient sans rien enregistrer.
3. Vérifiez les écarts affichés (anciennes notes barrées), puis confirmez la re-notation réelle. Les notes recalculées se propagent au carnet de notes.

C’est l’architecture du question engine (historique complet des étapes de chaque tentative de question — l’event sourcing évoqué en section 2.4) qui rend ce recalcul possible et fiable : Moodle rejoue les réponses enregistrées contre la définition corrigée.

⚠️ Piège : la re-notation utilise la version de la question que la tentative référence, selon la politique de version de l’emplacement. Selon votre cas (emplacement en « toujours la dernière » ou épinglé), assurez-vous que la tentative sera bien rejouée contre la version corrigée — le mode « dry run » est là pour le vérifier sans risque avant d’écrire quoi que ce soit. Et communiquez aux étudiants tout changement de note post-publication : techniquement trivial, humainement sensible.

📚 Aller plus loin : docs.moodle.org/fr → « Statistiques du test » pour les formules exactes des indices ; moodledev.io documente le calcul dans le module quiz_statistics.

8. Checklist : mettre en place un examen sécurisé

Synthèse opérationnelle du chapitre, à dérouler avant tout examen à enjeu :

La banque (en amont)

• Questions organisées en catégories homogènes par objectif et difficulté (tirages aléatoires équitables).
• Toutes les questions du sujet en statut Prêt, relues par un pair (commentaires), prévisualisées une à une.
• Pour les questions à réponse construite (courte, numérique) : variantes et tolérances testées.
• Versions épinglées dans le quiz si le sujet est validé et gelé.

Les réglages du quiz

• Dates d’ouverture et de fermeture posées ; limite de temps cohérente avec la fenêtre (fenêtre ≥ limite + marge).
• Dépassement : « la tentative est envoyée automatiquement ».
• Tentatives : 1 ; comportement : feedback a posteriori (deferred).
• Une question par page (autosave à chaque navigation) ; navigation libre sauf contrainte explicite.
• Options de relecture : rien pendant/immédiatement/plus tard (sauf éventuellement « Points ») ; correction complète uniquement après la fermeture.
• Mélange des questions (ou sections mélangées) + mélange des éléments + questions aléatoires si le stock le permet.
• Note pour passer renseignée ; catégorie de carnet de notes correcte.

La sécurisation

• Mot de passe de quiz (communiqué en salle au démarrage) et/ou restriction IP si le réseau le permet.
• Safe Exam Browser configuré et testé sur les postes réels (jamais la veille au soir).
• Dérogations créées : groupe tiers temps (durée majorée), rattrapages individuels.
• Ne pas compter sur la seule « sécurité du navigateur » popup — cosmétique.

Les répétitions générales

• Aperçu enseignant complet du quiz ; idéalement une tentative de bout en bout avec un compte étudiant de test.
• Quiz blanc proposé aux étudiants la semaine précédente (mêmes réglages, contenu anodin) : matériel, SEB et procédure validés côté étudiants.
• Plan B écrit : que faire en cas de panne (dérogation de prolongation, réouverture ciblée, contact support).

L’après

• Correction manuelle des essais avant publication des notes.
• Rapport Statistiques : traquer facilité extrême et discrimination négative ; corriger et re-noter (dry run d’abord).
• Alimenter la banque : commentaires sur les questions à revoir, tags mis à jour, questions défectueuses repassées en Brouillon.

Transition vers le chapitre 5

Vous savez désormais construire l’évaluation automatisée : des questions versionnées et partagées dans des banques dignes d’un registre de packages, assemblées en quiz dont vous maîtrisez chaque réglage — comportements, relecture, sécurisation — et dont vous exploitez les statistiques pour vous améliorer d’une session à l’autre.

Mais tout n’est pas automatisable. Dissertations, projets, rendus de code, productions créatives : l’évaluation de travaux complexes exige la remise de fichiers, des workflows de correction, des grilles critériées (rubrics), l’anonymisation des copies, voire l’évaluation par les pairs. C’est le territoire du chapitre 5 : l’activité Devoir (Assignment) et les autres activités d’évaluation — là où l’humain reprend la main sur la notation, avec Moodle en assistant méthodique.