Chapitre 10.4 — Moodle en tant qu’outil : « Publish as LTI tool »

Dans le chapitre 3, Moodle jouait la plateforme : il consommait des outils externes (notre QuizLab Next.js s’y lançait). On retourne maintenant la carte. Ici, Moodle est l’outil (tool, côté fournisseur / provider) : une autre plateforme — un second Moodle, un Canvas, ou même votre app Next.js jouant cette fois le rôle de plateforme — lance à distance un cours ou une activité Moodle, avec authentification transparente des utilisateurs et remontée des notes dans l’autre sens.

C’est un besoin très concret : une organisation qui possède un catalogue de cours Moodle veut les exposer dans le LMS d’un partenaire, sans y recréer le contenu. L’utilisateur reste sur la plateforme du partenaire, clique sur une activité, et arrive dans Moodle, authentifié et inscrit automatiquement, comme si c’était une activité native. Sa note dans l’activité Moodle remonte dans le carnet de la plateforme d’origine.

Ce chapitre s’appuie sur toute la théorie des chapitres 1 et 2 (LTI 1.3, OIDC, JWT, AGS) : ici, Moodle est de l’autre côté de ces mêmes flux. Nous verrons le mécanisme Publish as LTI tool, sa configuration, le provisioning des utilisateurs, la synchronisation des notes, et les pièges spécifiques au rôle de fournisseur.

Mini-sommaire du chapitre :

1. Le cas d’usage et le renversement des rôles
2. Les plugins en jeu : enrol_lti, auth_lti, tool_lti
3. Publier un cours ou une activité (pas à pas)
4. L’enregistrement côté plateforme consommatrice
5. Provisioning des utilisateurs
6. Remontée des notes (AGS dans l’autre sens)
7. Pièges spécifiques au rôle de fournisseur
8. Exercices et quiz

1. Le cas d’usage et le renversement des rôles

Rappel des rôles (chapitre 1) : la plateforme (platform / consumer) est le LMS où vit l’utilisateur ; l’outil (tool / provider) est l’application lancée. Jusqu’ici Moodle = plateforme. Désormais :

• Plateforme = le LMS distant (un autre Moodle, Canvas, votre app Next.js…).
• Outil = notre Moodle, qui expose un cours ou une activité.

Le point mental à intégrer : tous les flux des chapitres 2 et 3 sont identiques, mais Moodle est à l’autre bout. C’est le LMS distant qui initie l’OIDC login, et Moodle qui reçoit le launch, valide le JWT de la plateforme distante, provisionne l’utilisateur, et renvoie la note via AGS. Moodle sait jouer les deux rôles simultanément (il peut consommer des outils et être publié comme outil).

💡 Pour un dev React : c’est le même protocole vu « en miroir ». Si au chapitre 5 vous construisez QuizLab comme tool, ici Moodle est ce tool. Comprendre les deux côtés vous rend capable de brancher n’importe quelle combinaison LMS ↔ outil — c’est tout l’intérêt d’un standard interopérable.

2. Les plugins en jeu

Trois plugins du core collaborent pour faire de Moodle un fournisseur LTI :

Ces plugins doivent être activés : enrol_lti (Administration → Plugins → Inscriptions), auth_lti (Plugins → Authentification). En LTI 1.3 (Advantage), Moodle fournisseur agit comme un outil enregistré auprès de la plateforme distante : il expose des endpoints (login, launch, JWKS) et gère les deployments.

⚠️ Piège : sans auth_lti activé, les utilisateurs distants ne peuvent pas être provisionnés — le launch échoue ou l’utilisateur n’est pas relié à un compte. Les trois plugins forment un ensemble : vérifiez qu’ils sont tous activés avant de déboguer plus loin.

3. Publier un cours ou une activité

Le mécanisme Publish as LTI tool expose une ressource Moodle. Deux granularités : un cours entier ou une activité précise (un quiz, un devoir…).

Pas à pas (côté Moodle fournisseur) :

1. Activer enrol_lti et auth_lti (§2).
2. Dans le cours à publier, ajouter la méthode d’inscription « Publier en tant qu’outil LTI » (Participants → Inscription → Méthodes d’inscription), ou passer par Administration du site → Plugins → Inscriptions → Publier en tant qu’outil LTI.
3. Créer un outil publié : choisir la ressource (le cours entier, ou une activité via son cmid), le rôle attribué aux utilisateurs distants (souvent étudiant), et les options (nom, achèvement de note, partage des données d’identité).
4. Moodle génère les informations d’enregistrement de cet outil : l’URL de lancement, l’URL d’initiation du login (OIDC), l’URI de redirection, et l’URL du jeu de clés publiques (JWKS). Ce sont ces valeurs que la plateforme distante utilisera (§4).
5. Communiquer ces informations à l’administrateur de la plateforme consommatrice.

