Chapitre 6.1 — Pourquoi xAPI

⏱️ TL;DR — SCORM a un mur : il ne trace que dans un navigateur, lancé depuis un LMS (rappel Partie 2). Impossible de suivre une révision sur appli mobile hors-ligne, un atelier présentiel, un simulateur métier ou un jeu sérieux. xAPI (Experience API) fait sauter ce mur : n’importe quelle application, n’importe où, peut décrire une expérience d’apprentissage sous forme d’une petite phrase JSON — un statement acteur – verbe – objet — et l’envoyer à un LRS (magasin de données). Née sous le nom Tin Can API, standardisée en 1.0 (2013), puis 1.0.3, xAPI est devenue en 2023 la norme IEEE 9274.1.1 (xAPI 2.0). C’est le standard qui débloque tout ce que SCORM ne savait pas faire.

🎯 Objectifs

• Nommer précisément ce que SCORM ne sait pas tracer, et pourquoi (rappel de sa limite structurelle).
• Comprendre le changement de paradigme de xAPI : de « un module dans un LMS » à « une expérience, partout, vers un LRS ».
• Connaître l’histoire et les versions : Tin Can API → Experience API ; 1.0 (2013), 1.0.3, xAPI 2.0 = IEEE 9274.1.1 (2023).
• Cerner la portée de xAPI (ce qu’il couvre, ce qu’il ne fait pas) pour ne pas le confondre avec SCORM ou cmi5.

Le mur de SCORM

Reprenons la limite structurelle de SCORM, posée en Partie 2. Un SCO trace à trois conditions cumulatives :

1. il tourne dans un navigateur ;
2. il est lancé par un LMS (qui expose l’objet JS API / API_1484_11) ;
3. il dialogue en direct, pendant la session, avec ce LMS-là.

Retire une de ces conditions et SCORM ne trace plus rien. Or l’apprentissage réel les retire tout le temps :

Le point commun : ce sont de vraies expériences d’apprentissage, mais hors du tunnel « navigateur + LMS ». SCORM, par construction, ne les voit pas. Et même quand il voit, il voit peu : un lesson_status, un score, un suspend_data compact. Pas « quelle question, quelle réponse, à quel instant, dans quel contexte ».

⚠️ Piège — Croire qu’on peut « faire du mobile avec SCORM ». On peut afficher un SCORM dans un webview mobile connecté à un LMS, oui. Mais dès qu’il n’y a plus de LMS en ligne au bout du fil (hors-ligne, appli native, présentiel), SCORM n’a aucun moyen de transporter la donnée. Ce n’est pas un défaut d’implémentation : c’est le modèle de SCORM (un SCO qui parle à son LMS pendant sa session).

Le changement de paradigme

xAPI ne « corrige » pas SCORM : il change de modèle.

Trois bascules à retenir :

• De l’écran à l’expérience. SCORM trace un module lancé. xAPI décrit une expérience vécue : « a lu », « a répondu », « a réussi le geste », « a assisté à l’atelier ». L’unité n’est plus un fichier, c’est une phrase.
• De « mon LMS » à « un magasin ». SCORM parle à son LMS via un objet JS. xAPI envoie des phrases à un LRS (Learning Record Store) via une API REST — depuis n’importe quelle source qui sait faire une requête HTTP. Le LRS peut vivre à l’intérieur d’un LMS, ou être un service séparé.
• Du live-uniquement au différé. Un statement peut être émis plus tard, en lot, depuis une file d’attente (l’appli mobile stocke hors-ligne et synchronise au retour du réseau). L’expérience et son enregistrement sont découplés.

💡 Réflexe — Quand tu entends « on veut tracer l’apprentissage en dehors du module e-learning classique » — mobile, terrain, présentiel, outil maison, IoT pédagogique — pense xAPI, pas SCORM. La question « où et quoi trace-t-on ? » décide du standard avant toute autre considération.

Tin Can, Experience API, xAPI : la même chose

Un point de vocabulaire qui déroute les débutants : Tin Can API et Experience API désignent le même standard.

• Le projet a été mené par ADL (la même famille que SCORM — rappel Partie 1) pour dépasser les limites de SCORM. Nom de code du projet : « Tin Can » (le « téléphone à ficelle », clin d’œil au fait que deux systèmes se parlent enfin).
• Au moment de la publication officielle, le nom retenu a été Experience API, abrégé xAPI. « Tin Can API » reste très utilisé dans l’industrie et dans de vieux outils : c’est un synonyme, pas une version différente.

