Chapitre 12.5 — Parcours d’apprentissage et carrière

Partie 12 : Annexes — Où vous situer, comment progresser, et ce que le marché Moodle offre à un développeur. À consulter au début (pour planifier) et régulièrement (pour vous situer). Version de référence : Moodle 5.2.

1. Parcours d’apprentissage semaine par semaine

Le plan du README racine, détaillé avec des livrables vérifiables. Adaptez le rythme.

Sem.	Parties	Objectif	Livrable jalon
1	1–3	Comprendre Moodle (utilisateur/admin)	Sur une démo, créer un cours avec 3 activités, inscrire un étudiant, noter, expliquer rôles/contextes/capabilities.
2	4	Environnement de dev qui tourne	moodle-docker up, Moodle 5.2 installé, `DEBUG_DEVELOPER` + `cachejs=false`, code sous les yeux.
3–4	5	Architecture du cœur	Savoir tracer : frankenstyle, DML, Form API, Output API, hooks, tasks, cache. Le plus gros morceau conceptuel.
5–6	6	Premiers plugins	`local_todolist` installé et fonctionnel (fait, cassé, upgradé) ; un bloc ; commencer un `mod`.
7	7–8	Frontend + thèmes	Un template Mustache surchargé, un module AMD, `theme_maboite` (couleur+fonte), un îlot React si besoin.
8	9	Web Services + Next.js	Un service custom, un token, une external function, un client Next.js qui lit/écrit dans Moodle.
9	10	LTI de bout en bout	Comprendre OIDC/JWT/AGS/NRPS ; QuizLab (outil LTI Next.js) branché sur Moodle.
10+	11	Expert	Sécuriser, tester (PHPUnit/Behat + CI), profiler, privacy provider, publier un plugin.

Projets jalons (à réaliser vraiment) : local_todolist (sem. 5–6), theme_maboite (sem. 7), une intégration Next.js (sem. 8), un plugin publiable avec CI (sem. 10+).

2. Auto-évaluation : où en êtes-vous ?

🟢 Débutant Moodle

Je distingue rôle / capability / contexte et je traduis un terme FR ↔ EN ↔ code (glossaire ch. 12.1).
Je navigue dans l’interface 5.2 et l’administration ; je sais purger les caches.
J’ai un environnement de dev local qui tourne (Partie 4).

🟡 Confirmé

J’écris un plugin local/block/mod complet (schéma XMLDB, capabilities, Form API, DML, Output API, upgrade).
Je maîtrise le pattern de page sécurisée (require_login + contexte + capability + sesskey) et j’évite l’IDOR.
Je surcharge un template/renderer/thème et j’écris un module AMD ; je consomme et j’expose des web services.

🔴 Expert

J’écris du code sûr (Partie 11.1) et performant (mesurer avant d’optimiser, 11.2).
Mes plugins ont PHPUnit + Behat + CI sur une matrice de versions (11.3–11.4).
Je gère RGPD (privacy provider), IA (aiprovider_), l’exploitation d’une instance et je publie au directory (11.5–11.8).

Le vrai marqueur d’expertise n’est pas « je sais tout faire » mais « je choisis le bon niveau » : le bon type de plugin, le bon niveau frontend (Mustache vs React), le bon arbitrage flexibilité/maintenance. Ch. 6.1, 7.6, 8.4.

3. Le marché du travail Moodle

Moodle est l’un des LMS les plus déployés au monde (universités, administrations, entreprises, ONG). Le marché du développeur Moodle est de niche mais durable :

Employeurs : universités et établissements (souvent via un Moodle Partner), agences/prestataires spécialisés, éditeurs de plugins, entreprises avec plateforme de formation interne (souvent Workplace).
Formes : salariat (intégrateur, dev plateforme), freelance/agence (plugins sur mesure, thèmes, intégrations), ou dev de produits (plugins/thèmes premium, ch. 11.8).
Atout d’un dev web moderne : la rareté. Peu de devs maîtrisent à la fois Moodle et l’écosystème JS/Next.js. Le pont Moodle ↔ Next.js (web services, LTI, React) que ce cours enseigne est exactement le profil recherché pour moderniser des plateformes.

Les salaires et TJM varient fortement selon le pays, le statut (salarié/freelance) et la spécialisation. Le différenciateur qui paie : savoir intégrer Moodle à un écosystème moderne (API, SSO, apps front) et garantir la qualité (sécurité, tests, CI) — pas seulement « poser un plugin ».

4. Certifications

Moodle Academy (ch. 12.4) propose des parcours et certifications reconnues : côté enseignant (Moodle Educator Certification), administrateur, et contenu développeur.
Pour un dev, la certification a moins de poids que le portfolio : des plugins publiés au directory (avec CI verte, ch. 11.8) et des contributions valent démonstration.

5. Contribuer au core

Vous n’avez pas besoin de contribuer au core pour être un dev Moodle productif (l’essentiel se fait en plugins). Mais contribuer :

Renforce votre compréhension et votre visibilité.
Se fait via le tracker (MDL-, ch. 1.4) : ticket → diff lié → CI (prechecker) → peer-review → integration review par HQ. Plus exigeant qu’une PR GitHub, mais formateur.
Commence petit : corriger un bug documenté, améliorer une chaîne, un correctif ciblé.

6. Rester à jour (le métier ne se fige jamais)

Moodle sort deux versions par an (ch. 1.5). Rester pertinent :

Lire les upgrade / API change notes à chaque version (moodledev.io).
Tester ses plugins contre les release candidates (CI multi-versions, ch. 11.4).
Suivre les grandes orientations (ces dernières années : l’IA intégrée au core, ch. 11.6 ; la racine public/ ; la modernisation frontend, React dans le core en 5.2).
Fréquenter la communauté (forums, MoodleMoot) pour anticiper.

7. Le mot de la fin

Vous êtes parti dev Next.js/React face à 500 000 lignes de PHP « d’un autre âge ». Vous savez maintenant que Moodle n’est pas un vieux projet mal fichu, mais un système à contrats explicites : de fichiers (par type de plugin), de sécurité (capabilities/contextes), de cycle de vie (version, upgrade, backup), de rendu (Mustache, îlots JS), de thème (héritage + SCSS), d’intégration (web services, LTI), et de qualité (tests, CI, RGPD).

Une fois ces contrats intégrés, développer pour Moodle devient mécanique et prévisible, malgré la taille du système — et votre double compétence Moodle + écosystème JS moderne est exactement ce qui manque au marché. De « je sais faire une feature » à « on me confie une plateforme » : le chemin est fait.

Bon code.

Retour au README général · Sommaire des annexes