Chapitre 2.3 — Les trois livres : CAM, RTE, SN

⏱️ TL;DR — SCORM n’est pas un bloc monolithique : c’est un ensemble de trois « livres » (books), chacun répondant à une question différente. CAM (Content Aggregation Model) répond à « comment empaqueter et décrire le contenu ? » — c’est le .zip PIF et l’imsmanifest.xml. RTE (Run-Time Environment) répond à « comment le contenu parle-t-il au LMS pendant l’exécution ? » — c’est l’API JavaScript et le modèle de données CMI. SN (Sequencing & Navigation) répond à « dans quel ordre et sous quelles règles enchaîner les activités ? » — et n’existe qu’en SCORM 2004. Comprendre SCORM, c’est savoir quel livre traite quoi — le reste du cours détaille chacun.

🎯 Objectifs

• Nommer les trois livres de SCORM et la question à laquelle chacun répond.
• Distinguer clairement le rôle de CAM (empaqueter), RTE (dialoguer), SN (séquencer).
• Savoir que SN n’existe qu’en SCORM 2004, et pourquoi.
• Situer où chaque livre est traité en profondeur dans le cours (Parties 3, 4, 5).
• Lire un diagramme qui relie les trois livres au cycle de vie d’un module.

Pourquoi trois livres

Empaqueter un contenu, le faire dialoguer avec le LMS, et orchestrer l’ordre des activités sont trois problèmes distincts. SCORM les traite dans trois spécifications séparées — historiquement publiées comme des « livres ». Cette séparation est une bonne nouvelle pour toi : elle te dit où chercher selon ta question, et elle explique pourquoi une version (1.2) peut exister sans l’un des livres (SN).

💡 Réflexe — Face à un problème SCORM, demande-toi d’abord de quel livre il relève. « Mon .zip ne s’importe pas » → CAM. « Mon score ne remonte pas » → RTE. « Le module 2 ne se débloque pas dans le bon ordre » → SN. Le bon livre pointe le bon chapitre.

CAM — le paquet et sa carte d’identité

Le CAM (Content Aggregation Model) définit le contenant. Il répond à : comment livre-t-on un contenu SCORM, et comment un LMS sait-il ce qu’il contient ?

Sa réponse : un PIF (Package Interchange File) — un .zip — qui contient à sa racine un imsmanifest.xml. Ce manifeste décrit deux choses :

• organizations : l’arbre de ce que l’apprenant voit et lance — une hiérarchie d’item, dont les feuilles pointent vers les unités lançables (les SCO).
• resources : la liste des fichiers réels du paquet, chaque resource portant un attribut adlcp:scormType valant sco (unité qui dialogue) ou asset (fichier passif).

<resources>
  <resource identifier="RES-1" adlcp:scormtype="sco"
            href="module1/index.html">
    <file href="module1/index.html" />
  </resource>
  <resource identifier="RES-2" adlcp:scormtype="asset"
            href="ressources/annexe.pdf">
    <file href="ressources/annexe.pdf" />
  </resource>
</resources>

Le CAM, c’est donc le « avant » de l’exécution : on empaquette, on décrit, on importe. On le construit et on le lit en détail dans la Partie 3 — SCORM : le paquet.

📚 La spec — CAM couvre le format du PIF, la structure de l’imsmanifest.xml (organizations, resources, métadonnées) et le typage adlcp:scormType. C’est le livre qui rend un paquet échangeable entre plateformes.

RTE — le dialogue à l’exécution

Le RTE (Run-Time Environment) définit le contrat de conversation entre le contenu lancé et le LMS. Il répond à : une fois le module ouvert dans le navigateur, comment envoie-t-il et lit-il des données de suivi ?

Il normalise deux choses :

1. L’API JavaScript. Un objet exposé par le LMS que le SCO retrouve dans la fenêtre parente. En SCORM 1.2, l’objet s’appelle API (méthodes LMSInitialize, LMSGetValue, LMSSetValue, LMSCommit, LMSFinish…). En SCORM 2004, il s’appelle API_1484_11 (méthodes Initialize, GetValue, SetValue, Commit, Terminate…).
2. Le modèle de données CMI. Un ensemble de champs normalisés que le SCO lit et écrit : cmi.core.lesson_status, cmi.core.score.raw, cmi.core.student_name, cmi.suspend_data… (1.2) ou cmi.completion_status, cmi.success_status, cmi.score.scaled… (2004).

