Chapitre 12.4 — Migrer & faire cohabiter

⏱️ TL;DR — Tu as un catalogue SCORM qui tourne chez des clients, et tu veux la richesse de cmi5/xAPI. On ne fait pas de « big bang » : on migre progressivement et on fait cohabiter. Trois leviers : (1) livrer deux formats en parallèle — le même module en SCORM 1.2 et en cmi5 — pour ne casser aucun client ; (2) Rustici Dispatch — livrer aux LMS clients un petit paquet SCORM « pointeur » qui charge le contenu resté central, mis à jour d’un seul endroit ; (3) versionner tes contenus et tes verbes xAPI (une IRI de verbe est un contrat permanent : on ne change pas son sens, on en crée un nouveau). La stratégie : garder SCORM vivant, ajouter un LRS, passer les nouveaux modules en cmi5, centraliser avec Dispatch, et laisser cmi5 devenir primaire à mesure que les clients modernisent.

🎯 Objectifs

• Migrer de SCORM vers cmi5/xAPI sans casser les inscriptions en cours.
• Livrer deux formats (SCORM et cmi5) pour un même contenu, et savoir pourquoi.
• Utiliser Rustici Dispatch pour centraliser le contenu et le diffuser dans les LMS clients.
• Versionner contenus et verbes xAPI comme des contrats stables.
• Dérouler une stratégie de migration progressive en phases.

Migrer, oui — casser, non

SCORM a un plafond : pas de mobile, pas de hors-ligne, pas de données fines, tracking limité au navigateur lancé depuis un LMS (Partie 2). cmi5 et xAPI lèvent ce plafond. Mais tu ne peux pas débrancher SCORM du jour au lendemain : des centaines d’apprenants ont des inscriptions en cours, des clients ont des LMS qui ne gèrent que SCORM, des contrats parlent de « livraison SCORM ». La migration est un problème de continuité, pas de remplacement.

⚠️ Piège — Le « big bang » : convertir tout le catalogue en cmi5 et couper SCORM. Résultat garanti : les clients au vieux LMS ne peuvent plus rien importer, les parcours en cours se cassent, le support explose. En interop, on migre à côté de l’existant, jamais à sa place d’un coup. La cohabitation n’est pas une faiblesse, c’est la méthode.

Levier 1 — Livrer deux formats en parallèle

Le patron le plus simple : pour un même module, tu produis les deux paquets — un SCORM 1.2 (compatibilité maximale) et un cmi5 (richesse, mobile). Le client prend celui que son LMS sait ingérer. Ton outil auteur (chapitre 12.2) exporte souvent les deux d’un clic ; en code maison, tu génères deux packagings depuis la même base HTML5.

Le même contenu, deux emballages, deux clientèles servies. C’est la stratégie d’éditeur du scénario A (chapitre 12.1).

💡 Réflexe — Sépare contenu et packaging dès la conception. Si ta logique pédagogique (les écrans, les questions, la notation) est indépendante de la façon dont elle remonte (SCORM API vs cmi5 initialized/terminated), tu génères N formats depuis une source. Coupler le contenu à un standard, c’est se condamner à tout réécrire pour en ajouter un.

🔌 Côté intégration — Proposer « SCORM et cmi5 au choix » est un argument commercial. Ça dit au client : « votre LMS ancien ? on gère. Votre LMS moderne et votre besoin de données ? on gère aussi. » Tu ne perds aucun segment de marché à cause d’un choix de format imposé. Beaucoup d’appels d’offres demandent explicitement la double livraison.

Levier 2 — Rustici Dispatch : centraliser le contenu

Livrer deux formats règle la compatibilité, mais pas la maintenance : une fois un .zip SCORM importé dans dix LMS clients, corriger une faute t’oblige à redistribuer dix paquets et à demander à dix clients de réimporter. Cauchemar.

Rustici Dispatch résout ça. L’idée : au lieu de livrer le vrai contenu, tu livres un petit paquet SCORM « pointeur » (un dispatch). Le client l’importe dans son LMS comme un SCORM normal ; mais au lancement, ce pointeur charge le contenu resté hébergé chez toi, au centre.

Ce que ça débloque :

• Mise à jour centrale : tu corriges le contenu une fois, chez toi ; tous les clients voient la version à jour sans réimporter.
• Contrôle d’accès : tu peux révoquer ou limiter l’accès d’un client (fin de licence, quota) depuis le centre.
• Suivi d’usage : tu vois qui lance quoi, côté éditeur.
• Protection du contenu : le client n’a jamais le vrai contenu dans son LMS, seulement le pointeur.

