Scénario illustratif. Lundi, la direction qualité diffuse une nouvelle version d'une procédure. Trois modules du catalogue la citent. Tant qu'ils ne sont pas corrigés, votre LMS forme des salariés à une règle périmée, et enregistre soigneusement la preuve qu'ils l'ont apprise.
La mise à jour est la partie la moins visible du métier, et celle qui expose le plus. Voici comment l'organiser.
Pourquoi les mises à jour traînent
Dans la plupart des équipes, corriger un module suit ce circuit : demande au prestataire ou au concepteur, réouverture du projet dans l'outil auteur, correction, republication, test, remise en ligne. Chaque étape a son délai, et aucune n'est longue en soi. C'est l'enchaînement qui transforme une correction de cinq minutes en un chantier de plusieurs semaines.
Trois obstacles reviennent :
- Le fichier source est introuvable, ou chez un prestataire.
- La licence de l'outil auteur n'est installée que sur un poste.
- Personne ne sait quels modules sont touchés par le changement.
Les deux premiers se contournent en corrigeant le package publié. Le troisième demande un inventaire.
Tenir un inventaire qui sert
Vous n'avez pas besoin d'un logiciel. Un tableau suffit, à condition de noter pour chaque module ce qui déclenchera sa mise à jour.
| Colonne | Exemple |
|---|---|
| Module | Sécurité au poste, module 2 |
| Version en ligne | v3, mise en ligne en mars |
| Sources citées | Procédure de consignation, règlement intérieur |
| Référent métier | Responsable sécurité du site |
| Fichier source disponible | Non, package seul |
| Prochaine revue | Date fixée à la mise en ligne |
La colonne « Sources citées » est celle qui compte. Le jour où une procédure change, vous filtrez et vous obtenez la liste des modules à corriger.
Classer la mise à jour avant de la faire
Toutes les mises à jour ne se traitent pas de la même façon.
| Type | Exemple | Traitement |
|---|---|---|
| Correction | Une faute, un chiffre, un logo, une image datée | Dans le package publié, le jour même |
| Révision | Une procédure modifiée, un écran à réécrire, une question à changer | Dans le package si la structure ne bouge pas |
| Refonte | Un nouveau parcours, de nouveaux objectifs | Nouveau module |
L'erreur fréquente est de traiter une correction comme une refonte : on attend d'avoir « le temps de tout revoir », et le module reste faux pendant des mois.
Corriger dans le package publié
Pour une correction ou une révision légère, le package suffit. Vous modifiez le texte ou remplacez l'image à l'endroit concerné, sans rouvrir l'outil auteur. Ce qui est possible dépend de l'outil qui a produit le module : le détail est dans Modifier un SCORM sans le fichier source.
Quand le même terme change dans tout un catalogue (un nom de service, un intitulé de poste, un numéro d'urgence), un rechercher-remplacer sur l'ensemble des modules évite d'en oublier un.
Remplacer le module dans le LMS sans perdre le suivi
C'est la question qui inquiète le plus, à raison. Deux cas :
La structure du module n'a pas changé. Mêmes écrans, même quiz, seuls des textes ou des images diffèrent. La plupart des LMS permettent de mettre à jour le package d'une activité existante. Les apprenants qui avaient terminé gardent leur statut, ceux qui étaient en cours reprennent.
La structure a changé. Des écrans ont été ajoutés ou supprimés. Les données de reprise des apprenants en cours ne correspondent plus au nouveau module, et la reprise peut échouer. Dans ce cas, créez plutôt une nouvelle activité et décidez qui doit la suivre.
Dans les deux cas, faites l'essai sur un cours de test avec un compte en cours de parcours avant de toucher à la production. Les contrôles à refaire sont dans Tester un SCORM avant de le livrer.
Faut-il faire repasser le module ?
Une mise à jour pose une question qui n'est pas technique : les personnes déjà formées doivent-elles être informées du changement ?
- Pour une faute d'orthographe : non.
- Pour une consigne de sécurité ou une obligation réglementaire modifiée : oui, d'une manière ou d'une autre. Un module court consacré au changement est souvent plus efficace que de faire repasser le module entier.
Cette décision appartient au référent métier. Notez-la avec la version.
Garder l'historique
Pour chaque mise à jour, conservez quatre informations : ce qui a changé, pourquoi, qui a validé, et à quelle date la nouvelle version a été mise en ligne. Conservez aussi l'ancienne version du package.
Cet historique a deux usages. En audit qualité, il montre que vos contenus sont tenus à jour. En cas d'incident, il établit quelle version un salarié a suivie à une date donnée.
Questions fréquentes
À quelle fréquence revoir un module ?
Fixez une date de revue à la mise en ligne, selon la vitesse à laquelle le sujet évolue. Un module réglementaire se revoit plus souvent qu'un module sur une méthode.
Qui décide qu'un module est à jour ?
Le référent métier pour le fond, le responsable formation pour la mise en ligne.
Mon prestataire facture chaque correction. Est-ce évitable ?
Pour les corrections de texte et d'image, oui, si vous corrigez le package vous-même. Pour une refonte, le prestataire reste la bonne voie.
Les notions de package, de manifeste et de statut sont expliquées dans le guide SCORM du responsable formation.
Corriger le jour même
Avec le correcteur SCORM, vous ouvrez le package, corrigez le texte ou remplacez l'image, testez la reprise et exportez. Chaque modification crée une version datée, et deux versions se comparent avec les changements surlignés. Corriger est gratuit.