Chapitre 5.5 — Pourquoi si peu utilisé

⏱️ TL;DR — Le séquencement de SCORM 2004 est techniquement puissant : tout ce qu’on a vu (arbre, objectifs globaux, règles, rollup) permet des parcours adaptatifs qu’aucun autre standard packagé n’égale. Et pourtant, la majorité des SCORM 2004 dans la nature n’utilisent presque aucun séquencement. Trois raisons : c’est réputé complexe (le pseudo-code du livre SN fait peur, la logique déclarative se raisonne mal), les implémentations LMS sont inégales (le même paquet se comporte différemment selon Moodle, Canvas, un vieux LMS maison), et c’est difficile à déboguer (l’état est dans un moteur opaque). Résultat : on contourne — on remet la logique de parcours dans le contenu (le JavaScript du SCO), ou on change de standard. Ce chapitre fait le bilan honnête : quand le séquencement 2004 vaut le coup, quand rester en 1.2 simple, et quand passer à cmi5 / xAPI.

🎯 Objectifs

• Comprendre pourquoi un standard aussi puissant est si peu employé.
• Reconnaître les trois causes : complexité, implémentations inégales, débogage difficile.
• Décider en connaissance de cause : séquencement 2004, SCORM 1.2 simple, ou cmi5.
• Situer ce choix dans la trajectoire du cours (vers xAPI et cmi5, parties 6 à 8).

Un paradoxe : puissant et pourtant délaissé

Sur le papier, le séquencement 2004 devrait avoir tout raflé. Il fait des choses que ni SCORM 1.2, ni un simple export vidéo ne savent faire : verrouiller un ordre, adapter le parcours à la réussite, agréger proprement des dizaines d’activités. C’est le seul standard de contenu packagé à embarquer une logique de parcours portable, appliquée par le LMS lui-même.

Et pourtant, va inspecter les SCORM 2004 réellement diffusés : l’immense majorité se contente d’un controlMode basique (choice="true" flow="true") et d’aucune règle. Le séquencement fin — pré-conditions, objectifs globaux, rollup personnalisé — reste une niche. Ce n’est pas un accident ; c’est le produit de trois frictions réelles.

Cause 1 — La complexité intrinsèque

Le livre SN est déclaratif : tu ne programmes pas « fais ceci puis cela », tu déclares des règles que le moteur combine selon un algorithme (le sequencing loop) décrit en pseudo-code sur des dizaines de pages. Raisonner sur l’interaction de plusieurs règles, d’objectifs locaux et globaux, et du rollup, demande un modèle mental que peu de développeurs (et encore moins d’auteurs de contenu) prennent le temps de construire.

Symptômes concrets : on n’est jamais sûr de l’ordre d’évaluation, une pré-condition en masque une autre, un mapInfo oublié fait échouer une règle « sans raison ». Le XML est verbeux et se relit mal. Là où écrire une condition en JavaScript prend deux minutes, la traduire en règles imsss correctes en prend deux heures — et une de plus à tester.

⚠️ Piège — Se lancer dans le séquencement 2004 « parce que c’est le standard » sans avoir chiffré le coût. Écrire, tester et maintenir un arbre séquencé (surtout avec objectifs globaux) coûte cher, à toutes les évolutions du cours. Si le besoin est « juste » un ordre imposé simple, il existe des chemins bien moins coûteux (voir plus bas). Réserve l’artillerie 2004 aux cas qui la justifient vraiment.

Cause 2 — Les implémentations LMS inégales

C’est le clou dans le cercueil. Le séquencement n’a de valeur que s’il est appliqué… par le LMS de destination. Or tous les LMS n’implémentent pas le SN correctement, ni complètement. Un paquet qui se comporte parfaitement sur SCORM Cloud (référence Rustici) peut, dans un Moodle particulier ou un vieux LMS d’entreprise, ignorer une règle, mal gérer un objectif global, ou traiter le rollup autrement.

Conséquence directe pour toi : tu perds la garantie de portabilité qui est toute la raison d’être de SCORM. Un module 1.2 basique se comporte pareil partout ; un module 2004 richement séquencé se comporte… « ça dépend ». Tu dois tester ton paquet sur chaque LMS cible, ce qui annule une bonne part du bénéfice « un paquet, partout ».

💡 Réflexe — Si tu dois faire du séquencement 2004, teste sur les LMS réels de tes clients, pas seulement sur SCORM Cloud. Le comportement de référence (SCORM Cloud / suites ADL) te dit que ton paquet est correct ; il ne te dit pas qu’il sera appliqué identiquement chez le client. Demande la liste des LMS cibles avant de concevoir l’arbre, et valide sur chacun.

Cause 3 — Le débogage cauchemardesque

Quand un parcours séquencé « ne fait pas ce qu’il devrait », l’état vit dans le moteur du LMS : objectifs globaux, compteurs de tentatives, état de suivi de chaque activité — le tout largement invisible depuis ton contenu. Tu ne peux pas mettre un console.log dans le sequencing loop d’un LMS tiers. Tu ne vois souvent que le symptôme (« le chapitre reste grisé ») sans l’état qui l’explique (« l’objectif global n’a jamais été écrit parce que le SCO précédent a fait Terminate sans poser sa satisfaction »).

