Chapitre 8.1 — Pourquoi cmi5

⏱️ TL;DR — xAPI trace richement et partout, mais il ne dit ni comment un LMS lance un contenu, ni comment il décide de la complétion — un LRS stocke, il ne juge pas. SCORM sait lancer un module et statuer dessus, mais il trace pauvrement et vit enfermé dans le navigateur. cmi5 est le profil xAPI qui réintroduit le lancement depuis un LMS et la complétion cadrée, tout en gardant la richesse de xAPI. C’est, pour le cas « contenu lancé par un LMS », le vrai successeur de SCORM — pas un concurrent de xAPI, mais une couche de règles posée dessus.

🎯 Objectifs

Nommer précisément ce qui manque à xAPI seul pour remplacer SCORM.
Nommer ce qui manque à SCORM que xAPI apporte.
Comprendre que cmi5 est un profil xAPI (une convention), pas une technologie rivale.
Choisir en connaissance de cause entre SCORM, xAPI seul et cmi5.

Le chaînon manquant

Fais l’inventaire. En Partie 6, tu as appris que xAPI décrit n’importe quelle expérience sous forme de statements envoyés à un LRS. Puissant, souple, portable. Mais pose-toi les deux questions qu’un LMS se pose face à un contenu :

« Comment j’ouvre ce contenu ? » — En SCORM, le LMS trouve le SCO dans le manifeste et l’affiche dans une iframe ; le SCO retrouve l’API JavaScript par window.parent. En xAPI pur, rien de tel n’est défini : xAPI ne dit pas comment un contenu est lancé, ni comment on lui transmet quel apprenant, quel LRS, quelle tentative. Chacun bricole ses propres paramètres.
« Quand est-ce “terminé” ? » — En SCORM, le SCO pose cmi.completion_status = "completed" et le LMS le sait. En xAPI pur, le contenu envoie un statement completed… dans un LRS qui se contente de l’archiver. Le LRS ne décide rien : il ne dira jamais au LMS « cet apprenant a validé le module, tu peux débloquer la suite ». Ce jugement n’existe pas dans xAPI seul.

Voilà le trou. xAPI a libéré la donnée mais abandonné le cadre « lancé par un LMS, jugé par un LMS » qui faisait la force opérationnelle de SCORM. cmi5 comble ce trou — et rien d’autre. Il ne réinvente pas le statement ni le LRS : il ajoute un cadre au-dessus.

cmi5 est un profil xAPI (le point à ne jamais oublier)

Un profil xAPI, tu l’as vu en Partie 6, c’est une convention : un jeu de verbes recommandés + des structures de contexte, pour un usage donné. cmi5 est exactement ça, plus un protocole de lancement. Décomposons ce que cmi5 pose par-dessus xAPI :

Un protocole de lancement : le LMS ouvre l’AU en lui passant des paramètres d’URL (endpoint, fetch, actor, registration, activityId). L’AU récupère un jeton d’auth puis lit ses données de lancement. C’est le chapitre 8.3.
Un vocabulaire de verbes cadré : launched, initialized, completed, passed, failed, terminated, abandoned, waived, satisfied — avec un ordre imposé. C’est le chapitre 8.4.
Une structure de cours : le fichier cmi5.xml, avec ses AU et ses Block. C’est le chapitre 8.2.
Des règles de satisfaction : masteryScore et moveOn, qui disent au LMS quand l’AU est validé. C’est le chapitre 8.5.

Chaque statement cmi5 reste un statement xAPI ordinaire, stocké dans un LRS xAPI standard. Tu ne changes pas de magasin, tu ne changes pas de format : tu ajoutes une discipline.

⚠️ Piège — Opposer « xAPI ou cmi5 » comme s’il fallait choisir un camp. C’est un faux dilemme : cmi5 est du xAPI. La vraie question n’est jamais « xAPI ou cmi5 », mais « xAPI libre ou xAPI profilé cmi5 ? ». Tu profiles avec cmi5 dès que tu as besoin d’un lancement LMS et d’une complétion jugée par le LMS. Tu restes en xAPI libre pour tracer des expériences hors de ce cadre (un atelier présentiel, une appli autonome).

SCORM vs xAPI seul vs cmi5

Le tableau à retenir. Il montre pourquoi cmi5 est le successeur de SCORM pour le cas LMS, là où xAPI seul ne pouvait pas l’être.

Critère	SCORM	xAPI seul	cmi5
Lancement depuis un LMS	Oui, natif (le SCO trouve l’API)	Non défini	Oui, par paramètres d’URL
Complétion décidée par le LMS	Oui (`lesson_status`)	Non (le LRS ne juge pas)	Oui (`moveOn` + `masteryScore`)
Richesse du suivi	Pauvre (modèle CMI figé)	Riche (statements libres)	Riche (xAPI) et cadrée
Hors navigateur (mobile, présentiel)	Non	Oui	Oui
Structure de cours	`imsmanifest.xml`	Aucune	`cmi5.xml`
Où vivent les données	Dans le LMS	Dans un LRS	Dans un LRS
Interop « contenu packagé »	Excellente (dominant)	Faible (pas de lancement standard)	Bonne, croissante

Lis la colonne cmi5 de haut en bas : c’est SCORM plus la richesse de xAPI. C’est très exactement le sens de la formule d’ADL — cmi5 est « le profil qui permet d’utiliser xAPI comme on utilisait SCORM ».

💡 Réflexe — Quand un client dit « je veux du xAPI dans mon LMS », traduis-le presque toujours par « je veux du cmi5 ». Le xAPI pur dans un LMS pose immédiatement les deux problèmes du lancement et de la complétion. cmi5 est la forme déployable de xAPI dans un LMS.

