Chapitre 12.3 — Tester la conformité

⏱️ TL;DR — « Ça marche dans mon Moodle » n’est pas une preuve de conformité. Un standard se teste, sur plusieurs cibles, avant de livrer. Ta boîte à outils : SCORM Cloud (Rustici) — le banc d’essai universel qui teste SCORM, xAPI, cmi5 et LTI ; les suites de tests ADL (SCORM Test Suite) ; le projet CATAPULT d’ADL pour cmi5 ; un LRS de test pour inspecter tes statements xAPI ; les implémentations de référence et la certification 1EdTech pour LTI. La méthode : reproduire, isoler l’étape fautive, lire les logs réseau, tester sur au moins deux plateformes différentes. Ce chapitre est celui de la qualité : livrer du vérifiable, pas du « ça devrait passer ».

🎯 Objectifs

• Comprendre pourquoi « ça marche chez moi » ne prouve rien en interop.
• Utiliser SCORM Cloud comme banc d’essai universel (SCORM, xAPI, cmi5, LTI).
• Savoir à quoi servent les suites ADL, CATAPULT, un LRS de test et les implémentations de référence LTI.
• Appliquer une checklist de test par standard avant chaque livraison.
• Déboguer un lancement qui échoue en isolant l’étape fautive.

« Marche chez moi » ne veut rien dire

Le piège fondateur de l’interop (déjà nommé dans l’accueil du cours) : croire que « ça marchera bien quelque part ». Un module qui « fonctionne dans mon navigateur » n’est pas un SCORM valide. Un outil qui « se lance chez moi » n’est pas un outil LTI conforme. Pourquoi ? Parce que chaque LMS implémente les standards avec ses propres tolérances : ton Moodle de dev pardonne peut-être un lesson_status mal formé, un scoreMaximum manquant, un JWT à la signature approximative — que le LMS du client, lui, rejette.

La conformité, c’est la propriété « fonctionne sur toute implémentation conforme », pas « fonctionne sur la mienne ». Elle se prouve avec des outils faits pour ça.

La boîte à outils de test

⚠️ Piège — Confondre un LMS et la conformité. Tester uniquement sur ton Moodle, c’est tester une implémentation, avec ses bugs et ses tolérances. Un outil de conformité (SCORM Cloud, suites ADL, CATAPULT) est neutre : il vérifie le standard, pas les habitudes d’un LMS. Les deux sont complémentaires — le LMS dit « ça passe ici », l’outil de conformité dit « ça passe partout ».

SCORM Cloud : le banc d’essai universel

SCORM Cloud (édité par Rustici, les auteurs historiques de bien des outils de l’écosystème) est l’outil que tu ouvriras le plus souvent. Tu y importes ton paquet et tu le lances dans un environnement de référence, en voyant exactement ce qui remonte. Il couvre les quatre standards du cours :

• SCORM 1.2 / 2004 : importe le PIF, lance le SCO, affiche le modèle de données CMI en direct (lesson_status, score.raw, suspend_data…). Tu vois ce que le SCO envoie.
• xAPI : SCORM Cloud héberge un LRS. Tu y envoies tes statements et tu les inspectes un par un.
• cmi5 : il joue le rôle du LMS — construit l’URL de lancement, délivre le fetch/auth-token, sert LMS.LaunchData, reçoit initialized…terminated. Idéal pour valider un AU (chapitre 8.3).
• LTI : il peut agir comme plateforme pour lancer ton outil et vérifier le flux.

💡 Réflexe — Fais de SCORM Cloud ta première cible de test, avant tout LMS client. Il est neutre, rapide, et te montre les échanges bruts. Si ça remonte proprement dans SCORM Cloud et dans un vrai LMS différent du tien, tu tiens une preuve sérieuse de conformité. « Ça passe sur SCORM Cloud » est un argument de vente que les clients EdTech reconnaissent.

🔌 Côté intégration — Beaucoup d’acheteurs EdTech exigent une validation SCORM Cloud dans leur cahier des charges (« le contenu doit être validé sur SCORM Cloud sans erreur »). C’est devenu un standard de fait du test. Livrer un rapport de test SCORM Cloud propre, c’est parler la langue de l’acheteur — et raccourcir la recette.

Les suites ADL et CATAPULT

Là où SCORM Cloud est un produit commercial pratique, les suites ADL sont les tests officiels de la spec :