// RTE : la même logique dans les deux versions, des noms différents.
// SCORM 1.2
api.LMSInitialize("");
api.LMSSetValue("cmi.core.score.raw", "82");
api.LMSCommit("");
api.LMSFinish("");

Le RTE, c’est le « pendant » de l’exécution : l’apprenant utilise, le module remonte. On l’étudie — découverte de l’API, modèle CMI complet, gestion des erreurs — dans la Partie 4 — SCORM : le runtime.

⚠️ Piège — Confondre CAM et RTE. Un manifeste parfait (CAM impeccable) n’empêche pas un module de ne rien remonter si le SCO ne respecte pas le contrat RTE (il ne trouve pas l’API, oublie Initialize, ou écrit des valeurs invalides). Les deux livres doivent être corrects ensemble : l’un fait entrer le paquet, l’autre le fait parler.

SN — le séquencement, en SCORM 2004 seulement

Le SN (Sequencing & Navigation) définit l’orchestration des activités. Il répond à : dans quel ordre l’apprenant parcourt-il les activités, et sous quelles conditions débloque-t-on la suite ?

Il introduit un arbre d’activités, des objectives, des règles de séquencement (sequencing rules) et le rollup (la remontée d’état des enfants vers le parent — par exemple : « le module est complété si ses trois sous-activités le sont »). C’est puissant mais réputé complexe et souvent sous-utilisé : beaucoup de contenus se contentent de laisser le LMS gérer l’ordre.

Point crucial : SN n’existe qu’en SCORM 2004. C’est même le grand ajout de 2004 par rapport à 1.2. Un paquet 1.2 n’a aucune notion de séquencement interne : l’ordre y est géré côté LMS, pas dans le paquet. On étudie SN dans la Partie 5 — SCORM 2004 : séquencement.

📚 La spec — SN (SCORM 2004) décrit l’activity tree, les objectives, les sequencing rules et le rollup. Absent de SCORM 1.2. C’est le livre le plus méconnu — et la principale raison pour laquelle certaines équipes trouvent 2004 « compliqué ».

Comment les trois livres s’articulent

Lecture du schéma : CAM produit le paquet importable ; à l’import, SN (en 2004) décide de l’ordre des activités ; au lancement d’un SCO, RTE porte le dialogue qui remonte statut et score. Trois livres, trois moments, un même contenu.

💡 Réflexe — Retiens l’ordre temporel : CAM avant (on empaquette, on importe), SN à l’orchestration (2004 : dans quel ordre lancer), RTE pendant (le SCO parle). Cette chronologie est aussi celle des Parties 3, 5 et 4 du cours.

🧭 Sur FormaCampus — Comme FormaCampus publie en SCORM 1.2, elle ne travaille que deux livres : CAM (elle empaquette proprement ses .zip avec un imsmanifest.xml valide) et RTE (chaque module remonte statut et score via l’API API). Le troisième livre, SN, lui est fermé : il n’existe pas en 1.2. Conséquence assumée : l’ordre des modules d’un parcours est géré dans le Moodle du client (par la structure du cours, les conditions d’achèvement Moodle), pas dans le paquet SCORM. Un module = un SCO autonome ; l’enchaînement, c’est l’affaire du LMS.

✏️ Exercices

Exercice 1 — Quel livre ? Range chaque symptôme sous le bon livre (CAM, RTE ou SN) : (a) « Moodle refuse d’importer mon .zip, il ne trouve pas de manifeste » ; (b) « le module s’ouvre mais aucun score n’apparaît dans le carnet » ; (c) « en 2004, l’activité 3 se débloque alors que l’activité 2 n’est pas réussie ».

Exercice 2 — Manifeste parfait, résultats absents. Un prestataire jure que son manifeste est validé et que le paquet s’importe sans erreur dans tous les LMS. Pourtant, aucun statut ne remonte. Le manifeste peut-il être en cause ? Où regardes-tu ?

Exercice 3 — Un paquet 1.2 et le séquencement. Un chef de projet veut, dans un paquet SCORM 1.2, définir des règles du type « l’activité B ne s’ouvre que si A est réussie », directement dans le paquet. Est-ce possible ? Sinon, quelle est l’alternative ?

🧠 Quiz de révision

Chapitre suivant : Le cycle de vie d’un SCO — comment un module vit, du lancement par le LMS jusqu’à la persistance de son statut.