Chapitre 12.1 — L’arbre de décision (en pratique)

⏱️ TL;DR — Le chapitre 1.4 t’a donné l’arbre « brancher / livrer / tracer ». Ici on le met au travail sur quatre produits réels : un éditeur de contenu qui vend des modules, une startup d’outil qui veut s’intégrer dans les LMS, un CFA qui trace du présentiel tablette en main, et une plateforme mobile avec suivi hors-ligne. Pour chacun, on déroule les questions, on nomme les critères qui tranchent (cible client, hors-ligne, renvoi de notes, richesse des données, modèle économique), et on assume qu’un vrai produit combine presque toujours plusieurs standards. À la fin, tu ne récites plus l’arbre : tu l’appliques à un cahier des charges.

🎯 Objectifs

• Dérouler l’arbre de décision sur quatre profils produit distincts et justifier chaque choix.
• Nommer les critères déterminants au-delà du technique : cible, hors-ligne, notes, modèle de vente.
• Reconnaître les combinaisons de standards typiques par type de produit.
• Éviter les deux pièges symétriques : le « SCORM par défaut » et le « tout xAPI ».

On ne réinvente pas l’arbre — on l’exploite

L’arbre de décision « as-tu besoin de brancher, de livrer ou de tracer ? » est posé au chapitre 1.4. On ne le recopie pas. On change d’entrée : au lieu de partir d’un besoin abstrait, on part d’un type de produit et on regarde où l’arbre le mène. C’est ainsi qu’on décide en vrai — on connaît d’abord ce qu’on vend, pas une question théorique.

Lis chaque branche comme une hypothèse de départ, pas un dogme : les critères de la section suivante peuvent la nuancer (un éditeur qui vise le mobile penchera vers cmi5, une startup dont le client n’a que du SCORM devra livrer un paquet, pas un outil LTI).

Scénario A — L’éditeur de contenu

Le produit : tu édites des modules e-learning (conformité, langues, sécurité) que tu vends à des entreprises et des écoles. Ce sont elles qui les importent dans leur LMS. Tu ne contrôles pas la plateforme cible.

Le déroulé : as-tu besoin de brancher un outil vivant ? Non, tu vends un contenu autonome. Descends. Ce contenu est-il importé dans un LMS ? Oui → SCORM ou cmi5. Le critère qui tranche : la diversité des LMS clients. Si ton marché inclut des Moodle anciens, des plateformes RH d’entreprise vieillissantes, des ENT d’académie, la compatibilité maximale l’emporte → SCORM 1.2.

⚠️ Piège — Choisir SCORM 2004 « parce que c’est la version récente ». En pratique, SCORM 1.2 reste le plus universellement ingéré ; certains LMS clients gèrent mal le séquencement 2004. Pour un éditeur qui vise « importable partout », 1.2 est le pari sûr, et 2004 ne se justifie que si tu as besoin de son séquencement (Partie 5) — rare pour du contenu vendu au catalogue.

Mais tu perds les données fines (pas de mobile, pas de suivi hors LMS). D’où la stratégie moderne d’éditeur : livrer les deux formats — un paquet SCORM 1.2 pour la compatibilité, et un paquet cmi5 pour les clients dont le LMS le gère (chapitre 12.4). Ton outil auteur (chapitre 12.2) exporte souvent les deux d’un clic.

💡 Réflexe — Pour un éditeur, la première question au client n’est pas technique mais commerciale : « Quels formats votre LMS sait-il importer ? » La réponse dicte le format de livraison. Un éditeur pro tient à jour une matrice format par client et livre le format le plus riche que la cible sait ingérer.

Scénario B — La startup d’outil

Le produit : une appli interactive (quiz adaptatif, éditeur de code, labo virtuel) que l’enseignant veut intégrer dans son cours — l’élève clique dans Moodle/Canvas et atterrit connecté dans ton appli, qui renvoie la note.

Le déroulé : as-tu besoin de brancher un outil vivant, avec compte et renvoi de notes ? Oui → LTI 1.3 + LTI Advantage (Parties 9 et 10). C’est la première question de l’arbre, et elle s’arrête là. Pas de paquet SCORM à empaqueter : ton appli vit chez toi, le LMS ne fait que la lancer.

Le critère décisif ici est le modèle économique. Un outil LTI est un SaaS : tu héberges, tu factures à l’usage ou à l’abonnement, tu déploies des correctifs sans que le client réimporte quoi que ce soit. À l’inverse, un contenu SCORM est vendu et livré — une fois dans le LMS du client, tu ne le contrôles plus. LTI = produit vivant ; SCORM = produit livré.

🔌 Côté intégration — Une startup d’outil vit ou meurt sur sa capacité à renvoyer les notes (AGS, chapitre 10.3). Un enseignant n’adopte durablement qu’un outil dont les notes atterrissent dans son carnet sans double saisie. C’est aussi ce que la certification 1EdTech vérifie de plus près. Sans AGS conforme, tu restes une « ressource sympa » hors des appels d’offres d’établissement.

Attention toutefois : certains clients n’exposent pas LTI, ou l’enseignant veut aussi une version téléchargeable. D’où une combinaison fréquente : outil LTI pour les LMS qui le gèrent, plus un export SCORM (avec ton appli emballée dedans) pour les autres. On y revient au chapitre 12.5.

Scénario C — Le CFA en présentiel

Le produit : un centre de formation d’apprentis veut tracer les gestes réalisés en atelier — un formateur valide sur tablette « soudure réussie », « machine réglée », « geste de sécurité respecté ». Il n’y a pas de LMS qui « lance » un contenu : l’apprentissage se passe dans le monde réel.