💡 Pour un dev React : c’est exactement l’enregistrement du chapitre 3, mais inversé. Au chapitre 3, vous donniez à Moodle les endpoints de votre outil ; ici, Moodle génère ses propres endpoints d’outil, que la plateforme distante enregistre. Les rôles émetteur/récepteur des endpoints sont permutés.

4. L’enregistrement côté plateforme consommatrice

Pour que la confiance LTI 1.3 s’établisse (chapitre 2), la plateforme distante doit enregistrer Moodle-outil avec :

• l’URL de lancement (où envoyer le launch),
• l’URL d’initiation OIDC (login),
• l’URI de redirection autorisée,
• l’URL JWKS de Moodle (les clés publiques pour vérifier les JWT signés par Moodle),
• un client_id et un deployment_id (identifiant le couple plateforme-outil).

Réciproquement, Moodle doit connaître, pour cette plateforme, son issuer, son client_id, son URL JWKS (pour vérifier les JWT signés par la plateforme) et ses endpoints de services (AGS…). Cette configuration se fait dans tool_lti (les plateformes enregistrées). C’est le même échange bidirectionnel de clés qu’au chapitre 3 — chaque partie publie ses clés publiques (JWKS) et connaît celles de l’autre.

⚠️ Piège : la confiance LTI 1.3 est mutuelle et bidirectionnelle. Il ne suffit pas que la plateforme connaisse Moodle : Moodle doit aussi connaître la plateforme (issuer, client_id, JWKS) pour valider les launches entrants. Oublier un côté de l’enregistrement produit une erreur de signature ou de « unregistered platform ». Vérifiez les deux sens.

5. Provisioning des utilisateurs

Quand un utilisateur distant lance l’outil pour la première fois, il n’a pas de compte dans notre Moodle. auth_lti s’en charge :

1. Le launch LTI arrive avec l’identité de l’utilisateur (claims : sub, nom, éventuellement e-mail selon le partage de données réglé).
2. auth_lti crée (ou relie) un compte local Moodle, lié à l’identité LTI (sub + issuer). Le même utilisateur qui relance retrouve son compte.
3. enrol_lti inscrit cet utilisateur dans le cours/activité publié, avec le rôle configuré (§3).
4. L’utilisateur voit la ressource Moodle, authentifié, comme un participant normal.

Le degré d’information partagé (nom, e-mail) dépend des réglages de confidentialité de la plateforme distante et de l’outil publié. Souvent, seul un identifiant opaque (sub) est garanti ; l’e-mail peut être absent (RGPD, réglage de la plateforme).

⚠️ Piège de provisioning : si la plateforme distante ne partage pas l’e-mail (ou un identifiant stable), Moodle peut créer des comptes en double ou ne pas relier correctement un utilisateur récurrent. La liaison repose sur un identifiant stable (sub + issuer) ; assurez-vous que la plateforme envoie un sub persistant par utilisateur. Un sub qui change à chaque launch casserait le rattachement.

💡 Pour un dev React : c’est du JIT provisioning (Just-In-Time), comme quand votre app crée un compte à la première connexion « Sign in with X » à partir du sub du token. La clé, comme toujours en fédération d’identité : un identifiant sujet stable pour relier les connexions successives à un même compte.

6. Remontée des notes

Le sens des notes s’inverse aussi. Ici, l’utilisateur travaille dans l’activité Moodle (le tool) ; sa note doit remonter dans le carnet de la plateforme distante. C’est AGS (chapitre 2), Moodle jouant le côté qui envoie la note vers la line item fournie par la plateforme :

1. La plateforme distante, au launch, fournit l’endpoint AGS (où poster les scores) et le contexte de note.
2. L’utilisateur obtient une note dans l’activité Moodle publiée (via le carnet de notes Moodle, Partie 2).
3. enrol_lti pousse ce score vers l’endpoint AGS de la plateforme distante (avec un access token OAuth client-credentials, chapitre 2).
4. La note apparaît dans le carnet de la plateforme distante.