Ce triple aveuglement — logique déclarative + moteur opaque + état distribué dans l’arbre — rend chaque bug coûteux. C’est l’inverse d’un code applicatif que tu instrumentes à volonté.

La conséquence : on contourne

Face à ces frictions, l’industrie a voté avec ses pieds. Deux contournements dominent :

1. Mettre la logique dans le contenu. Plutôt que de déclarer des règles imsss, on code le parcours en JavaScript à l’intérieur du SCO (ou d’un contenu mono-SCO qui embarque tout le cours). L’auteur maîtrise, débogue, itère vite. Le prix : cette logique n’est plus portable ni opposable — elle vit dans ton lecteur, pas dans le standard, et se contourne (ouvrir une URL à la main). Mais pour beaucoup de cas, le compromis vaut le coup.
2. Changer de standard. Pour du parcours riche et du suivi fin, on passe à xAPI (tracer partout, hors LMS) et surtout à cmi5 — qui offre une structure de cours (blocs, AU), un lancement propre depuis le LMS, et des moveOn (Passed, Completed, CompletedAndPassed…) beaucoup plus simples à raisonner que le SN, tout en gardant la donnée exploitable dans un LRS.

L’arbre de décision honnête

En clair :

• SCORM 1.2 simple reste le choix par défaut pour diffuser un module suivi partout, sans logique de parcours. C’est le plus portable, le plus prévisible.
• Un ordre imposé léger se code souvent plus sereinement dans le contenu qu’en règles imsss — au prix de la portabilité de cette logique.
• Le séquencement 2004 se justifie quand le parcours adaptatif est au cœur du besoin, que le LMS cible est connu, conforme et testé, et que tu acceptes le coût de conception/débogage.
• cmi5 / xAPI est la voie moderne dès que tu veux du suivi fin, du hors-LMS, ou t’affranchir des implémentations SN inégales — on y arrive aux parties 6, 7 et 8.

🔌 Côté intégration — Certains marchés (formation réglementaire, défense, parcours certifiants) exigent encore un séquencement opposable côté standard : là, le SN de 2004 garde une vraie valeur, parce que le blocage est appliqué par le LMS et non contournable dans le contenu. Ailleurs, un acheteur veut surtout que ton module s’importe et se suive partout sans surprise — et un 2004 sur-séquencé qui se comporte différemment d’un LMS à l’autre devient un risque, pas un argument. Adapte ton offre au marché.

📚 La spec — Le séquencement relève du livre SN de SCORM 2004 (fondé sur IMS Simple Sequencing), présent uniquement dans SCORM 2004, jamais en 1.2. Pour les alternatives modernes : xAPI et cmi5 sont publiées par ADL. Les suites de test (SCORM Test Suite pour valider un paquet 2004, CATAPULT pour cmi5) et les bonnes pratiques sont sur adlnet.gov . Rappel : un paquet conforme n’est pas un paquet appliqué identiquement partout — seul le test sur les LMS cibles le garantit.

🧭 Sur FormaCampus — Verdict. Après avoir modélisé l’arbre (5.2), écrit les règles (5.3) et débogué le rollup (5.4), FormaCampus fait ses comptes : le séquencement 2004 fonctionne sur SCORM Cloud mais se comporte différemment dans le Moodle d’une école cliente, et chaque bug coûte des jours d’aveuglement. Pour son besoin — imposer un parcours et tracer finement l’apprentissage, y compris mobile et présentiel — l’équipe tranche : ne pas industrialiser le SN. Ses cours de diffusion restent en SCORM 1.2 simple (portables partout) ; ses nouveaux modules à parcours passent à cmi5, où le moveOn et le suivi via LRS sont plus simples à maîtriser et à déboguer que le séquencement 2004. Le séquencement reste dans la boîte à outils — sorti seulement pour un client à LMS unique, conforme et testé. Un choix assumé, pas subi : c’est exactement l’esprit du cours.

✏️ Exercices

Exercice 1 — Le bon standard. Un client veut diffuser 40 modules de sensibilisation (une vidéo + un quiz chacun), importables dans les Moodle de 30 écoles différentes, sans logique de parcours entre modules. SCORM 2004 séquencé, ou autre ?

Exercice 2 — Parcours réglementaire. Une formation certifiante impose : pas d’examen final tant que les 5 modules ne sont pas réussis, et ce blocage doit être opposable (non contournable en ouvrant une URL). Où mets-tu la logique ?

Exercice 3 — Migration. FormaCampus veut, pour ses nouveaux modules, du parcours imposé et du suivi mobile/présentiel. Le séquencement 2004 répond-il au besoin ? Sinon, vers quoi orienter ?

🧠 Quiz de révision

Partie suivante : xAPI (Experience API) — on quitte le monde « lancé depuis un LMS dans un navigateur » pour tracer l’apprentissage partout : statements, verbes, LRS.