Chapitre 1 — Créer un cours

Bienvenue dans la Partie 3 de cette documentation, consacrée à la création de cours dans Moodle 5.2. Après avoir installé et configuré la plateforme (Partie 1) puis appris à gérer les utilisateurs et les rôles (Partie 2), nous entrons dans le cœur du métier de Moodle : le cours (course). C’est l’unité de travail centrale de la plateforme, l’endroit où enseignants et étudiants se retrouvent, où le contenu pédagogique est publié et où les activités d’apprentissage se déroulent.

Ce premier chapitre couvre tout ce qu’il faut savoir pour créer un cours proprement : les concepts fondamentaux (hiérarchie, contextes, permissions), le formulaire de création dans ses moindres réglages, les formats de cours natifs et tiers, l’interface d’édition moderne introduite avec Moodle 4.0 et affinée jusqu’en 5.2, et enfin les stratégies de réutilisation (duplication, import, sauvegarde/restauration, modèles). Les chapitres suivants de cette partie détailleront les ressources (chapitre 2), les activités (chapitres 3 à 5), les groupes (chapitre 6) et l’évaluation.

💡 Pour un dev React : si vous venez de Next.js, pensez au cours comme à une application déployée sur une plateforme multi-tenant. La catégorie est le dossier de routage, le format de cours est le layout, les sections sont des composants de liste, les activités sont les composants feuilles, et le mode édition transforme la page publiée en interface d’administration — un peu comme le mode « preview/edit » d’un CMS headless (Sanity, Payload, Strapi).

Voici la feuille de route de ce chapitre :

1. Concepts fondamentaux — ce qu’est un cours, la hiérarchie catégories → cours → sections → activités, le contexte de cours, qui a le droit de créer ;
2. Le formulaire de création — chaque réglage passé au crible, section par section ;
3. Les formats de cours natifs — Sections personnalisées, Hebdomadaire, Activité unique, Social, et les sous-sections de Moodle 4.5 ;
4. Les formats tiers — Tiles, Grid, Buttons, Collapsed Topics, et comment évaluer un plugin de format ;
5. L’édition moderne (4.x/5.x) — mode édition, index de cours, cartes d’activité, édition en masse, corbeille ;
6. La réutilisation — duplication, import, sauvegarde/restauration, modèles, création en masse, réinitialisation ;
7. Checklist finale — la procédure complète pour créer proprement, une FAQ et un glossaire.

1. Concepts fondamentaux

1.1 Qu’est-ce qu’un cours dans Moodle ?

Dans Moodle, un cours (course) est un espace en ligne structuré qui rassemble :

• des ressources (resources) : contenus consultables (fichiers, pages, liens, livres…) ;
• des activités (activities) : contenus interactifs (devoirs, tests, forums, wikis…) ;
• des participants : utilisateurs inscrits avec un rôle (enseignant, étudiant, etc.) ;
• des services transverses propres au cours : carnet de notes (gradebook), rapports d’activité, calendrier, banque de questions, groupes, badges, suivi d’achèvement (completion tracking).

Un cours n’est donc pas un simple « dossier de fichiers » : c’est un conteneur riche qui possède son propre cycle de vie (dates de début et de fin), sa propre politique d’inscription (enrolment), ses propres permissions, et son propre affichage (le format de cours).

Point important pour un nouveau venu : tout contenu pédagogique dans Moodle vit dans un cours. Il n’existe pas, nativement, de « bibliothèque globale de contenus » indépendante des cours (la banque de contenu H5P et la banque de questions partagée nuancent un peu cette règle, mais le principe reste vrai). Si vous voulez publier un simple document, il vous faut un cours pour l’héberger.

1.2 La hiérarchie : catégories → cours → sections → activités/ressources

Moodle organise ses contenus selon une hiérarchie stricte à quatre niveaux :

Site
└── Catégorie de cours (course category)          ex. « Informatique »
    └── Sous-catégorie (optionnelle, imbricable)   ex. « Développement web »
        └── Cours (course)                          ex. « JavaScript avancé »
            └── Section (section / topic)           ex. « Semaine 3 : les closures »
                └── Sous-section (depuis 4.5)       ex. « Exercices supplémentaires »
                    └── Activités et ressources     ex. un Test, un fichier PDF

Quelques règles à connaître :

• Les catégories sont créées par les administrateurs (ou gestionnaires) via Administration du site → Cours → Gérer les cours et catégories. Elles peuvent être imbriquées sans limite pratique de profondeur, masquées, réordonnées, et portent leurs propres permissions. Une installation neuve contient une seule catégorie, « Category 1 » (renommez-la immédiatement).
• Un cours appartient à exactement une catégorie. On peut le déplacer d’une catégorie à l’autre à tout moment sans perte de données.
• Les sections découpent le cours en blocs logiques (thèmes, semaines, modules). Leur comportement dépend du format de cours choisi (voir section 3 de ce chapitre).
• Les activités et ressources sont toujours rattachées à une section. Chacune est une instance d’un module d’activité (activity module), c’est-à-dire d’un plugin de type mod (nous y reviendrons longuement dans la Partie 8 sur le développement).

💡 Pour un dev React : la hiérarchie ressemble au routage par système de fichiers de Next.js. Les catégories ≈ dossiers de routes imbriqués, le cours ≈ un segment de route avec son layout.tsx (le format de cours), les sections ≈ des <Section> rendus en liste, les activités ≈ des composants enfants dont le type détermine le rendu. La différence majeure : dans Moodle, cette arborescence vit en base de données (tables course_categories, course, course_sections, course_modules) et se manipule via l’interface, pas via le code.

⚠️ Piège : ne confondez pas les catégories de cours (organisation des cours entre eux) avec les catégories de notes (organisation du carnet de notes à l’intérieur d’un cours) ni avec les catégories de questions (organisation de la banque de questions). Trois concepts homonymes, trois écrans différents. Cette collision de vocabulaire piège tous les débutants.

1.3 Le contexte de cours : la clé du système de permissions

Chaque nœud de la hiérarchie ci-dessus correspond à un contexte (context) dans le système de permissions de Moodle (vu en Partie 2, mais rappelons l’essentiel car c’est vital ici) :

Les permissions héritent vers le bas : un rôle attribué au niveau d’une catégorie s’applique à tous les cours de cette catégorie ; un rôle attribué dans un cours s’applique à toutes ses activités. C’est pourquoi « être enseignant » ne veut rien dire dans l’absolu dans Moodle : on est enseignant dans le contexte d’un cours donné. Le même utilisateur peut être enseignant dans un cours et étudiant dans un autre.

Le contexte de cours est donc la frontière naturelle d’isolation : les inscriptions (enrolments), les groupes, les notes, les rapports, tout est scopé au cours. Quand vous créez un cours, Moodle crée automatiquement son contexte, y active les méthodes d’inscription par défaut (inscription manuelle, auto-inscription désactivée par défaut selon la configuration du site) et initialise le carnet de notes.

