Chapitre 3.5 — Empaqueter & valider

⏱️ TL;DR — Tu sais lire un manifeste ; il reste à produire un PIF que le LMS accepte, puis à le prouver. Empaqueter à la main tient en trois temps : (1) structurer le dossier (contenu + fichiers partagés), (2) écrire le imsmanifest.xml à la racine, (3) zipper le contenu (pas le dossier parent). Les erreurs qui reviennent : manifeste pas à la racine, href faux, scormType oublié, chemins cassés (casse/slash), XML mal formé. Ne livre jamais sans valider : dépose le .zip sur SCORM Cloud (ou une suite ADL) et vérifie que ça se lance, se navigue, et remonte statut et score. « Ça marche chez moi » n’est pas une validation.

🎯 Objectifs

• Construire un PIF à la main, étape par étape, sans outil auteur.
• Reconnaître et corriger les cinq erreurs de packaging les plus fréquentes.
• Valider un paquet sur SCORM Cloud ou une suite ADL avant livraison.
• Dérouler une checklist de contrôle qualité reproductible.
• Comprendre ce que le client vérifiera de son côté à la réception.

Construire un PIF à la main, pas à pas

Même quand un outil auteur exporte le SCORM, savoir en fabriquer un à la main est ce qui te rend capable de débuguer n’importe quel paquet. On reprend « Sécurité numérique ».

Étape 1 — Structurer le dossier. Range le contenu en sous-dossiers clairs, mets le partagé à part, noms en minuscules sans espaces :

securite-numerique/
├── intro/
│   ├── index.html
│   └── intro.js
├── phishing/
│   ├── index.html
│   └── phishing.js
├── mots-de-passe/
│   ├── index.html
│   └── passwords.js
├── docs/
│   └── charte.pdf
├── shared/
│   ├── scorm-api.js
│   └── styles.css
└── media/
    ├── logo.png
    └── video-phishing.mp4

Étape 2 — Écrire le imsmanifest.xml à la racine du dossier. On assemble les blocs des chapitres précédents : <metadata> (version), <organizations> (arbre), <resources> (inventaire + dépendances) :

<?xml version="1.0" encoding="UTF-8"?>
<manifest identifier="FORMACAMPUS_SECU_NUM" version="1.0"
          xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2"
          xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.imsproject.org/xsd/imscp_rootv1p1p2 imscp_rootv1p1p2.xsd
                              http://www.adlnet.org/xsd/adlcp_rootv1p2 adlcp_rootv1p2.xsd">
 
  <metadata>
    <schema>ADL SCORM</schema>
    <schemaversion>1.2</schemaversion>
  </metadata>
 
  <organizations default="ORG_SECU">
    <organization identifier="ORG_SECU">
      <title>Sécurité numérique</title>
      <item identifier="ITEM_INTRO" identifierref="RES_INTRO">
        <title>Introduction à la sécurité</title>
      </item>
      <item identifier="ITEM_MENACES">
        <title>Les menaces courantes</title>
        <item identifier="ITEM_PHISHING" identifierref="RES_PHISHING">
          <title>Reconnaître un phishing</title>
        </item>
        <item identifier="ITEM_MDP" identifierref="RES_MDP">
          <title>Mots de passe robustes</title>
        </item>
      </item>
      <item identifier="ITEM_CHARTE" identifierref="RES_CHARTE">
        <title>Charte informatique (PDF)</title>
      </item>
    </organization>
  </organizations>
 
  <resources>
    <resource identifier="RES_INTRO" type="webcontent"
              adlcp:scormType="sco" href="intro/index.html">
      <file href="intro/index.html"/>
      <file href="intro/intro.js"/>
      <dependency identifierref="RES_COMMON"/>
    </resource>
    <resource identifier="RES_PHISHING" type="webcontent"
              adlcp:scormType="sco" href="phishing/index.html">
      <file href="phishing/index.html"/>
      <file href="phishing/phishing.js"/>
      <file href="media/video-phishing.mp4"/>
      <dependency identifierref="RES_COMMON"/>
    </resource>
    <resource identifier="RES_MDP" type="webcontent"
              adlcp:scormType="sco" href="mots-de-passe/index.html">
      <file href="mots-de-passe/index.html"/>
      <file href="mots-de-passe/passwords.js"/>
      <dependency identifierref="RES_COMMON"/>
    </resource>
    <resource identifier="RES_CHARTE" type="webcontent"
              adlcp:scormType="asset" href="docs/charte.pdf">
      <file href="docs/charte.pdf"/>
    </resource>
    <resource identifier="RES_COMMON" type="webcontent" adlcp:scormType="asset">
      <file href="shared/scorm-api.js"/>
      <file href="shared/styles.css"/>
      <file href="media/logo.png"/>
    </resource>
  </resources>
 
