Partie 7 — xAPI en pratique

⏱️ TL;DR — La Partie 6 a posé la théorie : le statement (acteur – verbe – objet), le LRS, les verbes en IRI, les profils. Place au code. Ici on parle vraiment au LRS : on envoie un statement (en-tête X-Experience-API-Version, auth, PUT vs POST), on interroge le magasin avec des filtres et de la pagination, on gère la mémoire de session avec le State API (la reprise, l’équivalent moderne du suspend_data SCORM), on trace hors du LMS (mobile, atelier présentiel, simulateur, hors-ligne), et on discipline ses données avec un profil de verbes stable et gouverné. À la fin, tu sais brancher n’importe quelle source sur un LRS — proprement.

De la théorie à la ligne de commande

xAPI, en concept, c’est trois idées : une phrase qui décrit une expérience, un magasin qui la range, une API REST pour l’écrire et la lire. En pratique, c’est une série de détails qui font tout planter ou tout marcher : l’en-tête de version oublié qui renvoie 400, le statementId généré côté client qui rend un renvoi idempotent, la file d’attente hors-ligne qui préserve l’horodatage réel de l’événement, le stateId qui permet à un apprenant de reprendre son module là où il l’avait laissé.

Cette partie est la boîte à outils du dev qui branche des sources sur un LRS. Chaque chapitre est du concret : des requêtes HTTP brutes que tu peux rejouer contre un LRS de test, du fetch réel, du JSON réel. On reste collé au fil rouge FormaCampus, qui branche son appli mobile et ses ateliers présentiels sur son LRS, gère la reprise via State, et se dote d’un profil de verbes maison cohérent.

💡 Prérequis — Cette partie suppose acquis le vocabulaire de la Partie 6 : ce qu’est un statement, un acteur, un verbe (IRI + display), une activité, un result, un context, un LRS. Si mbox, registration ou contextActivities sont flous, relis-la d’abord.

Ce que tu sauras faire à la fin de cette partie

• Envoyer un statement à un LRS : en-tête de version, auth Basic (ou OAuth), choix PUT (id fourni) vs POST (id généré par le LRS).
• Rendre tes envois idempotents et résilients aux erreurs réseau.
• Interroger le LRS : filtres (agent, verb, activity, registration, since, until, limit, ascending), pagination via more, statements annulés (voided).
• Utiliser le State API pour la reprise / le bookmarking, et les profils (agent, activité) pour les préférences durables.
• Savoir quand écrire un statement (événement immuable) et quand écrire un State (état courant mutable).
• Tracer hors du LMS : appli mobile native, présentiel, simulateur, terrain, hors-ligne avec synchro différée, et identifier l’apprenant sans lancement LMS.
• Définir un profil xAPI maison : réutiliser des verbes/IRI stables, garder des activityId cohérents, versionner, et gouverner le volume et la vie privée.

Les chapitres

🧭 Sur FormaCampus — Le LRS est déployé (choix d’un LRS du marché, cf. Partie 6). Cette partie raconte le branchement de toutes ses sources : l’appli mobile qui trace même dans le train, la tablette du formateur en atelier, le module web du LMS, le simulateur métier. Et le garde-fou qui rend tout ça exploitable : un profil de verbes maison, documenté et versionné, plutôt que quinze façons de dire « terminé ».

📚 La spec — Toute cette partie s’appuie sur la spec xAPI publiée par ADL (adlnet.gov) — les ressources statements, activities/state, activities/profile, agents/profile, about — et sur la xAPI Profile Spec pour le chapitre 7.5. Les numéros de version exacts évoluent (1.0.3, puis xAPI 2.0 / IEEE 9274.1.1) : on enseigne les mécanismes et on renvoie à la source pour le détail courant.

On attaque par le geste fondateur : 7.1 — Envoyer un statement.