Chapitre 13.3 — Checklists

⏱️ TL;DR — Quatre listes à cocher, pensées pour être passées avant de livrer : produire un SCORM valide, brancher un outil LTI 1.3, choisir et déployer un LRS, préparer une certification 1EdTech. Chaque case est une vérification concrète — pas un principe. Coche tout, et tu livres du vérifiable, pas du « ça devrait passer ». En cas de doute sur une valeur exacte, remonte aux specs (adlnet.gov, 1edtech.org).

🎯 Objectifs

• Disposer d’une liste actionnable pour chaque grande livraison d’interop.
• Ne rien oublier entre « ça marche chez moi » et « c’est conforme ».
• Transformer les pièges du cours en points de contrôle systématiques.

Checklist 1 — Livrer un SCORM valide

Packaging (Partie 3)

• Version SCORM choisie selon la cible (1.2 = compatibilité maximale ; 2004 = complétion/réussite séparées, séquencement).
• imsmanifest.xml présent à la racine du .zip (le PIF), pas dans un sous-dossier.
• <metadata> : <schema>ADL SCORM</schema> + <schemaversion> correct (1.2 ou 2004 4th Edition).
• Namespaces déclarés : imscp (par défaut) et adlcp — copiés d’une référence, pas tapés de mémoire.
• <organizations default="…"> pointe une <organization> existante.
• Chaque <item identifierref="…"> correspond à un identifier de <resource> présent.
• adlcp:scormType="sco" sur les ressources lançables (asset pour les fichiers passifs).
• La page de lancement (href) est aussi listée en <file>.
• Tous les fichiers référencés sont réellement dans le .zip.
• Fichier en UTF-8 sans BOM ; caractères réservés échappés (&, <, >).

Runtime (Partie 4)

• Le SCO trouve l’API (API en 1.2 / API_1484_11 en 2004) en remontant window.parent puis window.opener.
• Ouverture par LMSInitialize("") / Initialize("") avant tout autre appel.
• Statut posé : cmi.core.lesson_status (1.2) ou cmi.completion_status + cmi.success_status (2004).
• Score posé si pertinent : cmi.core.score.raw (1.2) / cmi.score.scaled (2004).
• LMSCommit("") / Commit("") appelé pour forcer l’enregistrement.
• Fermeture systématique par LMSFinish("") / Terminate("") (y compris à la fermeture de l’onglet).
• cmi.suspend_data sous la limite (4096 en 1.2, 64000 en 2004).

Vérification

• Testé sur SCORM Cloud (référentiel neutre) et sur au moins un LMS cible réel.
• Remontée vérifiée : statut, score, reprise (suspend_data / lesson_location).

Checklist 2 — Brancher un outil LTI 1.3

Pré-requis & enregistrement (Partie 9)

• Ne pas partir sur du LTI 1.1 pour du neuf (fin de vie) — viser 1.3.
• Paire de clés générée ; jwks_uri de l’outil exposé (clé publique).
• Enregistrement effectué : échange de client_id, deployment_id, endpoints OIDC/auth, token endpoint, jwks_uri de chaque partie.
• redirect_uri pré-enregistrées (cause n°1 d’échec au lancement).
• Dynamic Registration proposé si possible (moins de support, moins d’erreurs).

Lancement (Partie 9)

