Chapitre 13.3 — Produits qui rapportent de façon récurrente

⏱️ TL;DR — Un plugin Moodle est GPL : vous ne pouvez pas vendre de licence propriétaire. Mais la GPL n’interdit pas de gagner de l’argent, et surtout pas du récurrent — elle interdit juste de faire payer le code. Vous vendez donc un service autour du code : SaaS/outil LTI hébergé (le meilleur pour un dev Next.js), abonnement support/maintenance, hébergement géré, sponsors, freemium hébergé. Le levier gagnant pour votre profil : héberger vous-même un outil LTI ou une app connectée et facturer l’accès par abonnement — le code peut être libre, le service est payant et récurrent.

🎯 Objectifs

• Comprendre ce que la GPL autorise et interdit vraiment (démonter le mythe « GPL = gratuit »).
• Connaître les 6 modèles de revenu récurrent compatibles, avec leurs forces/faiblesses.
• Savoir lequel colle à votre profil Next.js/React (et pourquoi).
• Avoir des chiffres réalistes : pas de fantasme « MRR passif », pas de défaitisme.

1. La GPL, sans le mythe

Tout code qui require du code Moodle hérite de la GPL v3+. Conséquence directe :

• ❌ Vous ne pouvez pas vendre une licence qui interdit à l’acheteur de redistribuer le plugin. Pas de « licence propriétaire par site ».
• ❌ Vous ne pouvez pas empêcher quelqu’un qui a reçu votre plugin de le repartager gratuitement.
• ✅ Vous pouvez vendre le plugin (rien n’oblige à le donner) — mais l’acheteur pourra le rediffuser, donc ce modèle « one-shot payant » fuit vite.
• ✅ Vous pouvez vendre tout service autour : hébergement, support, mises à jour garanties, formation, personnalisation, et l’accès à un service hébergé.

Le déclic : la GPL couvre le code qui tourne chez le client. Elle ne couvre pas un service que vous hébergez (SaaS). Si le cœur de valeur vit sur votre serveur (une app Next.js, un backend LTI), le client paie l’accès — récurrent — et la question de la licence du petit plugin-connecteur devient secondaire. C’est le loophole légitime des devs web dans l’écosystème GPL, et c’est exactement votre terrain.

2. Les 6 modèles de revenu récurrent

Modèle 1 — SaaS / outil LTI hébergé ⭐ (le meilleur pour vous)

Vous développez un outil (une app Next.js) que les Moodle des clients consomment via LTI (Partie 10) ou web services (Partie 9). Le connecteur côté Moodle peut être un petit plugin GPL gratuit ; la valeur (l’app, les données, le traitement) vit sur votre infra. Les clients paient un abonnement pour y accéder.

• Récurrence : native (abonnement mensuel/annuel par établissement ou par usage).
• Scale : excellent — un nouveau client = ~0 travail supplémentaire.
• GPL : non-problème (le service hébergé n’est pas distribué).
• Votre avantage : c’est littéralement ce que le cours vous a appris à construire (QuizLab, ch. 10 et 13.4).
• Coût : il faut construire un vrai produit + gérer l’infra, la facturation, le support.

C’est le modèle détaillé de bout en bout au chapitre 13.4.

Modèle 2 — Abonnement support & maintenance

Votre plugin est gratuit sur le directory ; vous vendez un abonnement qui garantit : support prioritaire, compatibilité assurée à chaque version Moodle (2×/an), corrections rapides. Les établissements paient pour la tranquillité et la garantie de non-rupture aux upgrades.

• Récurrence : oui (annuel surtout).
• Scale : moyen (le support prend du temps humain).
• Cible : établissements qui ne peuvent pas se permettre qu’un plugin casse en prod.

Modèle 3 — Hébergement géré

Vous hébergez et exploitez le Moodle (ou une brique) du client : install, upgrades, sauvegardes, monitoring, un abonnement mensuel. Business classique et solide, mais capitalistique (infra, astreinte) et concurrencé par les gros hébergeurs. Plus pertinent adossé à un produit (Modèle 1) qu’en pur hébergement générique.

Modèle 4 — Freemium hébergé (open-core côté service)

Le plugin/outil de base est gratuit ; les fonctions avancées vivent sur votre service payant. Ex : un plugin d’analytics gratuit qui affiche des stats basiques, mais les tableaux de bord riches, l’export, l’IA sont servis par votre backend sur abonnement. Combine adoption large (gratuit) et conversion (payant).

• Récurrence : oui. Scale : bon. Demande d’équilibrer finement gratuit/payant.

Modèle 5 — Sponsors / soutien récurrent