Repères de versions (on enseigne les concepts ; pour le détail courant, adlnet.gov) :

Le passage à l’IEEE (norme 9274.1.1) est un signal de maturité : xAPI n’est plus « le projet expérimental d’ADL », c’est une norme internationale. Les concepts (statement, acteur/verbe/objet, LRS) sont stables entre 1.0.x et 2.0 ; 2.0 clarifie, resserre et corrige, sans casser la grammaire de base que tu apprends dans cette partie.

📚 La spec — xAPI est publiée par ADL (adlnet.gov) pour les versions 1.0.x, et standardisée par l’IEEE (norme IEEE 9274.1.1) pour la version 2.0 (2023). N’invente jamais un numéro de version ou un mot-clé : en cas de doute, la référence fait autorité. « Tin Can API » = « Experience API » = « xAPI » : trois noms, un standard.

La portée : ce que xAPI fait, et ne fait pas

xAPI est puissant mais minimaliste. Il définit :

• une grammaire de phrase (le statement : acteur – verbe – objet, plus result, context, timestamp, authority) ;
• un magasin et son API REST (le LRS) pour stocker et relire ces phrases.

Ce qu’il ne fait pas, volontairement :

• Il ne dit pas comment lancer un contenu depuis un LMS (pas de packaging, pas de imsmanifest.xml). C’est justement le rôle de cmi5 (Partie 8), qui ajoute le lancement propre par-dessus xAPI.
• Il n’impose pas de vocabulaire métier unique : les verbes et les structures d’activité sont ouverts. C’est sa force (souplesse) et son risque (chacun peut décrire les choses à sa façon → on y répond par les profils, et par la discipline de réutiliser les vocabulaires existants — chapitre 6.3).
• Il ne remplace pas un LMS : un LRS stocke des données, il n’orchestre pas un parcours, ne gère pas d’inscriptions, ne rend pas de contenu. LRS ≠ LMS (on y revient au chapitre 6.5).

🔌 Côté intégration — Un cahier des charges qui demande « suivi xAPI » attend deux choses vérifiables : (1) que ton produit émette des statements conformes vers un LRS (le leur ou le tien), et (2) que ces statements soient exploitables (verbes cohérents, acteurs identifiables, contexte présent). « On envoie du JSON quelque part » ne suffit pas : c’est la conformité de la grammaire et le choix des verbes qui font qu’un tableau de bord ou une IA peut réellement lire tes données. D’où l’importance des chapitres suivants.

🧭 Sur FormaCampus — Le déclencheur. Une école cliente lance une formation en alternance avec des ateliers pratiques (soudure, sécurité chantier). Elle veut la preuve que chaque apprenti a réalisé et réussi les gestes — pas juste « a ouvert le module ». SCORM est hors-jeu : il n’y a pas de module, il y a un atelier et un formateur avec une tablette. Décision de FormaCampus : adopter xAPI et se doter d’un LRS. Le formateur tape sur sa tablette « Léa – a réussi – le geste de soudure d’angle », l’appli émet un statement, le LRS l’enregistre. Le même LRS recevra bientôt les statements de l’appli mobile de révision et des simulateurs. Pour la première fois, FormaCampus voit l’apprentissage là où il a vraiment lieu. Les chapitres suivants écrivent ces phrases une par une.

✏️ Exercices

Exercice 1 — SCORM ou xAPI ? Pour chaque besoin, dis si SCORM suffit ou s’il faut xAPI, et pourquoi : (a) un module HTML de sensibilisation, lancé dans le Moodle de l’école, qui doit remonter un score ; (b) une appli mobile qui fait réviser dans le métro, hors-ligne, et synchronise plus tard ; (c) un formateur qui valide un geste technique en atelier ; (d) un simulateur de conduite installé sur un poste, sans navigateur.

Exercice 2 — Le vocabulaire. Un collègue dit : « On m’a demandé du Tin Can API, mais nous on ne connaît que xAPI, il va falloir tout réapprendre. » Que lui réponds-tu ?

Exercice 3 — La portée. Vrai ou faux, en justifiant : « xAPI remplace à la fois SCORM (le packaging) et le LMS (l’orchestration). »

🧠 Quiz de révision

Chapitre suivant : 6.2 — Anatomie d’un statement — on ouvre la phrase acteur – verbe – objet et on lit un statement JSON complet, champ par champ.