Chapitre 1.1 — Pourquoi l’interopérabilité

⏱️ TL;DR — Sans standards, un contenu de formation est prisonnier de l’outil qui l’a produit, et deux logiciels pédagogiques ne savent pas se parler. Résultat : des réécritures à chaque nouveau client, des imports manuels de notes et de listes d’élèves, des données d’apprentissage perdues. Les standards d’interopérabilité — SCORM, xAPI, cmi5, LTI et leurs cousins — transforment ce chaos en branchements. Ils répondent à trois besoins distincts : faire circuler un contenu, brancher un outil, et transporter une donnée d’apprentissage. En EdTech, savoir ça, c’est la différence entre un produit vendable et un produit qu’aucune école ne peut adopter.

🎯 Objectifs

• Comprendre concrètement ce que coûte l’absence de standards (le contenu prisonnier).
• Distinguer les trois axes de l’interopérabilité e-learning : contenu, outils, données.
• Relier chaque axe au standard qui le sert (SCORM/cmi5, LTI, xAPI/Caliper, OneRoster).
• Savoir argumenter l’interopérabilité comme un enjeu commercial, pas seulement technique.

Le contenu prisonnier

Imagine : tu passes trois semaines à construire un superbe module interactif « Sécurité numérique ». Il tourne parfaitement dans ton outil auteur. Puis les demandes arrivent :

• une école veut l’intégrer dans son Moodle ;
• une entreprise dans son LMS propriétaire ;
• une académie dans son ENT régional ;
• un organisme de formation veut suivre qui l’a terminé, avec quel score.

Sans standard, chacune de ces cibles est un projet d’intégration : reformater le contenu, réécrire la couche de suivi, republier. Quatre clients = quatre chantiers. Et le jour où tu corriges une faute dans le module, tu la corriges… quatre fois.

Formalisons le coût. Avec N plateformes cibles et M contenus, sans standard, tu es sur une logique de maillage : potentiellement N × M adaptations. Avec un standard, tu produis une fois au format standard, et chaque plateforme sait l’ingérer : tu passes d’un maillage à un moyeu (hub).

⚠️ Piège — Croire que « mon contenu marche, donc il est interopérable ». Marcher chez toi et être importable partout sont deux choses différentes. L’interopérabilité n’est pas un effet de bord de la qualité : c’est une contrainte de format qu’on respecte volontairement, et qu’on teste.

Trois besoins, trois familles de standards

Le mot « interopérabilité » recouvre en réalité trois problèmes distincts. Les confondre, c’est choisir le mauvais standard. Garde cette grille en tête tout le cours :

Ces familles ne sont pas concurrentes : elles répondent à des questions différentes. Un même produit EdTech en combine souvent plusieurs — un contenu SCORM lancé dans un LMS branché à ton studio en LTI, qui trace des activités mobiles en xAPI, tout en synchronisant les classes en OneRoster.

💡 Réflexe — Avant de choisir un standard, demande-toi de quel des trois besoins tu parles. « Je veux tracer » n’est pas la même chose que « je veux packager » ni que « je veux brancher ». La Partie 1.4 en fait un arbre de décision.

Pourquoi c’est un enjeu commercial (pas juste technique)

L’interopérabilité n’est pas un raffinement d’ingénieur : c’est un critère d’achat.

• Les appels d’offres l’exigent. Un cahier des charges d’académie ou de grand compte demande presque toujours « contenus SCORM/xAPI » ou « intégration LTI ». Sans ça, ta candidature est éliminée d’office.
• Ça réduit le coût d’adoption. Un outil qui se branche en LTI en trois clics se déploie ; un outil qui demande une intégration sur mesure dort dans un comité.
• Ça protège l’investissement du client. Une école qui achète du contenu standardisé sait qu’elle pourra changer de LMS sans tout jeter. C’est un argument de vente en soi.
• Ça ouvre les données. Tracer en xAPI, c’est pouvoir prouver l’efficacité pédagogique, alimenter un tableau de bord, nourrir une IA d’adaptation. Les données enfermées ne valent rien.

🔌 Côté intégration — Mets-toi à la place du responsable numérique d’une académie. Il gère déjà quinze outils. Le seizième, s’il n’est pas SCORM/LTI, c’est pour lui un risque : comptes à gérer à la main, notes à ressaisir, dépendance à un fournisseur. Un produit interopérable lui dit « je m’intègre dans ton écosystème, pas l’inverse ». C’est ce qui fait signer.

🧭 Sur FormaCampus — FormaCampus a d’abord grandi avec un produit « fermé » : super appli, mais chaque école devait créer ses comptes et ressaisir les notes. Les ventes calaient au moment du déploiement. Le tournant stratégique : rendre le produit interopérable — cours exportables en SCORM, studio d’exercices branché en LTI dans le Moodle des écoles, suivi en xAPI. Ce cours raconte cette bascule, chantier par chantier. C’est aussi ta feuille de route pour devenir le dev EdTech qu’on s’arrache.

📚 La spec — Il n’y a pas « une » spec de l’interopérabilité : il y a un écosystème de standards, publiés par deux familles — ADL (adlnet.gov) pour SCORM, xAPI et cmi5 ; 1EdTech, anciennement IMS Global (1edtech.org), pour LTI, QTI, Common Cartridge, OneRoster et Caliper. Le chapitre 1.2 dresse la carte.

✏️ Exercices

Exercice 1 — Nomme le besoin. Pour chacun de ces énoncés, dis s’il s’agit de faire circuler un contenu, brancher un outil ou transporter une donnée, et cite une famille de standards adaptée : (a) « Je veux que mon module de e-learning s’importe dans le LMS de n’importe quel client. » (b) « Je veux que mon appli de quiz apparaisse dans le cours Moodle et renvoie la note au carnet. » (c) « Je veux enregistrer qu’un apprenti a réussi un geste technique lors d’un atelier en atelier, hors de tout LMS. »

Exercice 2 — Le coût du non-standard. Une PME de formation a 12 modules et démarche 5 LMS clients différents, chacun exigeant un format « maison ». Combien d’adaptations dans le pire cas ? Et si elle produit une seule fois en SCORM ?

🧠 Quiz de révision

Chapitre suivant : La carte des standards — qui publie quoi, et comment les familles se répartissent le terrain.