• SCORM Test Suite (ADL) : la suite historique de conformité SCORM 1.2 / 2004. Elle exerce méthodiquement l’API RTE et le modèle de données. C’est la référence quand tu veux prouver une conformité au sens strict de la spec.
• CATAPULT : le projet d’ADL dédié à cmi5 — il fournit une suite de tests, un lecteur de référence et des bonnes pratiques. C’est la ressource pour valider un AU cmi5 contre la spec, au-delà d’un simple « ça remonte ».

📚 La spec — Les suites de conformité sont éditées par ADL (adlnet.gov) : SCORM Test Suite pour SCORM, CATAPULT pour cmi5. Elles matérialisent les exigences des specs en tests exécutables. Quand un doute subsiste sur « est-ce vraiment conforme ? », c’est vers ces suites qu’on se tourne — pas vers l’avis d’un LMS particulier.

Le LRS de test pour xAPI

Pour xAPI, l’outil de test, c’est un LRS que tu peux inspecter. Tu envoies un statement, tu le relis, tu vérifies sa structure. Le LRS de test valide déjà beaucoup pour toi : il refuse un statement mal formé (verbe sans IRI, acteur sans identifiant valide, JSON invalide) avec un code d’erreur HTTP.

POST https://lrs-test.example/xapi/statements HTTP/1.1
Content-Type: application/json
X-Experience-API-Version: 1.0.3
Authorization: Basic ...
 
{
  "actor": { "objectType": "Agent", "account": { "homePage": "https://formacampus.fr", "name": "u-2342" } },
  "verb": { "id": "http://adlnet.gov/expapi/verbs/completed", "display": { "fr-FR": "a termine" } },
  "object": { "id": "https://formacampus.fr/modules/securite", "definition": { "name": { "fr-FR": "Securite numerique" } } }
}

Un LRS conforme accepte ce statement (200/204) et le range. S’il te renvoie un 400, ton statement est mal formé — le message d’erreur pointe le champ fautif. C’est ton test le plus direct.

⚠️ Piège — Tester ses statements en les envoyant directement au LRS de production. Tu pollues tes données réelles avec des essais, et un verbe de test mal choisi peut fausser un tableau de bord. Utilise un LRS de test séparé (une instance dédiée, ou l’espace de test de SCORM Cloud) — jamais le LRS qui alimente les vraies analytics.

💡 Réflexe — Valide tes statements avant de les envoyer : structure acteur–verbe–objet complète, verbe = IRI connue (réutilise les vocabulaires existants, n’invente pas), acteur avec un identifiant valide (account, mbox…), en-tête X-Experience-API-Version présent. Le LRS de test confirme, mais un statement propre passe du premier coup.

LTI : implémentations de référence et certification

Pour LTI, tester veut dire vérifier le flux complet : OIDC login → redirection → id_token (JWT) POSTé → validation via JWKS → rendu. Deux niveaux :

• Implémentations de référence (1EdTech) : des plateformes et outils de test contre lesquels tu valides ton flux. Ton outil se lance-t-il correctement depuis une plateforme conforme ? La signature du JWT est-elle vérifiée ? Les services Advantage (AGS, NRPS) répondent-ils ?
• Certification 1EdTech : le label officiel. 1EdTech (ex-IMS Global) fait passer un produit par une batterie de tests et certifie sa conformité (LTI 1.3, LTI Advantage, QTI, OneRoster…). Un produit certifié apparaît dans le registre public de 1EdTech.

🔌 Côté intégration — La certification 1EdTech n’est pas un gadget : de nombreux LMS et académies n’intègrent que des outils certifiés LTI Advantage. C’est parfois un prérequis d’appel d’offres pur et simple. Pour une startup d’outil (scénario B du chapitre 12.1), viser la certification, c’est viser l’éligibilité aux gros marchés. La testabilité (implémentations de référence) est l’antichambre de la certification.

La méthode : plusieurs cibles, toujours

La règle d’or tient en une phrase : ne teste jamais sur une seule cible. Le minimum sérieux :

1. SCORM Cloud (banc neutre) — vérifie la conformité au standard.
2. Au moins un LMS réel différent de ton environnement de dev — vérifie le comportement en conditions clients (un Moodle et un autre LMS, idéalement).
3. Pour cmi5 : CATAPULT en plus, contre la spec.
4. Pour xAPI : un LRS de test dédié.
5. Pour LTI : une implémentation de référence, puis viser la certification.

Si un livrable passe sur SCORM Cloud et sur deux LMS différents, tu as une confiance raisonnable qu’il passera chez le prochain client. Une seule cible ne te dit rien de la conformité — seulement que ton unique implémentation est tolérante.