</manifest>

Étape 3 — Zipper le contenu (pas le dossier). Place-toi dans le dossier et compresse son contenu, pour que le manifeste soit à la racine du .zip :

cd securite-numerique
zip -r ../securite-numerique.zip . -x ".*"

Le -x ".*" exclut les fichiers cachés parasites (.DS_Store de macOS, Thumbs.db, dossiers .git/) qui alourdissent le paquet et déclenchent parfois des avertissements de validation.

💡 Réflexe — Après le zip, rouvre l’archive et vérifie que la première entrée est imsmanifest.xml (pas un dossier). Ce coup d’œil de deux secondes attrape le piège nº 1 avant qu’il ne parte chez le client.

Les cinq erreurs qui reviennent toujours

⚠️ Piège — L’erreur nº 3 est la plus sournoise parce qu’elle ne casse rien de visible : le module s’affiche, l’apprenant le parcourt… mais le LMS le marque incomplet pour l’éternité et aucune note ne remonte. C’est le adlcp:scormType="sco" oublié (ou le namespace adlcp non déclaré, qui revient au même). Toujours vérifier, pour chaque ressource censée dialoguer, qu’elle est bien sco.

💡 Réflexe — Fais deux passes de validation, dans cet ordre. D’abord une validation XML locale (un simple validateur, ou l’ouverture du manifeste dans un éditeur qui signale les erreurs de forme) : elle attrape gratuitement les erreurs nº 5. Ensuite seulement, la validation fonctionnelle sur un LMS de test : elle attrape les nº 1 à 4. Inutile d’uploader un XML qui ne passe même pas un parser.

Valider avant de livrer

Un paquet n’est « bon » que prouvé. Le réflexe professionnel : le passer sur un environnement de test avant le client.

• SCORM Cloud (Rustici) — la référence de fait. Tu déposes le .zip, il importe, lance, et te montre en détail ce que le contenu remonte (statut, score, temps, suspend_data) et les erreurs rencontrées. C’est le juge de paix : si ça passe proprement sur SCORM Cloud, ça passera sur l’immense majorité des LMS. Il teste aussi xAPI, cmi5 et LTI.
• Suites de test ADL — la SCORM ADL Test Suite vérifie la conformité d’un contenu au standard (et, historiquement, des LMS eux-mêmes). Plus austère que SCORM Cloud, mais c’est l’autorité : ADL publie le standard. Pour cmi5, l’équivalent est le projet CATAPULT.
• Ton LMS cible, si tu le connais — si tu sais que le client est sous Moodle, un test sur un Moodle de démo attrape les spécificités d’ingestion propres à cette plateforme.

Ce que tu observes pendant la validation (pas seulement « ça s’importe ») :

1. Le paquet s’importe sans erreur ni avertissement bloquant.
2. Le menu reflète l’arbre <organizations> (bons titres, bon ordre, bonne hiérarchie).
3. Chaque SCO se lance (pas d’écran blanc, pas de 404 en console).
4. Le SCO remonte son statut (completed/passed…) et son score — c’est le test qui prouve que scormType="sco" et le runtime fonctionnent (Partie 4).
5. La reprise fonctionne : on quitte à mi-parcours, on revient, on retrouve où on en était (suspend_data).

