Terrain 18 — LTI & headless (Next.js)

En LTI, la plateforme (Moodle) lance un outil externe (ton app). L’outil s’affiche intégré, reçoit qui/où, et peut renvoyer une note. Moodle peut être les deux (plateforme via mod_lti, ou outil via enrol/lti). Ici : Moodle = plateforme, QuizLab = outil.

L’activité Outil externe (mod_lti) intègre un outil LTI dans un cours. C’est via elle que l’étudiant lance QuizLab. Les outils se préconfigurent au niveau site (jeu 3) puis s’ajoutent aux cours.

On saisit l’URL de lancement, l’URL de login/redirect, et l’URL des clés publiques (JWKS) de l’outil. Moodle fournit en retour ses propres endpoints + un client id et deployment id. C’est l’appariement des deux parties.

Chaque partie publie ses clés publiques (JWKS .well-known) pour que l’autre vérifie les signatures des JWT. Le client id identifie l’outil auprès de la plateforme ; le deployment id identifie un déploiement précis. Socle cryptographique du launch (jeu 10).

Depuis le cours, un clic lance l’outil : Moodle initie le flux OIDC, l’outil s’affiche (intégré ou nouvelle fenêtre) en connaissant l’utilisateur et le contexte. C’est le cœur de l’expérience LTI. Teste en « se connectant en tant qu’ » étudiant.

Le JWT de launch (id_token) porte l’identité et le contexte. L’outil doit le valider avant tout (jeu 10). Flux OIDC classique, appliqué à l’éducation.

Le Deep Linking laisse l’enseignant, depuis Moodle, ouvrir l’outil pour sélectionner/configurer un contenu (un quiz précis), qui revient s’insérer comme activité. Deux flux : deep link (config) et resource link (lancement). Confort enseignant majeur.

AGS (Assignment & Grade Services) : l’outil crée/associe une line item et POST le score → il apparaît dans le carnet de notes (terrain 07). Appel REST authentifié par un jeton OAuth2 obtenu via les clés. La note « boucle » de l’outil vers Moodle.

NRPS (Names and Role Provisioning Services) permet à l’outil de lire la liste des participants et leurs rôles — pour un tableau de bord enseignant dans QuizLab. Optionnel mais puissant. Complète le trio LTI Advantage (launch + AGS + NRPS).

Jamais faire confiance à un launch sans vérifier : signature (via JWKS de Moodle), iss, aud, exp, nonce (anti-rejeu), deployment_id. Un outil qui saute une vérif est exploitable. C’est le cœur sécurité du produit (terrain 16, mentalité).

QuizLab (App Router) expose : /api/lti/login (init OIDC), /api/lti/launch (reçoit et valide le JWT), /.well-known/jwks.json (tes clés publiques), /api/lti/deep-link. Une lib LTI 1.3 (ltijs, ou custom) gère le protocole. Ton terrain : le reste est du Next.js.

Une fois le launch validé, tu es en plein React : composants de quiz, état, timer, UI moderne. C’est là que ta compétence brille (bien au-delà de ce que fait un quiz Moodle natif). L’identité/contexte viennent du JWT validé.

Score calculé → obtention d’un access token OAuth2 (client credentials, signé avec ta clé privée) → POST vers l’endpoint scores de la line item. Vérifie que la note apparaît dans le carnet Moodle (terrain 07). La boucle est fermée.

Un vrai outil LTI stocke la config par plateforme/déploiement (issuer, client id, clés, endpoints) et route chaque launch vers le bon tenant. Ainsi le même QuizLab sert Moodle A, Moodle B, Canvas… C’est ce qui en fait un produit (1 outil, N clients), pas une intégration jetable.

La clé privée de signature, les client secrets : jamais dans le bundle client — uniquement en variables d’environnement, utilisées dans les routes serveur. HTTPS partout. Même hygiène que les web services (terrain 17, jeu 19), enjeu encore plus fort.

LTI gère launch + identité + note ; les web services (terrain 17) donnent l’accès aux données (cours, participants). Un outil riche combine les deux : LTI pour l’intégration, WS pour la data. Ton pont Moodle↔moderne complet.

Un client LTI de référence (1EdTech LTI RI) simule une plateforme → tu débogues le launch/validation/AGS isolément, sans dépendre de Moodle. Puis tu valides le vrai launch depuis Moodle. Méthode pro pour un protocole complexe.

Via enrol/lti, Moodle peut être l’outil : publier un cours/activité consommable par un autre LMS. Utile pour vendre du contenu Moodle à des tiers. Le protocole est symétrique — savoir les deux sens élargit tes options business.

Un outil LTI multi-tenant + facturation (abonnement par établissement, quotas de quiz) = un micro-SaaS récurrent (QuizLab, Partie 13). Standard LTI = portabilité (tout LMS compatible). C’est le débouché premium de ta double compétence Moodle × Next.js.

Tu as bâti un outil LTI headless en Next.js branché sur Moodle — le sommet de ta double compétence, et un produit revendable (projet Niveau 5, Partie 13). Tu as bouclé les 18 terrains : de « je découvre Moodle » à « j’héberge un micro-SaaS LTI ». 🎉

Et maintenant ? Enchaîne sur les projets guidés : ils assemblent tous ces réflexes en réalisations complètes et monétisables.