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

Partie 8 : Les thèmes — Chapitre 4/5 Public : dev front / décideur technique évaluant Moodle pour un projet à forte exigence design. Le chapitre-réponse à LA question de la partie. Version de référence : Moodle 5.2 (Boost / Bootstrap 5.3).

⏱️ TL;DR

• Oui, on est radicalement flexible : 100 % du HTML/CSS/JS est atteignable par un thème, sans core hack. Mais tout n’a pas le même coût.
• Facile (SCSS + réglages) : couleurs, fontes, radius, header/footer, page de connexion, dashboard, dark mode. C’est 80 % des demandes clients.
• Moyen (surcharge de templates ciblés) : markup d’un composant précis, disposition d’une activité core, blocs custom.
• Dur / risqué : les formulaires moodleform (markup généré en PHP, peu de templates), les plugins tiers sans templates (HTML en dur), et surtout maintenir des dizaines de surcharges à travers deux upgrades par an.
• Thème from scratch sans Boost : techniquement possible, fortement déconseillé (réimplémenter et maintenir toute l’UI).
• Thèmes du marché très transformés (Moove, Adaptable, RemUI, LearnR…) prouvent qu’on peut atteindre un look « SaaS moderne » — mais au prix d’une grosse base de surcharges maintenue par des équipes dédiées.
• Le vrai facteur limitant n’est pas la faisabilité, c’est la maintenance. Un thème très transformé est un produit à maintenir, pas un fichier de config.

🎯 Objectifs

• Classer précisément ce qui est facile / moyen / dur à personnaliser.
• Comprendre pourquoi les formulaires et les plugins tiers sont les points durs.
• Décider en connaissance de cause d’un thème from scratch (spoiler : non).
• Connaître les techniques avancées (multi-tenant, dark mode, design tokens) et leur coût.
• Répondre à un client/décideur avec un plan d’action réaliste.

1. La réponse en une phrase

Tout est atteignable ; tout n’a pas le même prix. La flexibilité de Moodle est totale en surface (SCSS + templates), mais le coût réel se mesure en surcharges à maintenir à chaque upgrade, pas en « est-ce possible ? ».

Un dev front qui découvre Moodle pose la mauvaise question (« puis-je faire X ? » — réponse presque toujours oui) et néglige la bonne (« combien coûtera X sur trois ans, à travers six versions de Moodle ? »). Ce chapitre recadre.

2. La carte facile / moyen / dur

2.1 🟢 Facile (SCSS + réglages) — ~80 % des demandes

Couleurs, fontes, arrondis, ombres, header/footer, page de connexion, logo, dark mode : tout cela se fait en SCSS + variables Bootstrap + réglages (ch. 8.2), sans surcharger un seul template. C’est robuste (les variables sont stables entre versions) et peu coûteux à maintenir. La grande majorité des briefs « aux couleurs de la marque » tombent ici.

2.2 🟡 Moyen (surcharge de templates ciblés)

Changer le markup d’un composant précis (la carte d’un cours sur le dashboard, l’en-tête d’une activité, un bloc), écrire un layout custom, remapper des icônes : possible via surcharge de templates Mustache / layouts (ch. 8.3). Coût moyen : chaque template surchargé doit être diffé à chaque upgrade (ch. 8.3 §7). Gérable si on en compte quelques-uns, lourd au-delà de quelques dizaines.

2.3 🔴 Dur / risqué

Trois zones résistent, détaillées ci-dessous : les formulaires, les plugins tiers, et la maintenance à l’échelle.

3. Pourquoi les formulaires moodleform sont durs

La Form API (ch. 6.3) génère son HTML en PHP (via QuickForm), avec peu de templates exposés. Résultat : restyler finement un formulaire (disposition des champs, wrapping, groupes) est difficile :

• Beaucoup de markup est produit par des renderers de formulaire internes, pas par des .mustache que vous pouvez copier.
• Les points de personnalisation existent (templates d’éléments core_form/element-*, classes de renderer de formulaire) mais sont plus techniques et plus fragiles que les templates ordinaires.
• Bootstrap 5 stylise déjà les formulaires correctement ; combattre ce style pour une maquette très éloignée coûte cher.

