Partie 6 — xAPI (Experience API)
⏱️ TL;DR — SCORM ne sait tracer qu’une chose : un module HTML lancé dans un navigateur, depuis un LMS. Or l’apprentissage a lieu partout — sur une appli mobile, dans un atelier présentiel, sur un simulateur, dans un jeu, dans un livre. xAPI (Experience API, ex-Tin Can API) répond exactement à ça : décrire n’importe quelle expérience, où qu’elle arrive, sous forme d’une petite phrase JSON — un statement :
acteur–verbe–objet(« Léa – a terminé – l’atelier soudure »). Ces phrases sont envoyées à un LRS (Learning Record Store), un magasin qui les reçoit et les sert via une API REST. Cette partie te fait maîtriser la grammaire d’un statement (acteur, verbe, objet,result,context) et le rôle du LRS. La Partie 7 passe à la pratique (auth, envoyer, lire, hors-LMS).
Le problème qu’on résout
Rappelle-toi la limite structurelle de SCORM (Partie 2) : il ne tracke que dans un navigateur, lancé depuis un LMS. Pas de mobile hors-ligne, pas d’atelier en salle, pas de simulateur métier, pas de données fines. Le jour où FormaCampus a voulu prouver qu’un apprenti avait réussi un geste technique lors d’un atelier présentiel, SCORM n’avait rien à proposer : il n’y a ni navigateur, ni LMS, ni imsmanifest.xml dans un atelier de soudure.
xAPI change de paradigme. Au lieu de « un module qui dialogue avec son LMS », on a « une expérience décrite par une phrase, envoyée à un magasin de données ». La phrase est portable, lisible, indépendante de la plateforme. L’appli mobile, le formateur avec sa tablette, le simulateur, le module web : tous peuvent émettre la même sorte de phrase vers le même LRS. On ne trace plus un écran, on trace une expérience d’apprentissage, où qu’elle survienne.
Ce que tu sauras faire à la fin de cette partie
- Expliquer pourquoi xAPI existe et ce que SCORM ne savait pas faire (mobile, présentiel, simulateur, jeu).
- Situer l’histoire (Tin Can API → Experience API ; 1.0 en 2013 ; xAPI 2.0 = IEEE 9274.1.1, 2023) et la portée du standard.
- Lire et écrire un statement complet :
acteur–verbe–objet, plusresult,context,timestamp,authority. - Identifier un acteur (
mbox,mbox_sha1sum,account,openid;AgentvsGroup). - Choisir un verbe (IRI +
display) en réutilisant les vocabulaires ADL plutôt qu’en inventant. - Structurer un objet (
Activity, mais aussiAgent,StatementRef,SubStatement). - Enrichir avec
result(score,success,completion,duration) etcontext(registration,contextActivities…). - Décrire le rôle d’un LRS : ce qu’il stocke, son API REST, l’immutabilité des statements, le voiding.
Les chapitres
| # | Chapitre | En un mot |
|---|---|---|
| 6.1 | Pourquoi xAPI | Tracer partout, pas seulement dans un LMS. |
| 6.2 | Anatomie d’un statement | La phrase acteur – verbe – objet, en JSON. |
| 6.3 | Acteur, verbe, objet | Les trois briques en détail. |
| 6.4 | Result & context | Le score, la réussite, et ce qui relie les statements. |
| 6.5 | Le LRS | Le magasin qui reçoit et sert les statements. |
Le fil rouge dans cette partie
FormaCampus veut tracer l’apprentissage au-delà du LMS : son appli mobile de révision, ses ateliers présentiels, ses simulateurs. Elle adopte xAPI et se dote d’un LRS. Au fil des chapitres, on écrit ses vrais statements — « a terminé l’atelier », « a réussi le geste technique » — et on branche son premier magasin de données d’apprentissage.
💡 xAPI ne remplace pas SCORM. Il l’élargit. SCORM reste roi pour packager un module traçable importable dans n’importe quel LMS (Parties 2 à 5). xAPI répond à une autre question : « comment tracer une expérience hors de ce cadre ? ». Les deux cohabitent — et cmi5 (Partie 8) fera le pont entre les deux mondes.
On commence : Pourquoi xAPI — le besoin, l’histoire, et ce que SCORM ne savait pas faire.