C’est le miroir du chapitre 3 (où Moodle recevait les notes d’un outil externe). Moodle sait donc, selon le rôle, recevoir (plateforme) ou envoyer (outil) des notes via AGS.

⚠️ Piège : la remontée AGS dépend de ce que la plateforme distante a autorisé (scopes AGS) et fourni (line item, endpoint). Si la plateforme ne partage pas l’endpoint AGS ou refuse le scope de score, la note ne remonte pas, même si tout le reste marche. Vérifiez les scopes AGS accordés côté plateforme.

7. Pièges spécifiques au rôle de fournisseur

Au-delà des pièges transverses (cookies tiers en iframe, clock skew — chapitres 2 et 3), le rôle de fournisseur ajoute :

⚠️ Confusion des JWKS. Chaque partie signe avec sa clé privée et publie sa clé publique (JWKS). En fournisseur, Moodle publie son JWKS (pour ses propres jetons) et doit connaître le JWKS de la plateforme (pour valider les launches entrants). Confondre les deux jeux de clés est l’erreur n°1 : « invalid signature » vient presque toujours d’un JWKS mal orienté.

⚠️ Comptes en double. Sans identifiant sujet stable (§5), le provisioning crée des doublons. Auditez la liaison sub+issuer → compte Moodle.

⚠️ Périmètre du rôle. Le rôle attribué aux utilisateurs distants (§3) doit être minimal (étudiant, pas enseignant). Publier un cours en donnant un rôle trop puissant expose des capacités d’édition à des utilisateurs distants non maîtrisés.

⚠️ Données personnelles. Le provisioning importe des données d’utilisateurs distants dans votre Moodle (RGPD). Réglez le partage minimal nécessaire, documentez le traitement (Privacy API, Partie 11), et clarifiez qui est responsable de traitement entre les deux organisations.

📚 Aller plus loin : la documentation « Publish as LTI tool » et la configuration de enrol_lti / tool_lti en mode LTI Advantage sont sur docs.moodle.org  (administration) et moodledev.io  (côté technique). Le code de référence vit dans enrol/lti/, auth/lti/ et admin/tool/lti/ du core.

Synthèse

Moodle sait être outil autant que plateforme. En fournisseur, via enrol_lti + auth_lti + tool_lti, il publie un cours ou une activité, qu’une plateforme distante lance en LTI 1.3 ; il provisionne les utilisateurs distants (JIT, sur un sub stable), et renvoie leurs notes via AGS dans le carnet de la plateforme. Tous les flux des chapitres 2 et 3 s’appliquent, en miroir — d’où l’importance de bien orienter les JWKS et les rôles émetteur/récepteur. Vous maîtrisez désormais les deux moitiés du protocole ; le chapitre suivant les met en œuvre de bout en bout, du côté outil, en construisant QuizLab en Next.js.

✏️ Exercices

Exercice 1 — Qui est quoi ? Une université publie un cours Moodle pour qu’un Canvas partenaire le lance. Identifiez : plateforme, outil, qui signe le launch, qui renvoie la note.

Exercice 2 — Plugins manquants. Vous publiez un cours, mais les utilisateurs distants arrivent sans compte et le launch échoue. Quel plugin est probablement inactif ?

Exercice 3 — JWKS mal orienté. Un launch entrant échoue en « invalid signature ». Expliquez la confusion de JWKS la plus probable.

Exercice 4 — Comptes en double. Après quelques semaines, un utilisateur distant a trois comptes dans votre Moodle. Cause probable et correctif ?

Exercice 5 — La note ne remonte pas. Le SSO et l’inscription marchent, mais les notes n’apparaissent pas côté plateforme distante. Où regarder ?

🧠 Quiz de révision

Q1. Dans « Moodle comme outil », qui est la plateforme et qui est l’outil ?

Q2. Quels trois plugins permettent à Moodle d’être fournisseur LTI, et leurs rôles ?

Q3. Pourquoi la confiance LTI 1.3 est-elle bidirectionnelle ici ?

Q4. Comment les utilisateurs distants obtiennent-ils un compte, et sur quoi repose la liaison ?

Q5. Dans quel sens vont les notes, et via quel service ?

Chapitre suivant : 05 — Construire un outil LTI 1.3 complet en Next.js — le grand tutoriel : QuizLab en Next.js 15, branché sur Moodle 5.2, avec launch SSO, Deep Linking, remontée de note AGS et liste des inscrits NRPS, chaque étape codée et sécurisée.