Chapitre 2 — Les ressources : transmettre du contenu dans Moodle

Introduction : ressources, activités et le sélecteur d’activités

Dans Moodle, tout ce que vous ajoutez à un cours appartient à l’une de deux grandes familles : les ressources (resources) et les activités (activities). La distinction est simple mais fondamentale, et elle structure toute la suite de cette partie.

Une ressource est un contenu que l’étudiant consulte : un fichier PDF, une page web rédigée dans Moodle, un dossier de documents, un lien vers un site externe, un livre structuré en chapitres. Le flux d’information est unidirectionnel, de l’enseignant vers l’apprenant. Moodle peut tout au plus enregistrer que l’étudiant a « vu » la ressource — via le suivi d’achèvement (completion tracking), que nous verrons au chapitre 4 — mais il n’y a ni production de l’étudiant, ni interaction évaluée, ni note.

Une activité est au contraire un module avec lequel l’étudiant interagit et qui, le plus souvent, produit des données : un devoir (assignment) où il dépose un travail, un test (quiz) qui génère une note, un forum où il écrit, un glossaire qu’il alimente, un atelier où il évalue ses pairs. Les activités sont le cœur pédagogique de Moodle et font l’objet du chapitre 3.

Techniquement, ressources et activités sont pourtant implémentées de la même manière : ce sont toutes des modules d’activité (activity modules), c’est-à-dire des plugins de type mod vivant dans le répertoire mod/ du code source de Moodle (mod/resource, mod/page, mod/book, mod/quiz, mod/forum…). La séparation « ressource / activité » est avant tout une convention d’interface destinée aux enseignants ; chaque module déclare lui-même à quelle famille il appartient (via sa fonction de support d’archétype MOD_ARCHETYPE_RESOURCE). C’est une nuance importante pour vous : quand vous développerez ou étudierez un plugin, vous ne trouverez pas deux API distinctes, mais une seule API de modules.

Le sélecteur d’activités depuis Moodle 4.0

Depuis Moodle 4.0, cette convention s’exprime dans le sélecteur d’activités (activity chooser), la boîte de dialogue qui s’ouvre via le chemin que vous emprunterez des centaines de fois :

Cours → Mode d’édition → Ajouter une activité ou ressource

Le sélecteur d’activités a été entièrement repensé dans Moodle 4.0 et propose depuis :

• des onglets de filtrage : Tout, Activités, Ressources, ainsi qu’un onglet Favoris (starred) et un onglet Recommandées ;
• un système de favoris : chaque enseignant peut « étoiler » les modules qu’il utilise le plus souvent (l’étoile en haut à droite de chaque carte), qui apparaissent alors regroupés dans l’onglet Favoris. C’est un réglage strictement personnel, propre à chaque utilisateur ;
• des recommandations : l’administrateur du site peut marquer certains modules comme « recommandés » (Administration du site → Cours → Sélecteur d’activités → Activités recommandées). C’est très utile dans un établissement pour orienter les enseignants vers les outils validés et maintenus par l’équipe pédagogique, sans pour autant désactiver les autres ;
• un champ de recherche en texte libre, qui filtre les cartes en direct ;
• une description contextuelle pour chaque module (icône « i » sur la carte), avec un lien vers la documentation officielle de Moodle.

L’administrateur contrôle également quels modules apparaissent (un module désactivé au niveau du site disparaît du sélecteur) et peut définir un état par défaut du sélecteur. Notez enfin que certains éléments visibles dans le sélecteur ne sont pas des modules à proprement parler : les sous-sections (introduites dans Moodle 4.5 comme un format délégué) y apparaissent par exemple comme un moyen de structurer le cours.

💡 Pour un dev React : pensez au sélecteur d’activités comme à une command palette (le Cmd+K de VS Code ou de Linear) avec onglets de filtrage, recherche fuzzy et favoris persistés par utilisateur. Et pensez à la dualité ressource/activité comme à la différence entre une page statique générée (SSG : contenu en lecture seule) et une route applicative avec formulaires, mutations et état serveur. Les deux sont des « pages » de votre application ; l’une affiche, l’autre interagit.

Ce que couvre ce chapitre

Ce chapitre couvre l’intégralité des ressources standard de Moodle 5.2 :

1. les réglages communs à tous les modules ;
2. le Fichier (File) — avec un détour technique par la File API et le stockage par hachage ;
3. le Dossier (Folder) ;
4. la Page ;
5. le Livre (Book) ;
6. l’URL ;
7. la Zone texte et média (Text and media area, l’ancienne Étiquette) ;
8. le paquetage IMS Content Package, format hérité.

Nous y ajoutons deux briques transversales sans lesquelles on ne comprend rien à la gestion de contenu dans Moodle :

9. l’éditeur TinyMCE, éditeur par défaut depuis 4.5 ;
10. les filtres de contenu (filters), le pipeline de transformation du HTML à l’affichage ;
11. les bonnes pratiques d’intégration des médias ;
12. et une synthèse éditoriale de fin de chapitre.

1. Ressource ou activité : quand utiliser quoi, et les réglages communs

1.1 Le bon réflexe : qu’attendez-vous de l’étudiant ?

Avant d’ajouter quoi que ce soit à un cours, posez-vous une seule question : est-ce que j’attends quelque chose de l’étudiant ? Si la réponse est « rien, il doit consulter », c’est une ressource. Si la réponse est « il doit produire, répondre, discuter, s’entraîner », c’est une activité.

Deux erreurs symétriques guettent le débutant :

• Sous-utiliser les activités : déposer un PDF de consignes puis demander l’envoi des travaux par e-mail, alors qu’une activité Devoir centralise dépôts, dates limites, détection de retard, notes et feedback. Dès qu’il y a production étudiante, il existe une activité pour la recevoir.
• Sur-dimensionner : créer une Leçon à embranchements ou un Livre de quarante chapitres quand une simple Page de deux écrans aurait suffi. La ressource la plus simple qui remplit le besoin est toujours la bonne.

1.2 Les réglages communs à tous les modules

Quel que soit le module ajouté — ressource ou activité — le formulaire de création partage un socle de réglages. Les connaître une fois pour toutes vous évitera de les redécouvrir à chaque module, et vous comprendrez mieux les chapitres suivants.

Nom

Champ obligatoire : c’est le texte du lien affiché sur la page de cours. Soignez-le, car il apparaît aussi dans :

• le fil d’Ariane et l’index de cours (le panneau latéral de navigation introduit en Moodle 4.0) ;
• les notifications et le calendrier ;
• les rapports d’activité et le carnet de notes ;
• la recherche globale.

Un nom comme doc1_final_v2.pdf est une faute éditoriale. Préférez « Chapitre 2 — Support de cours (PDF, 24 p.) ». Nous reviendrons sur les conventions de nommage en fin de chapitre.

Description

Un champ HTML libre, édité avec TinyMCE (section 9). Selon le module, la description sert de résumé, de consigne, de mise en contexte. Pour certaines activités (Devoir, Test), elle contient carrément l’énoncé.

Afficher la description sur la page de cours

Une case à cocher. Si elle est activée, la description s’affiche directement sous le lien de la ressource sur la page du cours, sans clic. C’est pratique pour une consigne courte : « À lire avant la séance du 15 mars ». Mais ne l’activez pas systématiquement : une page de cours où chaque élément déploie trois paragraphes devient un mur de texte illisible, en particulier sur mobile.

Disponibilité (Availability)

Le menu Disponibilité propose trois états :

• Afficher sur la page de cours : visible et cliquable — le cas normal ;
• Cacher sur la page de cours : invisible pour les étudiants ; l’enseignant la voit grisée avec la mention « Caché pour les étudiants ». Indispensable pour préparer du contenu à l’avance ou retirer temporairement un document erroné sans le supprimer ;
• Rendre disponible mais invisible sur la page de cours (stealth activity, « activité furtive ») : la ressource n’apparaît pas dans le flux du cours, mais reste accessible par son URL directe. Cas d’usage : une page annexe que vous liez manuellement depuis une autre ressource, sans encombrer la page de cours. Cette troisième option n’apparaît que si l’administrateur l’a autorisée (réglage allowstealth).

À cette visibilité s’ajoute la section Restreindre l’accès (Restrict access), qui conditionne l’accès à des règles combinables : date d’ouverture/fermeture, note obtenue ailleurs, appartenance à un groupe ou groupement, champ de profil, achèvement d’une autre activité. La logique conditionnelle complète (opérateurs ET/OU, conditions imbriquées, masquage total ou grisé) est traitée au chapitre 4 ; retenez à ce stade que toute ressource peut être conditionnée, ce qui permet des parcours progressifs.

Apparence (Appearance)

Section variable selon le module : options d’affichage d’un Fichier, dimensions de fenêtre surgissante d’une URL, formatage des chapitres d’un Livre. Nous détaillons ces options module par module dans les sections suivantes.

Réglages courants (Common module settings)

• Visibilité (redondante avec Disponibilité selon les versions et thèmes) ;
• Numéro d’identification (ID number) : un identifiant libre utilisé par le calcul de notes et les rapports personnalisés — laissez-le vide sauf besoin précis ;
• Mode de groupe et groupement : pertinents surtout pour les activités (un forum par groupe, par exemple), mais présents partout.

Marques et compétences

