Chapitre 5.1 — Complétion vs réussite

⏱️ TL;DR — Le plus grand apport de SCORM 2004, ce n’est pas le séquencement : c’est d’avoir coupé en deux une notion que 1.2 mélangeait. En 1.2, tout un module se résume à un seul champ, cmi.core.lesson_status, qui doit choisir entre passed, completed, failed, incomplete, browsed ou not attempted — impossible d’exprimer proprement « il a fini le test mais l’a raté ». SCORM 2004 sépare deux questions indépendantes : « a-t-il tout parcouru ? » → cmi.completion_status (completed / incomplete / not attempted / unknown), et « a-t-il réussi ? » → cmi.success_status (passed / failed / unknown). Le score se normalise dans cmi.score.scaled, de -1 à 1. Comprendre cette séparation, c’est la clé de tout le reste de la partie : le séquencement et le rollup raisonnent sur ces deux axes.

🎯 Objectifs

• Expliquer pourquoi un seul champ de statut ne suffit pas, avec le cas du test « terminé mais échoué ».
• Utiliser correctement cmi.completion_status et cmi.success_status — deux axes indépendants.
• Comprendre cmi.score.scaled (de -1 à 1) et son rôle face au seuil de réussite.
• Traduire un statut 1.2 vers 2004 et repérer les pièges de migration.

Le péché originel de SCORM 1.2 : un seul champ pour deux idées

En SCORM 1.2, un SCO résume toute sa vie dans un élément : cmi.core.lesson_status. Ses valeurs possibles sont passed, completed, failed, incomplete, browsed, not attempted. Le problème saute aux yeux dès qu’on les aligne : passed et failed parlent de réussite, completed et incomplete parlent d’avancement, et le champ te force à n’en garder qu’une.

Prends le cas le plus banal d’une formation : un test final que l’apprenant passe en entier mais rate (7/20). Que met le SCO ?

• Si tu écris failed, tu perds l’information « il a tout fait » — le LMS peut afficher le module comme « non terminé » et relancer l’apprenant à l’infini.
• Si tu écris completed, tu perds le « il a raté » — le module compte comme acquis alors qu’il ne l’est pas.

Il n’y a pas de bonne réponse avec un seul champ. En pratique, les SCO 1.2 bricolent : certains dérivent le statut d’un cmi.core.score.raw comparé au cmi.student_data.mastery_score, d’autres écrivent completed puis stockent le vrai verdict à la main dans cmi.suspend_data. Résultat : chaque LMS interprète différemment, et le « module réussi » de l’un devient le « module en cours » de l’autre.

⚠️ Piège — En 1.2, croire que completed et passed sont synonymes. Ils ne le sont pas, même dans le même champ : completed dit « arrivé au bout », passed dit « au-dessus du seuil ». Un module de lecture sans note se termine en completed (jamais passed) ; un test raté mais rendu ne peut se dire proprement du tout. C’est exactement ce trou que 2004 vient combler.

SCORM 2004 : deux axes, deux champs

SCORM 2004 pose une question à la fois, dans deux éléments distincts et indépendants :

Le cas du test terminé mais raté devient exprimable sans compromis :

// SCORM 2004 — l'objet API s'appelle API_1484_11
var api = /* ...trouvé en remontant window.parent... */;
api.Initialize("");
 
// L'apprenant est allé au bout du test :
api.SetValue("cmi.completion_status", "completed");
// ...mais il a échoué :
api.SetValue("cmi.success_status", "failed");
 
api.SetValue("cmi.score.raw", "7");
api.SetValue("cmi.score.min", "0");
api.SetValue("cmi.score.max", "20");
api.SetValue("cmi.score.scaled", "0.35"); // 7/20 normalisé
api.Commit("");
api.Terminate("");

Le LMS voit maintenant clairement : terminé et échoué. Il peut afficher « test rendu, note insuffisante », proposer une nouvelle tentative, et — surtout pour la suite de cette partie — le séquencement peut raisonner dessus : « débloque le chapitre suivant seulement si success_status vaut passed ». Cette précision est ce qui rend le SN de 2004 possible.

💡 Réflexe — Pose-toi deux questions, pas une, à chaque fin de SCO : « l’a-t-il parcouru ? » et « l’a-t-il réussi ? ». Un module sans évaluation (une vidéo, une fiche de lecture) répond complétion seulement : mets completed, et laisse success_status à unknown — ne mets surtout pas passed par réflexe, sinon tu déclares réussi ce qui n’a jamais été évalué.

Le score scalé : cmi.score.scaled de -1 à 1

