Skip to Content

Chapitre 3.2 — Le imsmanifest.xml

⏱️ TL;DR — Le imsmanifest.xml est la carte d’identité du paquet : un fichier XML à la racine du .zip qui déclare qui est le paquet (<manifest> avec un identifier et ses namespaces imscp/adlcp), quelle version de SCORM il vise (<metadata> : <schema>ADL SCORM + <schemaversion>), comment il se navigue (<organizations>) et de quels fichiers il est fait (<resources>). Quatre blocs, dans cet ordre. Sais lire et écrire ces quatre blocs, et tu sais lire n’importe quel paquet SCORM du marché.

🎯 Objectifs

  • Connaître les quatre blocs obligatoires d’un manifeste et leur ordre.
  • Comprendre le rôle des namespaces imscp et adlcp et pourquoi ils sont là.
  • Lire le bloc <metadata> pour identifier la version SCORM (1.2 vs 2004).
  • Écrire un imsmanifest.xml 1.2 minimal et valide, de zéro.
  • Repérer les erreurs qui cassent l’analyse XML (balise non fermée, & nu, namespace manquant).

La structure globale : quatre blocs dans l’ordre

Un manifeste SCORM, quelle que soit sa taille, tient dans une racine <manifest> qui contient quatre enfants, toujours dans le même ordre :

BlocRôleObligatoire
<metadata>Déclare le profil appliqué : ADL SCORM + la version.Oui
<organizations>L’arbre de navigation : titres, item, SCO lançables.Oui
<resources>L’inventaire : chaque <resource> et ses <file>.Oui
(sous-<manifest>)Manifestes imbriqués pour des paquets composites.Rare, ignore pour l’instant

Retiens l’ordre : metadata → organizations → resources. Certains parsers stricts refusent un manifeste où resources précède organizations.

📚 La spec — Le squelette manifest / metadata / organizations / resources vient du IMS Content Packaging (1EdTech), repris tel quel par le CAM de SCORM. SCORM y ajoute deux choses : l’obligation de renseigner <schema>ADL SCORM dans <metadata>, et l’attribut adlcp:scormType sur chaque <resource> (chapitre 3.4). Référence : livre CAM de SCORM, sur adlnet.gov.

Les namespaces : pourquoi ces URL bizarres en haut

La balise <manifest> s’ouvre toujours sur une salve de déclarations xmlns:.... Ce ne sont pas des URL à visiter : ce sont des identifiants d’espace de noms qui disent au parser « le préfixe adlcp: désigne le vocabulaire ADL, le préfixe par défaut désigne le vocabulaire IMS Content Packaging ». Deux comptent vraiment en SCORM 1.2 :

PréfixeNamespace (identifiant)Ce qu’il apporte
(défaut)http://www.imsproject.org/xsd/imscp_rootv1p1p2Le vocabulaire de packaging : manifest, organizations, item, resources, file
adlcphttp://www.adlnet.org/xsd/adlcp_rootv1p2Les extensions ADL : surtout adlcp:scormType, mais aussi adlcp:masteryscore, adlcp:prerequisites.

⚠️ Piège — Oublier de déclarer le namespace adlcp (ou se tromper d’URL) fait que adlcp:scormType="sco" devient un attribut inconnu : certains LMS l’ignorent silencieusement et traitent alors ton SCO comme un asset — le module se lance mais ne remonte plus rien (pas de statut, pas de score). L’erreur de packaging se paie au runtime. Copie les namespaces d’un manifeste de référence connu, ne les tape jamais de mémoire.

💡 Réflexe — Les URL de namespace SCORM 1.2 sont figées : imscp_rootv1p1p2 pour IMS CP, adlcp_rootv1p2 pour ADL. Le suffixe v1p2 (« version 1 point 2 ») est l’indice le plus fiable pour reconnaître un manifeste 1.2 au premier coup d’œil, avant même de lire <schemaversion>.

Le bloc metadata : lire la version

C’est le bloc que tu lis en premier pour savoir à quoi tu as affaire :

<metadata> <schema>ADL SCORM</schema> <schemaversion>1.2</schemaversion> </metadata>
  • <schema> vaut toujours ADL SCORM (texte exact, casse comprise). C’est ce qui annonce « ceci est un paquet SCORM », pas un IMS CP générique.
  • <schemaversion> porte la version : 1.2 pour SCORM 1.2, 2004 4th Edition (ou 2004 3rd Edition) pour SCORM 2004. C’est la valeur qui dit au LMS quel runtime exposer (objet API en 1.2 vs API_1484_11 en 2004, voir Partie 4).

⚠️ Piège<schemaversion>1.2 et <schemaversion>2004 4th Edition ne sont pas interchangeables. Un contenu écrit pour l’API 1.2 déclaré 2004 4th Edition (ou l’inverse) se lance dans le mauvais runtime : le SCO cherche un objet API que le LMS n’expose pas sous ce nom, et le tracking échoue en silence. La version du manifeste doit correspondre à la version que ton code de dialogue attend.