• Marques (Tags) : étiquettes transversales de site, utiles pour la recherche et les corrélations de contenus ;
• Compétences (Competencies) : liaison de la ressource à un référentiel de compétences, avec action déclenchée à l’achèvement (nous y reviendrons au chapitre 4).

💡 Pour un dev React : ce socle de réglages communs est l’équivalent d’une interface TypeScript de base que tous les modules étendent — quelque chose comme interface CourseModuleSettings { name: string; intro: string; showdescription: boolean; visible: 0 | 1; availability: AvailabilityTree | null; idnumber?: string; } — chaque module ajoutant ensuite ses propres props. Côté base de données, c’est exactement ça : une table générique mdl_course_modules (le « wrapper » commun : visibilité, section, restrictions) pointe vers une table spécifique par module (mdl_resource, mdl_page, mdl_book…) qui porte les champs métier. Une jointure, deux niveaux de responsabilité.

⚠️ Piège : « caché » n’est pas « inaccessible pour toujours ». Une ressource cachée puis rendue visible conserve son historique ; une ressource supprimée part dans la corbeille du cours (recycle bin), d’où elle peut être restaurée pendant un délai configurable (7 jours par défaut). Avant de supprimer pour « faire le ménage », demandez-vous si cacher ne suffit pas — la suppression casse les liens directs que d’autres ressources pouvaient pointer.

📚 Aller plus loin : la page « Réglages communs à tous les modules » sur docs.moodle.org/fr  détaille chaque champ ; côté développeur, la structure course_modules et l’API des activités sont documentées sur moodledev.io  (« Activity modules »).

2. La ressource Fichier (File)

La ressource Fichier (module mod_resource, historiquement le tout premier moyen de diffuser du contenu dans Moodle) met un fichier à disposition des étudiants : PDF, présentation, image, feuille de calcul, archive, voire une mini-application HTML complète. C’est la ressource la plus utilisée — et la plus mal utilisée, comme nous le verrons en fin de chapitre.

2.1 L’ajout par glisser-déposer

Le moyen le plus rapide de créer une ressource Fichier ne passe même pas par le sélecteur d’activités. En mode édition, glissez-déposez simplement un fichier depuis votre explorateur de fichiers directement sur la section voulue de la page de cours : une zone de dépôt en pointillés apparaît, et Moodle crée automatiquement une ressource Fichier portant le nom du fichier (que vous devriez immédiatement renommer via l’édition rapide du titre).

Subtilité intéressante : le glisser-déposer est contextuel selon le type de fichier. Moodle vous demande quoi faire selon ce que vous déposez :

C’est un vrai gain de temps au quotidien, mais avec une réserve importante.

⚠️ Piège : le glisser-déposer crée la ressource avec les réglages par défaut du site (mode d’affichage, visibilité, métadonnées affichées). Sur un site mal configuré, cela peut signifier « forcer le téléchargement » pour des PDF que vous vouliez afficher dans le navigateur, ou un nom de ressource égal au nom de fichier technique. Prenez l’habitude de passer par Modifier les réglages après un dépôt rapide pour vérifier au minimum le nom et le mode d’affichage.

2.2 Les options d’affichage

Dans la section Apparence du formulaire, le réglage Affichage (Display) contrôle ce qui se passe quand l’étudiant clique. Les options proposées dépendent du type de fichier et de la configuration du site (Administration du site → Plugins → Modules d’activité → Fichier, où l’administrateur choisit les options disponibles et la valeur par défaut) :

Deux options supplémentaires peuvent être activées par l’administrateur mais sont déconseillées : Dans un cadre (frame, un héritage des framesets HTML des années 2000) et Nouvelle fenêtre.

Trois cases à cocher complètent la section Apparence :

• Afficher la taille ;
• Afficher le type (PDF, document Word…) ;
• Afficher la date de téléversement/modification.

Ces métadonnées s’affichent à côté du lien sur la page de cours et rendent un vrai service à l’étudiant : « est-ce que ce PDF de 45 Mo passe sur ma connexion mobile ? », « le sujet a-t-il été mis à jour depuis la semaine dernière ? ». Activez au minimum la taille et la date : c’est une bonne pratique quasi systématique, et l’administrateur peut en faire le défaut du site.

2.3 Types de fichiers et embeds : PDF, images, HTML avec fichiers liés

Le rendu incorporé dépend du type MIME du fichier :

• PDF : affiché via le lecteur PDF natif du navigateur, dans un cadre à l’intérieur de la page Moodle. Fiable sur desktop ; sur mobile, certains navigateurs forcent le téléchargement au lieu d’afficher, d’où l’intérêt de l’application mobile Moodle qui gère les PDF nativement.
• Images (PNG, JPEG, GIF, SVG, WebP…) : affichées directement dans la page.
• Audio et vidéo (MP3, MP4, WebM, OGG…) : rendus via le lecteur multimédia du site — VideoJS par défaut, voir la section 10 sur les filtres — avec contrôles, réglage de vitesse et sous-titres éventuels.
• HTML : le cas le plus intéressant pour un développeur web, détaillé ci-dessous.

Une ressource Fichier peut en effet contenir plusieurs fichiers. Le scénario type : vous téléversez un index.html accompagné de ses feuilles de style, scripts et images dans la même zone de fichiers (en respectant l’arborescence, par exemple via un ZIP décompressé sur place), puis vous marquez index.html comme fichier principal (menu contextuel du fichier → « Fichier principal » ; il apparaît alors en gras). Moodle sert l’ensemble en résolvant les chemins relatifs : ./assets/style.css fonctionne, car toute la zone de fichiers est servie sous une même URL de base (pluginfile.php/<contextid>/mod_resource/content/<revision>/...).

Vous pouvez ainsi déposer comme simple ressource :

• une visualisation interactive (D3.js, Chart.js) exportée en statique ;
• un export HTML d’un outil auteur ou d’un notebook ;
• un mini-site généré (build Vite, export statique) ;
• une animation pédagogique HTML5.

💡 Pour un dev React : une ressource Fichier multi-fichiers avec index.html principal, c’est votre build statique (vite build, export statique Next.js) déposé tel quel dans le LMS. Deux réserves toutefois : le JavaScript s’exécute dans le domaine de Moodle (pas d’appels API cross-origin sans configuration côté API), et un HTML téléversé par un utilisateur est un vecteur XSS classique — c’est pourquoi certaines politiques de site restreignent qui peut déposer du HTML exécutable, et pourquoi certains sites servent les fichiers utilisateurs depuis un domaine séparé (bonne pratique d’administration que nous recroiserons en partie 6).

2.4 Zones de fichiers (file areas) et sélecteur de fichiers (file picker)

Quand vous cliquez sur « Ajouter un fichier » dans n’importe quel formulaire Moodle, vous n’uploadez pas « dans un dossier du serveur » : vous placez un fichier dans une zone de fichiers (file area). C’est un concept central de toute la plateforme.

Une zone de fichiers est identifiée par un quadruplet :

1. un contexte (context) : le module, le cours, l’utilisateur, le site… ;
2. un composant (component) : le plugin propriétaire (mod_resource, mod_folder, user, course…) ;
3. un nom de zone (file area) : content, intro, attachment, draft, private… ;
4. un identifiant d’élément (item id) : pour distinguer plusieurs instances dans la même zone.

Chaque champ « fichier » de chaque formulaire correspond à une zone précise. Pendant l’édition d’un formulaire, les fichiers vivent d’abord dans une zone brouillon (draft) propre à l’utilisateur ; ils ne sont déplacés vers la zone définitive qu’à l’enregistrement du formulaire. C’est pourquoi fermer un formulaire sans enregistrer ne laisse pas de fichiers orphelins dans le module — les brouillons abandonnés sont purgés par une tâche planifiée.

L’interface universelle d’ajout est le sélecteur de fichiers (file picker), la boîte de dialogue qui liste dans sa colonne de gauche des dépôts (repositories) — des sources de fichiers pluggables :

Pour certains dépôts, le sélecteur propose trois modes d’intégration :

• Faire une copie du fichier : Moodle stocke sa propre copie, indépendante de la source. Le plus sûr.
• Créer un alias/raccourci : le fichier reste dans le dépôt source, Moodle le référence ; les mises à jour côté source sont répercutées à la consultation. Puissant (un seul original à maintenir) mais fragile : si le fichier source disparaît ou si le compte lié est fermé, la ressource casse.
• Lien d’accès contrôlé (cas Nextcloud, Google Drive selon configuration) : Moodle gère les droits d’accès au document distant.

Enfin, chaque zone de fichiers impose ses contraintes : nombre maximal de fichiers, taille maximale et types de fichiers acceptés. La taille maximale d’upload est plafonnée en cascade : configuration PHP (upload_max_filesize, post_max_size) → limite du site → limite du cours → limite de l’activité. Quand un enseignant se plaint de ne pas pouvoir déposer un fichier, la réponse est presque toujours dans cette cascade.

2.5 Sous le capot : déduplication par hachage SHA1 dans moodledata

C’est ici que Moodle devient réellement intéressant pour un développeur. Depuis Moodle 2.0, les fichiers ne sont pas stockés sous leur nom dans une arborescence de dossiers qui refléterait les cours. La File API fonctionne comme un stockage adressé par contenu (content-addressable storage) :

