Partie 12 — Concevoir & tester un produit interopérable

⏱️ TL;DR — Les onze premières parties t’ont appris chaque standard un par un. Celle-ci les assemble en méthode de travail : comment choisir le bon standard pour un vrai produit (pas un cas d’école), avec quel outil auteur (ou en le codant en React/Next.js), comment tester la conformité avant de livrer (sur plusieurs cibles, pas juste « mon Moodle »), comment migrer de SCORM vers cmi5/xAPI sans rien casser, et comment architecturer une appli qui est à la fois outil LTI, émetteur xAPI et exporteur SCORM/cmi5. C’est la partie « ingénieur » : on passe du « je connais le standard » au « je livre un produit interopérable et certifiable ».

De la théorie au produit

Tu sais lire un imsmanifest.xml, écrire un statement xAPI, brancher un outil LTI 1.3. Bien. Mais un produit réel n’est jamais « du SCORM » ou « du LTI » : c’est un assemblage de décisions. Quel standard pour quel usage ? Quel outil pour produire le contenu ? Comment prouver que ça marche ailleurs que chez moi ? Comment faire évoluer un catalogue SCORM de dix ans sans casser les inscriptions en cours ? Comment héberger tout ça dans l’UE, en respectant le RGPD, avec des clés bien gardées ?

Ces questions ne sont pas dans les specs. Ce sont des décisions d’architecture et de qualité. Cette partie te les fait prendre, une par une, en s’appuyant sur tout ce qui précède — et en gardant l’angle qui compte : livrer du vérifiable, pas du « ça devrait passer ».

Ce que tu sauras faire à la fin de cette partie

• Trancher entre SCORM, cmi5, LTI et xAPI sur des scénarios produit réels, et savoir les combiner.
• Choisir entre un outil auteur (Storyline, Rise, Captivate, iSpring, Lectora, H5P) et un développement maison (React/Next.js), en connaissant ce que chacun exporte.
• Tester la conformité d’un contenu ou d’un outil sur SCORM Cloud, les suites ADL, CATAPULT (cmi5), un LRS de test et les implémentations de référence LTI — et viser la certification 1EdTech.
• Migrer progressivement de SCORM vers cmi5/xAPI, livrer deux formats en parallèle, centraliser avec Rustici Dispatch, et versionner contenus et verbes xAPI.
• Architecturer un produit Next.js qui est à la fois outil LTI, émetteur xAPI et exporteur SCORM/cmi5 — multi-tenant, hébergé UE, RGPD-compatible, sécurisé.

Les chapitres

🧭 Sur FormaCampus — C’est la partie où FormaCampus devient une entreprise interopérable, pas une collection de démos. Elle choisit ses standards par produit (catalogue en SCORM, nouveaux parcours en cmi5, studio en LTI, présentiel en xAPI), teste chaque livraison sur SCORM Cloud avant de l’envoyer à un client, migre progressivement son catalogue historique de SCORM vers cmi5, et assemble son studio — une appli Next.js unique qui exporte du contenu, se branche en LTI et alimente son LRS. On la suit à chaque chapitre.

On commence par la décision qui conditionne tout le reste : l’arbre de décision, en pratique.