Le LRS est un nouveau type de produit dans le monde du Digital Learning. Et quand on veut se faire une idée de ce qu’est un produit, on veut le voir. Et bien sans vouloir paraphraser Saint Exupéry1, je dirais que l’essentiel du LRS est invisible pour les yeux. Essayons de comprendre pourquoi…
Dans « Experience API », il y a « API »
Un LRS est avant tout une API2, mot rigolo utilisé par les informaticiens pour parler d’un programme informatique qui rend des services à d’autres programmes informatiques. Et comme tout ça se passe entre programmes informatiques, il n’y a pas nécessairement d’interface utilisateur que le commun des mortels peut contempler.
Mais que fait donc une API pour mériter autant de discrétion ? Dans le cas d’un LRS, il s’agit de collecter ou d’accueillir des données issues d’autres applications, de les stocker, puis de les rendre disponibles aux applications qui pourraient en avoir besoin.
Si vous n’êtes pas informaticien, ne zappez pas. Cela vous concerne aussi. Et si vous être vraiment impatient, vous pouvez aller directement à la conclusion.
Un LRS, plusieurs APIs
Pour être plus précis, un LRS n’est pas une API, mais un ensemble d’APIs puisqu’elles sont au nombre de 7. Chaque API permet d’enregistrer et de restituer un type particulier d’information, dont voici une liste simplifiée :
- Les traces d’apprentissage (l’apprenant a fait quelque chose)
- Les états d’apprentissage (l’apprenant en est là)
- Des informations sur les acteurs de la formation
- Des informations sur les activités pédagogiques
Des API standardisées
À première vue, enregistrer et restituer des données peut paraître simple. Après tout, c’est le travail d’une base de données, donc rien de bien sorcier. Ce serait occulter le côté « standardisé » de cette base de données. En effet, xAPI définit un certain nombre de tâches, plus ou moins complexes, que le LRS doit accomplir en respectant des règles strictes :
- Autoriser ou non les requêtes (authentification et permissions)
- Vérifier la validité des requêtes (bon usage des APIs)
- Vérifier la validité des données entrantes (bon format des données)
- Détecter les conflits (incohérences, concurrence d’accès)
- Stocker les données de manière appropriée
- Recherche et filtrer les données selon des critères bien définis
- Les restituer dans un format bien défini
C’est le nombre important de règles édictées par le standard qui rend le développement d’un LRS complexe, et c’est pour cela qu’un programme de certification existe.
Et des fonctions non standardisées
En plus des API standardisées, un LRS dispose souvent de capacités spécifiques, toutes aussi invisibles :
- Des connecteurs permettant de récolter ou d’accueillir des données issues de systèmes non conformes à xAPI
- Des algorithmes d’agrégation et d’analyse de données
Alors, API ?
Si vous n’êtes pas informaticien, tout cela peut vous sembler obscur. Il vous faut simplement retenir que ce que j’appelle la « face cachée du LRS », constitue le socle technique de la solution, et que c’est là que réside toute la complexité.
Pour le concepteur de solutions que je suis, cette face cachée a un coté frustrant puisqu’elle est difficile à valoriser. Pour le projet Trax LRS, elle constitue cependant plus de 70% des développements. La bonne nouvelle est que ce travail est désormais achevé et validé par ADL.
Reste à aborder « la face visible du LRS », bien plus gratifiante. Ce sera l’objet d’un prochain article.
1 « On ne voit bien qu’avec le cœur. L’essentiel est invisible pour les yeux. » Antoine de Saint-Exupéry
2 API – Application Programming Interface
D’autres articles vous attendent sur notre tout nouveau site dédié aux données d’apprentissage.