1. À l’upload, Moodle calcule le hachage SHA1 du contenu binaire du fichier : c’est le contenthash.
2. Le contenu est écrit une seule fois dans le répertoire de données moodledata/filedir/, dans un chemin dérivé du hash. Un fichier dont le SHA1 est d0b2f2bd... est stocké dans :

moodledata/filedir/d0/b2/d0b2f2bd6c17e6a67b18b91b0ba7a34412de708f

Les deux premiers octets du hash servent de sous-dossiers à deux niveaux, pour éviter des répertoires contenant des millions d’entrées (une limite classique des systèmes de fichiers).

3. Les métadonnées — nom de fichier d’origine, chemin logique, zone de fichiers (le quadruplet de la section 2.4), auteur, licence, date, taille, type MIME — sont enregistrées dans la table mdl_files, avec une ligne par référence au fichier.

Les conséquences pratiques sont nombreuses et toutes importantes :

• Déduplication native. Si trente enseignants téléversent le même PDF de 50 Mo dans trente cours différents, le disque ne stocke le contenu qu’une seule fois ; il y a simplement trente lignes dans mdl_files pointant vers le même contenthash. Idem quand un cours est dupliqué ou restauré sur le même site : les fichiers ne sont pas copiés physiquement.
• Suppression différée. Le contenu physique n’est supprimé que lorsque plus aucune ligne de mdl_files ne le référence, et il transite alors par une corbeille (moodledata/trashdir) purgée par tâche planifiée, avec un délai de grâce.
• Renommage gratuit. Renommer ou déplacer un fichier dans l’interface ne touche pas au binaire : seule la ligne de métadonnées change. Le « nom » d’un fichier n’est qu’une métadonnée.
• Contrôle d’accès systématique. Les URL de fichiers servies aux navigateurs passent par le script pluginfile.php, qui vérifie les permissions à chaque requête : le fichier d’un cours n’est servi qu’aux utilisateurs qui ont le droit de voir la ressource. Il n’existe pas d’URL « publique » directe vers filedir — et le serveur web ne doit jamais exposer moodledata en HTTP (c’est l’une des vérifications de sécurité de base d’une installation).
• Sauvegardes économes. Les sauvegardes de cours référencent les fichiers par hash, ce qui rend les restaurations sur le même site très rapides et légères.

💡 Pour un dev React : c’est exactement le modèle du store d’objets de Git (blobs adressés par SHA1, refs par-dessus) ou d’un stockage objet type S3 avec clés dérivées du contenu. Même bénéfice que le content hashing de vos bundlers (les main.a3f9c2.js de Webpack/Vite) : l’identité d’un fichier est son contenu, donc déduplication gratuite et invalidation triviale. La table mdl_files joue le rôle de la couche « pointeurs » — comme les refs Git au-dessus des blobs. Et pluginfile.php est votre middleware d’autorisation devant le bucket : jamais d’URL signée permanente, une vérification de session et de capacité à chaque hit.

⚠️ Piège : ne modifiez jamais des fichiers directement dans moodledata/filedir, et n’y « rangez » rien à la main. Sans ligne correspondante dans mdl_files, un fichier est invisible pour Moodle ; et un fichier modifié sur disque a un contenu qui ne correspond plus à son hash, ce qui casse l’intégrité du stockage (et les vérifications d’intégrité que certains outils d’administration exécutent). Tout passe par la File API ou par l’interface. De même, la base de données et moodledata doivent toujours être sauvegardés ensemble : l’un sans l’autre est inutilisable.

📚 Aller plus loin : la documentation développeur de la File API sur moodledev.io  (« File API ») explique zones, hachage, brouillons et pluginfile.php en détail — c’est l’une des trois API à lire en priorité quand on aborde le développement Moodle.

3. La ressource Dossier (Folder)

La ressource Dossier (module mod_folder) affiche un ensemble de fichiers — éventuellement organisés en sous-dossiers — derrière une seule entrée de la page de cours. C’est la réponse au problème du « mur de fichiers » : dix ressources Fichier alignées rendent une section illisible, tandis qu’un Dossier « Annales d’examens 2020-2025 » la garde propre et navigable.

3.1 Création et organisation

Après Cours → Mode d’édition → Ajouter une activité ou ressource → Dossier, la zone de fichiers du formulaire vous permet de :

• téléverser des fichiers un par un ou par lot (le glisser-déposer fonctionne dans la zone) ;
• créer des sous-dossiers (icône dossier de la barre d’outils de la zone), sur autant de niveaux que nécessaire ;
• déposer une archive ZIP puis la décompresser sur place (menu contextuel du fichier → Décompacter/Unzip) : toute l’arborescence du ZIP est reproduite d’un coup. C’est le réflexe efficace pour migrer un dossier existant.

Rappelez-vous aussi qu’un ZIP glissé-déposé directement sur la page de cours propose l’option « Décompresser les fichiers et créer un dossier » : deux gestes, un dossier complet.

3.2 Options d’affichage

La section Apparence propose des réglages propres au Dossier :

• Afficher le contenu du dossier :
  • Sur une page séparée : la page de cours n’affiche qu’un lien ; un clic ouvre la page du dossier avec son arborescence. C’est le mode par défaut, et le bon choix dans la majorité des cas ;
  • Incorporé sur la page de cours : l’arborescence est affichée directement dans la section, dépliable sur place. Séduisant, mais cela alourdit visuellement la page de cours — réservez ce mode aux petits dossiers de trois à six fichiers réellement centraux dans le déroulé.
• Afficher les sous-dossiers dépliés : arborescence ouverte ou repliée par défaut à l’arrivée sur la page.
• Afficher le bouton de téléchargement du dossier : ajoute un bouton « Télécharger le dossier » qui génère à la volée un ZIP de l’ensemble. Très apprécié des étudiants avant une période de révision hors ligne ou pour récupérer un squelette de projet. L’administrateur peut plafonner la taille totale au-delà de laquelle ce bouton disparaît — générer un ZIP de plusieurs gigaoctets à chaque clic est coûteux pour le serveur.
• Forcer le téléchargement des fichiers : chaque fichier du dossier se télécharge au clic au lieu de s’afficher dans le navigateur.

3.3 Cas d’usage réels

• Annales et corrigés classés par année ou par session : la structure en sous-dossiers (2024/, 2025/) est naturelle ;
• Ressources complémentaires facultatives (« Pour aller plus loin ») qu’on ne veut pas étaler sur la page de cours ;
• Jeux de données et squelettes de code pour des TP : le bouton ZIP est alors décisif ;
• Documents administratifs : chartes, modèles de rapport, formulaires de stage ;
• Portfolios de références : corpus d’images, d’extraits, de partitions.

⚠️ Piège : le Dossier ne trace l’achèvement qu’au niveau du dossier entier (« l’étudiant a affiché le dossier »), jamais fichier par fichier, et les journaux ne distinguent pas quel fichier a été ouvert dans un dossier incorporé. Si vous avez besoin de savoir précisément quels documents ont été consultés, ou de conditionner la suite du parcours à la lecture d’un document précis, utilisez des ressources Fichier individuelles avec suivi d’achèvement — quitte à les regrouper visuellement dans une sous-section (Moodle 4.5+).

💡 Pour un dev React : le Dossier, c’est le composant « accordéon de fichiers » : une seule entrée dans l’arbre de navigation, un état déplié/replié, et un endpoint de téléchargement en masse qui streame un ZIP généré à la demande — le même pattern que l’export ZIP d’un dépôt GitHub.

4. La ressource Page

La ressource Page (module mod_page) est une page web unique, rédigée dans l’éditeur TinyMCE et rendue par Moodle dans le thème du site. C’est, de très loin, la ressource la plus sous-utilisée par rapport à sa valeur réelle — et celle que vous devriez recommander en priorité aux enseignants que vous accompagnerez.

4.1 Pourquoi une Page plutôt qu’un fichier Word ou PDF ?

Le réflexe historique des enseignants est de rédiger dans Word, d’exporter en PDF et de déposer le fichier. Pour du contenu textuel de quelques écrans, la Page est presque toujours supérieure, et il faut savoir argumenter point par point :

Le PDF conserve deux terrains parfaitement légitimes :

1. les documents à mise en page maîtrisée destinés à l’impression ou à l’archivage : sujets d’examen, conventions, documents officiels ;
2. les documents produits ailleurs qu’il serait absurde de retranscrire (article scientifique, chapitre d’ouvrage sous licence, rapport externe).

Tout le reste — consignes, plans de cours, synthèses, notes de cadrage — gagne à devenir une Page.

4.2 Réglages

Le formulaire de la Page est volontairement minimal :

• Nom et Description (socle commun) ;
• Contenu de la page : le grand champ TinyMCE où tout se joue ;
• section Apparence : afficher ou non le nom de la page en titre et la date de dernière modification sur la page rendue.

Rien de plus : la Page est un contenant neutre, et c’est sa force.

4.3 Cas d’usage réels

• Syllabus : plan et modalités du cours, mis à jour au fil du semestre sans jamais re-téléverser quoi que ce soit — les étudiants consultent toujours la version courante ;
• Consignes détaillées d’un projet, avec liens directs vers l’activité Devoir de dépôt et le Forum de questions ;
• page « Bien démarrer » en tête de cours : présentation de l’enseignant, vidéo d’accueil intégrée, mode d’emploi du cours ;
• contenu de cours court : une notion = une page, quand un Livre serait disproportionné ;
• FAQ, liste de lectures commentée, barème expliqué, calendrier des séances.