💡 Pour un dev React : le contexte Moodle joue le rôle d’un scope d’autorisation, comparable à une hiérarchie de Context.Provider React dont les valeurs (les capacités accordées) se propagent aux enfants, avec possibilité de surcharge locale (permission override) à chaque niveau — sauf qu’ici tout est résolu côté serveur, en PHP, à chaque requête.

1.4 Qui peut créer un cours ?

La création de cours est contrôlée par la capacité moodle/course:create, vérifiée dans le contexte de la catégorie où le cours sera créé (ou dans le contexte système). Par défaut, cette capacité est accordée à trois rôles :

Le rôle Créateur de cours (Course creator) mérite une explication, car il surprend souvent. C’est un rôle « étroit » dont la seule vocation est de permettre à un utilisateur de confiance (un responsable pédagogique, par exemple) de créer des cours dans une catégorie, sans lui donner les pleins pouvoirs d’un gestionnaire. Deux comportements associés à connaître :

1. Lorsqu’un créateur de cours crée un cours, Moodle l’inscrit automatiquement comme enseignant dans ce cours (comportement contrôlé par le réglage Administration du site → Utilisateurs → Permissions → Politiques d’utilisateurs → « Rôle par défaut des créateurs dans les nouveaux cours », creatornewroleid).
2. Un créateur de cours ne peut pas supprimer un cours qu’il a créé après un certain délai : il n’a pas moodle/course:delete en dehors de la fenêtre de création. C’est voulu — la suppression reste un acte de gestionnaire.

⚠️ Piège : donner le rôle Enseignant à quelqu’un ne lui permet PAS de créer des cours. C’est logique (le rôle Enseignant s’attribue dans un cours, qui doit donc déjà exister) mais contre-intuitif pour qui vient d’autres LMS. Si vos enseignants doivent créer leurs propres cours, attribuez-leur en plus le rôle Créateur de cours au niveau de leur catégorie, ou mettez en place une procédure de demande de création (le plugin tiers block_coursrequest ou la fonctionnalité native de demande de cours, activable via Administration du site → Cours → Réglages par défaut des cours → Demande de cours).

1.5 Les trois chemins de création d’un cours

Selon votre rôle, trois portes d’entrée mènent au même formulaire de création :

1. Via l’administration du site (administrateurs et gestionnaires) : Administration du site → Cours → Gérer les cours et catégories, choisir la catégorie cible, puis cliquer sur « Créer un cours ». C’est le chemin le plus complet : on y voit l’arborescence des catégories, on peut trier, déplacer et masquer les cours. Raccourci équivalent : Administration du site → Cours → Ajouter un cours (le formulaire demande alors la catégorie).

2. Via la page d’une catégorie : en naviguant sur la page publique d’une catégorie de cours, un utilisateur disposant de moodle/course:create dans ce contexte voit un bouton « Ajouter un cours ». C’est le chemin naturel du créateur de cours.

3. Via « Mes cours » (depuis Moodle 4.0) : la page Mes cours (My courses), introduite dans Moodle 4.0 comme page distincte du Tableau de bord, affiche un bouton « Créer un cours » aux utilisateurs autorisés. Depuis Moodle 4.3, ce bouton s’accompagne d’un menu proposant aussi de demander un cours si la demande de cours est activée. C’est le chemin le plus rapide au quotidien.

Quel que soit le chemin, le formulaire est identique (course/edit.php). Passons-le en revue exhaustivement.

📚 Aller plus loin : la page officielle docs.moodle.org/fr/Ajouter_un_cours  décrit les chemins de création, et docs.moodle.org/fr/Capacités_de_cours  recense les capacités liées aux cours. Côté développeur, la structure des tables est documentée sur moodledev.io .

1.6 Ce que Moodle crée automatiquement avec un cours

À l’instant où vous validez le formulaire de création, Moodle ne se contente pas d’insérer une ligne dans la table course. Il provisionne tout un environnement de travail :

Trois conséquences pratiques de cette mécanique :

• le forum Annonces est le canal de communication descendant officiel du cours : comme l’abonnement y est imposé, chaque annonce part par e-mail (ou notification mobile) à tous les inscrits. C’est un outil puissant — et donc à ne pas galvauder ;
• la section générale (section 0) est l’endroit conventionnel pour le « chapeau » du cours : présentation, plan, forum Annonces, liens essentiels. Elle se comporte comme une section normale (contenus, résumé) mais n’est jamais numérotée ni datée par le format hebdomadaire ;
• un cours fraîchement créé est une coquille sans participants : tant que vous n’avez pas configuré les inscriptions (Partie 2) ou inscrit manuellement des utilisateurs, personne d’autre que vous (et les gestionnaires) ne peut y entrer.

⚠️ Piège : si un enseignant supprime le forum Annonces « pour faire le ménage », Moodle le recrée dès qu’un mécanisme en a besoin (bloc « Dernières annonces », réglage « Nombre d’annonces » supérieur à zéro) — mais les anciennes annonces, elles, sont parties à la corbeille. Pour se passer réellement des annonces, la bonne méthode est de mettre « Nombre d’annonces » à 0 dans les paramètres du cours, pas de supprimer le forum.

2. Le formulaire de création : tous les réglages, section par section

Le formulaire de création (et de modification — c’est le même, accessible ensuite via Cours → Paramètres dans le menu secondaire du cours) est organisé en sections repliables. Nous les parcourons dans l’ordre d’affichage de Moodle 5.2. Chaque réglage correspond à une colonne de la table course en base de données ou à une option du format de cours (table course_format_options).

Un principe transversal : la plupart des valeurs par défaut proposées ici sont configurables au niveau du site via Administration du site → Cours → Réglages par défaut des cours (moodlecourse settings). Si vous administrez la plateforme, réglez ces défauts une bonne fois pour toutes — vos créateurs de cours vous remercieront.

2.1 Section « Généraux »

Quelques réglages de cette section méritent un développement.

Le nom abrégé : unicité et usages

Le nom abrégé (shortname) est le seul champ du formulaire soumis à une contrainte d’unicité à l’échelle du site. Moodle refusera la création si un autre cours porte déjà ce nom abrégé. Il apparaît :

• dans le préfixe des e-mails envoyés depuis les forums du cours ([WEB-L3-2026] Nouveau message...) ;
• dans la barre de navigation quand le réglage du site l’exige ;
• comme clé de correspondance dans les imports CSV de cours et d’inscriptions — c’est son usage le plus critique côté administration ;
• dans certains blocs et rapports.

⚠️ Piège : ne mettez pas l’année dans le nom complet mais pas dans le nom abrégé (ou l’inverse). Quand vous dupliquerez le cours l’an prochain, l’unicité du shortname vous forcera à en changer — prévoyez une convention de nommage versionnée dès le départ (WEB-L3-2026, WEB-L3-2027…). Autre piège classique : changer le shortname d’un cours en production casse les scripts d’import CSV qui s’appuyaient dessus.

