Chapitre 13.5 — Quiz final

⏱️ TL;DR — L’épreuve transversale : vingt questions qui balaient les treize parties, de la carte des standards au renvoi d’une note en passant par le manifeste SCORM, le statement xAPI, le lancement cmi5 et la validation d’un id_token LTI. Réponds de mémoire, puis déplie la correction. Si trois réponses ou plus t’échappent, la partie visée mérite une relecture — chaque correction renvoie au bon endroit. À la fin : le mot de la fin du cours.

🎯 Objectifs

Vérifier ta maîtrise sur l’ensemble du cours, pas partie par partie.
Repérer tes angles morts et savoir vers quelle partie retourner.
Confirmer que tu sais choisir, lire, brancher, débuguer et livrer de l’interopérable.

Le quiz

Joue le jeu : formule ta réponse avant d’ouvrir la correction. Les questions vont volontairement d’une partie à l’autre.

Question 1 — Qui publie SCORM, xAPI et cmi5 d’un côté, LTI et QTI de l’autre ?

ADL (Advanced Distributed Learning, adlnet.gov) publie SCORM, xAPI et cmi5 — le contenu et la donnée d’apprentissage. 1EdTech (ex-IMS Global, 1edtech.org) publie LTI, QTI, Common Cartridge, OneRoster, Caliper — les intégrations et l’écosystème. (Partie 1)

Question 2 — Un contenu doit être lancé par un LMS, avec un suivi riche et un lancement propre. Quel standard ?

cmi5 : un profil xAPI qui réintroduit le lancement depuis un LMS et la complétion, tout en offrant la richesse de xAPI. SCORM conviendrait pour la compatibilité maximale ; xAPI seul ne normalise ni lancement ni complétion. (Parties 1 et 8)

Question 3 — En SCORM, quelle est la différence de modèle entre 1.2 et 2004 sur le statut ?

En 1.2, un seul champ mélange tout : cmi.core.lesson_status (passed, completed, failed, incomplete, browsed, not attempted). En 2004, complétion et réussite sont séparées : cmi.completion_status (completed/incomplete/…) et cmi.success_status (passed/failed/…). (Parties 2, 4 et 5)

Question 4 — Qu’est-ce qu’un PIF, et que contient-il obligatoirement à sa racine ?

Un PIF (Package Interchange File) est le .zip d’un paquet SCORM. Il doit contenir, à sa racine, un imsmanifest.xml — la carte d’identité du paquet, avec <metadata>, <organizations> et <resources>. (Partie 3)

Question 5 — SCO ou asset : lequel dialogue avec le LMS, et comment le déclare-t-on ?

Le SCO dialogue (statut, score) ; l’asset est passif (image, PDF). On le déclare sur la <resource> via adlcp:scormType="sco" (ou "asset"). Un namespace adlcp oublié fait traiter le SCO comme un asset → plus rien ne remonte. (Partie 3)

Question 6 — Comment un SCO trouve-t-il l’API, et comment s’appelle l’objet en 1.2 puis en 2004 ?

Il remonte window.parent puis window.opener (« find the API »). L’objet s’appelle API en SCORM 1.2 et API_1484_11 en SCORM 2004. On ouvre par LMSInitialize("") / Initialize("") et on ferme toujours par LMSFinish("") / Terminate(""). (Partie 4)

Question 7 — Quelle est la limite de `cmi.suspend_data` en 1.2 et en 2004 ?

4096 caractères en SCORM 1.2, 64000 en SCORM 2004. Dépasser la limite tronque les données de reprise — un bug de « reprise cassée » classique quand on migre du 2004 vers du 1.2 sans réduire la charge. (Partie 4)

Question 8 — À quoi sert le Sequencing & Navigation, et dans quelle version existe-t-il ?

Le SN (Sequencing & Navigation) décrit l’arbre d’activités, les règles de séquencement, les objectifs et le rollup (remontée d’état). Il existe uniquement en SCORM 2004. Puissant mais réputé complexe et souvent sous-utilisé. (Partie 5)

Question 9 — Quels sont les trois champs obligatoires d’un statement xAPI ?

actor (qui), verb (quoi) et object (sur quoi) — la phrase « acteur – verbe – objet ». Tout le reste (result, context, timestamp, authority) est optionnel ; id et stored sont posés par le LRS. (Partie 6)

Question 10 — Dans un verbe xAPI, qu’est-ce qui l’identifie : l’`id` ou le `display` ?