Un imsmanifest.xml 1.2 minimal, commenté

Voici un manifeste SCORM 1.2 complet, minimal et valide : un module à un seul SCO. C’est le squelette de départ à connaître par cœur.

<?xml version="1.0" encoding="UTF-8"?> <!-- La racine : identifiant unique du paquet + version libre + les namespaces --> <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"> <!-- 1. METADATA : quel standard, quelle version --> <metadata> <schema>ADL SCORM</schema> <schemaversion>1.2</schemaversion> </metadata> <!-- 2. ORGANIZATIONS : l'arbre de navigation. default pointe l'organisation active --> <organizations default="ORG_SECU"> <organization identifier="ORG_SECU"> <title>Sécurité numérique</title> <!-- Un item = une entrée de menu. identifierref pointe une <resource> --> <item identifier="ITEM_INTRO" identifierref="RES_INTRO"> <title>Introduction à la sécurité</title> </item> </organization> </organizations> <!-- 3. RESOURCES : l'inventaire des fichiers. scormType=sco => lançable et dialoguant --> <resources> <resource identifier="RES_INTRO" type="webcontent" adlcp:scormType="sco" href="intro/index.html"> <file href="intro/index.html"/> <file href="shared/scorm-api.js"/> <file href="shared/styles.css"/> </resource> </resources> </manifest>

Décryptons bloc par bloc.

La balise <manifest>

  • identifier="FORMACAMPUS_SECU_NUM" : un identifiant unique du paquet (le LMS s’en sert en interne). Pas d’espaces, pas de caractères spéciaux ; conventionnellement en MAJUSCULES_SNAKE.
  • version="1.0" : la version du contenu (libre, informative). À ne pas confondre avec la version SCORM (qui est dans <metadata>).
  • Les xmlns : les namespaces vus plus haut. xsi:schemaLocation associe chaque namespace à son fichier .xsd — utile pour la validation, facultatif pour l’exécution.

Le bloc <metadata> : déjà vu — ADL SCORM + 1.2.

Le bloc <organizations>

  • default="ORG_SECU" : obligatoire dès qu’il y a une organisation. Il désigne laquelle est active à l’ouverture. Oublier le default (ou le faire pointer sur un identifier inexistant) est une cause classique de « paquet vide » à l’import.
  • <organization identifier="ORG_SECU"> : l’arbre lui-même, avec son <title> (le nom du cours affiché).
  • <item ... identifierref="RES_INTRO"> : une entrée de menu. Son identifierref pointe un identifier de <resource>. C’est le fil qui relie la navigation aux fichiers.

Le bloc <resources>

  • <resource identifier="RES_INTRO"> : l’identifier que l’item référence.
  • type="webcontent" : quasi toujours cette valeur en SCORM (du contenu web).
  • adlcp:scormType="sco" : c’est un SCO — il se lance et dialogue avec le LMS. (Un asset serait passif ; chapitre 3.3.)
  • href="intro/index.html" : la page de lancement, chemin relatif à la racine du .zip.
  • <file href="..."/> : chaque fichier utilisé par la ressource doit être listé. Ici le HTML de lancement, le wrapper JS et la CSS.

💡 Réflexe — Lis un manifeste inconnu dans cet ordre : (1) <schemaversion> → quelle version ; (2) compte les <item> avec un identifierref → combien de SCO ; (3) suis un identifierref jusqu’à sa <resource> et lis son href → quel fichier se lance. Trois regards, et tu as cartographié le paquet.

🧭 Sur FormaCampus — Le manifeste ci-dessus est exactement le point de départ de FormaCampus pour « Sécurité numérique », avant d’ajouter les modules « Phishing » et « Mots de passe ». L’équipe garde identifier="FORMACAMPUS_SECU_NUM" stable d’une version à l’autre du contenu (elle ne l’incrémente pas à chaque correction), pour que le Moodle des écoles reconnaisse une mise à jour du même module et n’en crée pas un doublon.

🔌 Côté intégration — À l’import, le LMS valide ce manifeste avant tout le reste. Un XML mal formé (une balise <title> non fermée, un & écrit nu au lieu de &amp;, un default qui pointe dans le vide) fait échouer l’analyse avant que le contenu soit seulement regardé. Côté fournisseur, un manifeste qui passe un simple validateur XML local avant l’envoi, c’est zéro aller-retour avec le client sur des erreurs de forme.

Les erreurs qui cassent l’analyse XML

