Chapitre 7.5 — Profils xAPI & bonnes pratiques

⏱️ TL;DR — xAPI est libre : tu peux inventer n’importe quel verbe, n’importe quelle activité. C’est sa force et son piège. Si chaque source invente ses IRI, ton LRS se remplit de données ininterrogeables — dix façons de dire « a terminé », zéro statistique possible. La discipline s’appelle le profil xAPI : un ensemble convenu et documenté de verbes, d’activités et de structures pour un usage. Règle d’or : réutilise des verbes/IRI stables existants (ADL, cmi5, registres) ; n’invente que ce qui manque, sous ton domaine, versionné et documenté. Ajoute la gouvernance — volume, vie privée (lien vers /rgpd), données de mineurs — et tu passes d’un tas de statements à un actif exploitable. Ce chapitre finit sur une checklist « bon plan de traçage ».

🎯 Objectifs

• Comprendre ce qu’est un profil xAPI et pourquoi il rend les données exploitables.
• Savoir réutiliser des verbes/IRI stables plutôt qu’en inventer.
• Garder des activityId cohérents et versionner son vocabulaire.
• Poser une gouvernance : volume, vie privée, données de mineurs, rétention.
• Dérouler une checklist avant de tracer quoi que ce soit.

Le revers de la liberté

La spec xAPI ne t’oblige à aucun vocabulaire. Tu veux un verbe « a bidouillé » avec l’IRI https://monsite.fr/verbes/bidouille ? Le LRS l’accepte. C’est génial pour la souplesse — et catastrophique sans discipline. Regarde ce que trois équipes non coordonnées produisent pour le même fait :

[
  { "verb": { "id": "http://adlnet.gov/expapi/verbs/completed" } },
  { "verb": { "id": "https://formacampus.fr/verbs/termine" } },
  { "verb": { "id": "https://app.formacampus.fr/xapi/v/finished" } }
]

Trois IRI différentes pour « a terminé ». Conséquence : pour compter les complétions, ta requête (chapitre 7.2) doit connaître les trois — et la quatrième que quelqu’un ajoutera demain. Le tableau de bord devient un jeu de devinettes. Les données sont là, mais inexploitables.

⚠️ Piège — Inventer un verbe parce que c’est plus rapide que de chercher l’existant. Chaque verbe inventé sans raison est une dette : il faudra le connaître pour toute requête, à jamais. Le coût de l’invention n’est pas à l’écriture, il est à la lecture, multiplié par tous les tableaux de bord et toutes les analyses futures.

Le profil xAPI : la convention partagée

Un profil xAPI (au sens de la xAPI Profile Spec) est un document qui fixe les conventions d’un usage : quels verbes, quelles activités, quelles structures de statement, avec quelles IRI stables. C’est exactement ce que fait cmi5 (un profil qui normalise initialized, completed, passed, terminated… — Partie 8) ou le profil SCORM pour xAPI.

Deux réflexes, dans l’ordre :