Le déroulé : brancher un outil ? Non. Livrer un contenu importé dans un LMS ? Non — il n’y a pas de contenu packagé, il y a une activité physique. Tracer de l’apprentissage au-delà du navigateur et du LMS ? Oui → xAPI vers un LRS (Parties 6 et 7).

C’est le cas d’usage fondateur de xAPI : ni SCORM ni cmi5 ne peuvent tracer ce qui ne passe pas par un contenu lancé. Le critère décisif : il n’y a rien qui lance. Sans lancement LMS, cmi5 (qui est un profil de lancement) n’a pas lieu d’être — tu émets du xAPI libre depuis l’appli tablette du formateur.

⚠️ Piège — Vouloir « faire du cmi5 » pour du présentiel parce que « c’est plus normé que xAPI ». cmi5 exige un LMS qui lance l’AU, fournit endpoint, fetch, actor, registration (chapitre 8.3). En atelier, personne ne lance rien : le protocole cmi5 n’a pas de point d’entrée. C’est xAPI seul — quitte à définir toi-même tes verbes et ta logique de complétion.

💡 Réflexe — En xAPI libre, la discipline se déplace vers le vocabulaire : tu choisis des verbes stables, réutilisés (completed, passed, performed…), et tu les versionnes (chapitre 12.4). La liberté de xAPI se paie en conventions à tenir toi-même — sinon ton LRS devient un dépotoir de verbes incohérents.

Scénario D — La plateforme mobile

Le produit : une appli mobile de micro-learning. L’apprenant suit des modules hors-ligne dans le métro, l’appli synchronise ensuite un suivi détaillé (temps par écran, réponses, progression fine).

Le déroulé : brancher un outil ? Non. Livrer un contenu tracé importé dans un LMS ? Ici ça dépend d’un critère : y a-t-il un LMS qui orchestre l’apprenant ?

• Oui (l’entreprise cliente inscrit ses salariés via son LMS, veut une complétion pilotée) → cmi5. Il apporte exactement ce qu’il faut : lancement propre depuis le LMS, suivi riche via xAPI, complétion cadrée par moveOn, et — crucial — l’appli peut bufferiser les statements hors-ligne et les rejouer vers le LRS à la reconnexion.
• Non (ton appli est le point d’entrée, pas de LMS tiers) → xAPI seul, avec ta propre logique de complétion et de synchronisation.

Le critère qui tranche entre cmi5 et xAPI seul n’est donc pas le mobile (les deux le gèrent) mais la présence d’un LMS orchestrateur. C’est la nuance que le mot « mobile » masque : mobile ne veut pas dire « pas de LMS ».

⚠️ Piège — Croire que « hors-ligne » interdit SCORM et impose xAPI seul. SCORM est effectivement hors-jeu (il tracke uniquement dans un navigateur lancé depuis un LMS, chapitre 4). Mais entre cmi5 et xAPI seul, c’est la gouvernance de l’apprenant qui décide, pas la connectivité.

Le tableau des critères déterminants

Au-delà de l’arbre, ce sont ces critères produit qui font réellement pencher :

🧭 Sur FormaCampus — FormaCampus est les quatre scénarios à la fois, et c’est normal : (A) son catalogue part en SCORM 1.2 vers les Moodle des écoles, doublé d’un cmi5 pour les clients modernes ; (B) son studio d’exercices est un outil LTI 1.3 qui renvoie les notes aux académies ; (C) ses ateliers présentiels (formation adultes) tracent en xAPI vers son LRS ; (D) son appli mobile de révision fait du cmi5 quand un LMS d’entreprise orchestre, du xAPI seul sinon. Un seul éditeur, quatre décisions, chacune issue de l’arbre appliqué au produit — pas du réflexe « on fait du SCORM ».

🔌 Côté intégration — Le choix se négocie avec le client, il ne se décrète pas. Un cahier des charges d’appel d’offres liste souvent les standards exigés (« le contenu doit être fourni en SCORM 1.2 et cmi5 », « l’outil doit être certifié LTI Advantage »). Lis cette section avant de coder : elle transforme une préférence technique en obligation contractuelle. Rater un standard exigé = candidature écartée.

📚 La spec — Aucune spec ne choisit à ta place : le choix est une décision d’architecture (déjà dit au chapitre 1.4). Chaque standard définit un mécanisme ; à toi de mapper produit → mécanisme. Les mécanismes sont dans SCORM, xAPI, cmi5 (ADL, adlnet.gov) et LTI (1EdTech, 1edtech.org) ; la méthode de décision, elle, est ce chapitre.

✏️ Exercices

Exercice 1 — Quatre cahiers des charges. Attribue le(s) standard(s) : (a) un éditeur de MOOC veut vendre ses cours à des universités aux LMS variés, dont certains anciens ; (b) une edtech propose un simulateur de chimie que les profs intègrent dans Canvas et notent ; (c) un organisme forme des grutiers, validation des manœuvres sur tablette au pied de la grue ; (d) une appli de langues sur mobile, révisions hors-ligne, déployée en marque blanche dans le LMS RH de grandes entreprises.

Exercice 2 — Le critère qui bascule. Deux produits mobiles hors-ligne : l’un pour des salariés inscrits via le LMS de leur entreprise, l’autre en direct-to-consumer (l’apprenant s’inscrit lui-même dans ton appli). Même techno mobile, mais standards différents. Lesquels, et quel critère bascule ?

Exercice 3 — Combiner ou choisir ? Un client veut : ses cours catalogue importés dans son vieux Moodle, un studio interactif intégré qui renvoie les notes, et un tableau de bord du temps passé sur l’appli mobile associée. Un seul standard suffit-il ?

🧠 Quiz de révision

Chapitre suivant : Les outils auteurs — Storyline, Rise, Captivate, iSpring, Lectora, H5P : ce qu’ils produisent, ce qu’ils exportent, et quand coder soi-même.