L’id — une IRI (ex. http://adlnet.gov/expapi/verbs/completed). Le display n’est qu’un libellé humain, décoratif et multilingue. On réutilise des verbes de vocabulaires existants, on n’en invente pas. (Partie 6)

Question 11 — Qu’est-ce qu’un LRS, et quel en-tête est obligatoire sur ses requêtes ?

Un LRS (Learning Record Store) reçoit et sert les statements via une API REST (statements, activities/state, about…). L’en-tête X-Experience-API-Version est obligatoire sur toutes les requêtes ; l’oublier fait rejeter l’appel. (Parties 6 et 7)

Question 12 — Quels sont les cinq paramètres d’URL de lancement cmi5, et pourquoi le `fetch` ?

endpoint, fetch, actor, registration, activityId. L’endpoint (URL du LRS) ne donne aucun droit : l’AU doit POSTer le fetch pour obtenir son auth-token, sans quoi tout appel au LRS renvoie 401. (Partie 8)

Question 13 — Que décide `moveOn`, et dans quel mode l’AU peut-il « satisfaire » ?

moveOn décide quand l’AU est satisfait : Passed, Completed, CompletedAndPassed, CompletedOrPassed, NotApplicable. L’AU ne peut envoyer completed/passed/failed qu’en launchMode: "Normal" — jamais en Browse ni Review. Le seuil vient de masteryScore. (Partie 8)

Question 14 — Pourquoi préférer LTI 1.3 à 1.1, et comment sécurise-t-on le lancement ?

LTI 1.1 (signature OAuth 1.0, secret partagé) est en fin de vie — à éviter pour du neuf. LTI 1.3 utilise OpenID Connect + JWT signés : la plateforme envoie un id_token que l’outil valide via le JWKS de la plateforme (signature, iss, aud = client_id, exp, nonce). (Partie 9)

Question 15 — Quel champ identifie de façon stable un utilisateur dans un lancement LTI ?

Le sub, couplé à l’iss de la plateforme. C’est un identifiant opaque et stable. Pas l’e-mail (facultatif, changeant, parfois non partagé selon les réglages de confidentialité). (Partie 9)

Question 16 — Pour renvoyer une note (AGS), quel jeton utilise-t-on, et quels champs sont indissociables ?

Pas l’id_token : un access_token OAuth2 obtenu via grant_type=client_credentials + un client_assertion (JWT signé par ta clé privée), scope .../lti-ags/scope/score. Dans le Score, scoreGiven et scoreMaximum vont toujours ensemble ; userId = le sub. (Partie 10)

Question 17 — À quoi servent respectivement NRPS et Deep Linking ?

NRPS (Names and Role Provisioning Services) lit le roster d’un cours (membres et rôles). Deep Linking laisse l’enseignant choisir quel contenu de ton outil placer dans son cours. Avec AGS, ce sont les trois services de LTI Advantage. (Partie 10)

Question 18 — Situe QTI, Common Cartridge, OneRoster et Caliper.

QTI = échanger questions/tests. Common Cartridge = paquet de cours complet (peut embarquer LTI et QTI). OneRoster = échanger rosters et notes entre SIS et LMS. Caliper = analytics d’apprentissage (événements JSON-LD, cousin cadré de xAPI). (Partie 11)

Question 19 — « Ça marche dans mon navigateur » prouve-t-il la conformité ? Comment tester ?

Non. Un paquet peut s’afficher sans rien remonter ; un outil peut « se lancer » sans valider le JWT (faille). La conformité se teste : SCORM Cloud et suites ADL (SCORM), CATAPULT (cmi5), LRS de test (xAPI), certification 1EdTech (LTI/QTI…). Tester sur plusieurs cibles. (Parties 1 et 12)

Question 20 — « Tin Can », « xAPI » et « cmi5 » : combien de standards, et quel lien ?

« Tin Can API » et « xAPI » sont le même standard (Tin Can = ancien nom de projet). cmi5 n’est pas un concurrent : c’est un profil de xAPI (verbes imposés, lancement, structure de cours par-dessus xAPI). Donc : un seul socle (xAPI), un profil dessus (cmi5). (Parties 1 et 8)

Le mot de la fin

Félicitations — tu es arrivé au bout. Treize parties, du « pourquoi des standards ? » jusqu’au renvoi d’une note dans le carnet d’un enseignant. Ce n’était pas un catalogue de sigles : c’était un métier.

Tu es maintenant capable de :

Choisir le bon standard face à un besoin réel — SCORM, xAPI, cmi5 ou LTI — et le justifier.
Lire et écrire un imsmanifest.xml, empaqueter un PIF valide, distinguer SCO et asset.
Débuguer un runtime SCORM : trouver l’API, poser le statut et le score, fermer proprement la session.
Écrire un statement xAPI juste, l’envoyer à un LRS, et tracer hors du LMS.
Mettre en œuvre cmi5 : structure de cours, lancement (fetch, LMS.LaunchData), verbes, moveOn.
Brancher un outil en LTI 1.3 (OIDC + JWT, validation via JWKS) et exploiter LTI Advantage — Deep Linking, notes (AGS), roster (NRPS).
Situer QTI, Common Cartridge, OneRoster et Caliper, et savoir quand chacun entre en jeu.
Tester et livrer du vérifiable : SCORM Cloud, suites ADL, CATAPULT, LRS de test, certification 1EdTech.

Autrement dit : tu sais faire parler les plateformes entre elles. C’est exactement la compétence rare qui, en EdTech, fait la différence entre « un dev de plus » et le dev qu’on s’arrache. FormaCampus, notre fil rouge, a suivi ce chemin de bout en bout — publier en SCORM, tracer en xAPI, passer à cmi5, devenir outil LTI, échanger rosters et tests. Tu peux faire le même parcours sur tes produits.

💡 Et maintenant ? Garde ce Cookbook ouvert : cheatsheets, modèles, checklists et glossaire sont faits pour la production, pas pour la nostalgie. Et quand une valeur exacte compte, remonte toujours à la source — adlnet.gov et 1edtech.org.

Merci d’avoir suivi ce cours jusqu’ici. Bonne route — et bonnes intégrations.

Retour au hub des cours — d’autres parcours t’y attendent (Moodle, RGPD, et plus). L’interopérabilité, elle, est désormais dans ta boîte à outils.