Chapitre 5.3 — Les règles de séquencement

⏱️ TL;DR — Les règles de séquencement sont le cerveau de SCORM 2004 : elles disent au LMS quoi faire et quand. Trois familles selon le moment d’évaluation : preConditionRule (avant de livrer une activité — la sauter, la désactiver, la cacher du choix), postConditionRule (après — sortir du parent, réessayer, continuer) et exitConditionRule (à la sortie). Chaque règle est un couple conditions → action (« si l’objectif X n’est pas satisfait, alors disabled »). Par-dessus, le controlMode fixe le mode de circulation : flow (boutons précédent/suivant), choice (l’apprenant clique où il veut), forwardOnly (interdit le retour arrière). Et limitConditions plafonne le nombre de tentatives. Objectif du chapitre : écrire la règle « pas de chapitre 3 tant que le 2 n’est pas réussi ».

🎯 Objectifs

• Choisir la bonne famille de règle : preConditionRule, postConditionRule, exitConditionRule.
• Composer une règle conditions → action et connaître les actions clés (disabled, hiddenFromChoice, skip…).
• Régler le contrôle de flux avec controlMode (flow, choice, forwardOnly).
• Poser une limite de tentatives et écrire un verrou « chapitre N bloqué tant que N-1 non réussi ».

Le contrôle de flux d’abord : controlMode

Avant les règles fines, une décision de fond, posée sur un regroupement (ou la racine) : comment l’apprenant circule entre les enfants. C’est le <imsss:controlMode>, avec trois attributs booléens qui se combinent :

<!-- Parcours linéaire strict : suivant/précédent, aucun saut libre -->
<imsss:sequencing>
  <imsss:controlMode choice="false" flow="true" forwardOnly="false"/>
</imsss:sequencing>

<!-- Marche forcée : on avance, jamais de retour, pas de choix libre -->
<imsss:sequencing>
  <imsss:controlMode choice="false" flow="true" forwardOnly="true"/>
</imsss:sequencing>

Ces réglages combinés produisent l’expérience : choice="true" flow="true" = sommaire cliquable et boutons de navigation ; choice="false" flow="true" forwardOnly="true" = tunnel sans issue arrière (utile pour un examen surveillé).

⚠️ Piège — Mettre choice="false" et flow="false" : plus aucun moyen de navigation n’est autorisé, l’apprenant se retrouve coincé sur la première activité sans pouvoir avancer. Toujours activer au moins un mode de circulation. Le symptôme classique du support : « le module se lance mais on ne peut rien faire ». Regarde d’abord le controlMode.

L’anatomie d’une règle : conditions → action

Une règle de séquencement, c’est un ou plusieurs conditions évaluées ensemble, qui déclenchent une action. La structure XML :

<imsss:preConditionRule>
  <imsss:ruleConditions conditionCombination="all">
    <imsss:ruleCondition referencedObjective="LU-CH2"
                         operator="not"
                         condition="satisfied"/>
  </imsss:ruleConditions>
  <imsss:ruleAction action="disabled"/>
</imsss:preConditionRule>

Décortiquons :

• <imsss:ruleConditions> regroupe les conditions ; conditionCombination vaut all (toutes vraies) ou any (au moins une).
• <imsss:ruleCondition> : une condition. condition est la nature du test (satisfied, completed, attempted, objectiveMeasureGreaterThan, attemptLimitExceeded, always…) ; operator="not" inverse le test ; referencedObjective pointe l’objectif (souvent local, relié par mapInfo à un global) sur lequel porte le test.
• <imsss:ruleAction action="..."> : ce qu’on fait si les conditions sont réunies.

Les actions dépendent de la famille de règle. Les plus utiles :

Les trois familles : quand la règle est évaluée

Le moment d’évaluation détermine la famille :

• preConditionRule : évaluée avant de livrer l’activité. C’est là qu’on bloque (disabled), qu’on cache (hiddenFromChoice) ou qu’on saute (skip) — typiquement « ne débloque pas tant que le prérequis n’est pas satisfait ».
• exitConditionRule : évaluée pendant que l’activité est active, pour décider d’une sortie anticipée.
• postConditionRule : évaluée après que l’activité s’est terminée, pour décider de la suite (retry, exitParent, continue…).

L’exemple canonique : bloquer le chapitre 3 tant que le 2 n’est pas réussi

On assemble tout. Le Chapitre 2 écrit sa réussite dans un objectif global (vu en 5.2). Le Chapitre 3 lit ce global via un objectif local LU-CH2, et une pré-condition le désactive tant que ce n’est pas satisfait.

<item identifier="ITEM-CH3" identifierref="RES-CH3">
  <title>Chapitre 3</title>
  <imsss:sequencing>
 
    <imsss:objectives>
      <imsss:primaryObjective objectiveID="OBJ-CH3"/>
      <!-- Objectif local qui LIT l'état global écrit par le chapitre 2 -->
      <imsss:objective objectiveID="LU-CH2">
        <imsss:mapInfo targetObjectiveID="GLOBAL-CH2"
                       readSatisfiedStatus="true"/>
      </imsss:objective>
    </imsss:objectives>
 
    <!-- Pré-condition : SI (chapitre 2 NON satisfait) ALORS désactiver -->
    <imsss:sequencingRules>
      <imsss:preConditionRule>
        <imsss:ruleConditions>
          <imsss:ruleCondition referencedObjective="LU-CH2"
                               operator="not"
                               condition="satisfied"/>
        </imsss:ruleConditions>
        <imsss:ruleAction action="disabled"/>
      </imsss:preConditionRule>
    </imsss:sequencingRules>
 
  </imsss:sequencing>
