Chapitre 1.3 — Anatomie d’un écosystème e-learning

⏱️ TL;DR — Pour savoir où se branche chaque standard, il faut d’abord voir la carte des acteurs : le LMS (la plateforme qui orchestre), le contenu (les modules empaquetés), le LRS (le magasin de données d’apprentissage), les outils externes (branchés dans le LMS), le SIS (le logiciel de scolarité, source des personnes), et les outils auteurs (qui produisent le contenu). Chaque standard est un câble entre deux de ces boîtes : SCORM/cmi5 entre contenu et LMS, LTI entre outil et LMS, xAPI entre tout et LRS, OneRoster entre SIS et LMS. Une fois la carte en tête, plus aucun sigle n’est mystérieux.

🎯 Objectifs

Nommer les six briques d’un écosystème e-learning et leur rôle.
Placer chaque standard comme un câble entre deux briques précises.
Lire un schéma d’architecture EdTech et y repérer les points d’interopérabilité.
Distinguer les rôles plateforme (platform) et outil (tool), essentiels pour LTI.

Les six briques

Un écosystème e-learning, aussi complexe soit-il, se ramène à six types d’acteurs :

Brique	Rôle	Exemples
LMS / plateforme	Orchestre : inscrit, lance le contenu, affiche les notes, gère les parcours	Moodle, Canvas, Blackboard, 360Learning, un ENT
Contenu	Le module de formation, empaqueté et (souvent) traçable	Un `.zip` SCORM, un paquet cmi5, une vidéo, un H5P
LRS — Learning Record Store	Stocke et sert les données d’apprentissage (statements xAPI)	Learning Locker, SQL LRS, Veracity, SCORM Cloud
Outil externe — tool	Une appli tierce branchée dans le LMS (exercices, visio, correcteur)	Ton studio Next.js, un outil de quiz, une classe virtuelle
SIS — Student Information System	Le logiciel de scolarité : source des élèves, classes, inscriptions	Un logiciel de vie scolaire, un ERP formation
Outil auteur	Produit le contenu	Storyline, Rise, Captivate, H5P, ton propre éditeur

💡 Réflexe — Quand un client te décrit son « système », range chaque composant dans une de ces six cases. Tu verras aussitôt quels câbles (standards) il te faut. « On a Moodle (LMS), un outil de visio (tool), et Pronote côté scolarité (SIS) » te dit déjà : LTI pour la visio, OneRoster pour synchroniser Pronote↔Moodle.

Chaque standard est un câble

Voici la carte complète. Chaque flèche est un standard reliant deux briques :

Décryptage câble par câble :

Outil auteur → Contenu : l’auteur exporte au format standard (SCORM, cmi5, QTI). C’est le premier point d’interop, souvent invisible mais décisif.
Contenu → LMS (SCORM / cmi5) : le LMS importe le paquet et sait le lancer. C’est le cœur des Parties 2 à 5 et 8.
Outil → LMS (LTI) : l’outil externe s’intègre dans le LMS, l’élève y arrive connecté, et l’outil peut renvoyer une note (AGS) et lire le roster (NRPS). Parties 9-10.
Contenu / Outil / LMS → LRS (xAPI, Caliper) : tout ce petit monde émet des données vers le magasin d’apprentissage. Parties 6-7 et 11.
SIS → LMS (OneRoster) : les personnes (élèves, classes, inscriptions) descendent de la scolarité vers le LMS, et les notes peuvent remonter. Partie 11.
LRS → Tableau de bord : la donnée collectée devient pilotage (réussite, engagement, alertes).

⚠️ Piège — Confondre LMS et LRS. Le LMS orchestre (inscrit, lance, affiche) ; le LRS enregistre des faits d’apprentissage (statements xAPI). Un LMS peut embarquer un LRS, mais ce sont deux rôles distincts. Envoyer un statement xAPI « au LMS » n’a pas de sens : on l’envoie au LRS.

Plateforme vs outil : le couple de LTI

Un mot de vocabulaire qui reviendra sans cesse en Parties 9-10 : dans une intégration LTI, il y a toujours deux rôles :

la plateforme (platform) — historiquement « tool consumer » — c’est le LMS qui accueille ;
l’outil (tool) — historiquement « tool provider » — c’est ton appli qui est accueillie.