Le manifeste est du XML : les règles XML s’appliquent, sans indulgence.

  • Balise non fermée : <title>Intro sans </title> → analyse rejetée.
  • Caractères réservés en clair : &, <, > dans un texte doivent être échappés — &amp;, &lt;, &gt;. Un titre « Sécurité & réseaux » écrit tel quel casse le XML ; écris « Sécurité & réseaux ».
  • Namespace manquant ou faux : adlcp:scormType sans déclaration xmlns:adlcp → attribut orphelin, SCO potentiellement traité comme asset.
  • default orphelin : <organizations default="ORG_X"> alors qu’aucune <organization> n’a identifier="ORG_X" → menu vide.
  • identifierref cassé : un <item> qui pointe une <resource> inexistante → entrée de menu qui ne lance rien.

⚠️ Piège — L’encodage. Déclare encoding="UTF-8" et enregistre réellement le fichier en UTF-8 (idéalement sans BOM). Un manifeste plein d’accents (« Sécurité », « Réseaux ») enregistré en windows-1252 mais déclaré UTF-8 produit des caractères cassés dans le menu, voire une erreur de parsing selon le LMS.

✏️ Exercices

Exercice 1 — Lire la version. On te donne ce fragment. Quelle version de SCORM ? Quel objet JS le SCO devra-t-il chercher au runtime ?

<metadata> <schema>ADL SCORM</schema> <schemaversion>2004 4th Edition</schemaversion> </metadata>

✅ Solution

C’est du SCORM 2004 (4ᵉ édition). Au runtime, le SCO cherchera l’objet JavaScript API_1484_11 (et non API, qui est le nom en SCORM 1.2). Le modèle de données diffère aussi : en 2004, complétion et réussite sont séparées (cmi.completion_status vs cmi.success_status). Détails en Partie 4.

Exercice 2 — Écrire un manifeste minimal. Écris de zéro un imsmanifest.xml SCORM 1.2 valide pour un module « RGPD express » à un seul SCO, dont la page de lancement est cours/index.html et qui utilise aussi cours/app.js.

✅ Solution

<?xml version="1.0" encoding="UTF-8"?> <manifest identifier="RGPD_EXPRESS" 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_RGPD"> <organization identifier="ORG_RGPD"> <title>RGPD express</title> <item identifier="ITEM_1" identifierref="RES_1"> <title>Le cours</title> </item> </organization> </organizations> <resources> <resource identifier="RES_1" type="webcontent" adlcp:scormType="sco" href="cours/index.html"> <file href="cours/index.html"/> <file href="cours/app.js"/> </resource> </resources> </manifest>

Points de contrôle : ADL SCORM + 1.2, un default qui pointe l’organization existante, l’item dont l’identifierref correspond à l’identifier de la <resource>, adlcp:scormType="sco", le href de lancement aussi listé en <file>.

Exercice 3 — Corrige le bug. Ce manifeste s’importe mais le menu est vide. Pourquoi ?

<organizations default="ORG_A"> <organization identifier="ORG_MAIN"> <title>Mon cours</title> <item identifier="I1" identifierref="R1"><title>Chapitre 1</title></item> </organization> </organizations>

✅ Solution

Le default="ORG_A" pointe une organisation qui n’existe pas : la seule <organization> a identifier="ORG_MAIN". Le LMS cherche l’organisation active ORG_A, ne la trouve pas, et n’affiche rien. Correction : default="ORG_MAIN" (le default doit correspondre exactement à un identifier d’organisation présent).

🧠 Quiz de révision

1. Quels sont les quatre blocs d’un manifeste, et dans quel ordre ?

<manifest> (la racine) contient, dans l’ordre : <metadata>, <organizations>, <resources> (et, rarement, des sous-<manifest>). L’ordre metadata → organizations → resources doit être respecté.

2. À quoi servent les namespaces imscp et adlcp ?

imscp (namespace par défaut) apporte le vocabulaire de packaging IMS : manifest, organizations, item, resources, file. adlcp apporte les extensions ADL, dont l’essentiel adlcp:scormType. Sans le namespace adlcp déclaré, scormType devient un attribut inconnu.

3. Où lit-on la version SCORM, et quelles valeurs typiques ?

Dans <metadata> : <schema> vaut toujours ADL SCORM, et <schemaversion> porte la version — 1.2 pour SCORM 1.2, 2004 4th Edition (ou 3rd Edition) pour SCORM 2004.

4. Quelle est la différence entre l’attribut version du manifest et schemaversion ?

version sur <manifest> est la version du contenu (libre, informative). <schemaversion> dans <metadata> est la version du standard SCORM visé, qui détermine le runtime exposé par le LMS. Deux choses distinctes.

5. Cite trois erreurs XML qui font échouer l’analyse du manifeste.

Par exemple : une balise non fermée (<title>Intro sans </title>) ; un caractère réservé non échappé (& au lieu de &amp;) ; un namespace adlcp manquant ou une URL de namespace erronée. On peut ajouter un default orphelin ou un identifierref pointant dans le vide (qui ne cassent pas l’analyse mais vident le menu).


Chapitre suivant : Organizations, items, SCO vs asset — on entre dans l’arbre de navigation et on distingue enfin un SCO d’un asset.

Last updated on