Chapitre 11.8 — Publier son plugin sur moodle.org

Partie 11 : Niveau expert — Chapitre 8/8 Public : dev ayant un plugin prêt (Parties 6–8) et voulant le partager avec la communauté. Version de référence : Moodle 5.2.

⏱️ TL;DR

• Le plugin directory (moodle.org/plugins ) est le canal officiel. Publier = passer une review humaine exigeante, pas un simple upload.
• Prérequis non négociables : licence GPL v3+, privacy provider (même null_provider), code aux standards moodle-cs, PHPDoc, CI verte (moodle-plugin-ci), documentation.
• Process de review : soumission → relecture par un humain → allers-retours fréquents (délais de plusieurs semaines) → approbation. Anticiper les demandes réduit le nombre d’itérations.
• La fiche plugin : description claire, captures d’écran (attendues), versions de Moodle supportées, dépôt et tracker.
• Versions publiées : à chaque nouvelle release, on téléverse (ou la CI publie) une version, en déclarant maturité et branches supportées (supported, ch. 6.7).
• Maintenir un plugin communautaire : issues, contributions, traductions AMOS, politique de support — c’est un engagement dans la durée.
• Monétisation : possible en restant GPL (support, hébergement, versions « pro » de services), jamais en vendant une exclusivité du code.

🎯 Objectifs

• Réunir les prérequis de publication (GPL, privacy, standards, CI).
• Comprendre le processus de review et le préparer.
• Rédiger une fiche plugin efficace et gérer les versions publiées.
• Maintenir un plugin communautaire (issues, AMOS, support).
• Situer les modèles de monétisation réalistes en écosystème GPL.

1. Publier ≠ uploader

Le plugin directory n’est pas npm (ch. 1.4) : on ne publie pas en une commande. C’est un processus éditorial avec review humaine. Un relecteur bénévole/HQ examine votre code, teste l’installation, vérifie les standards, et dialogue avec vous jusqu’à ce que le plugin soit prêt. Comptez plusieurs semaines et des allers-retours — c’est normal, et c’est ce qui maintient la qualité du directory.

Corollaire : plus votre plugin arrive préparé (standards, tests, privacy, doc), moins il y a d’itérations. Ce chapitre est une checklist pour arriver prêt.

2. Les prérequis non négociables

Réunissez tout ceci avant de soumettre :

⚠️ Piège n°1 de rejet : soumettre sans privacy provider. Même un thème ou un filtre qui ne stocke rien doit implémenter null_provider (ch. 11.5). L’absence de provider est une cause de rejet automatique, pas un oubli mineur.

⚠️ Piège n°2 : soumettre avec des erreurs moodle-cs ou une CI rouge. Les reluceteurs regardent la CI ; un code non conforme au coding style rallonge la review de plusieurs itérations. Faites tourner moodle-plugin-ci avant de soumettre et corrigez tout.

💡 Pour un dev React : c’est un package open source publié avec review, mais plus strict que npm : licence imposée (GPL), conformité RGPD (privacy provider) et coding style vérifiés par un humain, sur une matrice de versions. Traitez la soumission comme une PR vers un projet exigeant : lint vert, tests verts, doc, avant de demander la relecture.

3. Le processus de review, concrètement

1. Compte + dépôt : un compte moodle.org, un dépôt public (souvent GitHub) contenant le plugin, avec des releases taguées.
2. Soumission : sur moodle.org/plugins, « Register a new plugin » — vous renseignez le dépôt, le type, la description, les versions supportées.
3. File d’attente de review : un relecteur prend le plugin (délai variable, souvent semaines).
4. Allers-retours : le relecteur signale les problèmes (standards, sécurité, privacy, installation, doc). Vous corrigez, poussez, répondez. Itérez.
5. Approbation : le plugin est publié ; sa fiche devient visible et il apparaît dans les recherches.

Réduire les allers-retours : arriver avec la checklist du §2 remplie, une CI verte publique (le relecteur la regarde), et un code lisible (un relecteur comprend vite un code standard). Répondez rapidement et précisément aux demandes.

⚠️ Piège : disparaître entre deux allers-retours. Une review avec un mainteneur qui ne répond pas stagne et peut être fermée. Traitez la review comme un échange actif ; la réactivité raccourcit tout le processus.

4. La fiche plugin

Une fois approuvé, votre plugin a une fiche — sa vitrine (ch. 1.4). Soignez :

• Description claire : à quoi sert le plugin, pour qui, en une lecture.
• Captures d’écran : attendues, surtout pour un thème/bloc/activité (l’aspect visuel décide). Une fiche sans capture inspire peu confiance.
• Versions de Moodle supportées : la grille de compatibilité (déclarée via supported, ch. 6.7) — le premier critère qu’un adoptant regarde.
• Liens : dépôt de code, tracker d’issues, documentation. (Rappel ch. 1.4 : les bugs du plugin vont dans son tracker, jamais dans MDL.)
• Maturité : Alpha / Beta / RC / Stable — honnête.

5. Gérer les versions publiées

À chaque nouvelle release de votre plugin :

• Bumper version.php (ch. 6.7) et taguer la release dans git.
• Publier la nouvelle version sur la fiche : téléversement manuel, ou — mieux — automatisé via la CI (moodle-plugin-ci peut publier une release vers le directory sur un tag).
• Déclarer les branches supportées (supported, ch. 6.7) : n’annoncez que ce que vous testez (matrice CI, ch. 11.4).
• Maturité par version : une nouvelle version majeure peut repartir en Beta le temps de se stabiliser.