• OIDC login third-party initiated implémenté (amorce → redirection → POST de l’id_token).
• id_token validé : signature via le JWKS de la plateforme, iss attendu, aud = ton client_id, exp non dépassé, nonce vérifié.
• Claims lus après validation : message_type, roles, context, resource_link.
• Identité de l’utilisateur = sub + iss (jamais l’e-mail).
• roles interprétés par présence dans le tableau d’URIs (…membership#Instructor ?).
• Données personnelles : ne stocker que le nécessaire (outil branché dans des LMS d’écoles = données de mineurs, cf. RGPD).

Advantage — si nécessaire (Partie 10)

• Endpoints de service persistés au lancement (claims AGS/NRPS), indexés par sub+iss+context.id.
• access_token obtenu via grant_type=client_credentials + client_assertion (JWT signé par ta clé privée).
• Scopes demandés au minimum nécessaire (séparés par des espaces).
• AGS : scoreGiven avec scoreMaximum, activityProgress/gradingProgress corrects, timestamp pour l’idempotence.
• NRPS : lecture du roster via context_memberships_url.

Checklist 3 — Choisir & déployer un LRS

Conformité (Parties 6-7)

• LRS conforme xAPI (versions supportées vérifiées).
• Endpoints REST disponibles : statements (PUT/POST/GET), activities/state, activities/profile, agents/profile, about.
• En-tête X-Experience-API-Version géré et exigé sur toutes les requêtes.
• Authentification supportée : Basic et/ou OAuth.
• Support du profil cmi5 si tu diffuses des modules cmi5 (state LMS.LaunchData, fetch/auth-token).

Choix & exploitation

• Candidat identifié parmi l’écosystème connu (Learning Locker, SQL LRS, Veracity, SCORM Cloud…).
• LRS de test disponible pour le développement.
• Volumétrie, stockage et capacités de requêtage évalués pour ton usage (tableau de bord, analytics).
• Choix xAPI vs Caliper tranché si besoin (xAPI = souple/ouvert ; Caliper = cadré, profils stricts).
• RGPD : les statements décrivent des apprenants (souvent mineurs) — minimisation, durées de conservation, sécurité de l’endpoint.

Checklist 4 — Passer une certification 1EdTech

Portée & standards (Parties 9-11)

• Standard(s) à certifier identifiés — chaque service LTI Advantage se certifie séparément (Core, Deep Linking, AGS, NRPS).
• Autres standards visés situés : QTI (tests), Common Cartridge (paquet de cours), OneRoster (rosters/notes), Caliper (analytics).

Rigueur exigée par les tests

• Sécurité LTI : id_token toujours validé (signature, iss, aud, exp, nonce) ; moindre privilège sur les scopes.
• AGS : barème respecté (scoreMaximum), gradingProgress correct (FullyGraded pour une note définitive), idempotence par timestamp.
• Jeton de service factorisé et mis en cache (getServiceToken réutilisable).
• Comportement testé sur plusieurs cibles (les LMS implémentent les standards avec des variations).

Outillage de conformité (Partie 12)

• SCORM : SCORM Cloud + suites de test ADL.
• cmi5 : projet CATAPULT (suite de tests, lecteur, bonnes pratiques).
• xAPI : LRS de test.
• LTI / QTI / etc. : programme de certification 1EdTech.
• Documentation d’intégration prête (guide d’enregistrement, ou Dynamic Registration).

⚠️ Piège — La plus grosse erreur commune aux quatre checklists : confondre « marche chez moi » et « conforme ». Un SCORM qui s’affiche, un lancement LTI qui « passe » sans validation du JWT, un statement accepté par un LRS de test permissif — rien de tout cela ne prouve la conformité. La conformité se teste sur des référentiels neutres et, souvent, se certifie.

🧭 Sur FormaCampus — L’équipe a transformé ces quatre listes en gabarits de Pull Request : impossible de merger un export SCORM sans cocher la Checklist 1, ni une intégration LTI sans la Checklist 2. Résultat : les allers-retours avec les écoles clientes sur des « erreurs de forme » ont quasi disparu — le contrôle est passé en amont, dans le workflow.

📚 La spec — Les points de contrôle ci-dessus résument les exigences des specs : SCORM (CAM/RTE) et cmi5 sur adlnet.gov ; LTI 1.3, ses services et le programme de certification sur 1edtech.org. Les seuils exacts (suspend_data, valeurs de statut, scopes) sont donnés en Parties 3 à 10 — et la source officielle tranche toujours.

Chapitre suivant : 13.4 — Glossaire — tous les sigles du cours, définis, en ordre alphabétique.