1. Réutiliser un vocabulaire existant. Avant d’inventer, cherche :
   • les verbes ADL (http://adlnet.gov/expapi/verbs/... : completed, passed, failed, experienced, attempted, answered, initialized, terminated, voided…),
   • les profils publiés (cmi5, profils de registres communautaires),
   • les types d’activité ADL (http://adlnet.gov/expapi/activities/... : course, module, assessment, question…).
2. N’inventer que le manquant — et le faire proprement (section suivante).

💡 Réflexe — Utilise les verbes standards pour les faits standards : completed, passed, failed, answered, experienced, attempted. Réserve tes verbes maison aux gestes vraiment propres à ton métier (« a réalisé la passe de fond en soudure TIG ») qu’aucun vocabulaire existant ne couvre. Le bon ratio, dans un profil sain : beaucoup de verbes réutilisés, peu d’inventés.

Bien frapper ses propres IRI

Quand tu dois inventer (un geste métier sans équivalent), l’IRI doit être stable, résoluble et maîtrisée. Une IRI de verbe ou d’activité est une promesse permanente : des statements vont la porter pour toujours.

Les règles :

• Sous un domaine que tu contrôles. https://formacampus.fr/xapi/verbs/... — pas le domaine d’un tiers, pas un domaine que tu risques de perdre.
• Descriptive et stable. .../verbs/a-realise-le-geste, pas .../verbs/v3temp. Une fois émise et utilisée, elle ne change plus (sinon tu casses l’historique).
• Documentée. Chaque IRI maison est décrite dans ton profil : sens, quand l’émettre, structure attendue. Idéalement, l’IRI résout vers cette doc.
• Versionnée avec soin (voir plus bas).

{
  "verb": {
    "id": "https://formacampus.fr/xapi/verbs/a-realise-le-geste",
    "display": { "fr-FR": "a réalisé le geste", "en-US": "performed the gesture" }
  }
}

⚠️ Piège — Réutiliser une IRI d’un tiers pour un sens différent du sien. Une IRI est un identifiant partagé : si tu recycles http://adlnet.gov/expapi/verbs/passed pour dire autre chose que « a réussi », tu pollues les analyses de tout le monde, y compris les tiennes. Et à l’inverse, ne mets pas tes verbes maison sous un domaine que tu ne maîtrises pas : le jour où tu le perds, l’identité de tes données part avec.

La cohérence des activityId

Même discipline pour les activités. Un activityId est l’identité permanente d’un objet d’apprentissage. Règle : une activité = une IRI, pour toujours.

• Stable dans le temps. Le module « Sécurité numérique » garde https://formacampus.fr/xapi/activities/module-securite-numerique même si son contenu évolue. Changer l’IRI, c’est créer une nouvelle activité aux yeux du LRS et couper l’historique en deux.
• Cohérente entre sources. Le module web, l’appli mobile et la tablette doivent référencer la même IRI pour la même activité. Sinon, impossible d’agréger « qui a fait ce module » toutes sources confondues (chapitre 7.4).
• Structurée. Un schéma d’IRI clair rend le parc lisible et évite les collisions.

💡 Réflexe — Tiens un référentiel d’IRI (un simple tableau versionné : IRI ↔ signification ↔ date d’introduction). C’est le document qui empêche deux devs de frapper deux IRI pour la même chose, ou de recycler une IRI pour autre chose. Sans ce référentiel, la cohérence tient à la mémoire des gens — elle ne tient pas.

Versionner son vocabulaire

Un vocabulaire vit. Mais une IRI émise est gravée dans l’historique. Comment évoluer sans tout casser ?

• Ne réutilise jamais une IRI pour un sens différent. Si le sens change, c’est une nouvelle IRI.
• Versionne le profil, pas chaque IRI à la légère. Ton profil (le document) a une version (v1, v2…) ; il ajoute des verbes, en déprécie (sans les supprimer de l’historique), documente les changements.
• Déprécier n’est pas supprimer. Un verbe qu’on n’émet plus reste interrogeable pour les anciens statements. On le marque « déprécié » dans la doc, on cesse de l’émettre, mais les tableaux de bord historiques doivent encore le connaître.
• Dates d’introduction. Sachant quand un verbe est apparu, tu interprètes correctement une absence de données avant cette date (ce n’est pas « personne n’a fait », c’est « on ne traçait pas encore »).

🔌 Côté intégration — Un profil documenté et stable est ce qui permet à un tiers (un LRS partenaire, un outil d’analytics, une académie) de comprendre tes données sans t’appeler. À l’inverse, un LRS aux verbes non documentés est une boîte noire : personne d’externe ne peut l’exploiter, et sa valeur analytique s’effondre. Publier son profil (ou l’aligner sur un profil existant), c’est rendre ses données interopérables au niveau sémantique — l’étage au-dessus de « ça transporte du JSON ».

Gouverner les données d’apprentissage

Un LRS branché sur mobile + présentiel + web grossit vite et contient des données personnelles sensibles : qui apprend quoi, quand, avec quels résultats. Ça ne se gère pas à la légère.

Volume

Chaque interaction peut devenir un statement. Multiplié par les apprenants, les sources et le temps, ça monte en millions. Décide ce qui mérite un statement (un fait d’apprentissage) et ce qui relève du State (un état courant, chapitre 7.3) ou d’un simple log applicatif. Tout tracer « au cas où » sature le LRS et noie le signal.

Vie privée

Les statements sont des données personnelles au sens du RGPD dès qu’ils identifient un apprenant. Conséquences directes :

• Minimise l’identifiant. Préfère un account avec id interne opaque à l’e-mail en clair (mbox) répété dans chaque statement. La correspondance id ↔ personne reste dans ta base (chapitre 7.4).
• Minimise le contenu. Ne mets pas dans un statement plus que le fait d’apprentissage : pas de commentaire libre potentiellement sensible, pas de donnée superflue dans result.response ou context.extensions.
• Base légale, information, durées. Il faut une base légale, informer les apprenants, définir une durée de conservation et pouvoir exercer les droits (accès, effacement). Le voiding masque un statement mais ne supprime pas ; l’effacement réel dépend de ton LRS et de ta politique de rétention.

⚠️ Piège — Traiter le LRS comme un simple log technique. C’est un traitement de données personnelles à part entière. Le brancher sur mobile + présentiel démultiplie la collecte : sans base légale, sans information, sans durée de conservation, tu construis une dette RGPD proportionnelle à ton volume. Cadre-le avant d’ouvrir les vannes, pas après.

Données de mineurs

En contexte scolaire, une grande partie des apprenants sont mineurs. Leurs données bénéficient d’une protection renforcée : recueil du consentement adapté (titulaires de l’autorité parentale), minimisation stricte, prudence maximale sur ce qu’on trace et combien de temps. Un plan de traçage qui ignore l’âge des apprenants est un plan incomplet.

🧭 Sur FormaCampus — FormaCampus fige un profil de verbes maison, versionné et documenté : l’essentiel réutilise les verbes ADL (completed, passed, failed, answered, experienced), et seuls quelques gestes métier (soudure, soins…) ont des IRI propres sous https://formacampus.fr/xapi/verbs/.... Un référentiel d’activityId garantit que le module web et l’appli mobile parlent de la même activité. Côté gouvernance : identifiants account opaques (pas d’e-mail en clair), durée de conservation définie, et traitement spécifique des mineurs côté LMS scolaire — le tout aligné avec ce que raconte le cours RGPD. Résultat : un LRS exploitable, défendable en audit, et compréhensible par un partenaire.

📚 La spec — La notion de profil xAPI (conventions de verbes, d’activités et de structures pour un usage) est formalisée par la xAPI Profile Spec d’ADL (adlnet.gov) ; cmi5 en est l’exemple canonique. Pour la conformité vie privée / données personnelles, la référence n’est pas ADL mais le RGPD — voir le cours dédié /rgpd, en particulier sur la minimisation, les durées de conservation et les données de mineurs.

Checklist : un bon plan de traçage

Avant d’émettre le premier statement d’un projet, réponds à tout ceci. C’est le livrable qui sépare un LRS exploitable d’un tas de données.

💡 Réflexe — Écris ce plan avant le code, pas après. Rétro-documenter un LRS déjà rempli de verbes anarchiques coûte dix fois plus cher que de convenir du profil au départ. Une page de plan de traçage évite des mois de données inexploitables.

✏️ Exercices

Exercice 1 — Réutiliser ou inventer ? Pour chacun, dis s’il faut un verbe standard (lequel) ou un verbe maison : (a) « a terminé un module » ; (b) « a répondu à une question » ; (c) « a réussi une manœuvre de créneau dans le simulateur de conduite » ; (d) « a échoué à l’évaluation ».

Exercice 2 — L’IRI qui change. Une équipe a tracé pendant six mois avec activityId = https://formacampus.fr/activites/secu puis a « rangé » ses IRI en passant à https://formacampus.fr/xapi/activities/module-securite-numerique. Que s’est-il passé côté données ?

Exercice 3 — Audit vie privée. On te montre ce statement émis par l’appli mobile d’un collège. Relève au moins deux problèmes de gouvernance / vie privée, et un problème de profil.

{
  "actor": { "mbox": "mailto:eleve.mineur@college-victor-hugo.fr" },
  "verb": { "id": "https://app.formacampus.fr/v/fini" },
  "object": { "id": "https://formacampus.fr/xapi/activities/module-3" },
  "result": { "response": "eleve stresse, en difficulte, a pleure" }
}

🧠 Quiz de révision

Fin de la Partie 7. Partie suivante : Partie 8 — cmi5, le pont vers le LMS — on reprend tout ce qu’on vient d’apprendre sur xAPI et on le structure pour un lancement propre depuis un LMS : c’est le profil cmi5.