Le directory garde l’historique des versions : un adoptant sur Moodle 5.1 peut télécharger la version compatible, un adoptant sur 5.2 la sienne. C’est le pendant, côté publication, de la stratégie de branches du chapitre 6.7.

6. Maintenir un plugin communautaire

Publier crée un engagement. Un plugin vivant demande :

• Suivre les issues : les utilisateurs remontent bugs et demandes dans votre tracker. Répondre, trier, corriger.
• Suivre les versions de Moodle : deux fois par an, tester et publier une version compatible (ch. 6.7 + 11.4). Un plugin non maintenu décroche et perd sa confiance (ch. 1.4).
• Accepter des contributions : PR de la communauté, dans le respect des standards (moodle-cs, tests).
• Traductions via AMOS : la plateforme de traduction de Moodle (ch. 1.4). Vos chaînes anglaises (lang/en/) y sont traduites par la communauté dans ~100 langues — vous n’écrivez pas les traductions, vous exposez des chaînes propres et AMOS fait le reste. Suivez les guidelines AMOS (clés stables, pas de HTML inutile).
• Politique de support : soyez clair sur ce que vous supportez (versions, canal, délais). Un plugin sans support annoncé déçoit ; un plugin honnête sur ses limites est respecté.

⚠️ Piège : publier puis abandonner. Un plugin non maintenu casse à la première majeure de Moodle, accumule des issues sans réponse, et nuit à votre réputation. Ne publiez que ce que vous pouvez maintenir — ou déclarez clairement l’abandon et cherchez un repreneur.

7. Monétiser en écosystème 100 % GPL

Peut-on gagner de l’argent avec un plugin Moodle ? Oui — mais en restant GPL (tout le directory l’est, ch. 1.4). Les modèles réalistes :

• Support et maintenance payants : le code est libre, vous vendez l’assistance, les corrections prioritaires, la garantie de compatibilité.
• Développement sur mesure : un plugin GPL vitrine attire des clients pour des prestations (adaptations, intégrations).
• Hébergement / SaaS : proposer le plugin dans une offre hébergée gérée.
• Versions « pro » / add-ons : certains vendent des fonctionnalités avancées sous GPL avec un modèle d’abonnement au service (mises à jour, support), pas à une licence exclusive du code. (C’est le modèle des thèmes premium, ch. 8.5.)

Ce qui ne marche pas : vendre une licence propriétaire ou empêcher la redistribution — la GPL l’interdit. Vous ne vendez jamais l’exclusivité du code ; vous vendez le service autour (support, mises à jour, hébergement, sur-mesure). C’est le modèle « open-core + services » que vous connaissez déjà côté JS.

💡 Pour un dev React : identique au modèle économique des libs open source à succès — le code est gratuit, la valeur est dans le support, les mises à jour, l’hébergement, le sur-mesure. Un plugin GPL bien maintenu et bien documenté est un actif commercial (visibilité, crédibilité, leads), même sans vente de licence.

8. Synthèse de la Partie 11

Publier un plugin = arriver prêt (GPL, privacy provider, moodle-cs vert, CI, doc) à une review humaine exigeante, soigner la fiche (captures, versions supportées), gérer les versions publiées (tag → CI → release), puis maintenir dans la durée (issues, AMOS, suivi des versions de Moodle) — un engagement, monétisable en restant GPL (services, pas licence).

Avec ce chapitre s’achève la Partie 11 — le niveau expert : sécurité (11.1), performance (11.2), tests (11.3) et CI/CD (11.4), RGPD (11.5), IA (11.6), exploitation (11.7) et publication (11.8). Vous savez désormais non seulement construire pour Moodle, mais le faire sûr, rapide, testé, conforme, exploité et partagé — la différence entre livrer une feature et prendre la responsabilité d’une plateforme.

✏️ Exercices

Exercice 1 — Prêt pour la soumission ? Un dev veut publier son bloc. Il a : code fonctionnel, version.php, chaînes EN. Que lui manque-t-il impérativement ?

Exercice 2 — Rejet immédiat. Une soumission est rejetée d’emblée alors que « le code marche ». Quelle est la cause la plus probable ?

Exercice 3 — Réduire les allers-retours. Comment minimiser le nombre d’itérations de review ?

Exercice 4 — Traductions. Vous ne parlez que français et anglais. Comment votre plugin sera-t-il disponible en espagnol, allemand, etc. ?

Exercice 5 — Gagner de l’argent. Un client veut « acheter une licence exclusive » de votre plugin Moodle. Que répondez-vous, et quels modèles proposez-vous ?

🧠 Quiz de révision

Q1. En quoi publier sur le plugin directory diffère-t-il d’un npm publish ?

Q2. Citez quatre prérequis non négociables de publication.

Q3. Que doit contenir une bonne fiche plugin ?

Q4. Comment gère-t-on les versions publiées dans le temps ?

Q5. Peut-on monétiser un plugin Moodle, et comment ?

Fin de la Partie 11. Vous maîtrisez le niveau expert : sécuriser, optimiser, tester, industrialiser (CI/CD), respecter le RGPD, exploiter l’IA, faire vivre une instance et publier vos plugins. C’est le sommet du parcours — de « je sais faire une feature » à « on me confie une plateforme ».

Partie suivante : Partie 12 — Annexes — les références à garder ouvertes : glossaire trilingue, cheatsheets copiables, top des pièges et FAQ, ressources annotées, et parcours de carrière. À consulter plus qu’à lire, au quotidien.