Chapitre 11.5 — Caliper vs xAPI

⏱️ TL;DR — Caliper et xAPI capturent tous deux des événements d’apprentissage — c’est leur point commun, et la source de toutes les confusions. La différence tient en un mot : cadrage. xAPI (ADL) est souple et ouvert — un verb est n’importe quelle IRI, on trace toute expérience, partout (mobile, présentiel, simulateur, informel), et on stocke dans un LRS doté d’une API de requête standardisée. Caliper (1EdTech) est cadré — actions issues d’un vocabulaire fermé, profils métier, entités typées, JSON-LD — pensé pour des analytics comparables dans un LMS institutionnel. Ni meilleur ni pire : xAPI pour la flexibilité et l’étendue, Caliper pour l’analytics standardisée. Ils coexistent volontiers ; certains outils émettent les deux. Ce chapitre te donne la grille de décision — et FormaCampus tranche.

🎯 Objectifs

• Comparer honnêtement xAPI et Caliper : gouvernance, grammaire, format, cadrage, portée.
• Comprendre pourquoi l’un est souple (xAPI) et l’autre cadré (Caliper) — et ce que ça implique.
• Décider quand choisir xAPI, Caliper, ou les deux.
• Suivre le raisonnement de FormaCampus jusqu’à sa décision.

Le même but, deux philosophies

xAPI (Parties 6 et 7) et Caliper (11.4) répondent à la même question : « comment enregistrer ce que fait un apprenant ? ». Leurs grammaires se ressemblent presque à s’y méprendre :

• xAPI : actor – verb – object (« Léa – a terminé – l’atelier »).
• Caliper : actor – action – object (« usr-2342 – Started – le quiz »).

La ressemblance s’arrête à la grammaire. Tout le reste découle d’un choix opposé :

• xAPI mise sur la liberté. Un verb est une IRI libre : tu peux décrire n’importe quelle expérience, y compris hors LMS (un atelier de soudure, une partie de simulateur, une lecture sur mobile hors-ligne). Les profils existent, mais ce sont des conventions, pas des barrières.
• Caliper mise sur le cadre. Une action se prend dans un vocabulaire fermé, à l’intérieur d’un profil métier ; les entités sont typées. Tu perds la liberté, tu gagnes la comparabilité.

💡 Réflexe — Formule-le comme un compromis, pas comme un duel : xAPI optimise l’étendue (tout tracer, partout), Caliper optimise la comparabilité (agréger proprement dans un écosystème). Dès que tu entends « on veut tout tracer, même hors LMS » → xAPI. Dès que tu entends « on veut des indicateurs comparables entre nos outils LMS » → Caliper. La phrase du besoin désigne souvent le standard.

La comparaison, ligne par ligne

Deux nuances à ne pas rater :

• Le stockage n’est pas symétrique. xAPI standardise l’écriture et la lecture : le LRS expose une API de requête (GET statements filtrés par acteur, verbe, activité, date… — Partie 7). Caliper standardise surtout l’émission (le Sensor → l’Envelope → l’endpoint) ; l’exploitation analytique se joue davantage côté event store / tableau de bord.
• Le cadre de Caliper est une force et une limite. Il rend les données comparables dans un écosystème LMS ; il devient une contrainte dès qu’on veut décrire une expérience que aucun profil ne prévoit — un cas où xAPI, lui, invente simplement un verbe.

⚠️ Piège — Croire que « Caliper remplace xAPI » ou l’inverse. Faux, sur les deux plans : ils ont des portées différentes (Caliper est taillé pour le LMS institutionnel, xAPI déborde partout) et ils peuvent coexister. Certains outils émettent les deux : du Caliper vers le tableau de bord de l’institution, du xAPI vers un LRS pour l’analyse transverse. Le choix n’est pas « lequel gagne », c’est « lequel sert ce besoin ».

Quand choisir quoi

Choisis xAPI si :

• tu traces au-delà du LMS : mobile, présentiel, simulateur, jeu, apprentissage informel ;
• tu veux un LRS requêtable pour analyser toi-même ;
• tu as besoin de décrire des expériences sur mesure (verbes que tu définis) ;
• ton écosystème est hétérogène (beaucoup de sources différentes).

Choisis Caliper si :

• ton terrain est un LMS institutionnel (université, district) qui veut des indicateurs comparables ;
• tu dois t’agréger dans le tableau de bord analytique de cette institution ;
• un client exige explicitement Caliper (sa plateforme d’analytics l’ingère) ;
• la cohérence entre outils prime sur la liberté de description.

