Chapitre 4 — L’écosystème Moodle

Partie 1 : Découvrir Moodle — Chapitre 4/5 Public : développeur web débutant sur Moodle. On sort du logiciel pour cartographier ce qui gravite autour : où trouver un plugin, où poser une question, où signaler un bug, où se former, qui héberge. Version de référence : Moodle 5.2 (avril 2026).

⏱️ TL;DR

• Moodle est autant un écosystème qu’un logiciel : sans le plugin directory, les forums, le tracker et la communauté, vous serez bloqué en permanence.
• Le plugin directory (moodle.org/plugins ) recense ~2000 plugins tiers, tous GPL, avec versions supportées, statistiques et review humaine à la publication.
• La communauté vit sur moodle.org  (forums en dizaines de langues, dont un espace francophone actif) : c’est le support gratuit de première ligne.
• Le tracker (tracker.moodle.org , un Jira public) référence bugs et évolutions du core sous des identifiants MDL-xxxxx que vous citerez sans cesse.
• Moodle Academy offre des cours gratuits (dont un cursus développeur) et des certifications ; MoodleDev (moodledev.io ) est la doc technique de référence.
• Le code vit sur github.com/moodle/moodle  (miroir officiel), mais les contributions passent par le tracker + git.moodle.org, pas par de simples PR GitHub.
• Le business tourne autour de Moodle HQ (l’éditeur), d’un réseau de Moodle Partners / Certified Service Providers (hébergement, intégration, support payant) et de produits : Moodle LMS (libre), Moodle Workplace (entreprise, commercial), MoodleCloud (SaaS hébergé), Moodle App (mobile officielle).
• Autres briques : MoodleNet (partage de ressources), H5P (contenu interactif, intégré), les MoodleMoot (conférences), AMOS (plateforme de traduction).

🎯 Objectifs

À la fin de ce chapitre, vous saurez :

• Trouver et évaluer un plugin tiers sur le plugin directory (et lire ses signaux de qualité).
• Distinguer les canaux : forums (entraide), tracker (bugs core), doc utilisateur vs doc développeur.
• Situer Moodle HQ, les partenaires et MoodleCloud dans le modèle économique.
• Différencier Moodle LMS, Workplace, MoodleCloud et l’app mobile.
• Savoir où se former (Moodle Academy) et où lire la doc selon votre besoin.

1. Pourquoi l’écosystème compte autant que le logiciel

Avec un framework JavaScript, votre écosystème tient dans npm, GitHub, Stack Overflow et la doc officielle. Moodle a l’équivalent, mais réparti sur des sites et des outils spécifiques qu’il faut connaître nommément — sinon vous chercherez au mauvais endroit. Un plugin ne s’installe pas depuis npm mais depuis le plugin directory. Une question ne se pose pas sur Stack Overflow (peu de réponses) mais sur les forums moodle.org. Un bug du cœur ne se signale pas par une issue GitHub mais dans le tracker. La doc n’est pas une seule, mais deux (utilisateur et développeur), et confondre les deux fait perdre des heures.

Ce chapitre est une carte. Gardez-la : dans six mois, vous y reviendrez pour savoir « où » avant de savoir « comment ».

2. Le plugin directory : le « npm » de Moodle (en plus surveillé)

moodle.org/plugins  est le catalogue officiel des extensions. ~2000 plugins y sont publiés, couvrant toute la taxonomie que vous verrez en Partie 6 : modules d’activité, blocs, thèmes, formats de cours, méthodes d’authentification, types de questions, filtres, intégrations…

2.1 Ce qu’on y trouve sur chaque fiche

• Le nom et le type du plugin (avec son frankenstyle, ex. mod_bigbluebuttonbn, block_xp, theme_moove).
• Les versions de Moodle supportées (une grille verte/rouge : indispensable pour vérifier la compatibilité 5.2).
• Le nombre de sites qui l’utilisent (statistique remontée par les instances : un excellent signal de fiabilité).
• La maturité déclarée (Stable, Beta, Alpha) et la date de dernière mise à jour.
• Le lien vers le dépôt (souvent GitHub), le tracker d’issues, la doc, et un bouton de téléchargement (zip) par version de Moodle.
• Les avis et l’espace de discussion.

2.2 Comment on installe (aperçu — détaillé en Parties 4 et 6)

Trois voies, par ordre de « propreté » pour un développeur :

1. Git dans le dossier du type de plugin (ex. git clone … mod/monactivite) — la voie recommandée en production maîtrisée et en dev.
2. Zip via l’interface : Administration du site → Plugins → Installer des plugins (upload du zip téléchargé).
3. « Install plugins » directement depuis le directory (si l’instance a accès réseau et l’option activée).