Conséquence pratique : si votre maquette impose des formulaires radicalement différents du rendu Bootstrap standard, prévenez le client du coût (ou négociez un design de formulaire proche du standard). C’est la limite la plus fréquemment sous-estimée.

⚠️ Piège de chiffrage : un designer livre des maquettes de formulaires pixel-perfect très éloignées de Bootstrap. Le dev accepte sans réaliser que les moodleform ne se restyle pas comme un composant libre. Le poste « formulaires » explose le budget. Auditez les maquettes de formulaires en amont et signalez ce coût.

4. Pourquoi les plugins tiers sont durs

Un thème surcharge proprement ce qui passe par des templates Mustache. Or tous les plugins ne sont pas « templatisés » : de vieux plugins (ou du code paresseux) produisent du HTML en dur dans du PHP, sans template surchargeable. Pour ceux-là :

• Pas de template à copier → la seule voie est le CSS (styliser le HTML existant) ou la surcharge du renderer du plugin (ch. 8.3), plus risquée.
• Certains plugins tiers ont un HTML inaccessible ou non-Bootstrap, difficile à intégrer visuellement.

Conséquence : la flexibilité d’un thème est fonction de la qualité des plugins installés. Un site n’utilisant que du core bien templatisé se thème facilement ; un site bardé de vieux plugins tiers a des îlots réfractaires au thème.

💡 Pour un dev React : c’est l’équivalent d’une lib tierce qui n’expose aucun point de personnalisation de rendu (pas de renderX, pas de className, du markup figé). Vous ne pouvez que la styler par CSS externe (fragile) ou la forker. La leçon : auditer les plugins tiers avant de promettre un design uniforme.

5. La vraie limite : maintenir à l’échelle

C’est le point. Un thème avec 3 surcharges de templates est trivial à maintenir. Un thème avec 40 surcharges de templates + 10 renderers + 5 layouts est un produit logiciel :

• Deux fois par an, chaque surcharge doit être diffée contre l’original mis à jour, testée, corrigée.
• Un template non re-diffusé peut casser silencieusement (contexte changé, correctif d’accessibilité manqué).
• La dette croît avec le nombre de surcharges et le nombre de versions traversées.

Corollaire de décision : chaque surcharge doit être justifiée. « C’est joli » ne paie pas la maintenance sur trois ans. Le bon thème atteint l’identité voulue avec le minimum de surcharges — d’où la primauté du SCSS (variables stables) sur les templates (copies fragiles).

6. Thème from scratch sans Boost : possible, déconseillé

Peut-on créer un thème sans parents (sans Boost) ? Oui. Faut-il ? Quasi jamais.

• Vous devez fournir tous les layouts, tous les templates, tout le SCSS de l’interface complète (des dizaines de milliers de lignes).
• Vous devez tout re-maintenir à chaque version — Boost évolue, vous ne bénéficiez d’aucune de ses améliorations (accessibilité, réactivité, correctifs).
• Vous re-livrez, en pire, ce que Boost fait déjà bien.

Le seul cas défendable : un besoin d’UI si radicalement différent qu’hériter de Boost coûterait plus à combattre qu’à réécrire — extrêmement rare, et même là, un enfant de Boost très surchargé est presque toujours plus sage. Recommandation ferme : enfant de Boost, toujours.

7. Preuves du marché et techniques avancées

Des thèmes commerciaux/communautaires très transformés existent et prouvent la flexibilité : Moove, Adaptable, Edwiser RemUI, LearnR, Degrade… Ils atteignent des looks « SaaS moderne », landing pages, dashboards riches. Mais : ce sont des produits maintenus par des équipes, avec de grosses bases de surcharges, versionnés à chaque Moodle. Leur existence prouve la faisabilité et confirme le coût.

Techniques avancées et leur coût :

