Partie 2 — SCORM, le standard historique

⏱️ TL;DR — SCORM (Sharable Content Object Reference Model) est le standard qui, depuis plus de vingt ans, permet à un module de formation d’être importé dans n’importe quel LMS et d’y remonter un statut et un score. Né d’une commande de l’armée américaine via l’ADL, il domine encore le marché en 2026 malgré son âge. Cette partie pose les fondations : ce que SCORM résout, ses deux versions vivantes (1.2 et 2004), ses trois « livres » (CAM, RTE, SN), le cycle de vie d’un module lancé par un LMS, et ses forces et limites — celles qui, plus tard, feront naître xAPI et cmi5. On ne code pas encore le paquet ni le runtime (Parties 3 à 5) : ici, on comprend le modèle avant de mettre les mains dedans.

Le problème qu’on résout

Tu as construit un module e-learning : des écrans, un quiz, une progression. Il tourne dans ton navigateur. Maintenant une école veut le mettre dans son Moodle, un centre de formation dans son 360Learning, une académie dans son ENT. Chacun te demande : « Est-ce que ça s’importe ? Est-ce que ça remonte les résultats dans notre carnet de suivi ? »

Sans standard commun, la réponse est « ça dépend, il faut développer un connecteur pour chaque plateforme ». SCORM est le standard qui transforme ce « ça dépend » en « oui, glissez le .zip ». Il définit deux choses : comment empaqueter un contenu (un .zip avec un manifeste qui décrit ce qu’il contient) et comment ce contenu dialogue avec le LMS pendant que l’apprenant l’utilise (une API JavaScript et un modèle de données). Résultat : un même module s’importe partout et remonte partout statut (réussi, terminé…) et score.

Comprendre SCORM, c’est comprendre le socle du e-learning packagé — celui sur lequel repose encore l’immense majorité des catalogues de formation, et celui dont on mesurera plus tard les limites pour justifier les standards modernes.

Ce que tu sauras faire à la fin de cette partie

Expliquer ce que SCORM résout (contenu portable et traçable) et ce que « conforme SCORM » veut dire concrètement.
Situer l’ADL et l’origine militaire du standard, sans mythologie.
Choisir entre SCORM 1.2 et SCORM 2004 en connaissant précisément ce que chacun apporte et coûte.
Nommer et situer les trois livres — CAM (le paquet), RTE (le runtime), SN (le séquencement) — et savoir dans quelle partie du cours chacun est traité.
Décrire le cycle de vie d’un SCO : lancement, découverte de l’API, Initialize, lecture/écriture CMI, Commit, Terminate.
Distinguer un SCO (qui dialogue) d’un asset (passif).
Énoncer les forces et les limites structurelles de SCORM — et savoir précisément pourquoi xAPI et cmi5 existent.

Les chapitres

#	Chapitre	En un mot
2.1	Qu’est-ce que SCORM	Le contenu portable et traçable, l’ADL, le principe paquet + dialogue.
2.2	SCORM 1.2 vs SCORM 2004	Deux versions vivantes, ce que chacune apporte, laquelle choisir.
2.3	CAM, RTE, SN	Les trois « livres » de SCORM et leur rôle.
2.4	Cycle de vie d’un SCO	Comment un module vit du lancement à la sortie.
2.5	Forces & limites	Pourquoi il domine encore, pourquoi xAPI a dû naître.

Le fil rouge, dans cette partie

FormaCampus publie ses cours au format SCORM pour que ses écoles clientes les importent dans leur propre Moodle ou ENT. Toute la partie suit une décision structurante de son équipe : choisir SCORM 1.2 plutôt que 2004 pour maximiser la compatibilité — ce qu’elle y gagne (ça s’importe partout, sans surprise) et ce qu’elle y perd (pas de complétion/réussite séparées, suspend_data étriqué, pas de séquencement). Un vrai arbitrage d’intégrateur, pas un choix de principe.

On commence par le socle : Qu’est-ce que SCORM.