xAPI vs SCORM : quel standard choisir pour vos modules en 2026 ?

Un prestataire vous propose « du xAPI, c'est plus moderne ». Votre LMS, lui, n'accepte que des .zip SCORM. Entre les deux, cmi5 et LTI apparaissent dans les devis sans que personne ne vous explique ce qu'ils changent pour vous. Cet article compare les quatre standards sur ce qui compte pour un responsable formation : ce que chacun enregistre, ce qu'il faut installer pour qu'il fonctionne, ce que les plateformes lisent réellement en 2026, et dans quels cas rester sur SCORM reste la bonne décision.

Sommaire :

1. Quatre standards pour trois problèmes différents
2. Que suit SCORM, concrètement ?
3. Que suit xAPI, et pourquoi faut-il un LRS ?
4. cmi5 : le chaînon manquant entre xAPI et votre LMS
5. LTI : brancher un outil externe, pas livrer un module
6. Ce que les LMS lisent vraiment en 2026
7. Quand rester sur SCORM
8. Quand passer à xAPI ou cmi5
9. Tableau de décision
10. Questions fréquentes

Quatre standards pour trois problèmes différents

SCORM, xAPI, cmi5 et LTI ne sont pas quatre générations d'un même besoin. Ils répondent à trois problèmes distincts : empaqueter un cours pour qu'un LMS l'importe et le lance, enregistrer ce qu'une personne a fait pendant une activité d'apprentissage, et connecter une plateforme à un outil externe sans recopier les comptes. Les confondre mène à des cahiers des charges qui demandent l'impossible, du type « un SCORM qui remonte dans un LRS depuis une application mobile hors ligne ».

SCORM règle le premier problème et une partie du deuxième. Il définit un paquet (le .zip et son manifeste), une façon de le lancer dans un navigateur, et un petit vocabulaire de suivi : statut, score, temps, données de reprise. xAPI règle le deuxième problème et seulement lui : il décrit comment écrire et lire des traces d'apprentissage dans une base dédiée, sans rien dire du paquet ni du lancement. cmi5 ajoute à xAPI ce qui manque pour qu'un LMS sache importer et lancer un cours, et pour qu'une trace « terminé » veuille dire la même chose partout. LTI, enfin, ne transporte aucun contenu : il connecte votre LMS à un outil qui héberge lui-même l'activité, et lui permet de renvoyer une note.

Si vous découvrez le vocabulaire (manifeste, SCO, statut), lisez d'abord le guide SCORM du responsable formation. Le présent article suppose que vous savez ce qu'est un paquet SCORM et que votre question est « faut-il en sortir ».

Que suit SCORM, concrètement ?

SCORM suit ce qui se passe à l'intérieur d'un module lancé depuis un LMS, dans un navigateur, et rien d'autre. La page de référence de l'ADL, l'organisme du ministère américain de la Défense qui a publié le standard, le décrit en trois parties : le modèle d'agrégation de contenu (le .zip, le manifeste imsmanifest.xml, les métadonnées), l'environnement d'exécution (le dialogue entre le cours et le LMS pendant la session) et, pour SCORM 2004 seulement, le séquencement et la navigation. SCORM 1.2 date de 2001 et reste la version « largement adoptée » selon l'ADL ; SCORM 2004 4e édition, publiée en 2009, est la dernière.

Le vocabulaire de suivi de SCORM

Le cours parle au LMS par une interface JavaScript que le LMS met à disposition dans la page. Il y écrit un nombre limité de valeurs, listées dans la référence d'exécution de scorm.com. En SCORM 1.2, le statut tient dans un seul champ (cmi.core.lesson_status) qui prend l'une des valeurs réussi, terminé, échoué, incomplet, parcouru ou non commencé. Le score va dans cmi.core.score.raw, le temps de session dans cmi.core.session_time, et l'état de reprise dans cmi.suspend_data, limité à 4 096 caractères.

SCORM 2004 sépare l'achèvement (cmi.completion_status) de la réussite (cmi.success_status), porte la limite de reprise à 64 000 caractères dans ses 3e et 4e éditions, et permet d'enregistrer le détail des réponses à un quiz. Le comparatif SCORM 1.2 ou SCORM 2004 détaille ces écarts ; retenez ici qu'aucune des deux versions ne sort du cadre « un apprenant, un module, une session dans le navigateur ».

