La question que pose vraiment l’auditeur
Une formation réglementaire n’est pas un contenu figé. Une procédure change après un incident, une règle interne est durcie, une consigne de sécurité est réécrite. Le module est révisé, parfois plusieurs fois dans l’année.
À partir de là, « 96 % des collaborateurs sont formés » ne répond plus à rien. La question devient : formés sur quelle version ? Un collaborateur qui a suivi le module en janvier n’a pas vu la règle introduite en juin. Sur le tableau de bord, il apparaît pourtant comme conforme.
C’est exactement ce qu’un auditeur, un contrôleur interne ou un responsable conformité cherche à établir : pour une personne donnée, à une date donnée, quel contenu a-t-elle réellement eu sous les yeux, et l’a-t-elle validé ?
Pourquoi un LMS seul y répond mal
Un LMS est conçu pour gérer des inscriptions et des complétions. Il sait qu’un apprenant a terminé le cours « LCB-FT réseau ». Ce qu’il y avait dans le paquet SCORM ce jour-là est une autre affaire. Trois situations reviennent sans cesse.
Le remplacement du paquet. Quand vous importez une nouvelle version d’un module, le comportement dépend du LMS et de son paramétrage : certains écrasent le contenu en gardant les anciennes complétions, d’autres créent une nouvelle tentative, d’autres encore demandent de créer un nouveau cours. Dans le premier cas, une complétion de janvier se retrouve attachée à un contenu de juin.
Les copies. Dès qu’un même module vit dans plusieurs environnements, le LMS du siège, celui d’une filiale, le portail d’un partenaire, chaque révision doit être réimportée partout. Les réimports n’ont jamais lieu le même jour. Pendant des semaines, deux populations suivent deux versions différentes sous le même titre.
Ceux qui n’ont pas de compte. Sous-traitants, intermédiaires, intérimaires, équipes terrain : ils sont concernés par l’obligation, mais absents du LMS. Leur formation finit dans une feuille d’émargement ou un tableur, donc en dehors de l’historique.
Aucune de ces situations n’est une faute. Elles sont la conséquence normale d’un outil qui suit des cours, pas des versions.
Ce que doit contenir une preuve
Une preuve exploitable relie quatre éléments, enregistrés au moment du lancement et non reconstitués après coup.
| Élément | Ce qu’il faut pouvoir montrer | Ce qui manque souvent |
|---|---|---|
| La personne | Un apprenant identifié, salarié ou externe | Les externes, suivis à part |
| La version | La version exacte du contenu qui a été servie | Seul le titre du cours est connu |
| La date | Le moment du lancement et celui de la validation | Une date écrasée par la dernière tentative |
| Le résultat | Le statut et, s’il existe, le score obtenu | Un résultat détaché de la version |
Il faut y ajouter un cinquième point, que l’on oublie souvent : quelle version était en vigueur à cette date, et qui l’a décidé. Sans cela, on sait ce que la personne a suivi, mais pas si c’était ce qu’elle devait suivre.
Trois façons d’y arriver
1. Un cours par version
La méthode la plus répandue consiste à créer un nouveau cours à chaque révision, avec la version dans le titre. Elle fonctionne, et elle ne demande aucun outil. Son coût apparaît avec le temps : le catalogue se remplit de doublons, les rapports doivent être consolidés à la main, les inscriptions sont à refaire, et tout repose sur la discipline de la personne qui importe.
2. Un tableur de suivi
Beaucoup d’équipes tiennent en parallèle un fichier qui note, pour chaque module, la date de chaque révision et l’environnement où elle a été publiée. Croisé avec les exports du LMS, il permet de reconstituer qui a vu quoi. C’est mieux que rien, mais c’est une preuve reconstituée : elle vaut ce que vaut la tenue du fichier.
3. Une source unique qui enregistre la version servie
La troisième approche inverse le problème. Le contenu est hébergé une seule fois. Les LMS n’en reçoivent qu’un paquet léger qui pointe vers cette source. Quand un apprenant lance le module, la source sait quelle version elle lui sert, et l’enregistre avec son identité et son résultat. La version n’est plus déduite, elle est constatée.
C’est l’approche de Sajay Dispatch. Vous choisissez la version en vigueur, vous pouvez revenir à la précédente, et chaque lancement reste rattaché à la version réellement servie, y compris pour les personnes invitées sans compte LMS. Vos apprenants gardent le LMS qu’ils connaissent.
Un test à faire cette semaine
Prenez un module réglementaire qui a été révisé au moins une fois depuis un an, et un collaborateur au hasard. Essayez de répondre, pièces à l’appui :
- Quelle version de ce module a-t-il suivie ?
- À quelle date, et avec quel résultat ?
- Quelle version était en vigueur ce jour-là ?
- Même question pour un sous-traitant concerné par la même obligation.
Si l’une de ces réponses demande plus de quelques minutes, ou repose sur la mémoire de quelqu’un, vous avez trouvé l’écart qu’un audit trouvera aussi.