Chapitre 13.4 — Construire une offre : QuizLab en micro-SaaS

⏱️ TL;DR — Étude de cas de bout en bout : transformer QuizLab (l’outil LTI Next.js construit en Partie 10) en un micro-SaaS à abonnement. Le plugin-connecteur reste gratuit et GPL sur le directory (il sert de canal de distribution) ; la valeur — l’app Next.js — vit sur votre infra et se paie en abonnement mensuel par établissement. Ce chapitre déroule l’architecture, le modèle freemium, la facturation Stripe, la remontée de notes AGS, et un go-to-market en 90 jours. C’est un patron réplicable pour votre produit.

🎯 Objectifs

• Voir l’architecture complète d’un SaaS LTI multi-tenant greffé sur Moodle.
• Concevoir un découpage freemium qui convertit sans frustrer.
• Brancher une facturation par abonnement (Stripe) sur des établissements.
• Dérouler un go-to-market concret et un P&L simplifié.

⚠️ Ce chapitre est stratégique + architectural, pas un tuto pas-à-pas : le code LTI/AGS/NRPS est en Partie 10, le code Next.js en Parties 9–10. Ici on assemble le tout en produit qui facture.

1. Le produit en une phrase

QuizLab = une banque de questions et un moteur de quiz modernes (UI React, types de questions riches, correction et analytics), branchés dans n’importe quel Moodle via LTI 1.3, hébergés en SaaS et facturés à l’établissement par abonnement.

Pourquoi ça se vend : le quiz natif de Moodle est puissant mais daté et rigide. Beaucoup d’enseignants veulent mieux (UX, types de questions, feedback) sans que l’établissement change de LMS. QuizLab se greffe — pas de migration, adoption indolore.

2. Architecture multi-tenant

Points d’architecture qui font le SaaS :

• Multi-tenant par deployment_id — chaque Moodle client = un tenant. À chaque lancement LTI, le JWT porte l’iss/client_id/deployment_id : vous isolez les données par tenant (Partie 10). Un seul déploiement Next.js sert tous les clients.
• Le plugin côté Moodle est mince et gratuit — il ne fait que configurer l’outil externe LTI (URL, clés, deep linking). Il est GPL sans enjeu : toute la valeur est côté serveur (ch. 13.3).
• Remontée de notes via AGS — quand l’étudiant finit un quiz, QuizLab repousse la note dans le carnet Moodle (Assignment and Grade Services, Partie 10). C’est la fonctionnalité qui rend l’outil « natif » aux yeux de l’enseignant, et un argument de vente majeur.
• Provisioning automatique — un nouvel établissement branche l’outil (deep linking) → un tenant se crée tout seul → il démarre en plan gratuit. Zéro action manuelle de votre part : c’est ça qui scale.

💡 Pour un dev React — Vous connaissez déjà 90 % de cette stack (Next.js App Router, Server Actions, une base Postgres, Stripe). La seule brique « Moodle » est la poignée de main LTI 1.3 + AGS (Partie 10). Votre courbe d’apprentissage produit est courte : c’est votre avantage décisif sur un éditeur EdTech classique.

3. Découpage freemium (le nerf de la conversion)

Le gratuit doit être vraiment utile (adoption) mais plafonner là où naît la valeur pro (conversion).

⚠️ Piège — le gratuit trop généreux ou trop pauvre. Trop généreux → personne ne paie. Trop pauvre → personne n’adopte, pas de bouche-à-oreille. Le curseur juste : le gratuit résout le cas d’un enseignant isolé ; le payant résout le cas de l’établissement (partage, analytics, marque, garantie). On paie quand on passe de « moi » à « nous ».

4. Pricing & facturation

Facturez l’établissement, pas l’enseignant. En éducation, l’acheteur est l’établissement/le service formation ; un prix par enseignant fragmente et plafonne bas.

Grille indicative (à valider sur le marché) :

Facturation technique :

