Chapitre 1.4 — Choisir le bon standard
⏱️ TL;DR — Face à un besoin, on choisit le standard avec trois questions : (1) dois-je brancher un outil vivant dans un LMS ? → LTI. (2) Dois-je livrer un contenu autonome et traçable importable dans un LMS ? → SCORM (compatibilité maximale) ou cmi5 (moderne, riche). (3) Dois-je tracer de l’apprentissage au-delà du navigateur/LMS ? → xAPI. À quoi s’ajoutent OneRoster (rosters), QTI (tests) et Caliper (analytics) pour des besoins d’échange spécifiques. Ce chapitre en fait un arbre de décision et le confronte à des scénarios réels.
🎯 Objectifs
- Appliquer un arbre de décision pour trancher entre SCORM, cmi5, LTI et xAPI.
- Comprendre les critères qui font pencher (compatibilité, richesse des données, hors-ligne, renvoi de notes).
- Savoir combiner plusieurs standards quand un seul ne suffit pas.
- Éviter le réflexe « SCORM par défaut » quand un autre standard est plus juste.
L’arbre de décision
Lis-le de haut en bas, en t’arrêtant à la première réponse « oui ».
Les critères qui font pencher
Quand l’arbre hésite entre deux options (surtout SCORM vs cmi5), ce sont ces critères qui tranchent :
| Critère | Penche vers SCORM 1.2 | Penche vers cmi5 | Penche vers xAPI seul |
|---|---|---|---|
| Compatibilité avec de vieux LMS | ✅ maximale | ⚠️ LMS récents | — |
| Richesse des données de suivi | ❌ pauvre | ✅ riche (xAPI) | ✅ riche |
| Mobile / hors-ligne / présentiel | ❌ non | ✅ oui | ✅ oui |
| Lancement propre depuis un LMS | ✅ oui | ✅ oui | ❌ non (pas de lancement normé) |
| Complétion pilotée par le LMS | ✅ | ✅ (moveOn) | ❌ à toi de gérer |
| Maturité de l’écosystème | ✅ énorme | ⚠️ en croissance | ✅ large |
Lecture : SCORM 1.2 si tu veux « que ça marche partout, même chez le client au vieux LMS ». cmi5 si tu veux la richesse de xAPI avec un lancement et une complétion cadrés par le LMS. xAPI seul si tu traces hors d’un cadre LMS (appli maison, atelier, terrain) et que tu gères toi-même la logique.
💡 Réflexe — Ne choisis pas « SCORM par défaut » par habitude. Demande : mon contenu quitte-t-il un jour le navigateur ou le LMS ? Si oui (mobile, présentiel, données fines), SCORM te bridera — regarde cmi5 ou xAPI. Si non, et que la compatibilité prime, SCORM 1.2 reste imbattable.
Combiner plusieurs standards
La plupart des vrais produits n’en choisissent pas un seul : ils combinent. Quelques patrons fréquents :
- Contenu SCORM + outil LTI : tu livres des modules SCORM importés dans le LMS, ET ton studio interactif branché en LTI à côté.
- cmi5 + xAPI libre : cmi5 cadre la complétion (verbes
initialized…terminated), et tu émets en plus des statements xAPI « libres » (dits cmi5 allowed) pour un suivi fin. - LTI + AGS + OneRoster : l’outil se branche en LTI, renvoie les notes via AGS, et le SIS alimente les classes via OneRoster — les trois se complètent.
- QTI dans Common Cartridge : tu échanges un cours complet en Common Cartridge, avec les tests au format QTI dedans.
⚠️ Piège — Vouloir « tout faire en xAPI » parce que c’est le plus flexible. xAPI ne définit pas comment un LMS lance ton contenu ni comment il décide qu’il est terminé. Sans cmi5 (ou SCORM) par-dessus, tu réinventes le lancement, l’auth et la complétion à la main — mal. La flexibilité de xAPI se paie en cadre à reconstruire.
🔌 Côté intégration — Le choix n’est pas que technique : il dépend de ce que le client sait ingérer. Un LMS d’académie qui ne gère « que SCORM » impose SCORM, même si cmi5 serait mieux. Demande toujours au client la liste des formats/standards supportés par son LMS avant de choisir. C’est la première question d’un intégrateur pro.
🧭 Sur FormaCampus — Décisions de FormaCampus : ses cours catalogue partent en SCORM 1.2 (des écoles ont de vieux Moodle → compatibilité maximale) ; ses nouveaux parcours passent en cmi5 (suivi riche, mobile) ; son studio d’exercices est un outil LTI 1.3 (renvoi de notes) ; ses ateliers présentiels tracent en xAPI. Un seul produit, quatre standards — chacun choisi par l’arbre ci-dessus.
📚 La spec — Aucune spec ne dit « choisis-moi » : le choix est une décision d’architecture. Les specs (SCORM, cmi5, LTI, xAPI) définissent chacune un mécanisme ; c’est à toi de mapper besoin → mécanisme. On approfondit cette décision, outils et tests à l’appui, en Partie 12.
✏️ Exercices
Exercice 1 — Tranche. Pour chaque cas, donne le(s) standard(s) : (a) un éditeur veut vendre des modules importables même dans des LMS anciens ; (b) une startup veut brancher son appli de quiz dans Canvas et renvoyer les scores ; (c) un CFA veut tracer les gestes réalisés en atelier, tablette à la main, sans LMS ; (d) un module qui doit tourner sur mobile hors-ligne puis synchroniser un suivi détaillé.
✅ Solution
(a) SCORM 1.2 (compatibilité maximale prime). (b) LTI 1.3 / Advantage avec AGS (renvoi de notes). (c) xAPI vers un LRS (présentiel, hors LMS — SCORM impossible). (d) cmi5 (mobile/hors-ligne + suivi riche via xAPI + complétion cadrée) ; à défaut, xAPI seul si aucun LMS n’orchestre. Le piège serait de répondre « SCORM » partout : il échoue en (b), (c) et (d).
Exercice 2 — Un seul ne suffit pas. Un client veut : des cours importés dans son Moodle, un studio interactif intégré qui renvoie les notes, et un tableau de bord du temps passé sur mobile. Quels standards, et pourquoi pas un seul ?
✅ Solution
Trois câbles, trois standards : SCORM ou cmi5 pour les cours importés dans Moodle ; LTI Advantage (avec AGS) pour le studio intégré qui renvoie les notes ; xAPI vers un LRS pour tracer le mobile et alimenter le tableau de bord. Aucun standard ne couvre les trois besoins : packager, brancher et tracer sont des problèmes distincts (cf. 1.1). La bonne réponse est une combinaison.
🧠 Quiz de révision
1. Quelle est la première question de l’arbre de décision ?
« Dois-je brancher un outil vivant dans un LMS (compte + renvoi de notes) ? » Si oui → LTI. Sinon on descend vers les questions « contenu » puis « tracer ».
2. SCORM 1.2 ou cmi5 : qu’est-ce qui fait pencher vers cmi5 ?
Le besoin de données riches, de mobile/hors-ligne/présentiel, tout en gardant un lancement propre et une complétion pilotée par le LMS (moveOn). cmi5 = la richesse de xAPI avec le cadre LMS.
3. Pourquoi « tout faire en xAPI » est-il souvent une erreur ?
Parce que xAPI ne définit ni le lancement depuis un LMS ni la décision de complétion. Sans SCORM ou cmi5 par-dessus, on réinvente lancement, auth et complétion à la main. xAPI est fait pour tracer, pas pour orchestrer.
4. Quelle question poser au client AVANT de choisir un standard de contenu ?
« Quels formats/standards ton LMS sait-il ingérer ? » Un LMS limité à SCORM impose SCORM. Le choix dépend autant de la cible que de l’idéal technique.
5. Un produit réel utilise-t-il un seul standard ?
Rarement. Il combine : SCORM/cmi5 pour le contenu, LTI pour les outils, xAPI pour le suivi étendu, OneRoster/QTI/Caliper pour les échanges. Packager, brancher et tracer sont des besoins différents.
Chapitre suivant : Mythes & réalités — « SCORM est mort », « xAPI remplace tout » : on démonte les idées reçues.