Choisis les deux si :

• tu sers à la fois un public « toute expérience » (ton propre suivi, ton mobile, ton présentiel) et des institutions qui réclament Caliper. Tu émets alors xAPI en socle (couverture maximale) et Caliper en complément, là où on te le demande.

🔌 Côté intégration — La question est souvent tranchée par le client, pas par toi. Une université dont la brique analytics ingère du Caliper te demandera du Caliper certifié, point. Un organisme de formation qui trace des ateliers présentiels voudra du xAPI. Le bon réflexe commercial : savoir émettre les deux et brancher celui que le marché réclame. Émettre les deux depuis une même source d’événements interne (un « bus » d’événements que tu traduis en xAPI et en Caliper) t’évite de choisir un camp.

FormaCampus tranche

Reprenons le dilemme posé au chapitre 11.4. FormaCampus veut un tableau de bord (complétion par classe, temps par quiz, alertes décrocheurs) et hésite entre Caliper (cadré, taillé pour ce genre d’analytics) et xAPI (déjà en place).

Les faits :

• FormaCampus émet déjà du xAPI partout — LMS scolaire, appli mobile, ateliers présentiels, simulateurs — vers un LRS (Partie 7). C’est son socle, et il couvre le hors-LMS que Caliper ne sait pas atteindre.
• Son tableau de bord se construit très bien sur le LRS : l’API de requête xAPI donne déjà complétion, durées et inactivité, par apprenant et par classe.
• Migrer vers Caliper lui ferait perdre la couverture mobile/présentiel — pour un gain quasi nul sur son propre tableau de bord.

La décision : FormaCampus garde xAPI comme socle de son tableau de bord — c’est déjà branché, ça couvre toutes ses expériences, et le LRS est requêtable. Elle n’ajoute Caliper que de façon ciblée : le jour où une université cliente exige que ses événements alimentent sa plateforme analytique en Caliper, FormaCampus ajoute un Sensor Caliper pour ce périmètre précis, sans toucher au socle xAPI. En clair : xAPI par défaut, Caliper à la demande. Elle ne choisit pas un camp — elle choisit le socle le plus large et branche le cadre quand le client le paie.

🧭 Sur FormaCampus — Le fil rouge se referme. FormaCampus est désormais interopérable de bout en bout : elle empaquette en SCORM et cmi5, trace en xAPI, se branche en LTI 1.3 (notes AGS, rosters NRPS), échange ses tests en QTI et ses cours en Common Cartridge, synchronise les rosters via OneRoster, et analyse en xAPI — avec Caliper en réserve pour les institutions qui l’imposent. Aucun standard n’a « gagné » : chacun occupe sa place. C’est exactement ça, la maîtrise de l’interop — non pas élire un standard, mais orchestrer le bon pour chaque besoin.

📚 La spec — xAPI : ADL (adlnet.gov), norme IEEE 9274.1.1 pour la 2.0 ; statements actor/verb/object, LRS avec API de requête. Caliper : 1EdTech (1edtech.org), versions 1.1/1.2 ; Event JSON-LD actor/action/object, Metric Profiles, Sensor/Envelope. Les deux capturent des événements d’apprentissage ; ils diffèrent par la philosophie (souple/ouvert vs cadré/comparable) et la portée (toute expérience vs LMS institutionnel), pas par l’ambition. Ils coexistent : à choisir selon le besoin, ou à émettre en parallèle.

✏️ Exercices

Exercice 1 — Qui pour quel besoin ? Choisis xAPI, Caliper, ou les deux : (a) tracer des ateliers de soudure en présentiel sur tablette hors-ligne ; (b) alimenter le tableau de bord analytique d’une université qui n’ingère que du Caliper ; (c) un éditeur qui vend à la fois à des organismes de formation (présentiel) et à des universités (Caliper).

Exercice 2 — Vrai ou faux : « Caliper va remplacer xAPI ». Argumente.

Exercice 3 — Le raisonnement de FormaCampus. FormaCampus a déjà xAPI + LRS partout. Pourquoi ne migre-t-elle pas simplement tout vers Caliper pour son tableau de bord ?

🧠 Quiz de révision

Fin de la Partie 11. Chapitre suivant : Partie 12 — Concevoir & tester — l’arbre de décision global, les outils auteurs, la migration et les suites de test pour livrer un produit interopérable et certifiable.