Chapitre 1.5 — Mythes & réalités
⏱️ TL;DR — Le monde des standards e-learning traîne des idées reçues qui font prendre de mauvaises décisions : « SCORM est mort » (faux, il domine), « xAPI remplace SCORM » (non, il le complète ; cmi5 est le vrai successeur pour le cas LMS), « LTI c’est réservé aux gros » (non, 1.3 est accessible), « Tin Can et xAPI, c’est différent » (non, même chose), « si ça marche dans mon navigateur, c’est conforme » (non, ça se teste). Ce chapitre déconstruit les mythes un par un — pour que tu parles de ces standards avec justesse, y compris face à un client.
🎯 Objectifs
- Corriger les mythes les plus répandus sur SCORM, xAPI, cmi5 et LTI.
- Répondre avec assurance aux objections d’un client ou d’un collègue.
- Éviter les décisions coûteuses fondées sur des croyances erronées.
- Sortir de cette partie avec une vue juste du paysage, prêt à plonger dans SCORM.
Mythe 1 — « SCORM est mort »
Réalité : SCORM reste, en 2026, le standard le plus utilisé du e-learning. Il a plus de vingt ans, son API est datée, mais tout le sait lire : LMS, outils auteurs, plateformes RH. Un éditeur qui veut vendre partout produit encore… du SCORM. On peut le trouver vieillissant — c’est vrai — mais le déclarer mort, c’est se couper d’une part immense du marché. Ce qui est exact, c’est qu’il est complété par des standards plus modernes pour ce qu’il ne sait pas faire (mobile, présentiel, données fines).
⚠️ Piège — Refuser d’apprendre SCORM « parce que c’est du legacy ». C’est précisément parce que c’est du legacy omniprésent que le maîtriser te rend utile : il y a beaucoup de contenus SCORM à produire, migrer et déboguer, et peu de devs web qui savent le faire.
Mythe 2 — « xAPI remplace SCORM »
Réalité : xAPI ne remplace pas mécaniquement SCORM ; il ouvre un champ que SCORM ne couvrait pas. SCORM trace dans un navigateur, lancé par un LMS. xAPI trace n’importe quelle expérience, n’importe où. Ce sont des portées différentes. Et surtout : xAPI, seul, ne dit pas comment un LMS lance un contenu ni comment il décide qu’il est terminé. Le vrai « successeur de SCORM pour le cas LMS », c’est cmi5 — un profil xAPI qui réintroduit le lancement et la complétion. Donc : xAPI élargit, cmi5 succède, SCORM persiste.
| Question | SCORM | xAPI seul | cmi5 |
|---|---|---|---|
| Tracer dans un LMS | ✅ | ⚠️ pas de lancement normé | ✅ |
| Tracer hors LMS (mobile, présentiel) | ❌ | ✅ | ✅ |
| Le LMS lance le contenu | ✅ | ❌ | ✅ |
| Le LMS décide de la complétion | ✅ | ❌ | ✅ (moveOn) |
| Données riches et extensibles | ❌ | ✅ | ✅ |
Mythe 3 — « Tin Can API et xAPI, ce sont deux choses »
Réalité : c’est le même standard. « Tin Can API » était le nom de projet ; le nom officiel est Experience API (xAPI). Tu croiseras encore « Tin Can » dans de vieux outils, des menus de LMS ou des offres commerciales : lis « xAPI ». Aucune différence technique — juste un héritage de vocabulaire.
💡 Réflexe — Face à un client qui dit « on veut du Tin Can », traduis mentalement « xAPI » et poursuis. De même, « API_1484_11 » n’est pas un troisième standard : c’est le nom de l’objet JavaScript de l’API SCORM 2004 (celui de 1.2 s’appelle
API). Le vocabulaire de ce domaine est un champ de mines d’acronymes ; garde ton lexique à jour (le glossaire est là pour ça).
Mythe 4 — « LTI, c’est compliqué et réservé aux gros éditeurs »
Réalité : LTI 1.3 est à la portée d’un dev web. Oui, il y a de l’OpenID Connect et des JWT à valider — mais ce sont des briques web standard que tu connais peut-être déjà. Des bibliothèques existent dans la plupart des langages, et une intégration LTI de base (lancement + identité) se met en place en quelques jours. Le retour sur investissement est énorme : un outil LTI se déploie dans un LMS d’établissement sans créer de comptes ni ressaisir de notes. Ce mythe fait rater à beaucoup de petites structures le sésame des marchés éducatifs.
🔌 Côté intégration — Ce qui est « compliqué » dans LTI, ce n’est pas le code : c’est l’enregistrement (échanger
client_id,deployment_id, URLs et clés entre la plateforme et l’outil) et la rigueur de sécurité (valider les JWT via le JWKS). On détaille tout ça, pas à pas, en Parties 9-10 — et une fois la mécanique comprise, elle est reproductible d’un client à l’autre.
Mythe 5 — « Si mon module marche dans mon navigateur, il est conforme »
Réalité : “marcher chez moi” n’est pas “être conforme”. Un paquet SCORM peut s’afficher parfaitement et pourtant ne rien remonter (statut jamais mis à completed, Terminate jamais appelé, manifeste mal formé). Un outil peut « se lancer » sans respecter le flux LTI (JWT non validé = faille de sécurité). La conformité se vérifie avec des outils dédiés : SCORM Cloud, les suites de test ADL, le projet CATAPULT pour cmi5, un LRS de test pour xAPI, les certifications 1EdTech pour LTI. Livrer sans tester, c’est livrer un bug au client — dans un système qu’il ne pourra pas déboguer lui-même.
⚠️ Piège — « Ça a marché sur le Moodle du client A, donc c’est bon partout. » Les LMS implémentent les standards avec des variations (surtout SCORM 2004 et son séquencement). Tester sur plusieurs cibles, ou sur un référentiel neutre comme SCORM Cloud, évite les mauvaises surprises au déploiement suivant.
Mythe 6 — « cmi5, c’est un concurrent de xAPI »
Réalité : cmi5 EST du xAPI. Précisément, c’est un profil de xAPI : un ensemble de règles (verbes imposés, structure de cours, mécanisme de lancement) par-dessus xAPI. Choisir cmi5 ne veut pas dire « au lieu de xAPI » mais « xAPI cadré pour le cas LMS ». Un module cmi5 envoie des statements xAPI — simplement, certains sont obligatoires et normalisés (initialized, completed, passed, terminated…).
🧭 Sur FormaCampus — En interne, l’équipe de FormaCampus a longtemps cru devoir « choisir entre xAPI et cmi5 ». La clarification a débloqué la décision : elle fait cmi5 pour ses modules lancés par un LMS (lancement + complétion cadrés) et émet en plus des statements xAPI libres pour son suivi fin. Pas un choix exclusif : une superposition. C’est le déclic que ce chapitre veut te donner avant d’attaquer la technique.
📚 La spec — Chaque démenti ci-dessus est vérifiable à la source : SCORM, xAPI et cmi5 sur
adlnet.gov(xAPI 2.0 = norme IEEE 9274.1.1) ; LTI sur1edtech.org. Devant un mythe, la bonne réflexe reste : remonter à la spec officielle plutôt qu’à une croyance de forum.
✏️ Exercices
Exercice 1 — Réponds au client. Un client affirme : « SCORM c’est mort, faites-nous du tout-xAPI, ça remplace tout. » Formule une réponse juste et pédagogue en trois phrases.
✅ Solution
Exemple : « SCORM est ancien mais reste le format le plus lu par les LMS — on le garde pour la compatibilité. xAPI ne le remplace pas : il permet de tracer au-delà du LMS (mobile, présentiel), mais il ne définit ni le lancement ni la complétion côté LMS. Pour vos modules lancés par le LMS avec un suivi riche, le bon choix est cmi5, qui est du xAPI cadré pour ce cas — et on peut livrer aussi du SCORM pour vos LMS plus anciens. » On corrige les deux mythes (SCORM mort, xAPI remplace) sans jargon inutile.
Exercice 2 — Vrai ou faux. (a) « Tin Can API » et xAPI sont deux standards différents. (b) Un module qui s’affiche bien est forcément conforme SCORM. (c) cmi5 est un profil de xAPI. (d) LTI 1.3 est hors de portée d’un dev web isolé.
✅ Solution
(a) Faux — même standard, « Tin Can » est l’ancien nom de projet de xAPI. (b) Faux — l’affichage ne garantit pas le tracking ni un manifeste valide ; la conformité se teste (SCORM Cloud, suites ADL). (c) Vrai — cmi5 est un profil xAPI. (d) Faux — LTI 1.3 s’appuie sur OIDC + JWT (briques web standard), avec des bibliothèques disponibles ; une intégration de base prend quelques jours.
🧠 Quiz de révision
1. SCORM est-il obsolète au point de l’ignorer ?
Non. En 2026 il reste le standard le plus utilisé ; tout LMS et tout outil auteur le lisent. Il est complété (pas remplacé) par des standards modernes. Le maîtriser rend utile, car peu de devs web le connaissent.
2. xAPI remplace-t-il SCORM ?
Non : il élargit la portée (tracer hors LMS) mais ne définit ni lancement ni complétion côté LMS. Le successeur « cas LMS » est cmi5. SCORM persiste, xAPI complète, cmi5 succède.
3. « Tin Can API », c’est quoi par rapport à xAPI ?
Le même standard : « Tin Can » était le nom de projet, « Experience API (xAPI) » est le nom officiel. Aucune différence technique.
4. « Ça marche dans mon navigateur » suffit-il à prouver la conformité ?
Non. Un module peut s’afficher sans rien remonter (statut, Terminate, manifeste). La conformité se vérifie : SCORM Cloud, suites ADL, CATAPULT (cmi5), LRS de test, certifications 1EdTech (LTI).
5. cmi5 est-il un concurrent de xAPI ?
Non : cmi5 est un profil de xAPI (règles de lancement, verbes imposés, structure de cours par-dessus xAPI). Le choisir, c’est faire du xAPI cadré pour le cas LMS, pas « à la place » de xAPI.
Fin de la Partie 1. On entre dans le concret avec le standard fondateur : Partie 2 — SCORM, le standard historique.