Les dates de début et de fin : ce qu’elles font vraiment

C’est l’une des sources de confusion les plus fréquentes. Récapitulons ce que ces dates font et ne font pas :

Pour réellement fermer un cours à une date donnée, il faut jouer sur la visibilité, sur les dates des méthodes d’inscription, ou sur des restrictions d’accès — pas sur enddate.

💡 Pour un dev React : startdate/enddate sont des métadonnées de tri et d’affichage, pas des guards d’accès. C’est comme un champ publishedAt dans un CMS headless : il pilote le rendu des listes côté front, mais ne remplace pas un middleware d’autorisation.

Le numéro d’identification (ID number)

Ce champ est invisible pour les étudiants et n’a aucun effet fonctionnel dans Moodle lui-même. Il existe pour une seule raison : servir de clé de correspondance stable avec le monde extérieur. Exemples concrets :

• votre système de scolarité connaît le cours sous le code INFO-4021 : mettez ce code dans l’ID number, et vos scripts de synchronisation (web services core_course_get_courses_by_field avec field=idnumber, plugin d’inscription par base de données externe, imports CSV) retrouveront le cours sans dépendre du shortname que les enseignants pourraient modifier ;
• les exports du carnet de notes peuvent utiliser les ID numbers pour se recoller avec un logiciel de gestion des notes.

Notez que les activités et même les items du carnet de notes ont aussi leur propre champ ID number, avec la même philosophie.

2.2 Section « Description »

L’image de cours (course image) est purement cosmétique mais a un impact énorme sur l’expérience : la page Mes cours affiche les cours sous forme de cartes, et une plateforme où tous les cours ont le motif géométrique par défaut paraît vite négligée. Recommandations pratiques : format paysage environ 16:9, ~1200 × 675 px, moins de 300 Ko, sujet lisible même recadré (Moodle recadre en object-fit: cover selon la carte). Depuis Moodle 4.x, l’image s’affiche aussi en bannière d’en-tête du cours dans certains thèmes.

⚠️ Piège : le champ s’appelle « Fichiers de résumé du cours » et accepte techniquement plusieurs fichiers si l’administrateur a relevé la limite (courseoverviewfileslimit), mais seul le premier fichier image est utilisé comme vignette. Déposez une seule image, au bon format.

2.3 Section « Format de cours »

Sections cachées : invisibles ou repliées ?

Quand un enseignant cache une section (par exemple la semaine 8, pas encore prête), deux comportements sont possibles pour l’étudiant, selon ce réglage :

• « Les sections cachées sont invisibles » : l’étudiant ne voit rien du tout — la section n’existe pas pour lui. C’est le choix le plus courant et le plus propre.
• « Les sections cachées sont affichées sous forme repliée » : l’étudiant voit un bandeau grisé « Non disponible » à l’emplacement de la section, sans pouvoir en consulter le contenu. Utile pédagogiquement pour montrer le plan complet du semestre (« il y aura bien une semaine 8 ») tout en gardant le contenu secret.

⚠️ Piège : avec l’option « affichées repliées », le titre de la section reste potentiellement visible selon les versions et thèmes. Ne mettez pas d’informations sensibles (« Semaine 8 : correction du partiel ») dans le titre d’une section cachée si ce mode est actif.

Mise en page : une page ou plusieurs ?

Avec « une section par page », la page principale du cours n’affiche que les titres et résumés des sections ; chaque section s’ouvre sur sa propre page avec une navigation précédent/suivant. Depuis l’arrivée de l’index de cours en 4.0 (voir section 5), ce mode a perdu de son intérêt pour la navigation, mais il reste pertinent pour les cours très volumineux : il allège considérablement le poids de la page principale (moins de nœuds DOM, moins de requêtes), ce qui compte quand un cours contient des centaines d’activités.

💡 Pour un dev React : « toutes les sections sur une page » ≈ une single-page app avec scroll ; « une section par page » ≈ un routage par segment (/course/view.php?id=42&section=3). Le second est l’équivalent d’un code splitting par route : on ne charge que ce qu’on regarde. Notez que depuis Moodle 4.4, le paramètre d’URL des sections migre vers des URL dédiées (course/section.php?id=...), chaque section ayant une véritable page propre.

2.4 Section « Apparence »

⚠️ Piège : « Afficher le carnet de notes aux étudiants → Non » ne rend pas le cours « sans notes ». Chaque activité notée continue d’alimenter le gradebook ; seul le lien est masqué. Si un enseignant réactive l’affichage six mois plus tard, les étudiants verront tout l’historique. Pour un contrôle fin (masquer une colonne le temps de la correction), utilisez plutôt le masquage d’éléments dans le carnet de notes lui-même.

2.5 Section « Fichiers et dépôts »

La chaîne de limites de taille mérite d’être comprise, car les messages d’erreur de dépôt de fichiers sont une plainte récurrente :

php.ini (upload_max_filesize, post_max_size)   ← plafond absolu, côté serveur
  ≥ limite du site (Administration du site → Sécurité → Réglages sécurité du site)
    ≥ limite du cours (maxbytes, ce réglage)
      ≥ limite de l'activité (ex. taille max des remises d'un devoir)

⚠️ Piège : si vos utilisateurs ne peuvent pas déposer plus de 2 Mo alors que le cours autorise 100 Mo, le coupable est presque toujours upload_max_filesize/post_max_size dans php.ini (et éventuellement client_max_body_size de Nginx). Le formulaire de cours ne proposera jamais une valeur supérieure au plafond du serveur.

Quant aux fichiers de cours hérités (legacy course files) : dans Moodle 1.x, les fichiers d’un cours vivaient dans un dossier commun, façon FTP. Depuis Moodle 2.0 (2010), chaque fichier est rattaché à son contexte d’usage via l’API Fichiers (File API), ce qui permet les permissions fines, la déduplication par hachage de contenu et les sauvegardes cohérentes. Le réglage n’existe que pour la compatibilité de très vieux cours migrés. Considérez-le comme du code mort.

2.6 Section « Suivi d’achèvement »

Le suivi d’achèvement (completion tracking) est le socle de trois fonctionnalités majeures que nous détaillerons plus tard : la barre de progression des étudiants, l’achèvement de cours (course completion) (avec ses conditions agrégées et son usage dans les prérequis entre cours), et les restrictions d’accès (access restrictions) conditionnées (« ouvrir le Test 2 uniquement si le Test 1 est achevé »). Activez-le systématiquement, même si vous ne vous en servez pas au début : l’activer a posteriori fonctionne, mais les données d’achèvement ne sont calculées qu’à partir de l’activation.

Depuis Moodle 4.3, la configuration de l’achèvement au niveau des activités a été refondue (interface unifiée, conditions par défaut par type d’activité configurables en masse), et Moodle 4.5/5.x ont continué à polir l’affichage des états d’achèvement sur les cartes d’activité (badges « Fait », « À faire »).

2.7 Section « Groupes »

