Chapitre 6.3 — Acteur, verbe, objet

⏱️ TL;DR — On ouvre les trois briques du noyau. L’acteur (actor) est identifié par un identifiant fonctionnel : mbox (l’e-mail en mailto:), mbox_sha1sum (son empreinte, pour ne pas exposer l’e-mail), account (homePage + name, quand il n’y a pas d’e-mail) ou openid ; c’est un Agent (une personne) ou un Group. Le verbe (verb) est une IRI unique plus un display lisible : on réutilise les vocabulaires existants (http://adlnet.gov/expapi/verbs/completed, experienced, attempted, passed, failed, answered) au lieu d’inventer. L’objet (object) est le plus souvent une Activity (id IRI + definition) mais peut aussi être un Agent, un StatementRef (pointer un autre statement) ou un SubStatement (une phrase imbriquée). Mal identifier l’acteur, c’est fragmenter les données d’une même personne ; inventer un verbe, c’est produire de la donnée que personne ne saura relire.

🎯 Objectifs

• Identifier un acteur avec le bon IFI (Inverse Functional Identifier) : mbox, mbox_sha1sum, account ou openid.
• Distinguer un Agent (une personne) d’un Group (plusieurs), et savoir quand utiliser chacun.
• Choisir un verbe existant plutôt que d’en inventer, et comprendre pourquoi l’IRI prime sur le display.
• Structurer un objet Activity (id + definition avec name/description/type) et connaître les trois autres formes d’objet.

L’acteur : une personne, un identifiant stable

L’acteur répond à « qui ? ». Le piège central : xAPI a besoin d’un identifiant stable et unique pour recoller tous les statements d’une même personne. Cet identifiant s’appelle un IFI (Inverse Functional Identifier) : une propriété qui, à elle seule, désigne une et une seule personne. Un acteur porte un IFI (et un seul), parmi quatre formes possibles.

Les quatre façons d’identifier un acteur

// 1) mbox — l'e-mail, en mailto: (le plus courant)
{
  "objectType": "Agent",
  "name": "Léa Martin",
  "mbox": "mailto:lea.martin@formacampus.fr"
}

// 2) mbox_sha1sum — l'EMPREINTE SHA1 de l'IRI mailto (pour ne pas exposer l'e-mail)
{
  "objectType": "Agent",
  "name": "Léa Martin",
  "mbox_sha1sum": "d9b1d7db4cd6e70935368a1efb10e377"
}

// 3) account — un compte applicatif (quand la personne n'a pas d'e-mail à exposer)
{
  "objectType": "Agent",
  "name": "Léa Martin",
  "account": {
    "homePage": "https://app.formacampus.fr",
    "name": "apprenant-4815"
  }
}

// 4) openid — une URI d'identité OpenID
{
  "objectType": "Agent",
  "name": "Léa Martin",
  "openid": "https://openid.formacampus.fr/lea.martin"
}

Quelques règles à graver :

• Un seul IFI par acteur. On ne met pas à la fois mbox et account sur le même acteur. Choisis-en un et tiens-t’y pour toute la plateforme, sinon la même personne apparaît comme deux apprenants différents.
• name n’identifie pas. C’est un libellé d’affichage, pas un IFI. Deux « Léa Martin » existent ; leur mbox les distingue, pas leur name.
• mbox s’écrit en mailto:. C’est mailto:lea@…, jamais lea@… nu. C’est une IRI, pas une chaîne d’e-mail brute.
• mbox_sha1sum est le hash SHA1 de la chaîne mailto:lea@… (IRI comprise). Il sert quand on veut identifier sans stocker l’e-mail en clair dans le LRS — utile côté vie privée.

⚠️ Piège — Changer d’IFI en cours de route. Si ton appli mobile identifie Léa par account (apprenant-4815) et que ton module web l’identifie par mbox (mailto:lea.martin@formacampus.fr), le LRS voit deux personnes. Tous les tableaux de bord, toute la progression, toute la certification se fragmentent silencieusement. Décide une stratégie d’identité pour toute la plateforme et applique-la partout. C’est la décision la plus structurante de ton adoption xAPI.

💡 Réflexe — Pas d’e-mail fiable pour tes apprenants (mineurs, comptes internes, invités) ? Utilise account (homePage + name), pas un mbox bricolé avec une adresse bidon. account est fait exactement pour « un identifiant applicatif interne ». Et si tu veux tracer sans exposer d’e-mail, mbox_sha1sum pseudonymise proprement.

Agent ou Group ?

• Agent = une personne (ou un système). C’est le cas par défaut, celui de tous les exemples ci-dessus.
• Group = plusieurs personnes, pour tracer une expérience collective (un binôme, une équipe projet, une classe qui réalise une activité ensemble).

// Un Group : un binôme d'atelier identifié par ses membres
{
  "objectType": "Group",
  "name": "Binôme soudure B12",
  "member": [
    { "objectType": "Agent", "mbox": "mailto:lea.martin@formacampus.fr" },
    { "objectType": "Agent", "mbox": "mailto:sami.ould@formacampus.fr" }
  ]
}

Un Group peut être identifié (il porte lui-même un IFI, ex. un account d’équipe) ou anonyme (juste une liste de member, comme ci-dessus). On l’utilise pour le travail collaboratif ; pour du suivi individuel classique, on reste sur Agent.

Le verbe : réutiliser, ne pas inventer

Le verbe répond à « quoi ? ». Deux propriétés :

• id : une IRI qui identifie le verbe de façon unique et globale. C’est la partie qui compte pour la machine.
• display : un ou plusieurs libellés lisibles (multilingues), décoratifs.

{
  "id": "http://adlnet.gov/expapi/verbs/passed",
  "display": { "fr-FR": "a réussi", "en-US": "passed" }
}

La règle d’or : réutilise un verbe existant au lieu d’en forger un nouveau. Un LRS et un tableau de bord ne savent agréger que ce qu’ils reconnaissent ; si chaque équipe invente son propre http://monsite/verbes/afiniletruc, plus personne ne peut compter « qui a terminé quoi ». Le vocabulaire ADL couvre l’essentiel :

⚠️ Piège — Inventer un verbe « parce qu’aucun ne colle exactement ». Avant de forger .../aTermineLatelier, demande-toi si completed ne suffit pas (l’objet précise quoi : l’atelier). Le verbe porte l’action, pas le détail de l’activité. Multiplier les verbes maison, c’est se condamner à des données illisibles : ni les outils du marché, ni un futur collègue, ni une IA d’analyse ne sauront les regrouper. En cas de doute réel, cherche d’abord un vocabulaire publié (registres sur adlnet.gov, profils xAPI) avant d’inventer.

💡 Réflexe — Sépare mentalement verbe et objet. « A terminé l’atelier », « a terminé le module », « a terminé le quiz » = un seul verbe (completed) et trois objets différents. Le verbe est un petit vocabulaire réutilisable ; c’est l’objet qui porte la diversité. Cette discipline garde tes données agrégeables.

L’objet : l’activité, et trois variantes

L’objet répond à « sur quoi ? ». Dans la grande majorité des cas, c’est une Activity — une ressource, un module, une question, un atelier. Mais l’objet peut aussi être une personne, un autre statement, ou une phrase imbriquée. Quatre formes, une seule très fréquente.

La forme reine : Activity

{
  "objectType": "Activity",
  "id": "https://formacampus.fr/xapi/activities/atelier-soudure",
  "definition": {
    "name": { "fr-FR": "Atelier soudure d'angle" },
    "description": { "fr-FR": "Atelier pratique de soudure à l'arc en présentiel" },
    "type": "http://adlnet.gov/expapi/activities/course"
  }
}

• id : une IRI qui identifie l’activité de façon stable et globale. C’est la clé : deux statements sur la même activité doivent partager exactement le même id. Choisis un schéma d’IRI propre à ta plateforme (ici https://formacampus.fr/xapi/activities/…) et ne le change jamais.
• definition : les métadonnées lisibles — name, description (multilingues), et type (une IRI de vocabulaire indiquant la nature de l’activité : cours, évaluation, question, simulation…). La definition est optionnelle et surtout indicative : c’est l’id qui identifie, pas la définition.

⚠️ Piège — Faire varier l’id d’une même activité (ajouter un ?v=2, changer de domaine, mettre un identifiant de session dedans). Chaque variante crée une nouvelle activité aux yeux du LRS : la progression se disperse, les rapports comptent des activités fantômes. L’id d’activité est une clé primaire stable, pas une URL de navigation. Ne mets jamais de paramètre volatil (session, timestamp, tentative) dans l’id d’activité — ça, c’est le rôle de registration dans le context (chapitre 6.4).

Les trois autres formes d’objet

// Objet = un Agent : "Léa a encadré Sami" (l'objet de l'action est une personne)
{
  "objectType": "Agent",
  "name": "Sami Ould",
  "mbox": "mailto:sami.ould@formacampus.fr"
}

// Objet = un StatementRef : pointer un AUTRE statement par son id
// (usage clé : annuler/commenter un statement — voir le "voiding", chap. 6.5)
{
  "objectType": "StatementRef",
  "id": "8f2a1c30-6b4e-4d2a-9f11-3c7e5a9b0d21"
}

// Objet = un SubStatement : une phrase IMBRIQUÉE, non enregistrée séparément
// Ici : "le formateur a prévu que Léa tenterait l'évaluation"
{
  "objectType": "SubStatement",
  "actor": { "objectType": "Agent", "mbox": "mailto:lea.martin@formacampus.fr" },
  "verb": {
    "id": "http://adlnet.gov/expapi/verbs/attempted",
    "display": { "fr-FR": "tentera" }
  },
  "object": {
    "objectType": "Activity",
    "id": "https://formacampus.fr/xapi/activities/eval-soudure"
  }
}

Ce qu’il faut retenir de ces variantes :

• Agent comme objet : quand l’action porte sur une personne (encadrer, évaluer, mentorer). L’acteur et l’objet sont alors deux personnes distinctes.
• StatementRef : un pointeur vers un statement existant, par son id (UUID). C’est le mécanisme utilisé pour annuler un statement (le voiding, chapitre 6.5) ou pour commenter/relier deux statements.
• SubStatement : une phrase complète mais imbriquée, qui n’existe pas comme statement autonome dans le LRS. Elle sert à décrire une expérience hypothétique, prévue ou rapportée (« il a prévu que … », « il a suggéré que … »). Un SubStatement n’a ni id, ni stored, ni authority : ce n’est pas un enregistrement, c’est un complément d’objet.

📚 La spec — Les formes d’identification de l’acteur (mbox, mbox_sha1sum, account, openid), la distinction Agent/Group, la structure du verbe (IRI + display) et les quatre formes d’objet (Activity, Agent, StatementRef, SubStatement) sont définies par xAPI (ADL, adlnet.gov ; IEEE 9274.1.1 pour la 2.0). Les IRI de verbes (http://adlnet.gov/expapi/verbs/…) et de types d’activité relèvent de vocabulaires publiés par ADL : on les réutilise et on cherche dans les registres avant d’inventer.

🧭 Sur FormaCampus — Décision d’architecture d’identité. FormaCampus a des apprenants avec e-mail (adultes en formation continue) et sans e-mail exploitable (alternants mineurs). Plutôt que de mélanger mbox et account, l’équipe tranche : account partout, avec homePage https://app.formacampus.fr et un name = l’identifiant interne stable de l’apprenant. Un IFI unique, sur toutes les sources (mobile, atelier, web), garantit qu’un même alternant n’apparaît jamais en double. Côté verbes, règle interne stricte : on ne pioche que dans le vocabulaire ADL (completed, passed, failed, attempted, experienced, answered) ; toute envie de verbe maison passe d’abord par une revue. Résultat : quand l’atelier émet « account:app…/apprenant-4815 – passed – atelier-soudure », le tableau de bord recolle immédiatement ce geste au reste du parcours de Léa.

✏️ Exercices

Exercice 1 — Le bon identifiant. Pour chaque cas, choisis l’IFI le plus adapté : (a) des salariés en formation continue, tous dotés d’un e-mail pro ; (b) des collégiens mineurs, sans e-mail à exposer ; (c) un besoin de tracer sans jamais stocker d’e-mail en clair dans le LRS.

Exercice 2 — Verbe maison ou pas ? Un dev veut créer le verbe https://formacampus.fr/verbs/aTermineLatelierEnPresentiel pour tracer la fin d’un atelier. Critique ce choix et propose mieux.

Exercice 3 — Choisir la forme d’objet. Quelle forme d’objet (Activity, Agent, StatementRef, SubStatement) pour : (a) « Léa a terminé le module Sécurité » ; (b) « Karim a évalué Léa » ; (c) « ce statement-ci annule le statement 8f2a… » ?

🧠 Quiz de révision

Chapitre suivant : 6.4 — Result & context — on ajoute au noyau le score, la réussite, la durée, et le contexte qui relie les statements entre eux.