Suivi de la progression SCORM

Comment la progression est reportée

SecureCodingHub implémente à la fois les modèles de rapport SCORM 1.2 et SCORM 2004 (3e et 4e éditions), donc le même package de contenu fonctionnera à l'intérieur de tout LMS conforme au standard. Pendant une session active, le lecteur échange des données d'exécution avec le LMS via l'adaptateur API SCORM que le LMS injecte au lancement, et cet échange est ce qui produit les quatre points de données que vos administrateurs voient dans leur carnet de notes ou leur rapport de complétion. Les champs ci-dessous sont l'ensemble canonique que nous écrivons à chaque commit ; les fournisseurs LMS spécifiques les exposent sous différents libellés de colonnes mais les valeurs sous-jacentes sont identiques.

Lorsqu'un apprenant termine la formation, le bridge SCORM renvoie les données suivantes au LMS :

• Statut de complétion (incomplet → terminé)
• Score (0-100)
• Temps de session
• Signet pour la reprise

Chacun de ces éléments correspond à un élément de modèle de données SCORM spécifique. Le statut de complétion s'écrit dans cmi.completion_status en SCORM 2004 et dans cmi.core.lesson_status en SCORM 1.2. Le score s'écrit dans cmi.score.raw dans les deux versions, avec l'équivalent mis à l'échelle dans cmi.score.scaled uniquement en 2004 (1.2 n'a pas de champ mis à l'échelle). Le temps de session s'accumule dans cmi.session_time au format de durée ISO 8601, et le signet de reprise est sérialisé dans cmi.suspend_data. Le bridge re-commit ces éléments à chaque tick de heartbeat pendant une session active, donc une session interrompue produit toujours un état partiellement reporté que le LMS peut afficher.

Critères de complétion

Une session SCORM est marquée comme terminée lorsque l'apprenant a terminé chaque affectation obligatoire dans son organisation, ou — si aucune affectation obligatoire n'est en attente — une fois qu'il a une progression enregistrée quelconque. Le seuil n'est pas configurable par affectation ou par package aujourd'hui ; la même logique est livrée dans chaque package SCORM généré par la plateforme.

SCORM 2004 distingue entre complétion (l'apprenant a-t-il terminé l'activité) et réussite (l'a-t-il réussie). Le bridge reporte les deux : cmi.completion_status reflète si l'activité est terminée, et cmi.success_status reflète si le seuil moyen de score de passage a été atteint. SCORM 1.2 n'a pas de séparation complétion / réussite distincte — le bridge écrit passed ou failed dans cmi.core.lesson_status une fois la complétion vraie, et incomplete sinon.

Calcul du score

Le score que le LMS reçoit est calculé côté serveur à partir de la progression de pratique de l'apprenant. L'échelle de score interne va de 0 à 160 par challenge (Phase 1 + Phase 2, avec les deux phases valant jusqu'à 100 pour une complétion au premier essai sans indice). Pour produire un nombre 0-100 compatible SCORM, le bridge fait la moyenne des scores de pratique sur les challenges terminés par l'apprenant et divise par 1,6, puis plafonne le résultat à 100. La transformation est fixe ; il n'y a pas de pondération par package ou par affectation dans cette version.

Reprise / Suspension

Si un apprenant ferme la session avant de la terminer :

• La position actuelle est enregistrée comme signet
• Le prochain lancement reprend depuis le signet
• Le heartbeat de session maintient la session active pendant l'utilisation

Le signet complet — sur quel sujet l'apprenant était, quel challenge, quelle phase, quels indices il avait révélés — vit côté serveur sur l'enregistrement de session SecureCodingHub, et non à l'intérieur du package SCORM. Ce que le bridge met effectivement dans cmi.suspend_data est une petite enveloppe JSON contenant uniquement l'id de session SecureCodingHub (par exemple {"sid":"..."}) ; à la reprise, le bridge lit cet id, appelle le point de terminaison de session SecureCodingHub et utilise l'état côté serveur pour réhydrater le lecteur. Le LMS ne détient donc jamais le contenu des challenges, l'historique des réponses ou l'état des indices.

SCORM impose un plafond de 64Ko sur cmi.suspend_data dans la spécification 1.2 et effectivement la même limite dans de nombreuses implémentations 2004. Parce que le bridge n'écrit qu'un id de session vers le LMS, la charge utile de suspension reste bien en deçà d'un kilo-octet quelle que soit la longueur de l'affectation ou le nombre de fois où l'apprenant suspend et reprend.

Heartbeat

Pendant que l'apprenant a le lecteur SCORM ouvert, le lanceur déclenche un heartbeat vers le backend SecureCodingHub à POST /api/sch/scorm/heartbeat toutes les 60 secondes, portant l'id de session, le signet actuel et le temps de session accumulé. Le même tick re-commit le modèle de données SCORM côté LMS pour que la complétion, le score, le temps de session et les données de suspension restent synchronisés sans attendre des événements de sauvegarde explicites.

Affichage de la progression

Les administrateurs peuvent voir les sessions SCORM depuis :

La vue admin SecureCodingHub est la source de vérité pour les analyses fines : tentatives par challenge, utilisation d'indices, temps passé sur la tâche et les remédiations spécifiques que l'apprenant a choisies. Le carnet de notes LMS voit le résumé SCORM — complétion, score, temps de session — et est la bonne surface pour les rapports de conformité et l'émission de certificats, mais il n'a pas de visibilité sur les données pas-à-pas sous-jacentes. La plupart des administrateurs utilisent les deux vues en tandem : le LMS pour les rapports « l'apprenant a-t-il terminé et réussi », et le tableau de bord SecureCodingHub pour les décisions « où la cohorte rencontre-t-elle des difficultés et que devrions-nous ajuster ». Pour le workflow d'analyse plus approfondi et la configuration des permissions de rôle d'administrateur sur le tableau de bord, consultez notre documentation du tableau de bord d'administration et le guide des rôles et permissions compagnon.

L'émission xAPI est sur la feuille de route et n'est pas disponible aujourd'hui. Quand elle sera livrée, SecureCodingHub pourra pousser les mêmes événements par challenge (révélations d'indices, tentatives incorrectes, transitions de challenge) vers un Learning Record Store aux côtés des commits SCORM. D'ici là, l'ensemble de commits SCORM est la seule surface LMS prête à l'emploi et le tableau de bord d'administration SecureCodingHub est le seul endroit pour voir la granularité par événement.