💡 Pour un dev React : une Page Moodle, c’est une route de contenu rendue côté serveur dans le layout global — l’équivalent d’un app/syllabus/page.tsx qui ne rend que du contenu éditorial. Le HTML que vous saisissez est stocké en base avec son format (section 9.3), puis traverse au rendu le pipeline des filtres (section 10) : votre « source » est transformée à l’affichage, exactement comme un fichier MDX traverse remark/rehype avant de devenir le HTML final. La source de vérité n’est jamais le rendu.

⚠️ Piège : le copier-coller direct depuis Word vers TinyMCE embarque des styles parasites (<span style="font-family: Calibri; font-size: 11pt">, classes Mso*) qui cassent la cohérence visuelle du thème et le mode sombre. TinyMCE nettoie une partie du balisage à l’import, mais le résultat n’est jamais garanti : vérifiez via l’affichage du code source HTML (< >), ou collez en texte brut puis remettez en forme avec les styles de l’éditeur (Titre 2, Titre 3, listes) plutôt qu’avec des tailles de police manuelles. Règle d’or : dans une Page, la mise en forme est sémantique (des titres, des listes), jamais cosmétique (du gras agrandi coloré).

5. La ressource Livre (Book)

La ressource Livre (module mod_book) est un ensemble de pages HTML organisées en chapitres et sous-chapitres, avec une table des matières et une navigation séquentielle. Quand une Page devient trop longue — au-delà de trois ou quatre écrans de défilement — le Livre prend le relais.

Une caractéristique de conception à connaître d’emblée : le Livre n’accepte qu’un seul niveau d’imbrication. Un chapitre peut avoir des sous-chapitres, mais pas de sous-sous-chapitres. C’est un choix assumé de simplicité : si votre contenu réclame trois niveaux de hiérarchie, c’est le signe qu’il faut le découper en plusieurs Livres (ou repenser le plan).

5.1 Structure, création et navigation

À la création du Livre, la section Apparence vous fait définir :

• le formatage des chapitres (Chapter formatting), qui contrôle le rendu de la table des matières :
  • Aucun : titres bruts, à vous de numéroter dans les titres si besoin ;
  • Nombres : numérotation automatique 1, 1.1, 1.2, 2… ;
  • Puces : liste à puces indentée ;
  • Indentation : simple retrait des sous-chapitres ;
• le style de navigation : flèches (images) ou texte (titres des chapitres précédent/suivant), voire aucune navigation selon la configuration du site ;
• l’option titres personnalisés (custom titles) : si elle est cochée, le titre du chapitre n’est pas affiché automatiquement en haut de la page de contenu, ce qui vous laisse le composer vous-même dans le corps (utile pour des titres longs dans la table des matières et courts dans la page, ou l’inverse).

Une fois le Livre créé, il est vide. Vous ajoutez le premier chapitre — un titre, une case « sous-chapitre » (grisée pour le premier, forcément de premier niveau), un contenu TinyMCE — puis les suivants via les icônes de la table des matières en mode édition : ajouter (+), modifier (engrenage), supprimer, masquer (un chapitre masqué est invisible des étudiants et sa numérotation est recalculée — pratique pour publier progressivement), déplacer (flèches).

Pour le lecteur, la table des matières s’affiche dans un bloc latéral (ou un panneau, selon le thème), et la navigation précédent/suivant borde chaque page. L’étudiant garde ainsi une lecture linéaire et un accès direct à n’importe quel chapitre : le meilleur des deux mondes pour de la documentation.

5.2 Impression et export

Le Livre embarque des outils de livre (book tools), des sous-plugins soumis à permissions, accessibles via le menu du Livre :

• Imprimer le livre / Imprimer ce chapitre (outil booktool_print, activé par défaut) : génère une vue consolidée imprimable — l’intégralité des chapitres à la suite, précédée d’une table des matières — que le navigateur peut imprimer ou « imprimer en PDF ». C’est la réponse standard au besoin « je veux une version hors ligne / papier ».
• Export IMS CP (outil booktool_exportimscp) : exporte le Livre au format IMS Content Package (un ZIP normalisé avec manifeste, voir section 8), théoriquement réimportable dans un autre LMS. L’outil fonctionne, mais son usage est devenu rare ; certains administrateurs le désactivent, donc vérifiez sa disponibilité avant de le promettre à quelqu’un.
• Import de chapitres (outil booktool_importhtml) : le chemin inverse, précieux pour les migrations — vous fournissez un ZIP de fichiers HTML, et chaque fichier (ou chaque dossier, selon l’option) devient un chapitre du Livre. Si vous devez migrer une documentation existante (export d’un wiki, d’un CMS, de fichiers Markdown convertis en HTML), c’est l’outil à connaître.

5.3 Cas d’usage : la documentation structurée

Le Livre excelle pour :

• un polycopié de cours complet, chapitre par chapitre, avec médias intégrés ;
• un guide de procédures ou manuel de TP : une manipulation = un chapitre, captures d’écran à l’appui ;
• un document de référence méthodologique : guide de rédaction du mémoire, normes de citation ;
• la documentation d’un outil utilisé dans le cours (précisément ce que vous lisez en ce moment : ce cours Moodle lui-même serait un excellent Livre).