Nous consacrons le chapitre 6 de cette partie aux groupes et groupements (création, auto-inscription par clé, restriction d’accès par groupe, cas d’usage multi-cohortes). Retenez à ce stade : ces trois réglages ne créent aucun groupe ; ils définissent seulement les comportements par défaut. Un cours fraîchement créé n’a aucun groupe.

⚠️ Piège : régler « Groupes séparés » ici sans avoir créé de groupes ni réparti les étudiants produit un effet déroutant : dans les forums en mode séparé, les étudiants sans groupe ne voient que les discussions « sans groupe » et les enseignants croient le forum cassé. Le mode de groupe ne fait rien de magique : il filtre selon une appartenance qui doit exister.

2.8 Section « Renommer les rôles »

Cette section permet de redéfinir, pour ce cours uniquement, le libellé affiché de chaque rôle : « Enseignant » peut devenir « Formateur », « Tuteur » ou « Chef de chantier » ; « Étudiant » peut devenir « Apprenti » ou « Participant ».

Points essentiels :

• c’est purement cosmétique : les permissions, capacités et comportements du rôle ne changent pas d’un iota ;
• le renommage apparaît dans la liste des participants, sur les profils dans le cours et dans le sélecteur de rôles à l’inscription ;
• c’est très utilisé en formation professionnelle, où le vocabulaire scolaire (« enseignant/étudiant ») est mal perçu.

Pour de vrais changements de permissions, on passe par Administration du site → Utilisateurs → Permissions → Définition des rôles (rôles globaux) ou par les dérogations de permissions au niveau du cours — jamais par ce formulaire.

2.9 Section « Tags »

Les tags sont l’outil de classification transversal de Moodle, orthogonal à la hiérarchie des catégories : un cours appartient à une seule catégorie mais peut porter autant de tags que nécessaire. L’administrateur peut standardiser les tags (collections, tags officiels) via Administration du site → Apparence → Gérer les tags. Sur les grosses plateformes, une politique de tags officiels évite la prolifération de variantes (« Débutant », « débutant », « pour débutants »…).

📚 Aller plus loin : chaque réglage du formulaire est documenté sur docs.moodle.org/fr/Paramètres_du_cours . Les valeurs par défaut au niveau du site : docs.moodle.org/fr/Réglages_par_défaut_des_cours .

3. Les formats de cours natifs

Le format de cours (course format) est le plugin (type format) qui contrôle intégralement la mise en page de la page principale du cours : comment les sections sont rendues, quelle navigation est proposée, quelles options supplémentaires apparaissent dans le formulaire de réglages. Moodle 5.2 embarque quatre formats natifs.

💡 Pour un dev React : le format de cours est exactement un layout au sens Next.js : un composant parent qui reçoit la même donnée (la liste des sections et activités, le course_modinfo) et décide de son rendu. Changer de format ne change pas les données — seulement leur présentation. Depuis Moodle 4.0, le rendu des formats repose d’ailleurs sur des composants réactifs JavaScript (la bibliothèque « reactive state » de core_courseformat) : un store d’état côté client, des mutations optimistes, une synchronisation serveur — une architecture qui vous rappellera furieusement Redux/Zustand.

3.1 Format « Sections personnalisées » (Custom sections, ex-Topics)

C’est le format par défaut et de très loin le plus utilisé. Historiquement nommé « Thèmes » (Topics), il a été renommé « Sections personnalisées » (Custom sections) dans Moodle 4.4 — le nom interne du plugin reste format_topics, ce qui compte pour les imports CSV et les web services.

Caractéristiques :

• le cours est découpé en sections numérotées, chacune librement nommable (cliquez sur le crayon à côté du titre en mode édition — tant qu’aucun nom n’est saisi, Moodle affiche « Section 1 », « Section 2 »…) ;
• les sections se réordonnent par glisser-déposer ;
• une section peut être mise en évidence (highlight) : elle reçoit un marquage visuel « section actuelle » (une seule à la fois) ;
• les sections sont repliables/dépliables individuellement, avec un lien « Tout replier / Tout déplier » (comportement natif depuis 4.x) ;
• depuis Moodle 4.5, il prend en charge les sous-sections (voir 3.5).

Cas d’usage : tout découpage thématique non calendaire — modules de compétences, chapitres d’un manuel, parcours par niveaux. En cas de doute, choisissez ce format.

3.2 Format « Hebdomadaire » (Weekly)

Identique au format Sections dans son fonctionnement, à une différence structurante près : chaque section représente une semaine, datée automatiquement à partir de la date de début du cours. La première section couvre la semaine de la date de début, la deuxième la semaine suivante, etc. Les titres sont générés (« 5 janvier - 11 janvier ») mais restent renommables individuellement.

Comportements à connaître :

• si vous changez la date de début du cours, toutes les semaines se redatent automatiquement — c’est le grand intérêt lors de la reconduction annuelle d’un cours ;
• la semaine courante est automatiquement mise en évidence ;
• la date de fin du cours peut servir à calculer automatiquement le nombre de semaines (selon le réglage du format « Calcul automatique de la date de fin »).

Cas d’usage : cours calés sur un calendrier réel — semestre universitaire, MOOC à cohortes, formation avec un rythme imposé. Contre-indication : formation à entrées/sorties permanentes ou auto-rythmée, où les dates n’ont aucun sens et induisent les étudiants en erreur.

⚠️ Piège : dupliquer un cours hebdomadaire pour l’année suivante sans mettre à jour la date de début produit un cours daté de l’an passé, avec la mauvaise semaine en surbrillance. Mettez à jour startdate immédiatement après toute duplication/restauration — c’est le premier point de la checklist finale.

3.3 Format « Activité unique » (Single activity)

Ce format supprime la notion de page de cours : le cours entier est une seule activité, affichée directement quand on entre dans le cours. Le formulaire de réglages demande simplement le type d’activité (Test, SCORM, Forum, Livre, LTI, H5P…), puis vous configurez cette activité.

Précision historique demandée par la rigueur : jusqu’à Moodle 3.11 existait un format « SCORM » dédié, qui affichait un paquet SCORM en pleine page. Il a été supprimé dans Moodle 4.0, le format Activité unique (introduit bien avant, en 2.6) le remplaçant intégralement — les cours au format SCORM ont été migrés automatiquement vers Activité unique lors de la mise à niveau.

Cas d’usage :

• déployer un module e-learning autoportant (paquet SCORM ou H5P) comme « cours » dans le catalogue — très courant en formation professionnelle ;
• un « cours-forum » d’échanges généraux (quoique le format Social soit fait pour ça) ;
• exposer un outil externe LTI comme s’il s’agissait d’un cours ;
• créer un examen isolé : un cours = un Test, pratique pour des permissions et inscriptions dédiées.

⚠️ Piège : dans un cours Activité unique, il n’y a pas de page où poser d’autres activités visibles — mais les activités supplémentaires que vous créeriez (par web service ou en changeant temporairement de format) deviennent orphelines et sont listées dans une section « Activités orphelines » visible des seuls enseignants. Ne construisez pas un cours multi-activités dans ce format.