Checklists de test par standard

SCORM (1.2 / 2004)

• Le PIF s’importe sans erreur (manifeste valide, chemins corrects).
• Le SCO trouve l’API (API en 1.2, API_1484_11 en 2004) et fait Initialize.
• La complétion remonte (lesson_status en 1.2 ; completion_status et success_status en 2004).
• Le score remonte (score.raw ; score.scaled en 2004).
• La reprise fonctionne (suspend_data relu, dans la limite de taille).
• Commit puis Finish/Terminate sont bien appelés à la sortie.

xAPI

• Chaque statement a acteur–verbe–objet complets.
• Le verbe est une IRI connue et réutilisée.
• L’en-tête X-Experience-API-Version est présent, l’auth valide.
• Le LRS accepte (200/204) ; un 400 = statement mal formé.
• Les statements sont relisibles et cohérents dans le LRS.

cmi5

• L’URL de lancement porte les cinq paramètres (endpoint, fetch, actor, registration, activityId).
• Le POST fetch renvoie un auth-token.
• LMS.LaunchData est lu (launchMode, masteryScore, moveOn).
• initialized en premier, terminated en dernier.
• passed/completed respectent masteryScore et pas en mode Browse/Review.
• Validé sous CATAPULT.

LTI 1.3 / Advantage

• Le login OIDC s’initie correctement.
• Le JWT (id_token) est validé via le JWKS de la plateforme (jamais accepté sans vérif de signature).
• Les claims attendus sont présents (sub, rôles, resource_link…).
• AGS : un score remonte au carnet (barème respecté, gradingProgress).
• NRPS : le roster se lit.
• Testé contre une implémentation de référence, puis certification visée.

Déboguer un lancement qui échoue

Quand « rien ne remonte », on ne devine pas : on isole l’étape fautive en lisant les logs réseau (l’onglet Réseau du navigateur est ton meilleur ami).

💡 Réflexe — La question de débogage n’est jamais « pourquoi ça marche pas ? » mais « à quelle étape ça casse ? ». Nomme la chaîne (trouver l’API → init → set → commit → finish, ou lancement → fetch → LaunchData → initialized), regarde où la requête échoue dans les logs réseau, et tu isoles la panne en minutes au lieu de tâtonner (voir le débogage cmi5 du chapitre 8.3).

🧭 Sur FormaCampus — Règle interne chez FormaCampus : rien ne part chez un client sans passer SCORM Cloud. Chaque module exporté (SCORM et cmi5) est importé sur SCORM Cloud, lancé, et son rapport archivé. Les AU cmi5 passent en plus par CATAPULT. Le studio LTI est testé contre une implémentation de référence avant chaque déploiement d’académie, et FormaCampus vise la certification 1EdTech pour être éligible aux appels d’offres. Résultat : quand un client dit « ça ne marche pas », le premier réflexe est « montrez-moi vos logs réseau » — et neuf fois sur dix, la panne est une tolérance de leur LMS, pas un défaut du livrable, preuve SCORM Cloud à l’appui.

📚 La spec — Les outils de test matérialisent les specs : SCORM Test Suite et CATAPULT (ADL, adlnet.gov) pour SCORM et cmi5, les implémentations de référence et la certification (1EdTech, 1edtech.org) pour LTI. SCORM Cloud (Rustici) est un produit qui implémente ces standards fidèlement — pratique, mais la référence normative reste ADL et 1EdTech.

✏️ Exercices

Exercice 1 — Choisis l’outil. Pour chaque cas, quel outil de test : (a) valider qu’un AU cmi5 respecte la spec au sens strict ; (b) vérifier qu’un module SCORM remonte score et complétion dans un environnement neutre ; (c) s’assurer que tes statements xAPI sont bien formés ; (d) prouver à une académie que ton outil LTI est conforme.

Exercice 2 — Isole la panne. Un AU cmi5 « marchait chez le dev », mais chez le client chaque appel au LRS renvoie 401. Le POST fetch réussit et renvoie un auth-token. Où est le problème, et comment le prouves-tu ?

Exercice 3 — La règle des cibles multiples. Un collègue dit : « J’ai testé, ça marche parfaitement dans notre Moodle, on peut livrer. » Que réponds-tu ?

🧠 Quiz de révision

Chapitre suivant : Migrer & cohabiter — passer de SCORM à cmi5/xAPI sans casser l’existant, livrer deux formats, centraliser avec Dispatch, versionner ses contenus et ses verbes.