Scénario illustratif. Un module sur la sécurité au poste tourne dans votre LMS depuis deux ans. La consigne de l'écran 7 vient de changer. Le prestataire qui a produit le module ne répond plus, et vous n'avez que le .zip. Sur les forums, la réponse est toujours la même : « sans le fichier source, il faut tout refaire ».
C'est faux pour une partie des corrections, et vrai pour une autre. Cet article trace la limite.
Fichier source et package publié : deux objets différents
Le fichier source est le projet de l'outil auteur : un fichier .story pour Storyline, .cptx pour Captivate, un projet en ligne pour Rise 360. C'est lui qu'on édite pour produire le cours.
Le package publié est le .zip que reçoit le LMS. C'est un site web compilé : des pages, des scripts, des images, et un manifeste. Les bases sont rappelées dans le guide SCORM du responsable formation.
On ne peut pas reconstruire le fichier source à partir du package. En revanche, le package contient tout ce que l'apprenant voit : les textes, les images, les sons. Ces éléments peuvent être modifiés à leur place, à condition de ne pas toucher au moteur qui les affiche.
Ce qui se modifie dans un package publié
| Correction | Faisable sans la source ? | Remarque |
|---|---|---|
| Remplacer une image, un logo, une vidéo | Oui | Le nouveau fichier doit garder le même nom |
| Corriger un texte | Oui pour beaucoup de packages | Dépend de la façon dont l'outil auteur stocke les textes |
| Réparer le manifeste | Oui | Titre, page de lancement, liste des fichiers |
| Réparer des chemins cassés | Oui | Majuscules, espaces, fichiers manquants |
| Changer le seuil de réussite | Souvent | S'il est déclaré dans le manifeste |
| Compresser les images | Oui | Pour passer sous la limite d'envoi du LMS |
| Supprimer ou déplacer un écran | Selon l'outil auteur | Voir plus bas |
| Modifier une interaction, une logique de quiz | Non | Le comportement est compilé dans le moteur |
La limite dépend de l'outil auteur
Tous les packages ne sont pas construits de la même façon.
Rise 360, iSpring, Lectora et les modules en HTML simple séparent assez nettement le contenu du moteur. Les textes et les médias s'y retrouvent et se corrigent.
Storyline et Captivate compilent le cours dans un moteur propre. Les médias se remplacent, à nom de fichier égal. Les textes se corrigent selon le package. La suppression ou le déplacement d'écrans n'est pas sûr : la navigation, les variables et le suivi sont liés entre eux dans le moteur. Pour cela, il faut l'outil auteur et le fichier source.
Les modules générés par une IA sont en général du HTML lisible. Ce sont les plus simples à corriger, et ceux pour lesquels la tentation de tout régénérer est la plus coûteuse. Voir Module e-learning généré par IA : relire et corriger sans régénérer.
Pourquoi éviter de modifier le zip à la main
Rien n'interdit de décompresser le package, d'ouvrir un fichier dans un éditeur de texte et de le rezipper. Trois accidents arrivent souvent :
- Le zip est refait de travers. On zippe le dossier au lieu de son contenu, le manifeste se retrouve dans un sous-dossier et le LMS refuse l'import. Sur un Mac, l'archive embarque aussi un dossier
__MACOSX. - Un caractère casse un fichier. Une apostrophe ou un guillemet de trop dans un fichier de script, et le cours n'affiche plus rien.
- Personne ne sait ce qui a changé. Sans historique, impossible de revenir en arrière ni de montrer au client ce qui a été modifié.
La méthode sûre, en cinq étapes
- Gardez l'original. Travaillez toujours sur une copie. Le package en production reste intact tant que la version corrigée n'est pas testée.
- Diagnostiquez avant de corriger. Identifiez l'outil auteur et la version SCORM. Ils déterminent ce qui est faisable.
- Faites la correction la plus petite possible. Un mot, une image, une réponse. Plus la modification est localisée, moins elle peut casser autre chose.
- Testez comme dans un LMS. Lancez le cours, allez jusqu'à l'écran corrigé, vérifiez que le statut et le score remontent toujours. La liste complète est dans Tester un SCORM avant de le livrer.
- Tracez. Notez ce qui a changé, quand, et par qui. Vous en aurez besoin au prochain audit ou à la prochaine question du client.
Ce que fait Scorm Editor, et ce qu'il ne fait pas
Scorm Editor ouvre le package publié dans le navigateur, sans le projet d'origine. Il retrouve les textes et les médias, les modifie à leur place et laisse le moteur de l'outil auteur intact. Chaque correction crée une version : l'original reste disponible et vous pouvez comparer deux versions.
Pour les packages Storyline et Captivate, il répare, teste, remplace les médias à nom égal et corrige les textes selon le package. Il ne supprime pas d'écrans dans ces packages : le diagnostic vous l'indique au lieu de tenter l'opération.
Questions fréquentes
Peut-on récupérer le fichier .story à partir du SCORM ?
Non. Le package publié ne contient pas le projet. Si le prestataire a livré le .zip sans la source, demandez-la : selon votre contrat, elle peut vous revenir.
Remplacer une image change-t-il le suivi ?
Non, si le fichier garde le même nom et que rien d'autre ne bouge. Le suivi dépend des scripts et du manifeste, pas des images.
Faut-il réimporter le module comme un nouveau cours ?
Dans la plupart des LMS, vous pouvez mettre à jour le package d'une activité existante. Vérifiez d'abord sur un cours de test ce que devient le suivi des apprenants en cours de parcours.
Pour essayer sur votre package
Déposez le .zip dans le correcteur SCORM. Le diagnostic vous dit quel outil auteur l'a produit et ce qui peut être modifié sans risque. Corriger est gratuit.