3.4 Format « Social »

Le format le plus ancien et le plus atypique : la page de cours est un unique forum (le « forum social »), affiché directement, les autres contenus étant relégués dans un bloc latéral « Activités sociales ». Pas de sections, pas de progression.

Cas d’usage : salle des professeurs virtuelle, espace d’échange d’un club ou d’une promotion, forum d’entraide transversal. Autrement dit : des espaces communautaires, pas des cours au sens pédagogique. Dans les faits, il est rarissime en production moderne — un cours standard avec un forum en première section offre plus de souplesse.

3.5 Sous-sections et délégation de sections (Moodle 4.5)

Nouveauté majeure de Moodle 4.5 : les sous-sections (subsections). Il s’agit techniquement d’un module d’activité (mod_subsection) qui, inséré dans une section, crée une section déléguée (delegated section) : une section de second niveau, imbriquée, avec son propre titre, sa propre visibilité, ses propres restrictions d’accès et ses propres activités.

Ce qu’il faut savoir :

• la profondeur est limitée à un seul niveau : pas de sous-sous-sections. C’est un choix délibéré de l’équipe UX de Moodle HQ pour éviter les arborescences illisibles ;
• une sous-section apparaît dans l’index de cours comme un nœud repliable sous sa section parente ;
• comme c’est un module, une sous-section se duplique, se déplace par glisser-déposer (avec tout son contenu), se masque et se restreint comme n’importe quelle activité ;
• les formats Sections personnalisées et Hebdomadaire les prennent en charge nativement ; les formats tiers doivent déclarer leur compatibilité (vérifiez avant d’en dépendre) ;
• l’administrateur peut désactiver le module Sous-section au niveau du site (Administration du site → Plugins → Modules d’activité).

Le terme « délégation de sections » désigne le mécanisme interne : la table course_sections porte désormais des colonnes (component, itemid) permettant à un composant (ici mod_subsection) de « posséder » une section. Cette API de délégation est ouverte : d’autres plugins peuvent créer des sections déléguées pour leurs besoins propres. Si vous développez un jour un format ou un module, c’est une API à connaître.

Cas d’usage des sous-sections : regrouper « Cours / Exercices / Corrections » à l’intérieur de chaque semaine ; isoler un contenu optionnel (« Pour aller plus loin ») repliable ; structurer un gros module sans exploser le nombre de sections de premier niveau.

💡 Pour un dev React : avant 4.5, la liste de sections était un tableau plat — l’équivalent d’une liste sans imbrication. Les sous-sections introduisent une composition récursive à profondeur 1 : <Section> peut rendre des <Activity> dont l’une est elle-même une <Section>. La limitation volontaire à un niveau évite le problème classique des arbres récursifs illimités : une UX de navigation ingérable.

3.6 Tableau récapitulatif des formats natifs

4. Formats de cours tiers populaires

Le format étant un simple plugin, l’écosystème en propose des dizaines sur moodle.org/plugins  (catégorie Course formats). Quatre dominent l’usage francophone et méritent d’être connus, même si vous ne les installez pas.

4.1 Tiles (Tuiles)

Le plus populaire. Chaque section devient une tuile cliquable (image ou icône + titre) disposée en grille responsive ; cliquer ouvre le contenu de la section, en surimpression animée ou en page dédiée. Options riches : photo par tuile, indicateurs de progression sur chaque tuile, couleurs, sous-tuiles pour les activités.

• Apporte : un rendu « catalogue » très visuel, une progression tangible, un rendu mobile soigné.
• Vigilance : plugin très riche donc surface de bugs plus grande à chaque mise à niveau majeure de Moodle ; les images par tuile sont un contenu à maintenir ; certaines fonctions (achèvement sur tuile) recalculent des données à l’affichage.

4.2 Grid (Grille)

L’ancêtre du genre : chaque section est représentée par une vignette-image dans une grille ; le contenu s’ouvre dans une fenêtre modale ou une page. Plus simple que Tiles, moins d’options.

• Apporte : visuel immédiat, prise en main triviale.
• Vigilance : le projet a connu des périodes de maintenance irrégulière ; vérifiez la compatibilité déclarée avec votre version exacte avant toute mise à niveau du cœur.

4.3 Buttons (Boutons)

Affiche une rangée de boutons numérotés (ou lettrés) en haut du cours ; chaque bouton affiche la section correspondante en dessous, sans rechargement. Minimaliste et efficace.

• Apporte : navigation compacte pour les cours à nombreuses sections, page toujours courte.
• Vigilance : projet porté par un mainteneur individuel — le risque d’abandon est structurellement plus élevé que pour un plugin porté par une société (Tiles) ou une communauté large.

4.4 Collapsed Topics (Thèmes repliés)

Historiquement incontournable : chaque section est repliable/dépliable, l’état étant mémorisé par utilisateur. Son intérêt a fortement diminué depuis que le format natif Sections personnalisées offre le repli des sections (Moodle 4.x) — c’est l’exemple parfait du plugin tiers « absorbé » par le cœur.

• Apporte aujourd’hui : des options de personnalisation du repli plus fines que le natif (couleurs, structures en semaines+thèmes mixtes).
• Vigilance : évaluez honnêtement si le natif ne suffit pas ; le mainteneur historique a annoncé des changements de disponibilité de ses plugins — vérifiez l’état du dépôt avant d’engager un parc de cours dessus.

4.5 Règles de prudence avec les formats tiers

1. La maintenance du plugin conditionne vos mises à niveau. Un format non compatible avec Moodle 5.2 peut bloquer votre montée de version ou, pire, casser l’affichage de centaines de cours après celle-ci. Avant d’adopter : consultez la page du plugin (versions supportées, date de dernière mise à jour, volume d’installations, réactivité du bug tracker).
2. Le choix du format est réversible… avec précautions. Changer le format d’un cours existant (via Paramètres du cours) ne détruit jamais les activités — elles restent en base, rattachées à leurs sections. Mais : les options spécifiques au format (images de tuiles, couleurs, réglages Grid) sont ignorées par le nouveau format (et conservées en base si vous revenez en arrière) ; le passage vers Activité unique rend orphelin tout le contenu au-delà de la première activité ; le passage Hebdomadaire ↔ Sections renomme l’affichage des sections (dates ↔ titres). Testez toujours sur une copie du cours.
3. Pensez à la migration de sortie. Si vous désinstallez un format tiers, tous les cours qui l’utilisaient retombent sur le format par défaut du site. Rien n’est perdu, mais l’expérience visuelle change brutalement pour les étudiants. Planifiez ce genre d’opération hors période de cours.
4. Uniformité avant originalité. Sur une plateforme mutualisée, trois formats maximum (par exemple : natif Sections, Hebdomadaire, Tiles) suffisent. Chaque format supplémentaire est un coût de support, de formation et de test.