🔌 Côté intégration — De plus en plus d’appels d’offres EdTech exigent une preuve de conformité : « contenu testé SCORM Cloud », voire une certification. Livrer un .zip accompagné d’un rapport SCORM Cloud propre, c’est répondre à l’objection avant qu’elle ne soit posée. À l’inverse, un fournisseur qui envoie un paquet « qui marche chez lui » et qui casse à l’import fait perdre du temps au client — et se fait rarement rappeler. La validation n’est pas une formalité : c’est un argument commercial.

🧭 Sur FormaCampus — Process de livraison de FormaCampus pour « Sécurité numérique », rôdé après un premier refus par le Moodle d’un collège : (1) valider le manifeste XML en local ; (2) zipper le contenu et vérifier le manifeste en tête d’archive ; (3) importer sur SCORM Cloud, lancer les trois SCO, confirmer que statut et score remontent et que la reprise marche ; (4) archiver le rapport de test à côté du .zip livré. Depuis, zéro paquet refusé à l’import. La règle interne tient en une phrase : « on ne livre que ce qu’on a vu remonter une note ».

📚 La spec — Les suites de conformité sont fournies par ADL (adlnet.gov) : SCORM ADL Test Suite pour SCORM, projet CATAPULT pour cmi5. SCORM Cloud (Rustici) est l’outil commercial de test/hébergement le plus utilisé. Les numéros de version des suites évoluent : télécharge la version courante depuis la source officielle.

La checklist de livraison

À dérouler avant chaque envoi :

[ ] imsmanifest.xml présent À LA RACINE du .zip (1re entrée de l'archive)
[ ] XML bien formé (validé localement) : balises fermées, & échappés
[ ] <schema>ADL SCORM</schema> + <schemaversion> correcte (1.2 ou 2004…)
[ ] namespace adlcp déclaré, URL exacte
[ ] organizations default pointe une <organization> existante
[ ] chaque <item> lançable a un identifierref vers une <resource> existante
[ ] chaque <resource> dialoguante a adlcp:scormType="sco"
[ ] chaque SCO a un href de lancement valide (fichier réel, casse exacte)
[ ] tous les fichiers utilisés sont déclarés en <file> (rien d'oublié)
[ ] chemins relatifs, minuscules, slashs avant, sans espaces ni accents
[ ] fichiers cachés parasites exclus (.DS_Store, Thumbs.db, .git/)
[ ] importé sur SCORM Cloud : se lance, navigue, REMONTE statut + score
[ ] reprise (suspend_data) testée
[ ] rapport de validation archivé avec le paquet livré

💡 Réflexe — Transforme cette checklist en script. Un petit outil qui, avant le zip : (1) parse le manifeste et vérifie que chaque href/<file> correspond à un fichier réel avec la bonne casse ; (2) vérifie que chaque identifierref a sa cible ; (3) signale les fichiers présents mais non déclarés. Trois vérifications automatisées suppriment la moitié des allers-retours avec le client.

✏️ Exercices

Exercice 1 — Ordonner la fabrication. Remets dans le bon ordre ces opérations et justifie : (a) importer sur SCORM Cloud ; (b) écrire le manifeste ; (c) valider le XML en local ; (d) structurer le dossier ; (e) zipper le contenu.

Exercice 2 — Diagnostic « incomplet à vie ». Un client rapporte : « Le module s’affiche et se parcourt bien, mais Moodle le laisse incomplet et n’affiche aucune note, quel que soit l’apprenant. » Quelle est la cause de packaging la plus probable, et comment la vérifier ?

Exercice 3 — Écrire la checklist minimale. Un collègue s’apprête à livrer un .zip SCORM sans l’avoir testé. Donne-lui les cinq vérifications non négociables, dans l’ordre.

🧠 Quiz de révision

Partie suivante : SCORM : le runtime (l’API) — le paquet est prêt et validé ; on passe de l’autre côté, dans le navigateur, pour voir comment un SCO dialogue avec le LMS : l’API JavaScript, le modèle de données CMI, le statut, le score et la reprise.