C’est relatif au sens du branchement, pas absolu : un même logiciel peut être outil dans un contexte et plateforme dans un autre. Moodle, par exemple, sait être plateforme (il accueille des outils LTI) et outil (il peut être branché dans un autre LMS).

🔌 Côté intégration — Une école ne t’achète pas « une appli » : elle t’insère dans un écosystème qui existe déjà (un LMS, un SIS, parfois un LRS académique). Ton produit gagne l’appel d’offres s’il se présente comme un composant qui se câble, pas comme un système de plus à administrer. Savoir dessiner ce schéma devant le client — « voilà où je me branche, voilà les standards » — est un argument commercial redoutable.

🧭 Sur FormaCampus — L’écosystème cible de FormaCampus : son studio Next.js (outil) se branche en LTI dans le Moodle des écoles (plateforme) ; ses cours partent en SCORM/cmi5 dans ce Moodle ; son appli mobile et ses ateliers tracent en xAPI vers son LRS ; les classes arrivent du SIS de chaque établissement en OneRoster ; un tableau de bord lit le LRS pour piloter. Chaque partie du cours branche un câble de ce schéma.

📚 La spec — Aucun standard ne définit « l’écosystème » dans son ensemble : chacun définit un câble. SCORM/cmi5 (ADL) : contenu↔LMS. xAPI (ADL) : tout↔LRS. LTI (1EdTech) : outil↔LMS. OneRoster (1EdTech) : SIS↔LMS. C’est toi, l’architecte, qui assembles les câbles en un système cohérent.

✏️ Exercices

Exercice 1 — Range et câble. Un lycée décrit son besoin : « On a Moodle. On veut y ajouter votre outil d’entraînement au code, importer des modules de révision achetés à un éditeur, et récupérer nos élèves depuis notre logiciel de vie scolaire. » Range chaque élément dans une brique, puis nomme le standard de chaque câble.

✅ Solution

Moodle = LMS / plateforme.
Votre outil d’entraînement au code = outil externe → câble LTI (idéalement 1.3 / Advantage, pour renvoyer les notes).
Modules de révision de l’éditeur = contenu → câble SCORM (ou cmi5) : import dans Moodle.
Logiciel de vie scolaire = SIS → câble OneRoster : synchro des élèves/classes vers Moodle.

Bonus : si le lycée veut un suivi fin de l’entraînement au code, ajouter un câble xAPI de l’outil vers un LRS.

Exercice 2 — LMS ou LRS ? Vrai ou faux : « J’envoie la complétion de mon module en xAPI directement au LMS. » Corrige si besoin.

✅ Solution

Faux (ou imprécis). Les statements xAPI vont dans un LRS, pas « au LMS ». Le LMS peut héberger un LRS interne, mais le rôle qui reçoit du xAPI est le LRS. Formulation correcte : « J’envoie la complétion en xAPI au LRS » (qui peut être celui du LMS, ou un LRS externe). En cmi5 justement, le LMS fournit à l’AU l’endpoint du LRS à utiliser.

🧠 Quiz de révision

1. Quelles sont les six briques d’un écosystème e-learning ?

LMS/plateforme, contenu, LRS, outil externe, SIS (scolarité), outil auteur. Chaque standard relie deux de ces briques.

2. Quel câble relie le contenu au LMS ? Et l’outil externe au LMS ?

Contenu↔LMS : SCORM ou cmi5 (import + lancement). Outil↔LMS : LTI (lancement connecté, renvoi de notes, lecture de roster).

3. Quelle est la différence entre un LMS et un LRS ?

Le LMS orchestre (inscrit, lance le contenu, affiche les notes, gère les parcours). Le LRS enregistre des faits d’apprentissage (statements xAPI). Rôles distincts, même si un LMS peut embarquer un LRS.

4. Dans LTI, que sont la « plateforme » et l’« outil » ?

La plateforme (platform) est le LMS qui accueille ; l’outil (tool) est l’appli accueillie. C’est relatif au sens du branchement : Moodle peut être l’un ou l’autre.

5. Par quel standard un SIS de scolarité alimente-t-il un LMS en élèves et classes ?

OneRoster : il synchronise utilisateurs, établissements, classes, inscriptions (et peut faire remonter les notes).

Chapitre suivant : Choisir le bon standard — l’arbre de décision qui tranche SCORM, cmi5, LTI ou xAPI.