💡 Pour un dev React : adopter un format tiers, c’est adopter une dépendance npm qui contrôle tout votre rendu — l’équivalent d’un framework UI complet, pas d’un petit utilitaire. Les critères d’évaluation sont les mêmes que pour une dépendance JS critique : fréquence des releases, issues ouvertes/fermées, bus factor du mainteneur, et existence d’une stratégie de sortie.

📚 Aller plus loin : l’annuaire des formats : moodle.org/plugins/browse.php?list=category&id=17 . Pour écrire votre propre format (nous le ferons en Partie 8) : moodledev.io/docs/apis/plugintypes/format .

5. L’édition de cours moderne (Moodle 4.x / 5.x)

Moodle 4.0 (2022) a entièrement refondu l’expérience d’édition de cours, refonte poursuivie à chaque version jusqu’en 5.2. Si vous consultez de vieux tutoriels (Moodle 3.x), l’interface décrite — bouton « Activer le mode édition » dans un bloc Administration, menus « Modifier » textuels — n’existe plus. Voici l’état de l’art.

5.1 Le mode édition

Depuis Moodle 4.0, l’édition s’active par l’interrupteur « Mode d’édition » (Edit mode) situé en permanence en haut à droite de la barre supérieure, sur toutes les pages où l’utilisateur a des droits d’édition. Ce toggle remplace l’ancien bouton « Activer le mode édition » et l’entrée équivalente du bloc Administration.

Le mode édition transforme la page de cours :

• chaque section et chaque activité affiche un menu d’actions (« ⋮ ») : modifier les paramètres, déplacer, masquer, dupliquer, attribuer des rôles, supprimer ;
• des liens « Ajouter une activité ou ressource » apparaissent dans chaque section (ouvrant le sélecteur d’activités (activity chooser), lui aussi refondu : recherche, onglets par catégorie, favoris, activités recommandées par l’admin) ;
• les poignées de glisser-déposer deviennent actives ;
• les titres deviennent éditables inline (voir 5.5).

💡 Pour un dev React : le mode édition est un booléen d’état global qui fait basculer toute la page entre un rendu « lecture » et un rendu « CRUD » — exactement le pattern inline editing d’un CMS headless avec visual editing (Sanity Presentation, Builder.io). Techniquement, l’état de la page de cours est géré par le module JS réactif de core_courseformat : les actions (déplacer, masquer, dupliquer) passent par des web services, mettent à jour un state store côté client et re-rendent les fragments Mustache concernés, sans rechargement complet. Du server-driven UI avec mutations optimistes, en somme.

5.2 L’index de cours (course index)

Introduit en Moodle 4.0, l’index de cours (course index) est le panneau latéral gauche, repliable, qui affiche l’arborescence complète du cours : sections, sous-sections (depuis 4.5) et activités. Il sert à :

• naviguer : un clic fait défiler la page jusqu’à l’élément (ou charge la bonne page en mode « une section par page ») ;
• situer : l’élément en cours de consultation est surligné ; les pastilles indiquent l’état d’achèvement pour l’étudiant, la visibilité (éléments masqués grisés) pour l’enseignant ;
• réorganiser : en mode édition, l’index accepte le glisser-déposer — c’est même le moyen le plus efficace de déplacer une activité d’un bout à l’autre d’un long cours, bien plus commode que de faire défiler la page centrale.

L’index est également visible pendant la consultation d’une activité, ce qui règle un vieux problème d’UX de Moodle : « où suis-je dans le cours et comment aller à l’activité suivante ? ».

5.3 Glisser-déposer des activités et des sections

Le drag-and-drop fonctionne à trois endroits : dans la page de cours (activités entre sections, sections entre elles), dans l’index de cours, et entre l’index et la page. Depuis Moodle 4.x, le menu d’action de chaque élément propose aussi « Déplacer », qui ouvre un dialogue listant les destinations — indispensable pour l’accessibilité (utilisateurs clavier/lecteur d’écran) et bien pratique dans les très longs cours.

Le déplacement d’une section emporte tout son contenu ; celui d’une sous-section aussi (c’est un module). Les déplacements sont enregistrés immédiatement, sans bouton « Enregistrer ».

5.4 L’indentation

L’indentation (décaler une activité vers la droite pour marquer visuellement une hiérarchie légère : « ce PDF accompagne le devoir au-dessus ») existait dans Moodle 3.x, a été supprimée dans Moodle 4.0 (au grand dam de la communauté), puis réintroduite dans Moodle 4.1 via les entrées « Déplacer à droite / Déplacer à gauche » du menu d’action de l’activité. Un seul niveau d’indentation est disponible depuis son retour. Depuis l’arrivée des sous-sections (4.5), l’indentation redevient ce qu’elle aurait toujours dû être : un artifice purement visuel — pour une vraie hiérarchie, préférez une sous-section.

5.5 Les cartes d’activité (activity cards)

Chaque activité sur la page de cours est rendue sous forme de carte d’activité (activity card), dont le design a été refondu dans Moodle 4.4 : mise en page plus aérée, zone d’icône repensée, badges d’état harmonisés. Les éléments d’une carte :

• l’icône du type d’activité, sur fond coloré selon la catégorie pédagogique (purpose) déclarée par le module — système introduit avec Moodle 4.0 et dont les couleurs/catégories ont été ajustées en 4.4 : Administration, Évaluation (assessment), Collaboration, Communication, Contenu (content), Interactif — chaque catégorie a sa couleur, ce qui donne une lecture immédiate de la nature de chaque ligne ;
• le nom de l’activité (lien), éditable inline en mode édition : le crayon à côté du titre permet de renommer sans ouvrir le formulaire — Échap annule, Entrée valide ;
• les dates (si showactivitydates est actif) : ouverture, échéance…;
• les conditions d’achèvement ou le badge d’état (Fait / À faire) ;
• le badge de visibilité : « Caché pour les étudiants » ou « Disponible mais non affiché sur la page de cours » (mode furtif, voir 5.7) ;
• en mode édition, le menu d’actions : Paramètres, Déplacer, Déplacer à droite, Masquer, Dupliquer, Attribution des rôles, Supprimer.

5.6 Duplication d’activité

« Dupliquer » (menu d’action de l’activité) crée une copie complète de l’activité — réglages, contenus, restrictions — juste en dessous de l’originale, avec l’ajout de « (copie) » au nom. En interne, c’est une mini sauvegarde/restauration : les données utilisateurs (remises, tentatives, messages) ne sont pas copiées. C’est l’outil idéal pour décliner une activité modèle (« Devoir semaine N ») sur toutes les sections.

⚠️ Piège : la duplication ne re-lie pas les références croisées. Si votre activité dupliquée contenait une restriction d’accès du type « avoir achevé le Test 1 », la copie pointe toujours vers le Test 1 original — vérifiez les restrictions et les liens internes après duplication.

5.7 Activités masquées et activités furtives (stealth)

Trois états de disponibilité existent pour une activité :