• Stripe Billing — abonnements mensuels/annuels, essais, upgrades/downgrades gérés. Vous connaissez déjà.
• Annuel privilégié en éducation — les établissements fonctionnent par budget annuel et bon de commande. Proposez -2 mois sur l’annuel : trésorerie + churn quasi nul.
• Bon de commande / virement pour les gros (le paiement carte bloque les marchés publics). Prévoyez une facture propre en plus de Stripe.

Le churn en éducation est votre allié. Une fois QuizLab utilisé dans des cours, le retirer casse les cours existants → coût de sortie élevé → les clients restent des années. C’est ce qui rend le MRR prévisible malgré un marché de niche (ch. 13.3).

5. Go-to-market en 90 jours

Jours 0–30 — MVP + pilotes. Version minimale : lancement LTI, 3 types de questions, AGS, plan gratuit. Recrutez 3 établissements pilotes (vos clients freelance de ch. 2, ou des contacts forums) en gratuit contre feedback + témoignage. Objectif : ça tourne en prod chez quelqu’un.

Jours 30–60 — Ouverture freemium. Publiez le plugin-connecteur gratuit sur le directory (ch. 11.8) — c’est votre canal de distribution : chaque install est un tenant potentiel. Activez le plan Pro + Stripe. Contenu : une démo publique, un article « moderniser vos quiz Moodle sans changer de LMS », posts LinkedIn.

Jours 60–90 — Conversion. Relancez les tenants gratuits actifs (ils utilisent → ils ont la douleur du plafond) vers le Pro. Transformez les pilotes en études de cas chiffrées (« +X% de complétion »). Chaque étude de cas alimente la vente suivante.

Le moteur : plugin gratuit sur le directory → tenants gratuits → usage → plafond → conversion Pro → étude de cas → plus de tenants. Ça compose.

6. P&L simplifié (pour poser les idées)

Coûts d’un tel SaaS, volontairement bas (c’est l’intérêt du modèle) :

• Infra : un déploiement Next.js (Vercel/VPS) + une base Postgres. Quelques dizaines d’€/mois au début, scale avec les clients.
• Stripe : ~1,5–3 % + commission par transaction. Négligeable vs le ticket.
• Votre temps : dev initial (le gros), puis support + compat. Moodle (2 upgrades/an à tester, ch. 11.4).

Le seuil de rentabilité arrive vite : quelques établissements Pro couvrent l’infra ; au-delà, chaque client est quasi marge pure (coût marginal ~0). C’est la magie du SaaS de niche : peu de clients, faible coût, churn faible → MRR net qui monte doucement mais sûrement.

Comparé au freelance : 20 j de mission = 20 j de revenu, puis fini. 20 j pour construire QuizLab = un revenu qui continue et s’additionne à chaque nouveau client. Même effort, actif vs consommable. C’est le basculement de cette Partie 13.

✏️ Exercices

1. Tracez l’architecture de votre propre idée de SaaS LTI (pas QuizLab) : où vit la valeur ? Qu’est-ce qui reste dans le plugin gratuit ? Quelle est la donnée par tenant ?
2. Dessinez votre grille freemium : quelle fonction précise fait basculer « moi » → « nous » (donc gratuit → payant) ?
3. Écrivez le pitch de 2 phrases de votre produit (« X = [quoi], branché dans n’importe quel Moodle via LTI, facturé [comment] »).

🧠 Points-clés

• Patron réplicable : plugin gratuit (distribution) + app Next.js hébergée (valeur) + abonnement (récurrent).
• Multi-tenant par deployment_id LTI ; provisioning auto = ça scale sans vous.
• AGS (remontée de notes) rend l’outil « natif » → argument de vente clé.
• Freemium : le gratuit résout « moi », le payant résout « nous ».
• Facturez l’établissement, à l’année, avec facture/BC pour le public ; churn faible = MRR prévisible.
• GTM 90 jours : pilotes → directory/freemium → conversion + études de cas, moteur qui compose.
• 20 j de freelance = revenu consommable ; 20 j de produit = actif qui s’additionne.

Chapitre suivant : 05 — Cadre pratique : cumuler avec un CDD.