🔌 Côté intégration — Un LMS moderne (Moodle avec le plugin adéquat, LMS d’entreprise récents, SCORM Cloud) sait importer un paquet cmi5 exactement comme un paquet SCORM : tu lui donnes un .zip contenant cmi5.xml, il gère le lancement, l’auth du LRS et la complétion. Pour l’école cliente, adopter un contenu cmi5 ne demande aucun développement : c’est la même expérience d’import qu’un SCORM, avec un suivi bien plus fin derrière. C’est un argument de vente direct.

🧭 Sur FormaCampus — FormaCampus édite déjà ses cours en SCORM (importables partout) et trace le présentiel en xAPI libre. Mais ses nouveaux modules posent un problème hybride : ils sont lancés depuis le Moodle des écoles (donc besoin d’un lancement propre et d’une complétion que Moodle comprenne), et ils veulent tracer finement (chaque vidéo vue, chaque tentative de quiz, y compris depuis l’appli mobile). SCORM ne trace pas assez ; xAPI libre ne se lance pas depuis Moodle. cmi5 est la seule réponse qui coche les deux cases. La décision est prise : les nouveaux modules passent en cmi5.

📚 La spec — cmi5 est publié par ADL (adlnet.gov), comme SCORM et xAPI. Le document de référence est la cmi5 Specification (« cmi5 — A Profile for xAPI »). Il définit la structure de cours, le protocole de lancement, les verbes, et les règles de moveOn. L’outillage de conformité est le projet CATAPULT (chapitre 8.5). Toujours vérifier la version courante et le vocabulaire exact sur adlnet.gov.

✏️ Exercices

Exercice 1 — Nomme le manque. Un collègue veut publier un module « pur xAPI » et le déposer tel quel dans le Moodle d’un lycée client, en comptant sur le fait que « le LRS enregistrera bien la complétion ». Quels deux problèmes va-t-il rencontrer, et comment cmi5 les résout-il ?

✅ Solution

Deux problèmes. (1) Le lancement : xAPI pur ne définit pas comment Moodle ouvre le contenu ni comment il lui transmet quel apprenant, quel LRS et quelle tentative — le module ne saura même pas à qui il a affaire ni où envoyer ses statements. (2) La complétion : le module enverra bien un statement completed au LRS, mais le LRS se contente de l’archiver ; il ne dira jamais à Moodle « cet élève a validé, débloque la suite ». Le LMS restera aveugle à la progression. cmi5 résout les deux : il définit le protocole de lancement (paramètres d’URL + jeton d’auth) et les règles de satisfaction (moveOn/masteryScore) que le LMS interprète pour statuer.

Exercice 2 — Vrai/faux argumenté. « cmi5 est un concurrent de xAPI qui finira par le remplacer. » Vrai ou faux ? Justifie.

✅ Solution

Faux, sur les deux points. cmi5 n’est pas un concurrent de xAPI : c’est un profil de xAPI — une convention posée par-dessus. Chaque statement cmi5 est un statement xAPI valide envoyé à un LRS xAPI standard. Il ne peut donc pas « remplacer » ce dont il dépend. La bonne formulation : cmi5 est le cadre qui rend xAPI déployable dans un LMS, à la place de SCORM. xAPI libre garde tout son sens hors de ce cadre (présentiel, appli autonome, simulateur). Les deux coexistent, l’un s’appuyant sur l’autre.

🧠 Quiz de révision

1. Quelles sont les deux choses que xAPI seul ne sait pas faire, et que cmi5 réintroduit ?

Le lancement depuis un LMS (comment le LMS ouvre le contenu et lui transmet apprenant, LRS, tentative) et la décision de complétion (un LRS stocke les statements mais ne juge pas ; il ne dit pas au LMS « c’est validé »). cmi5 ajoute un protocole de lancement et des règles de satisfaction (moveOn/masteryScore).

2. Qu’est-ce que SCORM sait faire que xAPI seul ne sait pas, et inversement ?

SCORM sait lancer un module depuis un LMS et statuer sur sa complétion, mais trace pauvrement et reste dans le navigateur. xAPI trace richement et partout (mobile, présentiel, simulateur), mais ne définit ni lancement ni jugement de complétion. cmi5 prend le meilleur des deux.

3. cmi5 est-il un concurrent de xAPI ?

Non. cmi5 est un profil de xAPI : une convention (verbes, contexte, lancement, satisfaction) posée par-dessus. Chaque statement cmi5 est un statement xAPI standard dans un LRS standard. La vraie alternative n’est pas « xAPI ou cmi5 » mais « xAPI libre ou xAPI profilé cmi5 ».

4. Pourquoi dit-on que cmi5 est « le vrai successeur de SCORM » ?

Parce que, pour le cas « contenu lancé par un LMS et dont le LMS décide la complétion », cmi5 offre exactement ce que faisait SCORM (lancement + statut) plus la richesse de suivi de xAPI et le hors-navigateur. xAPI seul ne pouvait pas succéder à SCORM, faute de lancement et de jugement de complétion.

5. Un contenu cmi5 change-t-il de magasin de données par rapport à du xAPI ?

Non. Un statement cmi5 est un statement xAPI ordinaire, envoyé à un LRS xAPI standard. cmi5 n’ajoute pas un magasin : il ajoute une discipline (verbes, contexte, lancement, satisfaction) au-dessus du même LRS.

Chapitre suivant : AU, Block & structure de cours — l’unité lançable, le regroupement, et le fichier cmi5.xml.