Ce que SCORM ne saura jamais

SCORM ignore ce qui se passe hors du module : une vidéo vue sur une autre plateforme, une mise en situation en salle, un geste professionnel validé par un tuteur, une consultation de fiche sur un téléphone sans connexion. Il ne connaît pas non plus le détail de ce qui s'est passé à l'intérieur, au-delà de ce que l'outil auteur a choisi d'écrire dans les champs ci-dessus. Vous savez que Madame Martin a terminé le module avec 85 %. Vous ne savez pas qu'elle a rejoué trois fois la séquence sur les équipements de protection, ni combien de temps elle a passé sur chaque écran.

La deuxième limite est structurelle : le cours doit tourner dans le même contexte de navigateur que le LMS, puisque c'est là qu'il trouve l'interface JavaScript. Pas de lancement depuis une application native, pas de suivi hors ligne, pas de remontée depuis un simulateur. Quand ces besoins apparaissent, SCORM ne peut pas être « amélioré » ; il faut un autre mécanisme d'enregistrement.

Que suit xAPI, et pourquoi faut-il un LRS ?

xAPI suit n'importe quelle expérience d'apprentissage, à condition que quelqu'un écrive la phrase qui la décrit. C'est la différence de nature avec SCORM : au lieu d'un petit tableau de champs fixes, xAPI enregistre des « déclarations » (statements) construites sur le modèle acteur, verbe, objet. « Nadia a visionné la vidéo Consignation électrique », « Karim a réussi l'évaluation Habilitation B1V avec 17/20 », « L'équipe du matin a participé à l'exercice d'évacuation ». Chaque déclaration est un objet JSON daté, rattaché à l'autorité qui l'émet, et peut porter un résultat, un contexte et des pièces jointes.

Le standard s'appelait Tin Can API à ses débuts, du nom du projet lancé par l'ADL en 2011 ; la première version officielle, xAPI 1.0, date de 2013 selon l'ADL. Il est devenu une norme IEEE en 2023 : la fiche IEEE 9274.1.1-2023 indique une approbation le 30 mars 2023 et une publication le 6 octobre 2023, et l'annonce de l'ADL précise que cette norme correspond à xAPI 2.0, la version 1.0.3 étant archivée. Si un prestataire vous parle de « Tin Can », il parle de xAPI ; si son outil ne produit que du xAPI 1.0.x, demandez-lui son calendrier de mise à niveau.

Le LRS, prérequis non négociable

Chaque déclaration xAPI doit être validée et stockée par un Learning Record Store, le LRS. La page xAPI de l'ADL est explicite : le LRS vérifie le format de chaque déclaration et n'accepte que celles qui sont conformes. Sans LRS, un module xAPI envoie ses traces dans le vide. C'est le point que les devis omettent le plus souvent : le format de sortie « xAPI » de l'outil auteur ne coûte rien de plus, mais il ne sert à rien si vous n'avez pas, derrière, un LRS qui reçoit, et quelqu'un pour exploiter ce qu'il contient.

Trois configurations existent. Soit votre LMS intègre un LRS (certaines plateformes en embarquent un, souvent limité à leurs propres contenus). Soit vous souscrivez un LRS externe, hébergé, qui reçoit les traces de plusieurs sources et les restitue dans des tableaux de bord. Soit vous installez un LRS open source, ce qui suppose une équipe technique pour l'héberger et le maintenir. Dans tous les cas, demandez au fournisseur sa conformité à xAPI 2.0 : l'ADL publie une suite de tests de conformité pour les LRS et recommande d'exiger ce résultat dans les appels d'offres publics.

Ce que xAPI ne dit pas

xAPI décrit comment écrire une trace. Il ne dit pas comment un LMS doit importer un cours, le lancer, authentifier l'apprenant auprès du LRS, ni ce que signifie « terminé » pour la plateforme. Deux outils auteur peuvent produire deux modules xAPI parfaitement conformes qui utilisent des verbes différents pour dire la même chose, et votre LMS n'a aucun moyen standard d'en déduire un statut de complétion. cmi5 a été écrit pour combler ce trou.

