Paillasse/docs/adr/0010-lti-moodle-comme-sixieme-facon-de-rejoindre.md

ADR 0010 — LTI 1.3 Moodle : une 6ᵉ façon de rejoindre une classe, pas un lancement de lab

• Date : 2026-10-14
• Statut : accepté

Contexte

CLAUDE.md, section 6 : « Moodle LTI 1.3 (V2) » est listé avec les autres façons d'ajouter des élèves (code/QR, import CSV, saisie rapide, invitation e-mail) — pas dans la description de l'espace de lab. Avancé à la demande explicite d'Adam (bloc C terminé, V2 lancée par anticipation).

Décisions

LTI sert à rejoindre une classe, pas à lancer un lab précis. Un lancement Moodle authentifie l'élève (OIDC + jeton signé) et le fait atterrir sur son tableau de bord habituel (eleve.show) — depuis là, il choisit un lab ou un devoir normalement, par le portail. Construire un lien direct vers un lab précis aurait demandé de router l'admission dans une séance (SeanceController::admettre), bien plus complexe, pour un besoin que le CLAUDE.md ne demande pas.

L'URL de lancement réutilise code_classe existant (/lti/lancement/{code_classe}), pas un nouveau jeton ou une nouvelle table de liaison. Exactement la même donnée que celle déjà affichée pour « Faire rejoindre tes élèves » (code/QR) — LTI est juste une 6ᵉ porte vers la même classe, pas un concept à part.

packbackbooks/lti-1p3-tool (Apache-2.0), recommandé par le CLAUDE.md. Bibliothèque bas niveau (pas de dépendance à un framework) : il faut lui fournir trois implémentations (ICache, ICookie, IDatabase, dans App\Services\Lti\) qui s'appuient sur Redis, les cookies et les tables lti_plateformes/lti_deploiements déjà en place.

Élève provisionné automatiquement au premier lancement, retrouvé par (classe_id, lti_emetteur, lti_sub) ensuite — jamais de doublon de compte à chaque connexion. Prénom/nom lus depuis les claims standards (given_name/family_name, puis name, jamais inventés : « Élève » / « Moodle » si Moodle n'envoie rien). Code secret généré au hasard, haché, jamais affiché : cet élève se connecte toujours via Moodle, jamais par identifiant/code comme les autres.

Cookie SameSite=None; Secure pour le jeton d'état OIDC. Sans ça, le cookie ne survit jamais au POST final que Moodle envoie depuis son propre domaine — chaque lancement échouerait silencieusement (« Please make sure you have cookies… », message déjà prévu par la bibliothèque pour ce cas précis, qui n'arrive qu'avec un réglage de cookie insuffisant).

Sécurité x-pack… non, pas de rapport ici — mais même logique que pour Elasticsearch/Ceph : une seule clé RSA par plateforme Moodle enregistrée (générée par le portail lui-même à l'enregistrement, phpseclib4\Crypt\RSA, jamais collée par Adam), exposée en public via /lti/cles.json — c'est le fonctionnement normal du protocole (Moodle doit pouvoir vérifier les jetons que nous lui envoyons, si jamais le portail appelle un service LTI plus tard), pas une fuite.

Enregistrement manuel, par commande Artisan, jamais une page d'administration. Une plateforme Moodle se configure une fois par établissement, par Adam, avec des informations lues dans l'administration Moodle — une page web pour ça serait une fonctionnalité sans usage réel (CLAUDE.md, section 8). lti:enregistrer-plateforme et lti:enregistrer-deploiement, voir docs/runbooks/lti-moodle.md.

Conséquences

• Testé avec un jeton LTI réellement signé (RS256, paire de clés générée dans le test), jeu de clés de « Moodle » simulé : lancement validé de bout en bout, élève créé avec le bon prénom/nom, deuxième lancement du même élève ne crée pas de deuxième compte. Pas de vrai Moodle disponible pour vérifier en conditions réelles — à refaire dès qu'Adam a un Moodle de test.
• En dette : pas de web service LTI (AGS pour les notes, NRPS pour la liste des inscrits, Deep Linking) — seul le lancement de ressource est géré, comme décidé ci-dessus. Les classes de la bibliothèque pour ces services existent déjà (LtiAssignmentsGradesService etc.) si le besoin devient réel.