Le mode furtif (stealth activity) doit être autorisé au niveau du site (Administration du site → Cours → Réglages par défaut des cours → « Autoriser les activités furtives », allowstealth). Une fois activé, l’option apparaît dans le menu de visibilité de l’activité (et dans le réglage « Disponibilité » de ses paramètres). Cas d’usage typiques : une page de correction liée seulement depuis le feedback d’un test ; des ressources annexes liées depuis une page centrale « Bibliographie » sans encombrer la page de cours ; les contenus d’une section masquée qu’on veut néanmoins rendre accessibles.

⚠️ Piège : furtif ≠ sécurisé. Une activité furtive est accessible à tout étudiant inscrit qui possède ou devine l’URL (/mod/page/view.php?id=...). Pour restreindre réellement l’accès, utilisez les restrictions d’accès (groupe, date, achèvement) — le mode furtif ne gère que l’affichage.

5.8 Édition en masse (bulk editing)

Depuis Moodle 4.2, le mode édition propose un bouton « Modification par lots » (Bulk actions) : il fait apparaître des cases à cocher sur chaque activité et chaque section, puis une barre d’actions en bas de page permettant de traiter la sélection en une fois : déplacer, dupliquer, masquer/afficher, supprimer plusieurs activités ou sections d’un coup. Avant 4.2, réorganiser massivement un cours signifiait des dizaines de clics ; c’est l’une des améliorations de productivité les plus concrètes du cycle 4.x.

5.9 La corbeille (recycle bin)

Toute suppression d’activité ou de cours n’est pas immédiatement définitive : le plugin Corbeille (recycle bin), intégré au cœur depuis Moodle 3.1 et activé par défaut, conserve :

• les activités supprimées, dans la corbeille du cours (menu du cours → Plus → Corbeille ; le lien n’apparaît que si la corbeille contient quelque chose) ;
• les cours supprimés, dans la corbeille de leur catégorie (accessible aux gestionnaires depuis la page de gestion de la catégorie).

Les éléments y sont stockés sous forme de sauvegardes automatiques et peuvent être restaurés en un clic pendant la durée de rétention configurée (Administration du site → Plugins → Outils d’administration → Corbeille — par défaut 7 jours, modifiable, avec option de vidage manuel). Passé ce délai, une tâche planifiée purge définitivement.

⚠️ Piège : la suppression d’une activité n’est pas instantanée même hors corbeille : elle passe par une tâche ad hoc (course_delete_modules) exécutée par le cron. Si votre cron est en panne, les activités « supprimées » restent en base dans un état zombie. Encore une raison (après la Partie 1) de surveiller votre cron. Second piège : la corbeille des activités stocke une sauvegarde sans les données utilisateurs dans certains cas limites de configuration de sauvegarde automatique — vérifiez les réglages de sauvegarde par défaut si la restauration de données étudiantes depuis la corbeille est un besoin critique pour vous.

6. Réutiliser des cours

Créer un cours à partir de zéro est l’exception ; dans la vraie vie, on réutilise : on reconduit le cours de l’an passé, on repart d’un modèle, on importe des activités d’un collègue. Moodle offre quatre mécanismes distincts qu’il faut savoir choisir. Tous sont regroupés depuis Moodle 4.x dans le menu du cours sous Plus → Réutilisation de cours (Course reuse) : Import, Sauvegarde, Restauration, Copier un cours, Réinitialiser.

6.1 La duplication complète (« Copier un cours »)

Gérer les cours et catégories → menu du cours → Copier un cours (ou Réutilisation de cours → Copier un cours). Cette fonction, introduite en Moodle 3.9, enchaîne automatiquement une sauvegarde et une restauration en tâche de fond (ad hoc task via cron) : vous indiquez le nouveau nom complet, le nouveau nom abrégé, la catégorie cible, la nouvelle date de début, la visibilité, et si les utilisateurs inscrits doivent être copiés. Le nouveau cours apparaît quelques minutes plus tard (dès que le cron a traité la tâche).

C’est l’outil de la reconduction annuelle : dupliquer « WEB-L3-2026 » en « WEB-L3-2027 », sans les étudiants, avec la nouvelle date de début.

6.2 L’import de contenus entre cours

Réutilisation de cours → Importer. L’import (import) copie des activités, ressources, sections (et optionnellement les groupes, groupements, la banque de questions liée, les compétences) d’un cours vers le cours courant. Conditions et caractéristiques :

• vous devez avoir des droits d’édition (moodle/backup:backuptargetimport sur la source) dans les deux cours — typiquement, être enseignant des deux ;
• l’import ne transporte jamais de données utilisateurs (ni inscriptions, ni remises, ni notes) : c’est une copie de structure et de contenu uniquement ;
• l’assistant permet une sélection fine : tout le cours source, ou activité par activité ;
• le contenu importé s’ajoute au contenu existant, section par section (le contenu de la section 3 source arrive dans la section 3 cible — attention si les structures diffèrent).

Cas d’usage : « récupérer le Test de mon collègue », mutualiser une banque d’activités entre les cours parallèles d’une même matière.

6.3 Sauvegarde et restauration (backup .mbz)

Le mécanisme le plus complet et le plus universel.

La sauvegarde

Réutilisation de cours → Sauvegarde. Moodle produit un fichier .mbz (Moodle backup) — en réalité une archive compressée (zip ou tgz selon la configuration) contenant des fichiers XML décrivant le cours (moodle_backup.xml, structure des sections, réglages de chaque activité, questions, carnet de notes…) et les fichiers binaires référencés (dans un pool nommé par hachage, comme dans moodledata). L’assistant propose des options décisives :

Puis un second écran permet de décocher individuellement chaque section et chaque activité. Le fichier .mbz produit atterrit dans la zone de sauvegarde de cours de l’utilisateur, d’où on peut le télécharger.

À noter : l’administrateur peut planifier des sauvegardes automatiques de tous les cours (Administration du site → Cours → Sauvegardes → Sauvegarde automatique) — hygiène de base d’une plateforme en production, en complément (et non en remplacement !) des sauvegardes serveur de la base et de moodledata.

La restauration

Réutilisation de cours → Restauration (ou depuis la page de gestion d’une catégorie). Après dépôt du .mbz, l’assistant propose trois destinations :

1. Restaurer comme nouveau cours dans une catégorie (le cas nominal) ;
2. Restaurer dans le cours courant en fusionnant avec son contenu (le contenu du backup s’ajoute) ;
3. Restaurer dans le cours courant après l’avoir vidé (le contenu existant est supprimé, remplacé par celui du backup).

Suivent le choix fin des éléments à restaurer, la correspondance des réglages, puis l’exécution. La restauration recrée les activités avec de nouveaux identifiants — les URL absolues codées en dur dans les contenus sont réécrites quand Moodle les reconnaît (liens internes au cours), mais pas toujours (liens inter-cours, liens dans des fichiers).