• Multi-tenant / marque blanche : plusieurs identités sur une instance, via thèmes par catégorie/cohorte (ch. 8.1) ou Workplace (multi-tenant natif, commercial). Coût : gestion de N jeux de tokens, N CSS compilés.
• Dark mode propre : Bootstrap 5.3 supporte data-bs-theme="dark" et les CSS variables ; Boost fournit une bascule. Personnaliser les deux modes = doubler l’attention sur les couleurs (contrastes, ch. 8.5).
• Design tokens / CSS variables : exposer les couleurs/espacements en CSS custom properties (--brand) permet un theming runtime (sans recompiler) et facilite le multi-marque. C’est la direction moderne, bien alignée avec Bootstrap 5.3.

💡 Pour un dev React : les design tokens en CSS variables sont votre passerelle mentale la plus utile ici : au lieu de tout piloter par SCSS compilé (statique), exposez des --brand-* que vous pouvez surcharger par contexte (tenant, dark mode) au runtime, comme vous le feriez avec des CSS variables dans une app Tailwind/React. Bootstrap 5.3 y est réceptif — c’est le meilleur compromis flexibilité/maintenance pour du multi-marque.

8. Plan d’action réaliste (à donner à un client)

Pour une refonte « SaaS moderne » d’un Moodle, l’ordre rationnel :

1. Maximiser le SCSS + réglages (couleurs, fontes, radius, header/footer, login, dark mode) — 🟢 couvre l’essentiel de l’identité, coût faible.
2. Surcharger quelques templates ciblés pour les écrans à fort impact (dashboard, page de cours, landing) — 🟡 en tenant une liste documentée.
3. Auditer les formulaires et plugins tiers en amont — 🔴 signaler les coûts, négocier des designs proches du standard là où c’est cher.
4. Exposer des design tokens (CSS variables) pour le multi-marque et le dark mode.
5. Budgéter la maintenance : ~2 passes/an de re-diff des surcharges. Le thème est un produit, pas un livrable one-shot.
6. Éviter : from scratch sans Boost ; surcharger 40 templates « pour faire propre » ; combattre Bootstrap sur les formulaires.

⚠️ Piège commercial : promettre un « pixel-perfect intégral » sans distinguer facile/dur mène à un projet qui déborde sur les formulaires et les plugins tiers, et à une maintenance intenable. Vendez la flexibilité ET son coût : c’est ce qui distingue un intégrateur Moodle expérimenté.

✏️ Exercices

Exercice 1 — Classer les demandes. Rangez en 🟢/🟡/🔴 : (a) « mettez nos couleurs et notre logo » ; (b) « refaites la page de cours en cartes » ; (c) « nos formulaires d’inscription doivent ressembler à cette maquette très custom » ; (d) « ajoutez un dark mode » ; (e) « intégrez visuellement ce vieux plugin tiers sans templates ».

Exercice 2 — Le piège du formulaire. Pourquoi restyler finement un moodleform est-il coûteux, et que proposez-vous à un designer ?

Exercice 3 — From scratch ? Un dev veut un thème sans Boost pour « avoir la main sur tout ». Argumentez contre (ou pour, si un cas le justifie).

Exercice 4 — La vraie limite. Un thème atteint le design voulu avec 45 templates surchargés. Le client est ravi à la livraison. Quel problème surgira dans 6 mois, et comment l’auriez-vous prévenu ?

Exercice 5 — Multi-marque moderne. Une plateforme doit servir 5 marques avec des couleurs différentes, et vous voulez limiter la maintenance. Quelle approche technique ?

🧠 Quiz de révision

Q1. La flexibilité des thèmes Moodle est-elle totale, et quel est le vrai facteur limitant ?

Q2. Qu’est-ce qui est facile, et quelle proportion des demandes cela couvre-t-il ?

Q3. Pourquoi les formulaires et les plugins tiers sont-ils les points durs ?

Q4. Faut-il faire un thème from scratch sans Boost ?

Q5. Quelle technique moderne facilite le multi-marque et le dark mode à moindre coût ?

Chapitre suivant : 05 — Thèmes avancés : performance, mobile, accessibilité, RTL, upgrades, distribution — les sujets qui séparent l’amateur de l’expert : poids du CSS/fontes et Core Web Vitals, le cas de l’app mobile (mobilecssurl), l’accessibilité WCAG 2.1 AA et le toolkit Brickfield, la compatibilité RTL (rtlcss-php), survivre aux upgrades (diff des templates), et distribuer/vendre un thème.