Dans tous les cas, l’installation se finalise en base en visitant la page de mise à niveau (Moodle détecte le nouveau code et joue le schéma). On y reviendra.

2.3 Lire les signaux de qualité

Avant d’adopter un plugin tiers en production, un développeur regarde, dans l’ordre :

• Compatibilité 5.2 explicite (pas juste « 4.x »).
• Nombre de sites et date de dernière release (un plugin non mis à jour depuis deux versions majeures = risque).
• Le dépôt : activité récente, issues traitées, présence de tests et d’une CI (bon signe d’un mainteneur sérieux — Partie 11).
• La présence d’un privacy provider (obligatoire pour la publication depuis le RGPD, Partie 11) — signe que le plugin est à jour sur les standards.

⚠️ Piège : tout plugin du directory est GPL, mais « GPL » ne veut pas dire « maintenu » ni « sûr ». Un plugin installe du code PHP avec les pleins pouvoirs du serveur. N’installez jamais en production un plugin abandonné ou non audité : c’est une surface d’attaque et une bombe à retardement lors du prochain upgrade. Le directory review humain filtre à la publication, pas la maintenance dans le temps.

💡 Pour un dev React : le plugin directory ≈ npm, mais avec review humaine à la publication (délais de plusieurs semaines, allers-retours avec un relecteur), pas de sémantique de dépendances transitives automatique (les dépendances entre plugins existent mais sont déclarées à la main), et une licence imposée (GPL v3+). On ne « publie » pas en une commande : c’est un processus éditorial (détaillé en Partie 11, chapitre « Publier son plugin »).

3. La communauté : forums moodle.org

moodle.org  héberge des forums structurés par thème et par langue. C’est le support gratuit de première ligne et, pour beaucoup de questions fonctionnelles, la ressource la plus efficace — souvent plus que les moteurs de recherche généralistes.

Points d’entrée utiles pour un développeur :

• Developer / Development forums (en anglais) : questions d’API, de plugins, d’architecture. Des développeurs du core et des mainteneurs expérimentés y répondent.
• **General help / Installation / Themes / … ** : par domaine fonctionnel.
• Espace francophone : il existe une communauté FR active (annonces, entraide). Utile pour les questions de terminologie et les spécificités françaises, mais pour les sujets techniques pointus, l’anglais reste la langue de la réponse (rappel du chapitre 2).

💡 Pour un dev React : ne comptez pas sur Stack Overflow comme réflexe premier — le volume de réponses Moodle y est faible et souvent périmé. Le bon ordre est : doc développeur (moodledev.io) → forums moodle.org → tracker → code source. Le code du cœur, lisible sur GitHub, est fréquemment la meilleure « documentation » (on le répétera).

4. Le tracker : MDL-xxxxx et la fabrique de Moodle

tracker.moodle.org  est le Jira public de Moodle. Chaque bug, chaque amélioration, chaque nouvelle fonctionnalité du cœur y vit sous un identifiant MDL- suivi d’un numéro (ex. MDL-79000). Vous le croiserez partout : dans les commits git (chaque commit du core cite son MDL-), dans les release notes, dans les réponses de forum (« c’est corrigé dans MDL-… »).

À quoi ça sert pour vous :

• Savoir si un bug est connu / corrigé : cherchez le symptôme dans le tracker avant de crier au bug. La correction est peut-être déjà planifiée pour la 5.2.1.
• Comprendre une régression : chaque ticket lie les commits, la version d’introduction et la version de correction.
• Signaler un vrai bug du core (pas de votre plugin) : après vérification, on crée un ticket documenté (étapes de repro, version, environnement).
• Contribuer : les correctifs du core passent par un ticket + un peer-review, pas par une simple pull request GitHub (voir §6).

D’autres projets Jira y cohabitent (par exemple pour la doc, l’app mobile, les composants). Le préfixe indique le projet ; MDL est le core.

⚠️ Piège : ne signalez jamais un bug de votre plugin (ou d’un plugin tiers) dans le tracker MDL — il est réservé au cœur. Les bugs d’un plugin tiers vont dans le dépôt/issue tracker de ce plugin (lien sur sa fiche du directory). Confondre les deux fait perdre du temps à tout le monde.

5. Le code source et la contribution

Le code officiel est publié sur github.com/moodle/moodle  — un miroir en lecture, synchronisé depuis le dépôt canonique git.moodle.org. Les branches suivent le schéma MOODLE_XYZ_STABLE (ex. MOODLE_502_STABLE pour la 5.2), plus main pour le développement en cours. On reviendra en détail sur ces branches au chapitre 5 et en Partie 4.

Contribuer au core ne se fait pas par « fork + PR GitHub » comme la plupart des projets JS. Le processus (encadré, exigeant) est :

