Chapitre 11.4 — Caliper Analytics

⏱️ TL;DR — Caliper Analytics (1EdTech) capture des événements d’apprentissage normalisés pour alimenter un tableau de bord. Comme xAPI, sa brique décrit une action — mais en actor / action / object — en JSON-LD. Sa force est le cadrage : les événements sont regroupés en profils métier (lecture, évaluation, usage d’outil, forum…), les actions viennent d’un vocabulaire fermé, et les entités sont typées. Un composant appelé Sensor emballe les événements dans une Envelope et la POST vers un endpoint (l’event store). Résultat : des données comparables d’un outil à l’autre dans un écosystème LMS. Versions 1.1 et 1.2. C’est le cousin rigoureux de xAPI ; on tranche entre les deux au chapitre suivant.

🎯 Objectifs

• Expliquer ce que capture Caliper et à quoi sert un tableau de bord analytics.
• Comprendre les profils métier (Metric Profiles) et pourquoi ils cadrent les événements.
• Lire un Event Caliper : actor / action / object, entités typées, JSON-LD.
• Suivre le trajet Sensor → Envelope → endpoint.
• Situer Caliper comme le cousin cadré de xAPI (comparaison détaillée au chapitre 11.5).

Capturer l’apprentissage, version cadrée

xAPI (Parties 6 et 7) t’a appris à tracer une expérience avec un statement acteur–verbe–objet. Caliper poursuit le même but — décrire ce que fait un apprenant — mais avec une philosophie opposée : la rigueur avant la liberté. Là où xAPI te laisse inventer n’importe quel verbe (une IRI libre), Caliper impose un vocabulaire d’actions fermé et des structures typées, regroupées par profils.

Pourquoi ce cadre ? Pour que les événements soient comparables. Si l’outil A et l’outil B émettent tous deux un AssessmentEvent avec action: "Started", un tableau de bord peut les agréger sans se demander si « commencé », « démarré » et initialized désignent la même chose. Caliper échange un peu de souplesse contre beaucoup de cohérence analytique — exactement ce que veut une institution qui pilote plusieurs outils.

Les profils métier (Metric Profiles)

Caliper ne définit pas « un événement générique » : il définit des profils, chacun couvrant un domaine d’usage avec ses types d’événements, ses actions autorisées et ses entités.

💡 Réflexe — Avant d’émettre un événement, identifie son profil. « L’élève a démarré un quiz » → profil Assessment, AssessmentEvent, action: "Started". « L’élève a regardé une vidéo » → profil Media, MediaEvent. Choisir le bon profil, c’est prendre le bon type d’événement et les actions autorisées qui vont avec — tu ne « choisis » pas une action au hasard, tu la prends dans la liste du profil.

Anatomie d’un Event

Un événement Caliper est un objet JSON-LD : du JSON, plus un @context qui donne un sens sémantique aux champs. Voici un AssessmentEvent : « l’élève usr-2342 a démarré le quiz Fractions ».

{
  "@context": "http://purl.imsglobal.org/ctx/caliper/v1p2",
  "id": "urn:uuid:cf6e0f3b-3511-4254-86f5-6f9b2f1d0a77",
  "type": "AssessmentEvent",
  "actor": {
    "id": "https://formacampus.fr/users/usr-2342",
    "type": "Person"
  },
  "action": "Started",
  "object": {
    "id": "https://formacampus.fr/assessments/quiz-fractions",
    "type": "Assessment",
    "name": "Quiz - fractions"
  },
  "eventTime": "2026-05-12T14:20:00.000Z",
  "edApp": {
    "id": "https://formacampus.fr",
    "type": "SoftwareApplication"
  },
  "group": {
    "id": "https://formacampus.fr/terms/2026/classes/6eA-math",
    "type": "CourseSection",
    "courseNumber": "MATH-6eA"
  },
  "membership": {
    "id": "https://formacampus.fr/terms/2026/classes/6eA-math/rosters/1",
    "type": "Membership",
    "member": "https://formacampus.fr/users/usr-2342",
    "organization": "https://formacampus.fr/terms/2026/classes/6eA-math",
    "roles": ["Learner"]
  },
  "session": {
    "id": "https://formacampus.fr/sessions/sess-8890",
    "type": "Session"
  }
}

Champ par champ :

• @context : le contexte JSON-LD — il fixe le vocabulaire et la version de Caliper (ici v1p2). C’est lui qui rend le JSON sémantiquement interprétable.
• id : l’identifiant unique de l’événement, un URN UUID (urn:uuid:...).
• type : le type d’événement, imposé par le profil (AssessmentEvent).
• actor / action / object : le noyau. actor = qui (une entité Person), action = quoi (un terme du vocabulaire fermé, Started), object = sur quoi (une Assessment). Note que chaque entité est typée (type: "Person", type: "Assessment").
• eventTime : quand, en ISO 8601.
• edApp : l’application qui a produit l’événement (SoftwareApplication).
• group : le contexte de classe (CourseSection) — précieux pour agréger par classe.
• membership : le rôle de l’acteur dans ce groupe (Learner).
• session : la session applicative, pour relier les événements d’une même connexion.