💡 Pour un dev React : le Livre, c’est votre site Docusaurus ou VitePress embarqué dans le LMS — sidebar auto-générée (la table des matières), navigation précédent/suivant en pied de page, un seul niveau de catégories. Si vous savez structurer une doc en docs/*.md avec un sidebar.js, vous savez structurer un Livre. Et booktool_importhtml, c’est votre pipeline de migration : convertissez vos Markdown en HTML (remark), zippez, importez.

⚠️ Piège : le suivi d’achèvement du Livre porte sur le Livre entier — consultation, ou consultation jusqu’au dernier chapitre selon la condition choisie — jamais chapitre par chapitre. Par ailleurs, les liens profonds vers un chapitre précis utilisent un paramètre chapterid numérique qui change après sauvegarde/restauration du cours : évitez de coder en dur ces liens dans d’autres ressources, ou reliez plutôt vers le Livre lui-même.

📚 Aller plus loin : « Livre » et « Réglages du livre » sur docs.moodle.org/fr  ; la liste des book tools installables (dont des exports PDF tiers) est sur le répertoire de plugins moodle.org.

6. La ressource URL

La ressource URL (module mod_url) crée un lien vers une ressource web externe : site, article, vidéo, application, document hébergé ailleurs. C’est plus qu’un simple <a href> posé dans une zone de texte : la ressource URL apporte une description, des options d’affichage, un suivi de consultation (journaux et achèvement), et — fonctionnalité méconnue — la transmission de paramètres dynamiques.

6.1 Options d’affichage

Comme pour le Fichier, la section Apparence propose :

• Automatique : Moodle choisit ;
• Incorporer (Embed) : le site externe est affiché dans un iframe à l’intérieur d’une page Moodle, avec nom et description autour ;
• Ouvrir : navigation pleine page vers le site, dans le même onglet ;
• Dans une fenêtre surgissante (In pop-up) : nouvelle fenêtre aux dimensions configurables (largeur/hauteur en pixels).

S’y ajoutent, selon la configuration du site, Nouvelle fenêtre et Dans un cadre. Pour un lien externe, « Ouvrir » (ou « Nouvelle fenêtre » quand on veut préserver le contexte Moodle) est presque toujours le bon choix.

⚠️ Piège : le mode Incorporer échoue silencieusement sur une grande partie du web moderne. Beaucoup de sites envoient l’en-tête X-Frame-Options: DENY ou SAMEORIGIN, ou une directive CSP frame-ancestors, qui interdit leur affichage dans un iframe tiers : l’étudiant voit alors un cadre vide ou un message d’erreur du navigateur — et l’enseignant, qui a testé connecté sur son poste, ne comprend pas. Google, la plupart des services authentifiés, de nombreux médias refusent l’embarquement. Testez systématiquement avec un compte étudiant, et repliez-vous sur « Ouvrir » au moindre doute. Par ailleurs, votre Moodle étant en HTTPS (il doit l’être), tout iframe vers une URL http:// sera bloqué par le navigateur comme contenu mixte (mixed content).

6.2 Variables d’URL : transmettre des informations en paramètres GET

La section Variables d’URL (URL variables) du formulaire permet d’ajouter dynamiquement à l’URL des paramètres issus du contexte Moodle. Vous choisissez :

• la donnée à transmettre : champs du profil de l’utilisateur courant (prénom, nom, adresse e-mail, identifiant, institution, ville…), propriétés du cours (nom complet, nom abrégé, identifiant, résumé) ou du site ;
• le nom du paramètre GET sous lequel l’envoyer.

À l’affichage, Moodle construit l’URL finale. Par exemple, avec deux variables (etudiant ← prénom de l’utilisateur, cours ← nom abrégé du cours) :

https://outil-externe.example.com/exercice?etudiant=Marie&cours=INFO101

Cas d’usage raisonnables :

• pré-remplir un formulaire externe (sondage, prise de rendez-vous, inscription à un événement) avec le nom et l’e-mail ;
• passer un code de cours à un outil maison pour contextualiser l’affichage ;
• personnaliser une page d’accueil externe (« Bonjour Marie »).

⚠️ Piège : les variables d’URL transitent en clair dans l’URL — donc dans l’historique du navigateur, les journaux du serveur cible, et potentiellement les en-têtes Referer. Ne transmettez jamais de données sensibles par ce canal. Et surtout, comprenez que rien n’est authentifié : l’étudiant peut trivialement modifier ?etudiant=Marie en ?etudiant=Paul dans sa barre d’adresse. C’est un mécanisme de confort de pré-remplissage, en aucun cas un mécanisme d’identification ou d’autorisation. Si l’outil externe prend des décisions (accès, note, traçage) sur la base de ces paramètres, l’intégration est cassée par conception.

6.3 URL ou Outil externe (LTI) ?

C’est précisément cette absence d’authentification qui distingue la ressource URL de l’activité Outil externe (External tool), fondée sur le standard LTI (Learning Tools Interoperability). LTI — dans sa version moderne 1.3 / LTI Advantage — établit une liaison signée cryptographiquement entre Moodle et l’outil externe : un flux OIDC avec des JWT signés transporte l’identité vérifiée de l’utilisateur, son rôle (étudiant/enseignant), le contexte de cours, et permet à l’outil de renvoyer des notes dans le carnet de notes Moodle et de recevoir des lancements profonds (deep linking).

La règle de décision est simple :

💡 Pour un dev React : variables d’URL = query params non signés, à la ?utm_source= — de la donnée d’ambiance, jamais de la donnée de confiance. LTI = un vrai flux OAuth2/OIDC avec JWT signés et échange de clés, comme une intégration NextAuth avec un identity provider. Vous ne mettriez jamais l’identité d’un utilisateur dans un query param modifiable pour autoriser un accès ; le réflexe est identique ici, et c’est un excellent critère pour auditer les « intégrations » bricolées que vous rencontrerez.

7. Zone texte et média (Text and media area, ex-Étiquette)

La Zone texte et média est la seule « ressource » qui ne crée pas de lien : son contenu s’affiche directement sur la page de cours, entre les autres activités. Historiquement nommée Étiquette (Label), elle a été renommée Text and media area — Zone texte et média en français — dans Moodle 4.3, un renommage purement cosmétique destiné à mieux décrire son usage réel. Le nom interne du module reste label (mod_label), ce qui explique que vous croiserez encore ce terme dans le code source, les URL, les web services et les documentations anciennes.

7.1 Structurer visuellement la page de cours

C’est son usage premier. Depuis la refonte de l’expérience de cours en Moodle 4.0, la page de cours affiche les activités sous forme de cartes épurées, avec l’index de cours en panneau latéral ; la Zone texte et média est ce qui vous permet d’insérer du contexte entre ces cartes :

• un intertitre ou une phrase d’introduction de séquence (« Cette semaine : les requêtes SQL ») ;
• une consigne courte positionnée avant un groupe d’activités (« Faites les lectures ci-dessous avant le test ») ;
• une image de bannière légère en tête de section ;
• un séparateur visuel ou un encadré d’avertissement ;
• un média d’accueil : la vidéo de bienvenue du cours, un lecteur audio de consigne — puisque la zone accepte tout ce que TinyMCE sait produire, filtres multimédia compris ;
• un contenu H5P incorporé directement sur la page (avec modération, voir ci-dessous).

C’est aussi la cible du glisser-déposer d’images et de texte sur la page de cours (section 2.1) : « Ajouter un média sur la page de cours » crée en réalité une Zone texte et média.

7.2 Bonnes pratiques : ne pas en abuser

La Zone texte et média est l’outil le plus détourné de Moodle. L’anti-pattern le plus répandu : la page de cours transformée en document, avec quinze zones contenant chacune trois paragraphes, des images décoratives lourdes et des vidéos en lecture directe. Les conséquences sont concrètes :

• la page de cours devient interminable à faire défiler, surtout sur mobile — or c’est la page la plus consultée du cours ;
• chaque média intégré dans une zone est chargé au chargement de la page de cours, pour tout le monde, à chaque visite : la page rame ;
• l’index de cours et l’application mobile représentent mal les zones verbeuses (une zone n’a pas de « nom » naturel : Moodle en dérive un du début du texte) ;
• les rapports et le suivi deviennent illisibles.

Règles de sobriété éprouvées :

1. une zone = un rôle visuel court : un titre, une consigne d’une ligne, une bannière légère ;
2. tout contenu de plus d’un paragraphe va dans une Page ;
3. toute vidéo de plus d’une minute va derrière un lien (Page ou URL) plutôt qu’en lecture directe sur la page de cours ;
4. avant d’ajouter une étiquette-titre, demandez-vous si la structure native ne suffit pas : depuis Moodle 4.x, chaque section a un nom et un résumé bien mis en valeur, et les sous-sections (Moodle 4.5) offrent un niveau de regroupement supplémentaire. Beaucoup de vieilles habitudes à base d’étiquettes datent d’époques où ces outils n’existaient pas.

💡 Pour un dev React : la page de cours est votre layout ; les activités sont des composants auto-contenus ; la Zone texte et média est le children libre que vous glissez entre deux composants. Comme dans un design system : si vous vous surprenez à tout construire en <div> libres au lieu d’utiliser les composants prévus, c’est un signe d’architecture défaillante — ici, de scénarisation pédagogique défaillante. Et le coût des médias chargés sur la page de cours, c’est votre budget performance : pensez « lazy loading derrière une navigation », pas « tout dans le viewport initial ».

⚠️ Piège : la Zone texte et média a un suivi d’achèvement quasi inutile (elle est « vue » dès que la page de cours s’affiche) et n’apparaît pas comme un élément cliquable. N’y placez donc jamais un contenu dont vous devez vérifier la consultation. Autre écueil : les restrictions d’accès s’y appliquent (on peut cacher une zone à un groupe), mais une zone restreinte en mode « grisé » affiche un pavé de conditions disgracieux au milieu de la page — préférez le masquage complet (l’œil barré dans la restriction).

8. Paquetage IMS Content Package

Le paquetage IMS Content Package (module mod_imscp) affiche un contenu conforme à la norme IMS CP : une archive ZIP contenant des pages HTML et un fichier imsmanifest.xml qui décrit la structure — l’arborescence des items et l’ordre de navigation. À l’ajout, Moodle décompresse le paquet, lit le manifeste et présente le contenu avec un menu de navigation généré automatiquement.

Soyons directs : c’est un format hérité (legacy). IMS CP date du début des années 2000 ; c’était alors le format d’échange standard des outils auteurs et des banques de contenus. Ses limites expliquent sa disparition progressive :

• il ne transporte que du contenu : aucune interactivité normalisée, aucun suivi de progression, aucune remontée de score (contrairement à SCORM, qui est grosso modo « IMS CP + une API JavaScript de suivi ») ;
• son HTML est celui de son époque : rarement responsive, rarement accessible ;
• les outils qui le produisent ne sont pratiquement plus maintenus.

Vous le rencontrerez encore dans trois situations :

1. des banques de contenus institutionnelles anciennes — notamment les contenus universitaires mutualisés produits dans les années 2000-2010 (universités numériques thématiques et projets similaires) ;
2. des exports d’outils auteurs historiques ou de LMS tiers en fin de vie, lors de migrations ;
3. l’export IMS CP du module Livre (section 5.2), utilisé comme format pivot entre plateformes.

Pour tout projet nouveau, préférez les alternatives modernes :

• SCORM (et ses successeurs xAPI/cmi5, via plugins) si vous avez besoin d’un paquet auto-porteur avec suivi — score, complétion, temps passé — produit par un outil auteur du marché (Articulate Storyline, iSpring, Genially export SCORM…). L’activité SCORM est traitée au chapitre 3 ;
• H5P, le standard de facto du contenu interactif dans Moodle — intégré au cœur depuis Moodle 3.9 avec la banque de contenus — traité en détail au chapitre 5 ;
• ou, pour du contenu non interactif, tout simplement des Pages et Livres natifs, qui restent la solution la plus durable, la plus accessible et la plus maintenable.

⚠️ Piège : ne confondez pas trois normes au sigle voisin. IMS Content Package est le module de ressource décrit ici (contenu statique) ; IMS Common Cartridge est un format d’échange de cours complets (importable via la restauration de cours) ; LTI — autrefois « IMS Basic LTI » — est le protocole d’intégration d’outils externes de la section 6.3. Le consortium IMS Global s’appelle d’ailleurs aujourd’hui 1EdTech, ce qui n’aide pas à s’y retrouver dans les documentations d’âges différents.

📚 Aller plus loin : « IMS content package » sur docs.moodle.org/fr  ; pour la comparaison des formats de contenu e-learning (IMS CP, SCORM, xAPI, cmi5, H5P), les pages du chapitre 3 et 5 de ce cours donneront les critères de choix détaillés.

9. L’éditeur TinyMCE

Toutes les zones de texte riche de Moodle — description d’activité, contenu de Page, chapitres de Livre, énoncés et feedbacks de questions, messages de forum — passent par l’éditeur HTML. Le maîtriser, c’est maîtriser 80 % de la production de contenu dans Moodle.

9.1 Un peu d’histoire : d’Atto à TinyMCE

L’histoire de l’éditeur de Moodle éclaire ce que vous verrez sur le terrain :

• de Moodle 2.7 à 4.4, l’éditeur par défaut était Atto, un éditeur développé spécifiquement pour Moodle ;
• Moodle 4.1 a introduit une intégration moderne de TinyMCE 6 (l’éditeur open source largement utilisé dans l’industrie, celui de WordPress classique) en tant qu’option ;
• depuis Moodle 4.5, TinyMCE est l’éditeur par défaut des nouvelles installations, le développement d’Atto étant arrêté ;
• dans la série 5.x, Atto a été retiré du cœur de Moodle (après dépréciation). Sur un Moodle 5.2, vous ne devriez plus le rencontrer, sinon via un plugin tiers non maintenu — à éviter absolument pour un nouveau site.

Un troisième choix minimaliste subsiste dans le cœur : l’éditeur « Zone de texte simple » (plain text), une simple textarea sans mise en forme, appréciée des puristes et utile dans certains contextes techniques (saisie de code, environnements contraints). Chaque utilisateur peut choisir son éditeur dans Préférences → Choix de l’éditeur, et l’administrateur définit l’ordre de priorité au niveau du site.

9.2 Tour des fonctionnalités

La barre d’outils de TinyMCE — configurable par l’administrateur, extensible par plugins — couvre les besoins suivants.

Mise en forme structurée

Styles de paragraphe (Titre 2, Titre 3, paragraphe, citation, préformaté), gras, italique, listes ordonnées et non ordonnées, indentation, exposant/indice, couleurs. Insistons une fois encore : utilisez les styles de titres, pas du texte agrandi en gras. C’est la base de l’accessibilité (navigation par titres au lecteur d’écran), de la cohérence avec le thème Bootstrap 5 du site, et de la robustesse au changement de thème.

Insertion d’images

Trois voies convergent vers le même résultat :

1. le bouton image, qui ouvre le sélecteur de fichiers (section 2.4) avec tous ses dépôts ;
2. le glisser-déposer direct d’une image dans la zone d’édition : l’image est téléversée automatiquement dans la zone de fichiers du champ en cours d’édition ;
3. le copier-coller d’une capture d’écran, téléversée de la même façon.

La boîte de dialogue d’image impose de traiter le texte alternatif : soit vous saisissez une description utile (« Schéma du cycle de l’eau en quatre étapes : évaporation, condensation, précipitation, ruissellement »), soit vous cochez explicitement « Cette image est décorative » (qui produit un alt="" correct). Ce caractère obligatoire est une exigence d’accessibilité (WCAG) : un lecteur d’écran n’a que l’attribut alt pour restituer l’image. Vous réglez également dimensions (en conservant le ratio) et alignement.

Médias vidéo et audio

Le bouton multimédia insère une vidéo ou un audio :

• par URL (YouTube, Vimeo, fichier distant) — sachant que, souvent, coller simplement le lien dans le texte suffit grâce au filtre multimédia (section 10) ;
• par fichier téléversé via le sélecteur de fichiers ;

avec des options : image de vignette (poster), dimensions, lecture automatique (à éviter : hostile à l’utilisateur et souvent bloquée par les navigateurs), boucle, et surtout l’ajout de pistes de sous-titres au format WebVTT — sous-titres, légendes pour sourds et malentendants, descriptions, chapitres, dans plusieurs langues. Fournir des sous-titres n’est pas un luxe : c’est une exigence d’accessibilité et un confort pour tous (consultation sans son dans les transports, non-francophones, révisions rapides).

Enregistrement audio et vidéo (RecordRTC)

Deux boutons — micro et caméra — permettent d’enregistrer directement depuis le navigateur, via l’API WebRTC/MediaRecorder, un message audio ou vidéo, sans aucun logiciel à installer. Les usages pédagogiques sont excellents :

• feedback oral sur un devoir (bien plus riche et rapide qu’un paragraphe écrit) ;
• consigne parlée, question de compréhension orale en langues ;
• réponse orale de l’étudiant dans un devoir ou un forum (l’éditeur est le même pour lui).

La durée maximale d’enregistrement est configurable par l’administrateur, et l’enregistrement produit un fichier ordinaire dans la zone du champ. Selon la configuration du site et la version, un enregistrement d’écran peut également être proposé ; vérifiez la disponibilité sur votre installation avant de bâtir un scénario dessus.

Tableaux

Création de tableaux avec en-têtes de ligne et de colonne (déclarés en <th>, important pour l’accessibilité), fusion et division de cellules, ajout/suppression de lignes et colonnes, styles. Les tableaux reçoivent les classes du thème Bootstrap. Réservez les tableaux aux données tabulaires : un tableau utilisé pour faire de la mise en page à deux colonnes se disloque sur mobile.

Code source HTML

Le bouton < > ouvre le HTML brut du champ — votre meilleur ami de développeur : nettoyer un collage douteux, poser une classe utilitaire Bootstrap (alert alert-info, table-striped), vérifier la structure, insérer un embed précis. Deux réalités à connaître :

• le HTML enregistré est nettoyé côté serveur en fonction des permissions de l’auteur : les balises <script> sont supprimées pour les utilisateurs ordinaires, et seuls les rôles disposant de la capacité de confiance adéquate peuvent enregistrer du HTML non filtré. Ne comptez donc jamais sur du JavaScript inline dans un contenu de cours ;
• le nettoyage dépend de qui enregistre : un même contenu collé par un administrateur et par un étudiant ne survit pas de la même manière.

Vérificateur d’accessibilité

Un bouton d’audit analyse le contenu en cours d’édition et signale : images sans texte alternatif, contrastes insuffisants entre texte et fond, tableaux sans en-têtes, structure de titres incohérente (un Titre 4 sous un Titre 2, par exemple). Prenez l’habitude de le lancer avant d’enregistrer tout contenu substantiel — trente secondes qui changent la vie d’une partie de vos étudiants.

Équations

Le bouton équation ouvre un éditeur qui génère de la notation TeX/LaTeX, avec des palettes de symboles (opérateurs, flèches, lettres grecques, matrices) et un aperçu en direct. Le code produit est inséré entre délimiteurs dans le texte ; le rendu final à l’affichage est assuré par le filtre MathJax (section 10). Les utilisateurs à l’aise avec LaTeX peuvent taper directement :

\( E = mc^2 \)        — équation en ligne
$$ \int_0^1 x^2\,dx = \frac{1}{3} $$   — équation centrée

Emojis, plein écran, et le reste

• un sélecteur d’émojis intégré (et, selon la configuration, le raccourci deux-points suivi du nom) ;
• le mode plein écran, qui agrandit l’éditeur à toute la fenêtre — indispensable pour rédiger une Page ou un chapitre de Livre confortablement ;
• recherche/remplacement, insertion de caractères spéciaux, de liens (avec ouverture dans un nouvel onglet), de dates, annuler/rétablir, compteur de mots.

9.3 L’autosave

TinyMCE sauvegarde automatiquement des brouillons en arrière-plan, à intervalle régulier (de l’ordre de la minute par défaut ; l’administrateur règle la fréquence et la durée de rétention). Si votre session expire, que le navigateur plante ou que vous fermez l’onglet par mégarde, le contenu est restauré à la réouverture du même formulaire, avec un message signalant la récupération d’un brouillon plus récent que le contenu enregistré.

Deux limites à bien comprendre :

• l’autosave protège le texte des champs riches, pas les autres réglages du formulaire (dates, menus, cases à cocher) : enregistrez régulièrement les formulaires longs ;
• les brouillons sont purgés après un délai : ne comptez pas retrouver un brouillon des semaines plus tard.

9.4 Les formats de contenu

Chaque champ de texte de Moodle est stocké en base avec un format qui indique comment l’interpréter au rendu :

En pratique, avec TinyMCE vous produisez toujours du FORMAT_HTML. Le Markdown intéresse surtout les utilisateurs de l’éditeur simple et les intégrations programmatiques : si vous alimentez Moodle par web services (nous le ferons dans la partie développement), vous fournirez systématiquement le couple (text, format) — et vous comprendrez alors pourquoi ce couple existe.

💡 Pour un dev React : TinyMCE dans Moodle, c’est un éditeur riche contrôlé (comme TipTap ou Slate dans vos applications) dont la sortie est sanitizée côté serveur selon le rôle de l’auteur, puis passée dans un pipeline de transformation au rendu. Le couple (content, contentformat) stocké en base est l’équivalent d’un champ { raw: string; format: 'html' | 'markdown' | 'plain' } : la source de vérité n’est pas le rendu final. Quant à l’autosave, c’est un debounce + POST vers un endpoint de brouillon avec restauration au montage — rien d’exotique, mais salvateur.

⚠️ Piège : ne collez jamais un <iframe> ou un code d’intégration en supposant qu’il s’exécutera pour tous les rôles : le nettoyage HTML dépend des permissions de celui qui enregistre, et certains embeds sont réécrits ou supprimés silencieusement. Testez toujours le rendu avec un compte étudiant (le sélecteur de rôle « Prendre le rôle… » est votre ami). Sur les sites migrés, un contenu créé jadis sous Atto peut par ailleurs contenir des classes CSS spécifiques au rendu légèrement différent sous les thèmes récents.

📚 Aller plus loin : « Éditeur TinyMCE » sur docs.moodle.org/fr  pour l’usage ; sur moodledev.io , la page « TinyMCE plugins » montre comment développer vos propres boutons — un plugin TinyMCE Moodle est un module JavaScript (AMD/ESM) plus une couche PHP de déclaration, projet très abordable pour vous.

10. Les filtres de contenu (filters)

Voici le concept le plus « développeur » de ce chapitre, et l’un des mécanismes les plus puissants et les plus méconnus de Moodle : les filtres (filters). Un filtre est un plugin qui transforme le HTML au moment de l’affichage, sans jamais modifier le contenu stocké en base. Chaque fois que Moodle rend un texte — contenu de Page, description d’activité, message de forum, énoncé de question, chapitre de Livre — ce texte traverse la chaîne des filtres activés, dans l’ordre, chacun réécrivant le HTML qu’il reçoit du précédent.

Ce découplage source/rendu a une conséquence capitale : un même contenu peut s’afficher différemment selon l’utilisateur (sa langue), le contexte (les filtres actifs dans ce cours) et la configuration du site — sans qu’aucune donnée ne change en base.

💡 Pour un dev React : c’est très exactement un pipeline unified/remark/rehype : une source stockée (votre « MDX »), une suite de plugins de transformation ordonnés, un HTML final rendu — la source restant intacte. Autre analogie : une chaîne de middlewares sur la réponse. Et le corollaire est identique à vos pipelines : l’ordre des plugins compte, un plugin mal placé consomme ou casse le travail du suivant, et le débogage consiste à examiner la sortie étape par étape.

10.1 Les filtres importants

Plugins multimédia (filter_mediaplugin)

Le filtre-vedette. Il détecte dans le HTML les liens vers des médias — fichier .mp4, .mp3, .webm, lien YouTube ou Vimeo… — et les remplace par un lecteur intégré. Le rendu est délégué aux media players configurés sur le site (Administration du site → Plugins → Lecteurs multimédia) :

• VideoJS : le lecteur HTML5 par défaut, qui gère vidéo et audio, les sous-titres WebVTT, la vitesse de lecture, le plein écran ;
• le lecteur YouTube (embed officiel de la plateforme) et, selon configuration, Vimeo.

Concrètement : l’enseignant colle une URL YouTube dans une Page ou une Zone texte et média, et à l’affichage l’étudiant voit le lecteur, pas le lien. C’est ce filtre qui rend l’intégration vidéo « magique » dans Moodle — et c’est lui qu’il faut suspecter quand « la vidéo ne s’affiche pas ».

MathJax (filter_mathjaxloader) et Notation TeX (filter_tex)

Le filtre MathJax charge la bibliothèque JavaScript MathJax, qui rend côté client la notation mathématique — \( E = mc^2 \), $$ \sum_{n=1}^{\infty} \frac{1}{n^2} $$ — en formules typographiées, accessibles (MathML sous-jacent) et zoomables. Le vieux filtre Notation TeX (rendu en images côté serveur via un binaire LaTeX ou une bibliothèque PHP) subsiste comme solution de repli pour des contextes sans JavaScript ; sur un site 5.2 standard, MathJax fait le travail. Un seul des deux doit traiter une expression donnée — cas d’école de conflit d’ordre de filtres, voir 10.2.

Auto-liaison des noms d’activités (filter_activitynames) et de glossaire (filter_glossary)

Deux filtres cousins :

• Auto-liaison des noms d’activités : toute occurrence textuelle du nom exact d’une activité du cours devient automatiquement un lien vers cette activité. Écrivez « rendez votre travail dans Devoir n°2 — Analyse » et le texte se lie tout seul, sans URL à maintenir ;
• Auto-liaison de glossaire : chaque occurrence d’un terme défini dans un glossaire du cours (dont l’auto-liaison est activée) devient un lien surligné qui ouvre la définition en surimpression.

Pédagogiquement redoutable — chaque texte du cours devient hypertexte vers les définitions — mais parfois envahissant : un glossaire définissant le mot « test » créera des liens partout, y compris dans les énoncés d’examen. Parades : exclure l’auto-liaison entrée par entrée dans le glossaire, ou désactiver le filtre localement (voir 10.2), notamment dans les tests.

Émoticônes (filter_emoticon)

Convertit les émoticônes texte :-) en émojis. Anecdotique, actif par défaut sur beaucoup de sites, première cause de smileys involontaires dans des contenus sérieux (désactivez-le au niveau du cours si cela pose problème).

Contenu multilingue (filter_multilang et filter_multilang2)

Le filtre du cœur Multi-language content affiche, parmi des blocs balisés par langue, celui qui correspond à la langue d’interface de l’utilisateur. Sa syntaxe historique passe par le code source HTML :

<span lang="fr" class="multilang">Bonjour</span><span lang="en" class="multilang">Hello</span>

Il existe par ailleurs un plugin tiers extrêmement répandu, Multi-language content (v2) (filter_multilang2), à la syntaxe bien plus confortable, saisissable directement dans le texte :

{mlang fr}Bonjour à tous{mlang}{mlang en}Hello everyone{mlang}
{mlang other}Texte par défaut{mlang}

Si vous voyez la syntaxe {mlang} dans un cours, c’est ce plugin qui est installé. Pour un site bilingue ou international, c’est l’un des premiers plugins que réclament les équipes ; sachez distinguer les deux syntaxes, vérifier lequel est actif sur votre site, et ne pas mélanger les deux dans un même contenu.

Et les autres

Citons encore : la censure de mots (word censorship), les connecteurs de communication, et des filtres tiers populaires comme FilterCodes (insertion de variables dynamiques {firstname}, {coursename} dans les contenus) ou les filtres d’intégration (GeoGebra, code source coloré…). Le mécanisme est toujours le même : du HTML entre, du HTML transformé sort.

10.2 Activation par site, cours et activité — et ordre des filtres

Les filtres se gèrent à trois niveaux, du global au local :

1. Site : Administration du site → Plugins → Filtres → Gérer les filtres. Chaque filtre y a un état : Désactivé, Activé (partout), ou Désactivé, mais disponible (les contextes locaux peuvent l’activer). C’est ici que se règlent aussi :
   • l’ordre d’application (flèches monter/descendre) — les filtres s’exécutent du haut vers le bas de cette liste ;
   • le périmètre : contenu seulement, ou contenu et titres/en-têtes — appliquer les filtres aux noms d’activités partout a un coût de performance mesurable, la plupart des sites s’en tiennent au contenu.
2. Cours : Cours → menu Plus → Filtres. L’enseignant active ou désactive localement les filtres que l’administrateur a laissés disponibles. Exemple : couper l’auto-liaison de glossaire dans un cours où elle parasite les textes.
3. Activité : le même écran existe au niveau d’une activité précise (menu Plus de l’activité → Filtres). Exemples classiques : désactiver le filtre multimédia dans un test où l’on veut montrer l’URL d’une vidéo et non le lecteur ; couper toute auto-liaison dans un examen.

L’ordre des filtres au niveau site est déterminant, car chaque filtre travaille sur la sortie du précédent. Les frictions classiques :

• le filtre multilingue doit s’exécuter en premier (ou très tôt) : ainsi les filtres suivants ne traitent que le texte de la langue affichée, et pas les variantes cachées ;
• MathJax et TeX ne doivent pas se disputer les mêmes expressions : si les deux sont actifs, l’ordre décide lequel « consomme » la notation ;
• les auto-liaisons viennent plutôt en fin de chaîne, après les filtres qui restructurent le HTML, pour ne pas lier du texte qui va être réécrit.

⚠️ Piège : « ma vidéo s’affichait hier et plus aujourd’hui », « les formules se rendent sur la page du cours mais pas dans le quiz » : ce sont presque toujours des problèmes de filtres — filtre désactivé localement, ordre modifié par un administrateur, ou contexte où le filtrage est réduit. Détail technique utile : Moodle rend les chaînes courtes (titres) via format_string() et les contenus via format_text(), avec des chaînes de filtrage différentes — c’est pourquoi un filtre peut agir dans le corps d’une page mais pas dans son titre. Avant de chercher un bug, remontez la pile des filtres aux trois niveaux.

📚 Aller plus loin : « Filtres » sur docs.moodle.org/fr  pour l’administration ; sur moodledev.io , la Filter API montre qu’écrire un filtre se résume pour l’essentiel à une classe avec une méthode filter($text, array $options) retournant le HTML transformé — l’un des types de plugins les plus simples de Moodle, et un excellent premier projet de développement pour vous.

11. Médias intégrés : bonnes pratiques

11.1 Héberger la vidéo ailleurs, presque toujours

Techniquement, rien n’empêche de téléverser un MP4 de 800 Mo comme ressource Fichier ou dans une Page. C’est presque toujours une mauvaise idée, pour trois raisons cumulatives :

• Le poids de moodledata. Chaque vidéo gonfle le stockage du site, les sauvegardes de cours (qui embarquent les fichiers) et les temps de sauvegarde/restauration. Un site où chaque enseignant dépose ses captations de cours devient ingérable en quelques semestres : c’est la première cause d’explosion du stockage d’un Moodle institutionnel, et le premier chantier de toute politique de site sérieuse.
• Pas de streaming adaptatif. Moodle sert le fichier tel quel — avec la gestion des requêtes de plage HTTP (Range) qui permet de se déplacer dans la vidéo, mais sans transcodage : pas de qualité adaptative selon le débit, pas de résolutions multiples, pas de vignettes de prévisualisation. L’étudiant en mobilité télécharge le fichier en pleine résolution.
• La charge serveur. Cent étudiants qui lancent la vidéo la veille de l’examen, ce sont cent flux servis par votre serveur web et votre pluginfile.php (avec vérification de permissions), pas par un CDN conçu pour cela.

La bonne architecture est claire : héberger la vidéo sur une plateforme dédiée et n’intégrer dans Moodle que le lien ou l’embed :

Réservez l’upload direct dans Moodle aux médias courts : capsules audio de feedback, mini-vidéos d’une minute, enregistrements RecordRTC (section 9.2) — des fichiers de quelques mégaoctets, pas de quelques centaines.

11.2 oEmbed et intégration par URL

Le chemin d’intégration le plus simple reste celui de la section 10.1 : coller l’URL de la vidéo dans TinyMCE (ou créer une ressource URL), et laisser le filtre multimédia la convertir en lecteur. Zéro HTML à écrire, zéro maintenance.

Pour les fournisseurs non couverts par le filtre du cœur, le plugin de filtre tiers oEmbed interroge le protocole oEmbed du fournisseur — le même mécanisme que Notion ou Slack utilisent pour « déplier » un lien collé — et génère l’embed officiel pour des dizaines de services (cartes, présentations, audio, réseaux sociaux). Ce n’est pas un composant standard de Moodle : vérifiez sa présence sur votre site avant de documenter son usage auprès des enseignants.

11.3 Iframes et sécurité

Quand vous collez un code d’intégration <iframe> manuellement — via le code source HTML de TinyMCE — gardez trois règles en tête :

1. HTTPS uniquement. Un iframe http:// dans un Moodle servi en HTTPS est bloqué par le navigateur comme contenu mixte (mixed content), souvent sans message visible pour l’utilisateur. Tous les fournisseurs sérieux servent en HTTPS ; corrigez les vieux codes d’intégration copiés d’archives.
2. X-Frame-Options et CSP frame-ancestors. Le site embarqué doit autoriser son affichage en iframe (déjà vu en 6.1). Utilisez toujours l’URL d’embed officielle du fournisseur (youtube.com/embed/..., player.vimeo.com/video/...), jamais l’URL de la page publique, qui refuse généralement l’embarquement.
3. Confiance et vie privée. Un iframe exécute du contenu tiers dans la page vue par vos étudiants : cookies, traceurs, scripts. Dans l’éducation, le RGPD n’est pas une abstraction — YouTube propose d’ailleurs le domaine youtube-nocookie.com pour limiter le dépôt de cookies avant lecture. Et rappelez-vous (section 9.2) : selon la configuration de nettoyage HTML du site, les iframes posés par des utilisateurs non enseignants peuvent être supprimés à l’enregistrement — c’est un comportement de sécurité voulu, pas un bug.

💡 Pour un dev React : le raisonnement est identique à celui d’une application Next.js bien conçue : vous ne servez pas vos vidéos depuis public/, vous utilisez un service de streaming derrière un CDN ; vous connaissez X-Frame-Options et frame-ancestors pour protéger vos propres pages ; et vous savez qu’un embed tiers, c’est du JavaScript tiers dans votre page avec tout ce que cela implique. Moodle ne change rien à ces fondamentaux du web — il y ajoute seulement sa couche de nettoyage HTML basée sur les rôles.

⚠️ Piège : la vidéo « qui marche chez moi mais pas chez les étudiants » a trois suspects récurrents : un embed testé avec une session ouverte chez le fournisseur (alors que l’étudiant anonyme est bloqué), une vidéo YouTube en visibilité « privée » au lieu de « non répertoriée », ou un iframe supprimé au nettoyage HTML pour le rôle qui a enregistré une copie du contenu. Toujours tester en navigation privée et avec un compte étudiant.

12. Bonnes pratiques éditoriales et synthèse

12.1 Accessibilité : non négociable

L’accessibilité n’est pas une option de confort. Dans l’éducation, c’est une obligation légale (RGAA en France, EN 301 549 en Europe, et les engagements d’accessibilité WCAG que Moodle HQ poursuit pour la plateforme elle-même) et surtout une condition d’équité : un cours inaccessible exclut des étudiants, silencieusement. Les réflexes à ancrer dès maintenant, tous déjà croisés dans ce chapitre :

• texte alternatif sur toute image porteuse de sens, et marquage explicite « décorative » sinon — TinyMCE vous y contraint, ne le contournez pas avec des alt vides de sens (« image1 », « photo ») ;
• structure de titres correcte dans les Pages et Livres : des Titre 2 puis Titre 3 hiérarchisés sans saut de niveau, jamais du gras agrandi — les lecteurs d’écran naviguent par titres ;
• contrastes suffisants : pas de gris clair sur blanc, pas de jaune sur blanc ; laissez le thème gérer les couleurs autant que possible (vos couleurs manuelles casseront aussi le mode sombre) ;
• liens explicites : « Consultez le guide de rédaction du mémoire » plutôt que « cliquez ici » — un lecteur d’écran peut lister les liens hors contexte ;
• sous-titres sur les vidéos, transcription pour l’audio ;
• tableaux avec en-têtes déclarés, réservés aux données tabulaires, jamais à la mise en page ;
• lancez le vérificateur d’accessibilité de TinyMCE avant chaque enregistrement substantiel ;
• et à l’échelle du cours, utilisez la boîte à outils d’accessibilité Brickfield (Brickfield Accessibility Toolkit, intégrée au cœur de Moodle depuis la série 4.x), qui audite l’ensemble des contenus d’un cours et produit un rapport priorisé.

12.2 Nommage cohérent et lisibilité de la page de cours

La page de cours est une interface : traitez-la comme telle.

• Adoptez une convention de nommage et tenez-la sur tout le cours : « Semaine 3 — Cours : Les boucles (vidéo, 12 min) », « TP 2 — Sujet (PDF, 6 p.) ». L’étudiant doit savoir avant de cliquer ce qu’il va ouvrir, sous quel format, et pour quel effort ;
• indiquez la durée ou le volume (pages, minutes) des ressources substantielles ;
• affichez taille et date des Fichiers (section 2.2) ;
• utilisez les descriptions affichées sur la page de cours avec parcimonie : des consignes d’une ligne, pas des paragraphes ;
• appuyez-vous sur la structure native — noms et résumés de sections, sous-sections (4.5+) — avant de recourir aux Zones texte et média ;
• relisez votre page de cours sur mobile : c’est là que la majorité de vos étudiants la verront.

12.3 Éviter le « mur de PDF »

L’anti-pattern ultime du cours Moodle : une page de cours qui n’est qu’une pile de quarante PDF déposés au fil de l’eau, semestre après semestre. C’est l’équivalent pédagogique d’un dossier partagé réseau — Moodle n’y apporte alors strictement aucune valeur. Les remèdes ont tous été vus dans ce chapitre :

1. le contenu textuel court devient des Pages — responsives, cherchables, maintenables ;
2. le contenu long et structuré devient des Livres — navigables et imprimables ;
3. les archives, annales et annexes se rangent dans des Dossiers — une entrée par corpus ;
4. la page de cours est scénarisée : sections nommées, quelques Zones texte et média sobres, un ordre qui raconte le déroulé du cours et pas l’ordre des dépôts ;
5. et surtout, les ressources s’articulent avec des activités (chapitre 3) : on lit pour faire — répondre, produire, s’entraîner — pas pour lire.

12.4 Tableau récapitulatif : quelle ressource pour quel besoin ?

12.5 Vers le chapitre 3 : les activités

Vous savez désormais transmettre du contenu dans Moodle, et vous savez pourquoi chaque brique fonctionne comme elle fonctionne : des fichiers dédupliqués par hachage SHA1 dans la File API, servis sous contrôle de permissions par pluginfile.php ; des Pages et des Livres natifs supérieurs aux documents bureautiques pour tout contenu vivant ; un éditeur TinyMCE qui impose les bons réflexes d’accessibilité ; un pipeline de filtres qui transforme le HTML au rendu sans toucher à la source ; et des médias intégrés sans plomber moodledata ni la sécurité du site.

Mais un cours qui ne fait que transmettre n’est qu’une bibliothèque bien rangée. Le chapitre 3 aborde ce qui fait de Moodle un LMS et non un simple CMS : les activités — le Devoir et ses flux d’évaluation, le Test et la banque de questions, les Forums, l’Atelier d’évaluation par les pairs, la Leçon, SCORM et les Outils externes LTI — c’est-à-dire tout ce que vos étudiants vont produire, et tout ce que Moodle va pouvoir évaluer, tracer et noter.

📚 Aller plus loin : la catégorie « Ressources » de docs.moodle.org/fr  documente un à un chaque module de ce chapitre, avec des captures d’écran de la version courante ; côté moodledev.io , les pages « Activity modules », « File API » et « Filter API » sont les trois lectures qui prolongent directement ce chapitre pour le développeur que vous êtes.