⚠️ Piège — Croire que Dispatch supprime la dépendance réseau. Le contenu étant central, si ton hébergement tombe, tous les clients tombent en même temps. Dispatch centralise le contrôle et le point de défaillance : héberge en conséquence (disponibilité, UE/RGPD — chapitre 12.5). Le compromis « je maîtrise tout / tout dépend de moi » est à assumer consciemment.

📚 La spec — Dispatch n’est pas un standard : c’est un produit de Rustici qui exploite SCORM (le pointeur est un SCORM valide, importable partout où SCORM l’est). Il s’appuie sur la spec SCORM (Parties 3 et 4) sans rien y ajouter côté LMS client. À situer : outil d’écosystème, pas norme.

Levier 3 — Versionner contenus et verbes

Migrer, c’est aussi faire évoluer dans le temps. Deux choses se versionnent, avec des règles différentes.

Versionner le contenu : chaque module a une version (v1, v2…). Quand tu modifies un module déjà déployé, décide : est-ce une correction (même identité, les parcours en cours continuent) ou une nouvelle version (nouvelle identité, on n’écrase pas l’historique des apprenants qui ont fait la v1) ? Garder des identifiants stables pour ce qui ne change pas de sens est la règle.

Versionner les verbes xAPI : c’est le point délicat. Une IRI de verbe (http://adlnet.gov/expapi/verbs/completed) est un contrat permanent. Tu ne changes jamais le sens d’une IRI existante : des milliers de statements déjà stockés dans les LRS s’y réfèrent. Si tu as besoin d’un sens nouveau, tu crées une nouvelle IRI — tu ne recycles pas l’ancienne.

{
  "verb": {
    "id": "http://adlnet.gov/expapi/verbs/completed",
    "display": { "fr-FR": "a termine", "en-US": "completed" }
  }
}

⚠️ Piège — Redéfinir le sens d’un verbe déjà utilisé, ou inventer des IRI internes fantaisistes qui changent d’un déploiement à l’autre. Tes analytics deviennent incomparables dans le temps : un même completed veut dire deux choses selon l’époque. Règle stricte : réutilise les vocabulaires standard (ADL), ne modifie jamais une IRI publiée, mints une nouvelle IRI pour un sens nouveau (voir le rappel du chapitre 12.1 sur la discipline de vocabulaire).

💡 Réflexe — Tiens un profil xAPI interne : la liste versionnée des verbes, activités et extensions que tes contenus émettent, avec leur sens. La xAPI Profile Spec existe justement pour ça. Un profil versionné, c’est le dictionnaire qui garde tes données comparables sur cinq ans — sans lui, ton LRS dérive vers l’incohérence.

La stratégie de migration progressive

On assemble les trois leviers en un plan par phases, où l’existant ne casse jamais :

L’ordre compte : on ajoute avant de retirer. À aucune phase un apprenant ne perd sa progression, aucun client ne se retrouve avec un format que son LMS ne lit pas. La migration est réversible à chaque étape.

🧭 Sur FormaCampus — Trajectoire réelle de FormaCampus, étalée sur plusieurs trimestres. Phase 0 : son catalogue conformité est en SCORM 1.2 dans les Moodle des écoles. Phase 1 : elle monte un LRS (Partie 7) et fait émettre du xAPI « en observation » sans toucher à la complétion SCORM. Phase 2 : ses nouveaux parcours « métiers » naissent directement en cmi5, et le catalogue historique est désormais livré en SCORM et cmi5 au choix du client. Phase 3 : elle bascule le catalogue en Dispatch — une faute corrigée le lundi est à jour chez tous les clients le lundi, sans réimport. Phase 4 : les écoles qui migrent vers un Moodle récent passent au cmi5, qui devient peu à peu le format primaire. À aucun moment un élève n’a perdu sa progression, ni un client son accès. Ajouter avant de retirer : c’est toute la doctrine.

✏️ Exercices

Exercice 1 — Pas de big bang. Un dirigeant veut « tout passer en cmi5 le mois prochain et arrêter SCORM ». Deux risques concrets, et la contre-proposition ?

Exercice 2 — Corriger une faute dans dix LMS. Une coquille est repérée dans un module déployé chez dix clients (chacun a importé le .zip SCORM). Comment éviter de redistribuer dix paquets à chaque correction future ?

Exercice 3 — Un nouveau sens de verbe. Tes contenus émettent http://adlnet.gov/expapi/verbs/passed pour « a réussi ». Tu veux désormais distinguer « a réussi du premier coup ». Que fais-tu, et que ne fais-tu surtout pas ?

🧠 Quiz de révision

Chapitre suivant : Architecture produit — assembler le tout : une appli Next.js qui est à la fois outil LTI, émetteur xAPI et exporteur SCORM/cmi5, multi-tenant, hébergée UE et RGPD-compatible.