1. Ouvrir/associer un ticket MDL- dans le tracker.
2. Pousser sa branche (via git.moodle.org ou GitHub) et lier le diff au ticket.
3. Passer la CI (prechecker : coding style moodle-cs, PHPUnit, Behat, etc. — Partie 11).
4. Obtenir un peer-review puis un integration review par l’équipe d’intégration de Moodle HQ, qui fusionne par cycles (« integration / testing » hebdomadaires).

C’est plus lourd qu’un projet npm, mais cohérent avec un logiciel critique déployé sur des dizaines de milliers de sites. Bonne nouvelle pour débuter : vous n’avez pas besoin de contribuer au core pour être un développeur Moodle productif — l’immense majorité du travail se fait en plugins (Partie 6), sur votre dépôt, à votre rythme.

6. Se former et lire la doc : deux docs, une académie

Il y a deux documentations officielles, et les confondre est l’erreur n°1 du débutant :

Retenez : docs.moodle.org = fonctionnel/admin, moodledev.io = code. Toute cette documentation-cours renvoie vers l’une ou l’autre via les encadrés 📚 Aller plus loin.

Moodle Academy (moodle.academy ) est la plateforme de formation officielle (elle-même construite sur Moodle, forcément). Elle propose des parcours gratuits pour enseignants, administrateurs et développeurs, ainsi que des certifications reconnues (Moodle Educator Certification, parcours administrateur, contenu développeur). Pour un dev qui découvre, c’est un bon complément structuré à cette documentation.

💡 Pour un dev React : moodledev.io est votre « MDN + docs du framework » ; docs.moodle.org est le « manuel utilisateur ». Vous vivrez sur moodledev.io, mais vous ouvrirez docs.moodle.org chaque fois qu’un client décrira un comportement de l’interface que vous devez reproduire ou expliquer.

7. Le modèle économique : HQ, partenaires, MoodleCloud

Moodle est open source et gratuit, alors comment l’écosystème se finance-t-il ? Trois piliers.

Moodle HQ (la société, basée en Australie, avec des équipes réparties) développe le cœur, emploie les mainteneurs, publie les versions, gère l’infrastructure communautaire et édite les produits commerciaux. C’est l’équivalent d’une fondation-entreprise qui pilote le projet.

Le réseau de partenaires — historiquement Moodle Partners, aujourd’hui structuré autour des Certified Service Providers / Moodle Certified Partners — regroupe des entreprises agréées qui vendent hébergement, intégration, développement sur mesure, formation et support. Une part de leurs revenus finance Moodle HQ. Beaucoup d’institutions passent par un partenaire plutôt que de s’auto-héberger. En tant que freelance ou agence, vous travaillerez souvent pour, avec, ou en concurrence de ces partenaires.

Les produits commerciaux (voir §8) : Moodle Workplace et MoodleCloud génèrent des revenus directs qui soutiennent le développement du LMS libre.

Ce modèle « cœur libre + services et éditions payantes » explique une tension saine que vous ressentirez : le core reste GPL et complet, mais certaines fonctionnalités « entreprise » (multi-tenant avancé, parcours de certification RH…) sont réservées à Workplace, le produit commercial.

8. Les produits : LMS, Workplace, MoodleCloud, App

On les confond souvent. Voici la carte.

Quelques précisions qui vous éviteront des malentendus :

• Workplace n’est pas un fork : c’est le LMS + un ensemble de plugins et de fonctionnalités propriétaires, distribué uniquement par des partenaires certifiés. Le code que vous apprenez ici (APIs, plugins, thèmes) s’y applique largement, mais Workplace ajoute ses propres concepts (tenants, programmes, etc.).
• MoodleCloud est du Moodle LMS hébergé : pratique pour tester, mais l’accès au code serveur et au système de fichiers est restreint — donc peu adapté au développement de plugins. Pour coder, vous voudrez un environnement local (Partie 4), pas MoodleCloud.
• L’app mobile a une conséquence de développement importante : votre thème web ne s’applique pas dans l’app (elle a son propre rendu, basé sur Ionic/Angular). Des réglages spécifiques (mobilecssurl, prise en charge des activités par l’app) existent — un point traité en Partie 8.

⚠️ Piège : un client qui dit « on est sur Moodle » peut être sur LMS auto-hébergé, sur MoodleCloud, chez un partenaire d’hébergement, ou sur Workplace. Ces quatre situations ont des contraintes de développement radicalement différentes (accès au code, plugins autorisés, possibilité de thème custom). Première question à poser sur tout projet Moodle : « quelle édition, hébergée où ? »

9. Les briques satellites à connaître

Quelques éléments que vous croiserez et qu’il faut savoir nommer :