</item>

Lecture ligne à ligne : tant que l’objectif LU-CH2 (qui reflète l’état du Chapitre 2 via le global GLOBAL-CH2) n’est pas satisfait, l’action disabled s’applique → le Chapitre 3 est non navigable. Dès que le Chapitre 2 est réussi et publie son statut, la condition devient fausse, la règle ne s’applique plus, le Chapitre 3 s’ouvre.

💡 Réflexe — disabled vs hiddenFromChoice : disabled grise l’activité (elle reste visible, mais on ne peut pas la lancer), hiddenFromChoice la fait disparaître du sommaire. Pour un prérequis, disabled est souvent préférable : l’apprenant voit qu’un chapitre existe et comprend qu’il doit débloquer le précédent — un chapitre invisible déroute davantage qu’il ne guide.

Limiter les tentatives : limitConditions

Pour plafonner le nombre d’essais d’une activité (un examen qu’on ne repasse pas indéfiniment), on pose un <imsss:limitConditions> avec attemptLimit :

<imsss:sequencing>
  <imsss:limitConditions attemptLimit="3"/>
  <!-- Au-delà de 3 tentatives, l'activité n'est plus délivrable -->
</imsss:sequencing>

Une fois la limite atteinte, la condition attemptLimitExceeded devient vraie et peut être testée dans une règle (par exemple pour afficher un message ou sortir). Le décompte d’une « tentative » est géré par le moteur du LMS au fil des livraisons de l’activité.

⚠️ Piège — Confondre « tentative » au sens du séquencement et « session » au sens du runtime. Une tentative (attempt) est un cycle de vie complet de l’activité côté moteur SN ; une session est une connexion de l’apprenant. Un apprenant peut faire plusieurs sessions dans une même tentative (il quitte, il revient, l’état est suspendu). Compter les sessions comme des tentatives fait épuiser attemptLimit beaucoup trop vite.

📚 La spec — Règles (preConditionRule, postConditionRule, exitConditionRule), conditions, actions, controlMode et limitConditions sont définis par le livre SN de SCORM 2004, sur la base d’IMS Simple Sequencing (imsss). La liste exhaustive des valeurs de condition et d’action, ainsi que l’algorithme d’évaluation (le sequencing loop), figure dans le pseudo-code du livre SN — la référence à consulter en cas de doute sur un comportement, sur adlnet.gov . N’invente jamais une action ou une condition : vérifie-la dans le SN.

🔌 Côté intégration — Une académie qui impose un parcours réglementaire (secourisme, sécurité) vérifie que ton SCORM 2004 verrouille bien l’ordre côté standard, et pas seulement dans le JavaScript de ton contenu. Une logique de blocage codée dans le SCO se contourne (on ouvre l’URL du chapitre à la main) ; une pré-condition disabled dans le manifeste est appliquée par le moteur du LMS, donc opposable. C’est parfois la différence entre un module « accepté » et « refusé » à l’audit.

🧭 Sur FormaCampus — FormaCampus code le verrou « pas d’évaluation finale tant que les fondamentaux ne sont pas satisfaits » avec une pré-condition disabled sur le regroupement « Évaluation », lisant l’objectif global GLOBAL-FONDAMENTAUX. En test sur SCORM Cloud, ça marche parfaitement. Puis l’équipe importe le même paquet dans le Moodle d’une école cliente… et le blocage se comporte différemment (on y revient en 5.5). Première leçon : une règle juste dans le manifeste n’est appliquée que si le LMS cible implémente correctement le SN.

✏️ Exercices

Exercice 1 — Lire une règle. Que fait cette règle, et à quel moment est-elle évaluée ?

<imsss:preConditionRule>
  <imsss:ruleConditions>
    <imsss:ruleCondition condition="completed"/>
  </imsss:ruleConditions>
  <imsss:ruleAction action="skip"/>
</imsss:preConditionRule>

Exercice 2 — Marche forcée d’examen. On veut un examen où l’apprenant avance question par question, sans jamais pouvoir revenir en arrière ni sauter dans le sommaire. Quel controlMode poses-tu sur le regroupement « Examen » ?

<imsss:controlMode choice="false" flow="true" forwardOnly="true"/>

Exercice 3 — Débloquer plutôt que bloquer. Un collègue a écrit une pré-condition avec condition="satisfied" (sans operator="not") et l’action disabled sur le Chapitre 3, en croyant « débloquer quand le 2 est satisfait ». Que se passe-t-il réellement ?

🧠 Quiz de révision

Chapitre suivant : Le rollup — comment l’état des activités enfants remonte vers le parent, et pourquoi ton cours « reste incomplet ».