GitHub Sponsors, Open Collective, Patreon sur un plugin populaire et bien maintenu. Des établissements et agences qui dépendent de votre plugin financent sa maintenance.

• Récurrence : oui, mais modeste et lente à construire. Rarement un revenu principal ; plutôt un complément qui récompense la popularité.
• Réaliste : significatif seulement si votre plugin est très utilisé.

Modèle 6 — Thème premium + abonnement

Un thème soigné (Partie 8) distribué avec un abonnement donnant droit aux mises à jour, variantes, et support. Comme pour les plugins, vous ne « verrouillez » pas le code (GPL) mais vendez updates + support + service en continu. Marché plus petit que les outils fonctionnels, mais votre compétence front (React/Tailwind dans un thème, Partie 7–8) permet des thèmes que les intégrateurs classiques ne savent pas faire.

Tableau comparatif

💡 Pour un dev React — Vos deux modèles naturels sont 1 (SaaS/LTI hébergé) et 4 (freemium hébergé). Tous deux mettent la valeur sur votre infra Next.js, ce qui (a) contourne proprement la contrainte GPL, (b) exploite exactement votre compétence, (c) crée du vrai récurrent qui scale. Les modèles 2/3/5 sont des compléments, pas votre cœur.

3. Chiffres réalistes (ni fantasme, ni défaitisme)

• Le récurrent démarre lentement. Les premiers mois d’un SaaS/plugin : quasi zéro. La courbe est plate longtemps, puis compose. Ne jugez pas à 3 mois.
• Peu de clients, ticket correct. Le marché Moodle est de niche : vous n’aurez pas 10 000 clients grand public. Mais un établissement paie bien et reste longtemps (churn faible en éducation). 20–50 établissements à quelques dizaines d’€/mois = un complément de salaire réel et stable.
• B2B éducation = cycles longs mais fidèles. La vente est lente (budgets, validations), mais une fois installé, un client Moodle part rarement (coût de changement élevé). Le churn faible est le cadeau de cette niche : votre MRR fuit peu.
• Ordre de grandeur d’un « complément » atteignable : viser un MRR (revenu mensuel récurrent) qui remplace une partie du salaire, pas une licorne. Quelques milliers d’€/mois de récurrent avec un produit de niche bien placé est un objectif crédible sur 12–24 mois de travail régulier — pas garanti, pas en un trimestre.

⚠️ Piège — le mirage du « revenu 100 % passif ». Aucun de ces modèles n’est passif. Un SaaS demande support, maintenance, compatibilité à chaque version Moodle, ventes. « Récurrent » ≠ « sans travail » : ça veut dire que le revenu ne repart pas de zéro chaque mois, pas qu’il tombe seul. Le bon cadre mental : le produit découple le revenu de vos heures, il ne le rend pas gratuit.

4. La séquence recommandée (freelance → produit)

Ne construisez pas un produit dans le vide. Laissez le freelance (ch. 2) vous montrer quel produit :

1. En mission, notez ce que plusieurs clients demandent la même chose (« encore quelqu’un qui veut ses notes dans son app »).
2. Ce problème récurrent + payé = candidat produit validé (vous avez déjà la preuve que ça se vend).
3. Construisez-le en modèle hébergé (1 ou 4). Vos clients freelance deviennent vos premiers abonnés — validation et revenu immédiats.
4. Le freelance finance le temps de dev du produit ; le produit réduit votre dépendance au freelance. Transition en douceur, sans quitter votre CDD (ch. 5).

✏️ Exercices

1. Vrai ou faux : « Comme les plugins Moodle sont GPL, on ne peut pas en tirer de revenu récurrent. » Justifiez.
2. Parmi les 6 modèles, choisissez les 2 qui collent le mieux à un dev Next.js et dites pourquoi en une phrase chacun.
3. Imaginez un produit hébergé à partir d’un besoin vu dans le cours (notes, progression, quiz externe…). Où vit la valeur ? Qu’est-ce que le client paie chaque mois ?

🧠 Points-clés

• GPL interdit de vendre le code en propriétaire, pas de gagner du récurrent via le service.
• 6 modèles ; pour vous, les deux gagnants sont SaaS/LTI hébergé et freemium hébergé (valeur sur votre infra Next.js).
• Support/maintenance, hébergement, sponsors, thème premium = compléments, pas le cœur.
• Chiffres : démarrage lent, marché de niche mais churn faible ; viser un complément stable sur 12–24 mois, pas une licorne.
• Aucun modèle n’est passif ; « récurrent » = ne repart pas de zéro chaque mois.
• Séquence gagnante : freelance révèle le problème récurrent → produit hébergé → MRR.

Chapitre suivant : 04 — Construire une offre : QuizLab en SaaS.