SCORM vs xAPI : guide technique pour développeurs EdTech
17/02/2026
Si vous développez une plateforme de formation, vous allez devoir choisir un standard de tracking des activités d'apprentissage. SCORM et xAPI sont les deux options dominantes, et ce choix a un impact direct sur l'architecture de votre système, les données que vous pouvez collecter, et les cas d'usage que vous pouvez couvrir.
Cet article est écrit pour les développeurs et les CTO qui construisent des plateformes EdTech. Pas de marketing, pas de slides PowerPoint : on parle de modèles de données, d'API, d'architecture, et de code.
SCORM : le standard historique
SCORM (Sharable Content Object Reference Model) a été créé par l'ADL (Advanced Distributed Learning) au début des années 2000. Il définit comment un contenu e-learning communique avec un LMS.
Comment ça fonctionne
Un package SCORM est une archive ZIP contenant du HTML, du JavaScript et un fichier manifeste XML (imsmanifest.xml). Le LMS charge ce contenu dans un iframe ou une fenêtre enfant. La communication entre le contenu et le LMS passe par une API JavaScript accessible dans le DOM du parent.
Le contenu cherche un objet API (SCORM 1.2) ou API_1484_11 (SCORM 2004) dans la hiérarchie des fenêtres parentes. Une fois trouvé, il utilise des méthodes Get/Set pour lire et écrire des données.
Le modèle de données CMI
SCORM utilise le modèle CMI (Computer Managed Instruction) pour stocker les données de l'apprenant. Les valeurs sont lues et écrites sous forme de chaînes de caractères via des chemins hiérarchiques :
cmi.core.lesson_status: statut du cours (incomplete, completed, passed, failed)cmi.core.score.raw: score brutcmi.core.score.max: score maximumcmi.core.total_time: temps total passécmi.suspend_data: données de reprise (max 4 096 caractères en SCORM 1.2, 64 000 en SCORM 2004)cmi.interactions[n].id: identifiant de la question n
SCORM 1.2 vs SCORM 2004
| Aspect | SCORM 1.2 | SCORM 2004 |
|---|---|---|
| Statut | Un seul champ lesson_status |
Deux champs séparés : completion_status et success_status |
| Suspend data | 4 096 caractères max | 64 000 caractères max |
| Séquencement | Aucun | Règles de navigation entre SCO |
| Lecture/écriture | Écriture seule | Le contenu peut relire les données précédentes |
| Messages d'erreur | Génériques | Descriptifs |
| Support LMS | Universel | Très large (séquencement variable selon les LMS) |
SCORM 1.2 reste le plus déployé dans la pratique. Sa simplicité le rend compatible avec tous les LMS du marché. SCORM 2004 ajoute le séquencement entre les objets de contenu, mais cette fonctionnalité est implémentée de manière inégale selon les LMS.
Les limites techniques de SCORM
Dépendance au navigateur. Toute la communication passe par une API JavaScript dans le DOM. Pas de LMS ouvert dans le navigateur, pas de tracking. Le mobile natif, les simulations hors navigateur, le terrain : rien de tout ça n'est couvert.
Synchrone et bloquant. Les appels LMSSetValue() et LMSCommit() sont synchrones. Sur des connexions lentes, ils bloquent l'interface utilisateur.
Données limitées. SCORM trace la complétion, le score et le temps. Il ne sait pas capturer le contexte (équipe, localisation, événement déclencheur), ni les interactions fines (temps par question, parcours de navigation dans le contenu).
Silo de données. Les données restent dans le LMS. Pas de moyen natif de les croiser avec des données métier externes (CRM, SIRH, performance commerciale).
xAPI : le standard moderne
xAPI (Experience API, anciennement Tin Can API) a été publié en 2013 par l'ADL comme successeur de SCORM. Son approche est fondamentalement différente : au lieu d'une API JavaScript dans le navigateur, xAPI utilise des requêtes HTTP REST vers un serveur dédié appelé LRS (Learning Record Store).
Le modèle Actor-Verb-Object
xAPI modélise chaque activité d'apprentissage sous forme d'un statement JSON avec trois composants obligatoires :
- Actor : qui a fait l'action (identifié par email, compte, ou OpenID)
- Verb : quelle action (identifié par un IRI, ex:
http://adlnet.gov/expapi/verbs/completed) - Object : sur quoi l'action porte (identifié par un IRI)
Et des composants optionnels :
- Result : score, durée, succès, réponse
- Context : équipe, programme, langue, extensions
- Timestamp : quand l'action a eu lieu
Exemple de statement xAPI
{
"actor": {
"objectType": "Agent",
"name": "Marie Dupont",
"mbox": "mailto:marie.dupont@entreprise.fr"
},
"verb": {
"id": "http://adlnet.gov/expapi/verbs/completed",
"display": { "fr-FR": "a terminé" }
},
"object": {
"objectType": "Activity",
"id": "https://formation.entreprise.fr/modules/vente-pharma",
"definition": {
"name": { "fr-FR": "Argumentaire vente secteur pharma" },
"type": "http://adlnet.gov/expapi/activities/module"
}
},
"result": {
"completion": true,
"success": true,
"score": { "raw": 85, "min": 0, "max": 100 },
"duration": "PT8M30S"
},
"context": {
"extensions": {
"https://formation.entreprise.fr/context/equipe": "Commercial IDF",
"https://formation.entreprise.fr/context/declencheur": "rdv-prospect-48h"
}
},
"timestamp": "2026-03-13T09:15:00Z"
}
Ce statement dit : "Marie Dupont a terminé le module Argumentaire vente secteur pharma avec un score de 85/100 en 8 minutes 30, dans l'équipe Commercial IDF, déclenché par un rendez-vous prospect dans les 48h." SCORM ne peut pas capturer les deux dernières informations.
Le LRS (Learning Record Store)
Le LRS est le serveur qui reçoit, stocke et expose les statements xAPI. Il expose quatre API REST :
- Statement API (
/statements) : stocker et requêter les statements - State API (
/activities/state) : stocker l'état en cours d'une activité (équivalent dususpend_dataSCORM) - Activity API (
/activities) : métadonnées des activités - Agent API (
/agents) : gestion des identités apprenants
Le LRS peut être intégré dans votre LMS ou déployé comme service indépendant. Des solutions open source existent (Learning Locker, lxHive) et des solutions cloud (Watershed, Yet Analytics).
Pour une plateforme EdTech sur mesure, intégrer le LRS directement dans votre backend est souvent le choix le plus cohérent. Vous contrôlez le stockage, les requêtes, et vous évitez une dépendance externe.
Comparaison technique
| Aspect | SCORM | xAPI |
|---|---|---|
| Protocole | JavaScript API (DOM) | REST HTTP/HTTPS |
| Format de données | Chaînes CMI (clé-valeur) | JSON (statements structurés) |
| Stockage | LMS uniquement | LRS (intégré ou standalone) |
| Sources de données | Navigateur uniquement | Mobile, serveur, IoT, simulateur |
| Mode offline | Impossible | Possible (queue locale + sync) |
| Requêtage | Limité aux rapports du LMS | API REST complète avec filtres |
| Contexte | Aucun | Équipe, programme, extensions custom |
| Timestamps | Temps total seulement | Chaque interaction horodatée |
| Scalabilité | Limitée au LMS | Distribuée (multi-sources, multi-LRS) |
cmi5 : le pont entre SCORM et xAPI
cmi5 est un profil xAPI défini par l'AICC qui combine la flexibilité d'xAPI avec les conventions de lancement et de reporting de SCORM. La formule : cmi5 = xAPI + règles d'interopérabilité LMS.
cmi5 définit :
- Un protocole de lancement (comment le LMS lance le contenu via URL avec paramètres et tokens d'authentification)
- Un vocabulaire contrôlé de verbes et d'activités
- Des règles de reporting (comment convertir les statements xAPI en données de complétion exploitables par le LMS)
cmi5 est pertinent si vous migrez depuis SCORM et que vous voulez garder la compatibilité LMS tout en bénéficiant de la richesse d'xAPI. Si vous construisez une plateforme from scratch, xAPI natif est plus simple à implémenter.
Quel standard choisir
Choisissez SCORM si
- Vous devez importer des contenus SCORM existants (créés avec Articulate, iSpring, Adobe Captivate)
- Votre plateforme est un LMS classique qui diffuse des modules e-learning dans le navigateur
- La compatibilité avec les LMS tiers de vos clients est une priorité
- Vous n'avez pas besoin de tracer des activités hors navigateur
Dans ce cas, implémentez SCORM 1.2 en priorité (compatibilité maximale) et SCORM 2004 en option pour les clients qui en ont besoin.
Choisissez xAPI si
- Vous tracez des activités sur mobile, en simulation, ou sur le terrain
- Vous avez besoin de contexte enrichi (équipe, événement déclencheur, localisation)
- Vous construisez un système d'adaptive learning qui ajuste les parcours en temps réel
- Vous voulez croiser les données de formation avec des données métier (CRM, performance commerciale)
- Vous développez une plateforme de microlearning contextuel
C'est l'approche que nous avons choisie pour Andra Learning. Le moteur de workflows déclencheurs génère des statements xAPI enrichis avec le contexte métier (type de prospect, historique commercial, capsule délivrée), ce qui permet de mesurer l'impact de la formation sur les indicateurs de vente.
Implémentez les deux si
- Vos clients ont des contenus SCORM existants qu'ils veulent importer
- ET vous avez besoin de tracking avancé pour vos propres fonctionnalités
C'est le cas le plus fréquent sur les plateformes EdTech sur mesure : SCORM pour la compatibilité avec l'écosystème existant, xAPI pour le tracking natif de la plateforme.
Conseils d'implémentation
Pour SCORM : abstraire l'API SCORM derrière une couche de service dans votre code. L'API JavaScript est fragile (recherche du parent, gestion des erreurs, timing des appels). Un wrapper robuste vous évitera les bugs les plus courants : contenu qui ne trouve pas l'API, données perdues au commit, conflits de fenêtres.
Pour xAPI : utilisez une bibliothèque wrapper plutôt que des appels REST bruts. TinCan.js (ADL) et @xapi/xapi (npm) simplifient la construction des statements et la gestion de l'authentification. Définissez votre vocabulaire d'IRI dès le départ (verbes, types d'activités, extensions de contexte) et documentez-le.
Pour le LRS : si votre plateforme est sur mesure, intégrez le stockage des statements directement dans votre base de données plutôt que de déployer un LRS séparé. Un table PostgreSQL avec le statement JSON, un index sur actor/verb/timestamp, et une API REST de requêtage couvrent 90 % des besoins. Vous ajouterez un LRS dédié quand le volume de statements le justifiera.
Pour la migration SCORM → xAPI : ne migrez pas tout d'un coup. Gardez le player SCORM pour les contenus existants et implémentez xAPI pour les nouvelles fonctionnalités. cmi5 peut servir de pont si vous avez besoin de reporter les données xAPI dans un format compréhensible par un LMS tiers.
Ce que vous devez retenir
- SCORM est un standard mature, universellement supporté, mais limité au navigateur et aux données basiques (complétion, score, temps). Implémentez SCORM 1.2 si vous devez importer des contenus tiers.
- xAPI est le standard moderne qui permet de tracer n'importe quelle activité d'apprentissage, depuis n'importe quelle source, avec un contexte riche. Choisissez xAPI si vous construisez du microlearning, de l'adaptive learning, ou du tracking mobile.
- cmi5 sert de pont entre les deux. Utile pour les migrations, moins pertinent pour les plateformes neuves.
- Dans la pratique, la plupart des plateformes EdTech sur mesure implémentent les deux : SCORM pour la compatibilité, xAPI pour l'intelligence.
Si vous développez une plateforme de formation et hésitez sur le choix de standard, nous pouvons vous aider à cadrer l'architecture. C'est un choix qui impacte le modèle de données, les intégrations, et la capacité d'analyse de votre plateforme sur le long terme.