Projet Niveau 5 (capstone) — QuizLab : outil LTI externe en Next.js

⏱️ TL;DR — Le capstone et le sommet de votre double compétence : un outil externe LTI 1.3 écrit en Next.js, lancé depuis un cours Moodle, qui affiche un quiz interactif et renvoie la note dans le carnet de notes (grade passback). C’est l’architecture d’un vrai micro-SaaS revendable (Partie 13) : Moodle = plateforme, QuizLab = tool hébergé chez vous, consommé par n’importe quel LMS compatible LTI. Vous bouclez la chaîne intégration standard → produit récurrent.

🎯 Niveau & objectifs

• Niveau : 5 (capstone). Prérequis : Niveau 4 (intégration externe) ; solide Next.js ; notions OAuth2/JWT.
• Durée indicative : 20–40 h (vrai mini-produit).
• Vous allez pratiquer : LTI 1.3 Advantage (enregistrement, launch OIDC, JWT/JWKS), Deep Linking, AGS (Assignment & Grade Services) pour le grade passback, NRPS (roster) en option, hébergement d’un tool Next.js multi-tenant, sécurité inter-domaines.

📋 Cahier des charges

Contexte — Vous voulez vendre un outil de quiz interactif indépendant de Moodle, utilisable par n’importe quel LMS via LTI. QuizLab s’enregistre comme outil externe, se lance depuis un cours, et pousse les scores dans le carnet de notes du LMS.

Objectif — Un outil LTI 1.3 fonctionnel de bout en bout : enregistrement, lancement sécurisé, activité, remontée de note.

Périmètre inclus

1. Enregistrement LTI 1.3 entre Moodle (plateforme) et QuizLab (tool) : URLs de login/launch/redirect, clés (JWKS), client id, deployment id.
2. Launch OIDC : Moodle initie le login, QuizLab valide le JWT de lancement (signature via JWKS, claims, nonce, deployment_id).
3. Deep Linking : depuis le cours, l’enseignant choisit/configure un quiz QuizLab qui s’insère comme activité.
4. Une UI de quiz Next.js (App Router) : l’apprenant répond, obtient un score.
5. Grade passback (AGS) : QuizLab crée/associe une line item et renvoie le score dans le carnet de notes Moodle.
6. Multi-tenant (au moins conceptuellement) : le tool gère plusieurs déploiements/plateformes via leur configuration.
7. Sécurité : validation stricte des JWT, gestion des nonces/état, secrets côté serveur, HTTPS.

Périmètre exclu — Pas de facturation réelle ni de mise en marché (on construit la capacité technique, la monétisation est traitée en Partie 13). NRPS (récupération de la liste des inscrits) en bonus seulement.

Contraintes

• Conformité LTI 1.3 / LTI Advantage (pas LTI 1.1 legacy).
• Validation complète du JWT de launch (signature, iss, aud, exp, nonce, deployment_id) — aucune confiance aveugle.
• Les clés privées / secrets côté serveur uniquement.
• Le grade passback doit réellement apparaître dans le carnet de notes Moodle.

Livrables

• Le dépôt Next.js QuizLab (tool LTI).
• La configuration d’enregistrement côté Moodle (documentée, reproductible).
• Un README d’architecture : séquence de launch (schéma), AGS, sécurité, et un GO-TO-MARKET.md (repris de Partie 13.4).

✅ Critères de réussite

• Depuis un cours Moodle, un clic lance QuizLab et affiche le quiz pour l’apprenant connecté.
• Le JWT de launch est validé (une signature ou un nonce invalide est rejeté).
• Le Deep Linking permet à l’enseignant d’insérer un quiz configuré.
• Le score obtenu apparaît dans le carnet de notes du cours (AGS).
• Les secrets ne sont jamais exposés côté client.
• Le tool peut, en principe, servir plusieurs plateformes (config par déploiement).

🗺️ Endroits à visiter

💡 Pour un dev React — LTI 1.3 est de l’OAuth2/OIDC + JWT que vous connaissez : un launch = un flux OIDC signé, un grade passback = un appel REST authentifié (AGS). La partie React/Next.js (l’UI du quiz, le multi-tenant, le déploiement) est votre terrain. Le vrai apprentissage : orchestrer proprement la séquence de launch et valider les JWT sans faille. Une fois ce squelette en place, QuizLab fonctionne avec n’importe quel LMS LTI — c’est ce qui en fait un produit (un tool, N plateformes clientes) et non une simple intégration Moodle.

⚠️ Piège — la validation du JWT. Le point de sécurité critique de LTI : jamais faire confiance à un launch sans vérifier la signature (via JWKS de la plateforme), l’iss, l’aud, l’exp, le nonce (anti-rejeu) et le deployment_id. Un tool qui saute une de ces vérifications est exploitable. Traitez cette validation comme le cœur sécurité du produit, pas comme une formalité.

🚀 Étapes suggérées

1. Poser l’archi QuizLab (Next.js) : routes login, launch, deep-link, jwks.
2. Enregistrer le tool dans Moodle (Outil externe) ; échanger les clés (JWKS).
3. Implémenter le launch OIDC + validation stricte du JWT.
4. Rendre l’UI du quiz pour l’apprenant lancé.
5. Deep Linking : sélection/config d’un quiz par l’enseignant.
6. AGS : créer la line item + envoyer le score → vérifier dans le carnet de notes.
7. Multi-tenant : configuration par déploiement.
8. Documenter la séquence + GO-TO-MARKET.md.

🎁 Bonus

• Ajoutez NRPS (récupérer la liste des inscrits) pour un tableau de bord enseignant.
• Rendez QuizLab multi-LMS en testant le launch depuis un second client LTI.
• Esquissez le modèle SaaS : plans, quotas, isolation des données par tenant (Partie 13.4).

🔗 Chapitres du cours liés

• Partie 10 — LTI (Learning Tools Interoperability)
• Partie 13 — Monétiser sa double compétence Moodle × Next.js · construire l’offre SaaS/LTI

🎓 Fin du parcours Moodle. Vous êtes passé de « je monte un cours dans l’interface » à « j’héberge un outil LTI qui renvoie des notes à n’importe quel LMS ». Les six projets forment un portfolio progressif — la preuve concrète de votre double compétence Moodle × Next.js, celle qui décroche missions et clients (Partie 13). Retour à la vue d’ensemble.