• H5P — un standard ouvert de contenu interactif (quiz, vidéos interactives, présentations…) intégré nativement à Moodle (comme type de contenu et via la banque de contenus). Traité en Partie 3. Sachez juste, ici, que « H5P » n’est pas un plugin exotique mais une brique de premier plan.
• MoodleNet (moodle.net ) — un réseau social de partage et de découverte de ressources pédagogiques ouvertes, avec import direct dans un cours. Utile côté enseignant, périphérique côté dev.
• AMOS — la plateforme de traduction collaborative de Moodle. C’est par AMOS que les chaînes de langue (les fichiers lang/, Partie 5) sont traduites dans ~100 langues. Si vous publiez un plugin, c’est là que la communauté le traduira.
• MoodleMoot — les conférences Moodle, mondiales et régionales (dont des éditions francophones). Bon endroit pour rencontrer la communauté et suivre la feuille de route.
• Le blog et les annonces sur moodle.com / moodle.org — pour suivre les sorties de version et les orientations (dont, ces dernières années, l’IA intégrée au core, traitée en Partie 11).

10. Synthèse et points à retenir

• Moodle = logiciel + écosystème ; connaître le second est aussi vital que maîtriser le premier.
• Où trouver un plugin : le plugin directory (GPL, review à la publication, statistiques d’usage, compatibilité par version — vérifiez toujours 5.2).
• Où demander de l’aide : forums moodle.org (dont un espace FR), pas Stack Overflow.
• Où vivent les bugs du core : le tracker (MDL-xxxxx) ; les bugs d’un plugin vont dans le dépôt du plugin, jamais dans MDL.
• Deux docs : docs.moodle.org (utiliser/administrer, FR) vs moodledev.io (coder, EN). Ne pas confondre. Formation structurée : Moodle Academy (+ certifications).
• Le code est sur GitHub (miroir) ; contribuer au core = tracker + peer-review + intégration HQ, pas une PR. Mais développer en plugins ne demande rien de tout ça.
• Quatre produits : LMS (libre, notre sujet), Workplace (commercial), MoodleCloud (SaaS), App mobile. Toujours demander : quelle édition, hébergée où ?

✏️ Exercices

Exercice 1 — Évaluer un plugin. Sur le plugin directory, ouvrez la fiche d’un plugin populaire (par ex. block_xp ou mod_bigbluebuttonbn). Relevez : (a) sa compatibilité annoncée avec Moodle 5.2, (b) le nombre de sites qui l’utilisent, (c) la date de la dernière version, (d) le lien de son dépôt de code. Concluez : l’adopteriez-vous en production ?

Exercice 2 — Le bon canal. Pour chaque situation, dites où aller (plugin directory / forums / tracker MDL / dépôt du plugin / docs.moodle.org / moodledev.io) : (a) « Le carnet de notes du core affiche un total faux, je pense que c’est un bug de Moodle. » (b) « Je veux savoir comment paramétrer une remise de devoir en groupe. » (c) « J’ai une erreur PHP dans un plugin tiers mod_truc. » (d) « Quelle est la signature de la fonction has_capability() ? » (e) « Je cherche un plugin de gamification. »

Exercice 3 — Quelle édition ? Un prospect vous dit : « On a Moodle, on veut un thème aux couleurs de notre marque et un plugin d’export vers notre SIRH. » Quelles questions posez-vous avant de chiffrer, et pourquoi ?

Exercice 4 — Décoder un identifiant. Vous lisez dans des release notes : « Corrige MDL-81234 ». Que signifie ce code, où le consulter, et qu’y apprendrez-vous ?

Exercice 5 — Deux docs. Classez ces besoins en « docs.moodle.org » ou « moodledev.io » : (a) écrire un db/install.xml ; (b) expliquer à un enseignant l’achèvement d’activité ; (c) la liste des types PARAM_* ; (d) configurer l’authentification OAuth2 côté admin.

🧠 Quiz de révision

Q1. Où trouve-t-on les plugins tiers, et quel est le premier critère à vérifier avant d’en adopter un ?

Q2. Quelle est la différence entre le tracker et l’issue tracker d’un plugin ?

Q3. docs.moodle.org vs moodledev.io : qui sert à quoi ?

Q4. Citez les quatre « produits » Moodle et lequel est l’objet de ce cours.

Q5. Pourquoi la question « quelle édition, hébergée où ? » est-elle la première à poser sur un projet Moodle ?

Chapitre suivant : 05 — Les versions de Moodle et le cycle de release, où l’on apprend à lire un numéro de version, à comprendre le rythme semestriel et les LTS, à choisir la version d’un projet, et à mesurer ce que ce cycle implique pour la maintenance de votre code.