⚠️ Piège n°1 : la restauration d’un backup avec utilisateurs exige des permissions élevées (moodle/restore:userinfo, réservée par défaut aux administrateurs/gestionnaires) : un enseignant qui restaure un backup contenant des données utilisateurs verra ces données silencieusement ignorées. Ce n’est pas un bug, c’est une protection des données personnelles.

Piège n°2 : la compatibilité des versions est ascendante uniquement : un backup Moodle 3.9 se restaure très bien en 5.2, mais un backup 5.2 ne se restaure pas en 4.1. Pensez-y avant d’échanger des cours entre plateformes de versions différentes.

Piège n°3 : la taille. Un cours chargé en vidéos produit un .mbz énorme qui peut dépasser les limites d’upload à la restauration. Réglez backup | restore côté admin, ou mieux : externalisez les vidéos (streaming) plutôt que de les stocker dans les cours.

6.4 Import vs sauvegarde/restauration vs duplication : le comparatif

Règle simple : même plateforme + tout le cours → Copier ; même plateforme + morceaux choisis → Import ; tout le reste (archivage, changement de serveur, partage) → Backup/Restore.

6.5 Les modèles de cours (course templates)

Moodle n’a pas, dans le cœur, de fonctionnalité « modèle de cours » à proprement parler. Trois approches comblent ce manque :

1. La catégorie de modèles + duplication (l’approche artisanale, la plus répandue) : créez une catégorie cachée « _Modèles », placez-y des cours gabarits soigneusement construits (structure de sections, annonces types, activités pré-réglées, image générique), puis, pour chaque nouveau cours, utilisez « Copier un cours » depuis le modèle. Simple, sans plugin, mais repose sur la discipline des équipes.
2. Les plugins dédiés, comme « Course Templates » (block_course_template) ou des outils plus récents qui présentent une galerie de modèles au moment de la création et automatisent la duplication. Vérifiez la compatibilité 5.x avant adoption — c’est un segment de plugins à maintenance inégale.
3. Le modèle appliqué à la création en masse : l’outil d’upload de cours (ci-dessous) accepte un paramètre templatecourse (nom abrégé d’un cours modèle) : chaque cours créé par le CSV est alors pré-rempli par restauration du modèle. C’est l’approche la plus industrielle.

À noter également : Administration du site → Cours → Réglages par défaut des cours définit les valeurs par défaut du formulaire (format, nombre de sections, achèvement…) — ce n’est pas un modèle de contenu, mais c’est la première brique d’une standardisation.

6.6 Création de cours en masse (survol)

Pour créer des dizaines ou des centaines de cours (typiquement à chaque rentrée, depuis l’export du système de scolarité), l’outil natif est Administration du site → Cours → Télécharger des cours (Upload courses) : un fichier CSV avec, au minimum, les colonnes shortname, fullname, category (ou category_idnumber/category_path), et en option toutes les colonnes du formulaire (format, startdate, visible, idnumber, summary…), plus des colonnes spéciales :

• templatecourse : restaure un cours modèle dans chaque cours créé ;
• backupfile : restaure un fichier .mbz donné ;
• des colonnes d’inscription (enrolment_1, enrolment_1_role…) pour pré-configurer les méthodes d’inscription.

L’outil gère aussi la mise à jour de cours existants (correspondance par shortname ou idnumber) et propose un mode « prévisualisation » avant exécution. Pour l’automatisation continue, les web services (core_course_create_courses) et la CLI offrent des alternatives programmatiques — nous y reviendrons dans la partie consacrée aux intégrations.

💡 Pour un dev React : upload CSV = seeding de base de données ; templatecourse = scaffolding à partir d’un boilerplate ; web services = l’API REST que vous appellerez depuis vos scripts Node/TypeScript (avec un token, format de réponse JSON — patience, la Partie 7 détaille l’API externe et ses pièges).

📚 Aller plus loin : docs.moodle.org/fr/Sauvegarde_de_cours , docs.moodle.org/fr/Restauration_de_cours , docs.moodle.org/fr/Import_de_données_de_cours , et pour l’upload en masse docs.moodle.org/fr/Télécharger_des_cours . Le format interne du .mbz est documenté côté développeur sur moodledev.io/docs/apis/subsystems/backup .

7. Checklist finale : créer un cours proprement

Avant d’ouvrir un cours aux étudiants, passez cette liste en revue. Elle condense tout le chapitre.

7.1 La checklist

Avant la création

• La catégorie cible existe et est correctement nommée.
• La convention de nommage est définie (nom complet lisible, nom abrégé unique et versionné, ID number aligné sur le SI externe).
• Le format de cours est choisi en connaissance de cause (thématique vs calendaire vs activité unique).

À la création

• Cours créé caché (visibilité : Cacher) — on publie quand c’est prêt.
• Dates de début et de fin correctes (impact : semaines du format hebdomadaire, classement dans Mes cours).
• Résumé rédigé (2-4 phrases) et image de cours déposée (~16:9, < 300 Ko).
• Suivi d’achèvement activé ; affichage des dates d’activité et des conditions d’achèvement laissé sur Oui.
• Taille maximale de dépôt cohérente avec l’usage prévu (remises vidéo ? → vérifier aussi les limites serveur).
• Mode de groupe réglé (et « imposer » réfléchi) si le cours accueille plusieurs cohortes — sinon laisser « Aucun groupe ».
• Rôles renommés si le contexte l’exige (formation professionnelle) ; tags posés selon la politique du site.

Après la création

• Structure des sections posée (titres explicites, sous-sections pour les regroupements internes).
• Méthodes d’inscription configurées (voir Partie 2) — un cours sans méthode d’inscription active est une coquille inaccessible.
• Test du rendu en vue étudiant (menu utilisateur → « Prendre le rôle… → Étudiant ») : rien de caché qui devrait être visible, rien de visible qui devrait être caché.
• Si le cours vient d’une duplication/restauration : date de début mise à jour, annonces de l’an passé purgées, liens inter-cours vérifiés, calendrier nettoyé (au besoin via Réutilisation de cours → Réinitialiser).
• Publication : visibilité passée à « Afficher ».

7.2 Tableau récapitulatif des réglages critiques

7.3 Et ensuite ?

Votre cours existe, sa structure est posée, ses réglages sont sains — mais il est vide. Le chapitre 2 de cette partie s’attaque au remplissage, en commençant par les ressources (resources) : fichier, dossier, page, livre, URL, zone de texte et média… Nous verrons pour chacune quand l’utiliser (et surtout quand ne pas l’utiliser — le réflexe « tout en PDF » est le premier travers à désapprendre), comment l’éditeur de texte de Moodle gère les médias, et comment penser ses contenus pour qu’ils restent maintenables sur plusieurs années.

📚 Aller plus loin : pour une vue d’ensemble officielle de la gestion des cours, gardez sous le coude docs.moodle.org/fr/Cours  et, côté architecture, moodledev.io/docs/apis/core/course  qui décrit les entités course, course_sections et course_modules que nous avons manipulées tout au long de ce chapitre via l’interface.