⚠️ Piège — Inventer une valeur d’action (« Commenced », « BegunQuiz »…) comme on inventerait un verbe xAPI. Interdit : en Caliper, action se prend dans le vocabulaire fermé du profil concerné (Started, Submitted, Viewed…). Une action hors-liste casse la comparabilité — et c’est précisément ce que Caliper existe pour éviter. Même chose pour type : c’est le profil qui dicte les types d’événements et d’entités valides.

💡 Réflexe — Repère le parallèle avec xAPI pour ne pas tout réapprendre : actor/action/object de Caliper ≈ actor/verb/object du statement xAPI (6.2). La grande différence tient en un mot : le verb xAPI est une IRI libre, l’action Caliper est enfermée dans une liste. Retiens ça : c’est le cœur de la comparaison du chapitre 11.5.

Du Sensor à l’endpoint

Caliper ne se contente pas de définir des événements : il définit comment les envoyer. Le composant émetteur s’appelle un Sensor. Il emballe un ou plusieurs événements dans une Envelope et la POST vers un endpoint (l’event store).

{
  "sensor": "https://formacampus.fr/sensors/lms-1",
  "sendTime": "2026-05-12T14:20:03.000Z",
  "dataVersion": "http://purl.imsglobal.org/ctx/caliper/v1p2",
  "data": [
    { "type": "AssessmentEvent", "action": "Started",  "...": "..." },
    { "type": "AssessmentItemEvent", "action": "Completed", "...": "..." }
  ]
}

• sensor : qui émet.
• sendTime : quand l’envoi part (distinct de l’eventTime de chaque événement — comme stored vs timestamp en xAPI).
• dataVersion : la version de Caliper des événements du lot.
• data : le tableau d’événements (on peut en grouper plusieurs par envoi, pour réduire les requêtes).

L’envoi lui-même est un simple POST HTTP :

POST /caliper/events HTTP/1.1
Host: analytics.formacampus.fr
Authorization: Bearer eyJ0eXAiOiJKV1Qi...
Content-Type: application/json
 
{ "sensor": "https://formacampus.fr/sensors/lms-1", "sendTime": "...", "dataVersion": "...", "data": [ ... ] }

À quoi sert le tableau de bord

Une fois les événements dans l’event store, on analyse. Parce que Caliper est cadré, l’agrégation est directe :

• Engagement : combien d’élèves ont démarré vs soumis un Assessment (un entonnoir de complétion).
• Temps passé : durée entre Started et Submitted, par élève, par classe (group).
• Repérage des décrocheurs : qui n’a aucun événement depuis dix jours.
• Comparaison inter-outils : parce que « démarrer une évaluation » se dit AssessmentEvent + Started partout, les données de l’outil A et de l’outil B s’additionnent sans retraitement.

C’est là tout l’intérêt du cadrage : un tableau de bord institutionnel veut des indicateurs comparables, pas un musée d’événements hétéroclites.

🔌 Côté intégration — Caliper est né dans le monde des LMS institutionnels (universités, districts) qui veulent une vue analytique unifiée de leurs outils. Si tu vends un outil à ces acteurs, émettre du Caliper aux profils standard te rend agrégeable dans leur tableau de bord — un argument de conformité. 1EdTech propose une certification Caliper. Mais attention : hors de ce monde LMS (mobile, présentiel, informel), le cadre de Caliper devient une contrainte — et c’est là que xAPI reprend l’avantage (chapitre 11.5).

🧭 Sur FormaCampus — FormaCampus veut un tableau de bord pour ses établissements : taux de complétion par classe, temps moyen par quiz, alertes décrocheurs. Techniquement, Caliper est taillé pour ça — événements cadrés, group = la classe, comparables d’un module à l’autre. Mais FormaCampus a déjà un LRS et émet du xAPI partout, y compris hors LMS (appli mobile, ateliers présentiels). Doit-elle ajouter un Sensor Caliper, migrer, ou faire coexister les deux ? La question est posée ; la décision — et sa justification — c’est le chapitre suivant.

📚 La spec — Caliper Analytics est publié par 1EdTech (1edtech.org), versions 1.1 et 1.2. Un Event (JSON-LD, @context) porte actor/action/object, des entités typées (Person, Assessment, CourseSection…), eventTime, et un contexte (edApp, group, membership, session). Les actions proviennent d’un vocabulaire contrôlé, regroupé par Metric Profiles (Assessment, Reading, Media, ToolUse, Forum, Grading, Session…). Un Sensor émet des Envelope (sensor, sendTime, dataVersion, data) vers un endpoint. Liste exacte des profils, types d’événements et actions sur 1edtech.org.

✏️ Exercices

Exercice 1 — Lis l’événement. D’après l’AssessmentEvent plus haut : qui, quoi, sur quoi, dans quel contexte de classe, et avec quel rôle ?

Exercice 2 — Choisis profil et action. Pour chaque cas, donne le profil, le type d’événement et une action plausible : (a) un élève met une vidéo en pause ; (b) un élève poste un message dans un forum ; (c) un élève se déconnecte.

Exercice 3 — Sensor et Envelope. Ton app génère 50 événements en une minute. Faut-il 50 POST ? Décris ce que fait le Sensor et pourquoi sendTime diffère de eventTime.

🧠 Quiz de révision

Chapitre suivant : 11.5 — Caliper vs xAPI — la comparaison honnête, et comment FormaCampus tranche.