Partie 8 — Les thèmes Moodle : le guide complet

Version de référence : Moodle 5.2 (publié le 20 avril 2026, PHP ≥ 8.3) — thème Boost basé sur Bootstrap 5.3, sans jQuery.

Cette partie répond en profondeur à LA question que se pose tout développeur front-end qui arrive sur Moodle : « est-on très flexible quand on crée un thème ? »

La réponse courte : oui, radicalement flexible — 100 % du HTML, du CSS et du JS de l’interface est atteignable depuis un thème, sans jamais toucher au core. Mais cette flexibilité a une structure (héritage de thèmes, pipeline SCSS, surcharges de templates Mustache et de renderers PHP) et un coût (maintenance des surcharges à travers les mises à jour). Les cinq chapitres qui suivent construisent cette réponse méthodiquement, du fonctionnement interne jusqu’aux sujets d’expert.

Le fil rouge de la partie : nous construisons theme_maboite, un thème enfant de Boost pour la société fictive « MaBoîte » (couleur de marque #5940c1, fonte Inter), que nous poussons de plus en plus loin de chapitre en chapitre.

Sommaire de la partie

Chapitre 1 — Comment fonctionne un thème Moodle

Les fondations : Boost comme thème de référence (et Classic, toujours présent en 5.2), le mécanisme d’héritage entre thèmes (parents), l’anatomie complète d’un dossier theme_xxx avec un config.php décortiqué ligne par ligne, le pipeline SCSS en trois étages (pre-SCSS → preset → extra-SCSS) et la surcharge des variables Bootstrap, la compilation serveur par scssphp et le cache de thème (themedesignermode), les niveaux de sélection de thème encore disponibles en 5.2 (site, catégorie, cours, cohorte, utilisateur, URL) et le statut vestigial des device themes.

Chapitre 2 — Tutoriel : créer `theme_maboite`, enfant de Boost, de A à Z

Le tutoriel intégral, chaque fichier complet et copiable : arborescence, version.php, config.php, chaînes de langue, lib.php avec les callbacks SCSS, la page de réglages standard d’un enfant de Boost (preset picker, couleur de marque, logo, boîtes SCSS brutes), le SCSS d’exemple (variables Bootstrap : couleurs, radius, fontes ; Google Fonts hébergées localement), la personnalisation de la page de connexion, un footer sur mesure, le favicon, puis l’installation, l’activation et la boucle d’itération avec themedesignermode et la purge de caches.

Chapitre 3 — Surcharges : templates Mustache, renderers PHP, layouts

Le cœur du pouvoir des thèmes : surcharger n’importe quel template Mustache de n’importe quel composant (templates/mod_forum/… — avec l’ordre de résolution exact), surcharger les renderers PHP via la theme_overridden_renderer_factory (un core_renderer custom, le renderer d’un plugin), déclarer et écrire ses propres layouts (PHP + Mustache, le système de drawers de Boost, des régions de blocs personnalisées), le cas des chaînes de langue, le système d’icônes FontAwesome 6 et l’icon map, et l’ajout de JavaScript (modules AMD) dans un thème.

Chapitre 4 — Est-on vraiment flexible ? La réponse honnête

La démonstration argumentée : tout est atteignable, mais tout n’a pas le même prix. Ce qui est facile (couleurs, fontes, header/footer, login, dashboard), moyen (markup des activités core via surcharges ciblées), dur ou risqué (formulaires moodleform, plugins tiers sans templates, maintenir des dizaines de surcharges au fil des upgrades). Thème from scratch sans parent Boost : possible mais fortement déconseillé — et pourquoi. Études de cas de thèmes du marché très transformés (Moove, Adaptable, Edwiser RemUI, LearnR, Degrade). Techniques avancées : marque blanche multi-tenant, dark mode propre en Bootstrap 5.3, design tokens / CSS variables, et un plan d’action réaliste pour une refonte type « SaaS moderne ».

Chapitre 5 — Thèmes avancés : performance, mobile, accessibilité, RTL, upgrades, distribution

Les sujets qui séparent l’amateur de l’expert : performance (poids du CSS compilé, fontes, images, Core Web Vitals sur Moodle), le cas de l’app mobile (le thème web ne s’y applique pas — remote themes CSS via mobilecssurl), l’accessibilité WCAG 2.1 AA et le toolkit Brickfield, la compatibilité RTL (flip automatique via rtlcss-php), survivre aux upgrades (processus 5.1 → 5.2, diff des templates core, tests visuels), et distribuer ou vendre un thème (répertoire de plugins, GPL, marchés commerciaux).

Comment lire cette partie

Vous voulez juste comprendre l’architecture → chapitre 1, puis chapitre 4.
Vous devez livrer un thème de marque rapidement → chapitre 2 (tutoriel autonome), puis chapitre 3 pour aller plus loin.
Vous évaluez Moodle pour un projet à forte exigence design → chapitre 4 d’abord (la réponse à « est-on flexible ? »), puis chapitres 1–3 pour la mise en œuvre.
Vous maintenez déjà un thème en production → chapitre 5.

Prérequis

Partie 5 (architecture de Moodle : plugins, Frankenstyle, caches) et Partie 7 (frontend : Mustache, AMD, renderers côté core) sont supposées lues. Les notions y sont réexpliquées brièvement quand c’est nécessaire, mais sans le même niveau de détail.
Une instance Moodle 5.2 locale (Docker ou autre, cf. Partie 5) avec accès au code et à la CLI.

💡 Pour un dev React : gardez en tête l’analogie générale de la partie — un thème Moodle, c’est un mélange de design system (SCSS + variables Bootstrap ≈ vos design tokens Tailwind), de composants (templates Mustache ≈ vos composants JSX, en plus statique) et de layouts (≈ les layouts Next.js). La grande différence : vous ne possédez pas l’arbre de rendu — vous surchargez celui du core, fichier par fichier, avec une résolution par convention de nommage.