Partie 11 — Niveau expert : sécurité, performance, qualité et industrialisation

Public : développeur web expérimenté (Next.js / React / TypeScript) ayant suivi les parties précédentes du cours, qui développe déjà des plugins Moodle et veut passer au niveau expert : écrire du code sûr et performant, le tester automatiquement, l’industrialiser en CI/CD, respecter le RGPD, exploiter le sous-système IA, faire vivre une instance en production et publier ses plugins à la communauté.

Version de référence : Moodle 5.2 (PHP 8.3+).

Cette partie est le sommet du parcours. Jusqu’ici, vous avez appris à faire ; ici, vous apprenez à faire bien, à grande échelle et dans la durée. C’est exactement la différence entre un développeur qui livre une feature et un expert à qui l’on confie une plateforme utilisée par des dizaines de milliers d’étudiants : la sécurité n’est plus une option, la performance se mesure avant de s’optimiser, les tests et la CI sont le filet de sécurité de chaque commit, et la conformité RGPD est une obligation légale, pas un détail.

💡 Pour un dev React : pensez à cette partie comme au passage de « je sais faire une app Next.js » à « je sais faire tourner une app Next.js en prod : audits de sécurité, profiling, Jest/Playwright, GitHub Actions, monitoring, publication de packages npm ». Ce sont les mêmes disciplines, transposées à l’écosystème Moodle/PHP.

Sommaire de la partie

Chapitre 1 — Sécurité Moodle pour développeur

Le modèle de menace d’un LMS, puis les règles d’or non négociables dans le code : require_login() / require_capability() systématiques, validation de contexte dans les external functions, sesskey pour toute action mutante, required_param() / optional_param() et le catalogue complet des types PARAM_*, placeholders DML contre l’injection SQL, échappement en sortie (s(), format_string(), format_text() et les niveaux de confiance du HTML), manipulation sûre des fichiers. Six erreurs classiques de revue de code en version « vulnérable → corrigée », la sécurité des sessions et cookies, les en-têtes HTTP, le processus officiel de sécurité Moodle (annonces, embargo, signalement de failles) et la checklist complète de durcissement d’une instance en production.

Chapitre 2 — Performance et montée en charge

Mesurer avant d’optimiser : perfdebug, profiling avec tool_excimer, détection des requêtes lentes. Optimisations côté code : recordsets vs get_records(), chasse aux requêtes N+1, bon usage des caches MUC. Puis l’infrastructure de montée en charge : architecture de référence (load balancer → serveurs web PHP-FPM stateless → Redis pour sessions et MUC → base primaire + réplicas en lecture → moodledata partagé NFS ou objectfs S3 → workers cron dédiés), OPcache, CDN, ordres de grandeur de dimensionnement, le cas critique du quiz à grande échelle (le pic d’examen) et le monitoring d’une plateforme (health checks, métriques clés).

Chapitre 3 — Tests unitaires avec PHPUnit

Le harnais PHPUnit spécifique de Moodle : initialisation (Composer, base de test, admin/tool/phpunit/cli/init.php), écriture de tests avec advanced_testcase et resetAfterTest(), le data generator complet (create_user, create_course, create_module, inscriptions, groupes…), setUser() et les assertions utiles. Tester du code émettant des events, des tâches et des messages grâce aux redirections (sinks), les dataProviders, la couverture d’une external function et des privacy providers, le lancement ciblé des tests, le debugging de tests et l’exécution dans moodle-docker — avec un plugin fil rouge entièrement testé.

Chapitre 4 — Behat et CI/CD

Les tests d’acceptation Behat : initialisation (CLI, profils, Selenium dans moodle-docker), écriture de fichiers .feature en Gherkin en s’appuyant d’abord sur la richesse des steps core, création de steps custom dans un plugin (behat_*.php), tags (@javascript), lancement, filtrage et gestion des tests flaky. Puis la CI/CD complète : moodle-plugin-ci sur GitHub Actions avec un workflow YAML complet (matrice PHP × Moodle × base de données, phplint, phpcs/moodle-cs, phpdoc, savepoints, mustache lint, grunt, phpunit, behat), badges, releases automatisées vers moodle.org et stratégies réalistes de déploiement continu d’une instance.