SCORM 2004 ajoute un score normalisé : cmi.score.scaled, un nombre entre -1 et 1. Contrairement au cmi.core.score.raw de 1.2 (souvent sur 100, mais en réalité sur n’importe quelle échelle), scaled est comparable d’un module à l’autre : 1 = parfait, 0 = zéro, et les valeurs négatives (jusqu’à -1) servent aux barèmes à pénalité (une mauvaise réponse retire des points).

Pourquoi c’est utile : le séquencement et le rollup travaillent sur une mesure normalisée (objectiveMeasure), et cette mesure vient typiquement de cmi.score.scaled. Le seuil de réussite d’une activité s’exprime lui aussi sur cette échelle 0–1 (par exemple « il faut au moins 0.8 »). Un score brut « 82 sur 120 » ne veut rien dire hors contexte ; « 0.68 » est directement exploitable par la machine.

// Barème /120, avec conversion propre en score scalé :
var raw = 82, min = 0, max = 120;
var scaled = (raw - min) / (max - min); // 0.6833...
api.SetValue("cmi.score.raw", String(raw));
api.SetValue("cmi.score.min", String(min));
api.SetValue("cmi.score.max", String(max));
api.SetValue("cmi.score.scaled", scaled.toFixed(4)); // "0.6833"

⚠️ Piège — Envoyer un cmi.score.scaled hors de [-1, 1] (par exemple 82 parce qu’on a confondu avec raw). Le LMS rejette la valeur (erreur de type) et ton score n’est jamais enregistré — le SCO croit avoir rapporté sa note, le carnet reste vide. scaled est toujours une fraction normalisée, jamais le score brut.

📚 La spec — Complétion, réussite et score relèvent du livre RTE (Run-Time Environment) de SCORM 2004, le modèle de données CMI — l’objet d’API API_1484_11. Le lien entre la mesure d’un objectif et cmi.score.scaled, ainsi que les seuils (cmi.scaled_passing_score, cmi.completion_threshold lus depuis le manifeste), sont décrits par le RTE et le livre SN. Pour les règles exactes de dérivation automatique du statut par le LMS, réfère-toi au modèle de données courant sur adlnet.gov .

Table de correspondance 1.2 ↔ 2004

Quand tu migres un module ou que tu lis un LMS bilingue, garde cette traduction en tête :

Et pour le reste du runtime :

🧭 Sur FormaCampus — FormaCampus publie ses modules en SCORM depuis des années, la plupart en 1.2. En analysant les remontées, l’équipe découvre le classique : le module « Gestes de premiers secours » finit en completed pour tout le monde, même quand le quiz est raté — parce que le SCO 1.2 écrivait completed à la dernière diapo, faute de pouvoir dire « fini mais raté ». En repackageant en 2004, elle sépare enfin les deux axes : completion_status = completed à la fin du parcours, success_status = passed/failed selon le quiz. Le tableau de bord distingue désormais « ont tout vu » de « ont validé » — deux chiffres que les clients réclamaient depuis longtemps.

🔌 Côté intégration — Une école qui importe ton SCORM 2004 dans son Moodle attend que les deux colonnes soient exploitables : la « progression » (complétion) et la « réussite » (note/validation). Si ton SCO ne pose que completion_status et laisse success_status à unknown sur un module évalué, le carnet de notes affiche un vide et l’enseignant te renvoie le ticket « la note ne remonte pas ». Renseigne explicitement l’axe qui correspond à la nature du module — et seulement celui-là pour un contenu non évalué.

✏️ Exercices

Exercice 1 — Le bon couple de valeurs. Pour chacun de ces modules, donne les valeurs de cmi.completion_status et cmi.success_status à poser en fin de session : (a) une vidéo de sensibilisation regardée jusqu’au bout ; (b) un test final passé en entier avec 9/20, seuil à 12/20 ; (c) une simulation abandonnée à mi-parcours.

Exercice 2 — Score scalé. Un SCO calcule un barème sur 250 points, avec pénalités possibles (le minimum atteignable est -50). L’apprenant obtient 150. Quel cmi.score.scaled envoyer ? Que se passe-t-il si le dev envoie "150" ?

Exercice 3 — Migration 1.2 → 2004. Un vieux SCO 1.2 termine en cmi.core.lesson_status = "passed". Tu le repackages en 2004. Quelles valeurs 2004 poses-tu, et quel piège guette si tu te contentes de « traduire » passed par success_status = passed ?

🧠 Quiz de révision

Chapitre suivant : L’arbre d’activités & les objectifs — comment l’organization cesse d’être un simple menu pour devenir un arbre séquencé.