Autre conséquence pratique : un paquet « xAPI » exporté par un outil auteur n'est pas un format d'import normalisé. Certains LMS acceptent ces .zip, d'autres non, et le comportement varie d'une plateforme à l'autre. Avant de commander un module en xAPI pur, faites livrer un module de test et importez-le dans votre LMS réel, comme vous le feriez pour tester un SCORM avant de le livrer.

cmi5 : le chaînon manquant entre xAPI et votre LMS

cmi5 est un profil de xAPI : il garde le mécanisme de traces et le LRS, et ajoute les règles que SCORM apportait et que xAPI avait laissées de côté. La spécification cmi5, dans sa version Quartz (1re édition, 1er juin 2016), décrit « la communication interopérable à l'exécution entre les systèmes de gestion de l'apprentissage et les unités assignables ». Sur sa page SCORM, l'ADL recommande xAPI et cmi5 « pour les nouvelles acquisitions et implémentations », tout en constatant que SCORM reste très utilisé.

Ce que cmi5 impose au LMS et au cours

Le LMS doit intégrer un LRS, ou s'y connecter : la spécification l'écrit noir sur blanc dans ses exigences. Il doit aussi savoir importer une structure de cours, décrite dans un fichier cmi5.xml, qui liste les unités assignables (l'équivalent des SCO de SCORM) et, pour chacune, l'adresse de lancement. Cette adresse peut être relative au paquet ou pleinement qualifiée : le contenu peut donc résider sur un autre serveur que le LMS, ce que SCORM ne prévoit pas.

Au lancement, le LMS appelle l'unité avec cinq paramètres : l'adresse du LRS (endpoint), une adresse pour récupérer le jeton d'autorisation (fetch), l'identité de l'apprenant (actor), l'identifiant de l'inscription (registration) et celui de l'activité (activityId). Le cours n'a plus besoin d'être dans la même page que le LMS : il peut s'ouvrir dans sa propre fenêtre (OwnWindow) ou dans n'importe quelle fenêtre (AnyWindow, le réglage par défaut), et il écrit directement dans le LRS.

Des verbes définis, donc un statut lisible

cmi5 fixe une liste de verbes dits « définis » : lancé, initialisé, terminé, réussi, échoué, abandonné, dispensé, clos, satisfait. Le LMS sait exactement quoi faire de chacun. La structure de cours précise aussi, par unité, le critère de passage (moveOn) parmi réussi, terminé, terminé et réussi, terminé ou réussi, ou sans objet. Un responsable formation retrouve ainsi ce qu'il connaissait de SCORM 2004 (achèvement et réussite distincts) avec, en plus, la liberté d'enregistrer dans le même LRS tout ce que le cours souhaite décrire par des déclarations « autorisées » (n'importe quel verbe, dans le gabarit de contexte cmi5).

Le prix de cette richesse est le même que pour xAPI : un LRS, et un LMS qui comprend cmi5. Le premier se loue ou s'installe. Le second est le vrai point de blocage, comme on le verra plus bas.

LTI : brancher un outil externe, pas livrer un module

LTI branche votre plateforme sur un outil qui héberge lui-même l'activité. Il ne transporte aucun module. Le standard est publié par 1EdTech, l'ancien IMS Global, et permet « aux plateformes d'intégrer des outils et contenus distants de manière standardisée », sans que l'utilisateur ait à se connecter à chaque outil. Concrètement, l'apprenant clique sur une activité dans son LMS, est reconnu automatiquement par l'outil externe (un simulateur, un éditeur de code, une banque de vidéos, un autre LMS), travaille là-bas, et une note peut revenir dans le carnet de notes de la plateforme.

LTI 1.3 et LTI Advantage, le seul choix viable

La version en vigueur est LTI 1.3, dont le modèle de sécurité repose sur OAuth 2 et des jetons JWT. LTI Advantage désigne l'ensemble des services qui s'y ajoutent : Assignment and Grade Services pour créer une colonne de notes et y publier des résultats, Names and Role Provisioning Services pour transmettre la liste des inscrits et leurs rôles, Deep Linking pour qu'un formateur sélectionne un contenu précis dans l'outil et le place dans son cours.

Les anciennes versions sont closes. Le calendrier de dépréciation de 1EdTech fixe la fin des nouvelles certifications LTI 1.1 et 2.0 au 31 décembre 2019 et la fin de tout support au 30 juin 2022. Si un éditeur vous propose encore une intégration « LTI 1.1 », vous achetez une dette technique et un risque de sécurité documenté.

Ce que LTI change pour vous

Avec LTI, rien n'est importé dans votre LMS : pas de .zip, pas de manifeste, pas de version SCORM à choisir. Le contenu vit chez le fournisseur, qui le met à jour sans que vous ayez à republier. En contrepartie, vous dépendez de sa disponibilité, vous ne possédez pas de copie du module, et la remontée se limite à ce que l'outil renvoie par les services LTI, le plus souvent une note et un statut. Pour un module que vous avez acheté et que vous voulez posséder, LTI n'est donc pas une alternative à SCORM. Son terrain est la connexion entre deux systèmes qui, sans lui, obligerait à recopier les comptes.

Ce que les LMS lisent vraiment en 2026

La compatibilité réelle des plateformes n'a pas suivi la chronologie des standards. SCORM 1.2 est le format que l'on retrouve sur pratiquement toutes les plateformes. SCORM 2004 est accepté par beaucoup de LMS commerciaux, mais refusé ou interprété partiellement par d'autres. Le support natif de xAPI et de cmi5 reste à vérifier au cas par cas, souvent via une extension. LTI 1.3, lui, se négocie plateforme par plateforme, selon les services Advantage implémentés.

Le cas Moodle, révélateur

Moodle est très utilisé par les organismes de formation français, et sa documentation est sans ambiguïté. La FAQ SCORM de Moodle, mise à jour en avril 2024, indique que SCORM 1.2 est pris en charge et passe la suite de conformité ADL 1.2.7, que les objets AICC sont acceptés, et que « SCORM 2004 n'est pas pris en charge dans Moodle », le développement du support natif ayant été arrêté. Pour xAPI et Tin Can, la même page renvoie à des extensions tierces (un logstore xAPI, une activité de lancement Tin Can) ; cmi5 n'y figure pas.

La leçon dépasse Moodle : avant de choisir un standard, lisez la page de compatibilité de votre LMS, et pas la plaquette commerciale de l'outil auteur. Un module cmi5 parfaitement conforme importé dans un LMS qui ne lit que SCORM 1.2 produira le même symptôme que celui décrit dans Import SCORM refusé par Moodle, avec une cause différente et aucune correction possible côté fichier.

Trois questions à poser à votre éditeur de LMS

La première : quelles versions de SCORM sont prises en charge, et le séquencement de SCORM 2004 est-il réellement appliqué ou simplement toléré à l'import ? La deuxième : xAPI et cmi5 sont-ils lus en natif, et avec quel LRS (intégré, à fournir, imposé) ? La troisième : LTI 1.3 est-il disponible en tant que plateforme, avec quels services d'Advantage, et l'éditeur est-il certifié par 1EdTech ? Exigez des réponses écrites, avec les numéros de version, et vérifiez-les sur une instance de test. Les réponses orales du type « on fait tout » couvrent en général SCORM 1.2 et rien d'autre.

Quand rester sur SCORM

Restez sur SCORM dès que votre besoin se résume à « un apprenant suit un module dans son navigateur, le LMS enregistre un statut, un score et un temps ». C'est le cas de la plupart des modules de conformité, d'intégration, de sécurité ou de présentation produit. SCORM 1.2 fait ce travail depuis 2001, et les plateformes n'ont aucun intérêt à cesser de le lire.

Les quatre situations qui tranchent en faveur de SCORM

Vous livrez à des clients ou à des filiales dont vous ne maîtrisez pas le LMS : SCORM 1.2 est le seul format que vous pouvez promettre sans vérification préalable. Votre LMS est Moodle sans extension xAPI : la question est close, la documentation éditeur l'a tranchée pour vous. Vous n'avez ni LRS ni personne pour exploiter des traces fines : du xAPI non exploité coûte plus cher qu'un SCORM exploité, parce qu'il ajoute un composant à maintenir sans produire de décision. Enfin, votre catalogue existant est en SCORM et fonctionne : une migration de format n'améliore ni le contenu ni la pédagogie, et elle réintroduit tous les risques de régression sur la reprise et le statut.

Ce que SCORM permet encore de corriger

Un argument revient souvent en faveur du changement de standard : « nos SCORM sont vieux et cassés ». Le plus souvent, c'est le paquet qui est en cause, et le standard n'y est pour rien. Un manifeste mal formé, un chemin de fichier avec une majuscule de trop, un seuil de réussite incohérent, une donnée de reprise qui dépasse les 4 096 caractères : tout cela se diagnostique et se répare dans le paquet publié, sans fichier source et sans changer de format. Les cas typiques sont décrits dans Progression SCORM perdue et dans Modifier un SCORM sans le fichier source. Passer à xAPI pour contourner un manifeste cassé, c'est acheter une voiture neuve parce que la précédente a un pneu à plat.

Quand passer à xAPI ou cmi5

Passez à xAPI quand vous avez un besoin précis que SCORM ne peut pas satisfaire par construction, et une personne identifiée pour exploiter les données. En pratique, trois besoins justifient le changement.

Suivre ce qui se passe hors du navigateur du LMS

Une application mobile de terrain utilisée sans réseau, un simulateur de conduite ou de maintenance, un parcours mêlant présentiel et distanciel où le tuteur valide des gestes : dans ces cas, aucune interface JavaScript du LMS n'est disponible au moment où l'apprentissage se produit. xAPI permet à l'application d'enregistrer ses déclarations localement puis de les envoyer au LRS quand la connexion revient. C'est le cas d'usage pour lequel le standard a été conçu, et celui où il n'a pas de concurrent.

Analyser le détail d'un parcours, pas seulement sa fin

Si votre question n'est pas « qui a terminé » mais « où les apprenants bloquent, quelles séquences ils rejouent, quelles réponses fausses reviennent », SCORM ne vous donnera jamais le grain nécessaire. Un module xAPI bien conçu, avec une liste de verbes et d'objets fixée à l'avance, alimente ce type d'analyse. La condition est de définir ce vocabulaire avant la production, avec l'ingénierie pédagogique et pas seulement avec le développeur. Un travail de conception de parcours, du type de ceux que mène La Forge Digitale, précède en général une décision xAPI qui tient dans le temps ; sans cette étape, le LRS se remplit de traces que personne ne lit.

Agréger plusieurs sources dans un seul relevé

Quand un apprenant suit des contenus sur votre LMS, sur une plateforme de vidéos tierce, dans une application métier et en salle, et que vous voulez un relevé unique, le LRS devient le point de convergence. Chaque source y écrit ses déclarations ; vos tableaux de bord y lisent. Cette architecture a un coût d'intégration par source, et un coût de gouvernance : il faut décider qui écrit quoi, avec quels identifiants d'apprenant, et comment on relie Nadia du LMS à Nadia de l'application mobile.

cmi5 plutôt que xAPI pur, si le LMS suit

Si votre besoin est « un cours lancé depuis le LMS, avec un statut clair, mais des traces plus riches et un contenu hébergé où je veux », cmi5 est le bon choix et xAPI pur le mauvais. cmi5 vous rend la structure de cours, le critère de passage et les verbes définis ; xAPI pur vous laisse inventer tout cela et vous expose à ce que le LMS ne reconnaisse rien. La réserve reste la même : vérifiez que votre LMS importe réellement un paquet cmi5 et se connecte à un LRS. Faites ce test avant de signer, pas après.

Tableau de décision

Le tableau ci-dessous résume les critères qui devraient guider votre choix. Lisez-le ligne par ligne en partant de votre contrainte la plus forte, le plus souvent la plateforme.

La règle en une phrase

Si vous ne pouvez pas nommer la personne qui lira les traces du LRS chaque mois et la décision qu'elle en tirera, restez sur SCORM. Si vous pouvez la nommer et que votre LMS lit cmi5, prenez cmi5. Si l'activité vit déjà dans un outil tiers, branchez-le en LTI 1.3 et ne cherchez pas à en faire un paquet.

Erreurs fréquentes dans les cahiers des charges

Trois formulations reviennent dans les consultations et conduisent à des livraisons inutilisables. La première est « compatible SCORM et xAPI » sans préciser laquelle des deux sorties sera déployée ni où sont les traces : le prestataire livre un .zip SCORM 1.2, et le xAPI reste une case cochée. La deuxième est « SCORM 2004 obligatoire » pour un catalogue qui tourne sur Moodle : le module sera converti en 1.2 à la réception ou refusé à l'import. La troisième est « xAPI avec LRS fourni par le prestataire » sans clause de restitution des données : à la fin du contrat, l'historique d'apprentissage de vos salariés est chez un tiers, dans un format que vous n'avez pas spécifié.

Une formulation qui protège : « Livraison en SCORM 1.2 pour déploiement sur [nom et version du LMS] ; livraison complémentaire en cmi5 si et seulement si le LMS cible le prend en charge, avec un LRS désigné par l'acheteur et un export complet des déclarations au format JSON en fin de contrat. » Vous obtenez ce qui fonctionne aujourd'hui et vous gardez l'option d'évoluer.

Questions fréquentes

xAPI remplace-t-il SCORM ?

Non. L'ADL recommande xAPI et cmi5 pour les nouveaux projets, mais maintient SCORM et constate qu'il reste très utilisé. Les deux cohabitent, et la plupart des outils auteur exportent les deux.

Peut-on convertir un SCORM existant en xAPI ou cmi5 ?

Un réexport depuis l'outil auteur est possible si vous avez le fichier source et si l'outil propose la sortie cmi5. Sans source, on peut changer la version de SCORM dans le paquet publié, pas le standard lui-même : le cours ne contient pas le code nécessaire pour écrire des déclarations xAPI.

Un LRS peut-il remplacer mon LMS ?

Non. Le LRS stocke et restitue des traces ; il ne gère ni inscriptions, ni catalogue, ni parcours, ni convocations. cmi5 suppose d'ailleurs explicitement un LMS devant le LRS.

Que vaut un module « Tin Can » livré en 2019 ?

Il écrit du xAPI 1.0.x. La norme IEEE de 2023 correspond à xAPI 2.0 et la version 1.0.3 est archivée. Demandez au fournisseur du LRS s'il accepte encore ces déclarations et prévoyez un réexport à la prochaine mise à jour du contenu.

LTI peut-il remonter un score dans Moodle ?

Oui, par les services Assignment and Grade de LTI Advantage, à condition que l'outil externe les implémente et que l'activité Outil externe soit configurée en LTI 1.3. En LTI 1.1, le mécanisme existait mais n'est plus supporté depuis le 30 juin 2022.

Faut-il SCORM 2004 pour séparer « terminé » et « réussi » ?

En SCORM, oui. En cmi5, le critère de passage le fait aussi, de façon plus lisible. Si votre LMS ne lit ni l'un ni l'autre, restez en 1.2 et faites porter la règle « terminé si réussi » par le réglage de suivi de l'outil auteur.

Par où commencer cette semaine

Ouvrez la documentation de votre LMS et notez, noir sur blanc, les standards et versions qu'il lit en natif. Cette page vaut plus que n'importe quel comparatif : elle élimine d'emblée plusieurs options et vous évite de commander un format que personne ne pourra importer. Puis listez vos trois besoins de suivi non couverts aujourd'hui et demandez-vous, pour chacun, qui lirait la donnée et ce qu'il en ferait. S'il n'y a pas de nom en face, le besoin n'est pas mûr.

Si votre catalogue est en SCORM et que des paquets posent problème à l'import, à la reprise ou au statut, le problème est presque toujours dans le fichier et non dans le standard. Vous pouvez diagnostiquer et corriger un fichier SCORM directement en ligne : le diagnostic est gratuit, et vous saurez en quelques minutes si le paquet est réparable avant d'envisager un changement de format.

Article rédigé avec l'assistance d'une IA, sous la responsabilité éditoriale de Ludovic Albisser.