Chapitre 5 — La Privacy API : Moodle et le RGPD

Les obligations légales européennes appliquées à un LMS, puis l’architecture de la Privacy API : providers de métadonnées, de requêtes et de listes d’utilisateurs. Implémentation complète dans un plugin : null_provider pour les plugins sans données personnelles, provider complet (get_metadata, export_user_data avec le writer, delete_data_for_all_users_in_context / for_user / for_users), traitement des data requests côté administration (export et suppression), tests du provider, exigences du plugin directory, et au-delà de l’API : registre des traitements et politiques de rétention avec tool_dataprivacy.

Chapitre 6 — Le sous-système IA (core_ai)

Le sous-système d’intelligence artificielle apparu en Moodle 4.5 et enrichi jusqu’en 5.2 : architecture providers / actions / placements, configuration admin, politiques d’acceptation et consentement utilisateur. Développement d’un provider custom (brancher l’API Claude d’Anthropic : structure d’un plugin aiprovider_, processeurs d’actions), développement d’un placement custom, bonnes pratiques (maîtrise des coûts, journalisation, confidentialité des données des élèves) et panorama de l’écosystème avec les différences 4.5 → 5.2.

Chapitre 7 — Maintenance et mises à jour d’une instance

Faire vivre une plateforme dans la durée : le cycle de release Moodle et la stratégie de mise à jour (mineures rapides, majeures planifiées), le chemin d’upgrade vers 5.2 (versions intermédiaires requises, environment checks), la procédure complète et scriptée (backup DB + moodledata + code, mode maintenance, bascule de branche stable git, upgrade CLI, gestion des plugins incompatibles), la gestion — à éviter — d’un fork ou de patchs core, les sauvegardes et restaurations d’instance, le monitoring d’une production (cron, tâches en échec, logs) et la maîtrise des données qui grossissent (logs, fichiers orphelins, trashdir).

Chapitre 8 — Publier son plugin sur moodle.org

Le plugin directory de moodle.org de bout en bout : prérequis stricts (licence GPL, privacy provider, code lisible, standards moodle-cs, documentation), le processus de review réel (délais, allers-retours fréquents et comment les éviter), la fiche plugin (description, captures, versions supportées), la gestion des versions publiées (maturité, branches MOODLE_XY), la maintenance d’un plugin communautaire (issues, contributions, traductions AMOS, politique de support), les statistiques d’usage et les modèles de monétisation réalistes dans un écosystème 100 % GPL.

Comment aborder cette partie

L’ordre des chapitres n’est pas arbitraire :

1. Sécurité d’abord (ch. 1) : chaque ligne de code que vous écrirez ensuite doit intégrer ces réflexes. C’est le prérequis de tout le reste — un plugin rapide mais vulnérable n’ira jamais en production.
2. Performance (ch. 2) : une fois le code sûr, il doit tenir la charge. Vous y gagnerez aussi la vision infrastructure indispensable pour dialoguer avec les ops.
3. Tests et CI/CD (ch. 3 et 4) : le filet de sécurité qui rend les deux premiers chapitres durables. Sans tests, chaque upgrade est une loterie.
4. RGPD et IA (ch. 5 et 6) : les deux sujets de conformité et d’innovation qui distinguent aujourd’hui un expert Moodle sur le marché européen.
5. Exploitation et publication (ch. 7 et 8) : la boucle se referme — vous savez construire, vous savez maintenant faire vivre et partager.

⚠️ Piège : ne sautez pas les chapitres tests (3 et 4) sous prétexte que « votre plugin marche ». Le plugin directory exécute des vérifications automatiques, les reviewers regardent la CI, et surtout : chaque nouvelle version majeure de Moodle (2 par an !) peut casser votre code. Sans suite de tests, vous le découvrirez en production.

📚 Aller plus loin : les références permanentes de cette partie sont moodledev.io  (documentation développeur officielle), docs.moodle.org  (documentation admin/utilisateur) et github.com/moodlehq/moodle-plugin-ci  (outillage CI officiel).