Partie 4 — SCORM : le runtime (l’API)

⏱️ TL;DR — Un paquet SCORM bien empaqueté (Partie 3) ne sert à rien s’il ne dialogue pas avec le LMS au moment de l’exécution. Ce dialogue, c’est le RTE (Run-Time Environment) : une API JavaScript que le LMS expose dans la page, et un modèle de données CMI que ton SCO lit et écrit. Le SCO doit trouver cet objet API (API en 1.2, API_1484_11 en 2004), ouvrir une session (LMSInitialize / Initialize), écrire au fil de l’eau (LMSSetValue / SetValue), persister (LMSCommit / Commit) et fermer proprement (LMSFinish / Terminate). Rater une seule de ces étapes, et ton module « marche » à l’écran mais ne remonte rien : la complétion et le score n’arrivent jamais dans le carnet. Cette partie t’apprend à écrire, lire et débuguer ce dialogue.

De quoi on parle

La Partie 2 t’a donné les trois « livres » de SCORM ; la Partie 3 a détaillé le premier, CAM (le paquet). On attaque ici le deuxième : le RTE. C’est le cœur battant de SCORM, celui qui fait la différence entre un .zip qui s’importe et un module qui trace vraiment l’apprentissage.

Le principe est simple, et il n’a pas bougé depuis 2001 : le LMS charge ton SCO dans une iframe (ou une pop-up), et met à disposition, dans une fenêtre ancêtre, un objet JavaScript qui expose une poignée de méthodes. Ton contenu appelle ces méthodes pour dire « je démarre », « voici le score », « j’ai terminé », « sauvegarde ». Le LMS stocke, et l’enseignant voit la complétion dans son tableau de bord.

Tout le drame de SCORM tient dans les détails de ce contrat : où est l’objet API, quand l’appeler, quels noms d’éléments écrire, et pourquoi rien ne remonte quand on oublie une étape. C’est un contrat strict — pas d’exceptions polies, pas de valeurs par défaut magiques. On le respecte à la lettre, ou on livre un SCO muet.

Ce que tu sauras faire à la fin de cette partie

• Trouver l’objet API du LMS en remontant window.parent puis window.opener, avec une vraie fonction findAPI() robuste et un garde-fou cross-domain.
• Piloter le cycle de vie complet d’un SCO : Initialize → écritures → Commit → Terminate, et comprendre pourquoi oublier Terminate perd les données.
• Lire et écrire le modèle de données CMI via GetValue / SetValue, en connaissant les éléments clés de SCORM 1.2 et de SCORM 2004 et leurs différences.
• Poser correctement le statut (lesson_status en 1.2 ; completion_status + success_status en 2004), le score (raw vs scaled), et gérer la reprise via suspend_data et lesson_location.
• Débuguer un « SCO muet » : lire GetLastError / GetDiagnostic, dérouler une checklist de diagnostic et corriger un module qui ne remonte pas la complétion.

Les chapitres

Le fil rouge de cette partie

Le module SCORM que FormaCampus a publié (Partie 3) s’importe bien dans le Moodle d’une école cliente… mais la complétion ne remonte jamais : tous les stagiaires restent « en cours », l’enseignant ne voit aucun résultat. Le paquet est pourtant valide. Le problème est au runtime. On va, chapitre après chapitre, poser le diagnostic (statut jamais mis à completed, Terminate jamais appelé) et livrer la correction — le tout dans l’encadré 🧭 Sur FormaCampus.

On commence par la première marche, invisible mais fondamentale : Trouver l’API.