Le jour où j’ai vraiment compris xAPI

Avant de commencer, je précise que cet article se veut accessible à tous : profils techniques et non techniques. Afin de satisfaire les plus aguerris d'entre vous, je fournis quelques détails techniques qui ne devraient toutefois pas gêner la compréhension générale du propos.

Le LRS : un dépôt centralisé ?

Pour ceux qui n'en ont pas encore entendu parler, le LRS (Learning Record Store) est un dépôt de traces d'apprentissage. La vision communément admise veut que tous les outils de votre écosystème digital (LMS, contenus, Apps, Serious Games, simulateurs, etc.) envoient des traces d'apprentissage à un LRS central. Pourtant, si vous adoptez cette approche, vous risquez de rencontrer quelques difficultés :

Problèmes de disponibilité : que se passe-t-il si le LRS est indisponible durant quelques minutes, ou bien si vous perdez la connexion Web durant vos activités pédagogiques ? Les traces d'apprentissage sont-elles perdues ?
Problème de volumétrie : que se passe-t-il si tous les systèmes de votre écosystème enregistrent des centaines de traces par seconde ? Faut-il s'attendre à des problèmes de dépassement de charge ou de volumétrie ?
Problème d'hétérogénéité : que se passe-t-il lorsque les outils de votre écosystème enregistrent des traces qui leur sont très spécifiques ? Ces traces sont-elles toutes définitivement mélangées au risque de complexifier les futures analyses ?

La spécification xAPI ne répond pas à ces questions. Mais il est impensable que ses concepteurs n'y aient pas pensé.

Rien sur les Learning Analytics ?

A la lecture de la spécification xAPI, on ne trouve aucune référence aux stratégies de Learning Analytics. En revanche, xAPI décrit des APIs qui permettent d'interroger le LRS pour en extraire des données, avec la possibilité d'utiliser un certain nombre de filtres (pour les tech : Statement API, méthode GET).

Ma première idée, et celle de nombre d'entre vous, fut donc de coder un tableau de bord utilisant cette API pour récupérer les données à afficher. Un de mes premiers exercices fut de réaliser un "learderboard", c'est à dire le tableau de classement des 10 meilleurs élèves ayant répondu à un Quiz.

Problème : l'API du LRS ne permet pas de dire "donne-moi les 10 premières traces liées à ce Quiz, classées sur la base de leurs notes, par ordre décroissant". Toute personne qui a des notions de bases de données sait qu'il s'agit pourtant d'une requête très simple.

Autre exemple : afficher les 10 dernières traces d'un apprenant, par ordre chronologique (pour les tech : selon leur "timestamp"). C'est surprenant mais ce type de requête, pourtant simple, n'est pas possible avec l'API du LRS. On peut en revanche classer les traces selon leur date d'enregistrement dans le LRS (pour les tech : selon la propriété "stored"). Quel intérêt ?

Pouvoir récupérer les traces d'un LRS par ordre d'enregistrement peut être très utile si vous souhaitez les transférer vers un autre LRS au fil du temps, afin de synchroniser les 2 LRS. C'est peut-être un indice.

Impossible de supprimer des traces ?

Autre curiosité d'xAPI pour le néophyte : l'API du LRS ne permet pas de supprimer une trace d'apprentissage. Il permet en revanche de l'annuler en envoyant une trace annulatrice qui ressemble à : "annule la trace XYZ" (pour les tech : on utilise le verbe "voided"). La trace annulée n'apparait alors plus dans les résultats des requêtes faites sur le LRS, mais la trace annulatrice est quant à elle bien visible. Pourquoi cette approche ?

Imaginons un instant que nous souhaitions transférer les traces d'un LRS A vers un LRS B en utilisant l'API du LRS (pour les tech : Statements GET). Ce transfert va se faire de manière itérative : on transfère les 100 premières traces, puis les 100 suivantes, etc. De nouvelle traces arrivent dans le LRS A : on les transfère vers le LRS B par groupe de 100, et ainsi de suite.

Imaginons maintenant que l'on puisse supprimer purement et simplement une trace du LRS A. Le LRS B n'est pas au courant. Il ne peut donc pas effectuer lui aussi cette suppression. Les 2 LRS ne sont donc plus synchronisés.

Avec le système d'annulation proposé par xAPI, le LRS B va récupérer des traces annulatrices, comme n'importe quelle autre trace, et va ainsi être informé des annulations effectuées dans le LRS A. Il peut ainsi les répercuter.

Ce second indice nous montre que tout a été pensé dans xAPI pour pouvoir synchroniser les données entre 2 LRS.

L'hypothèse du LRS réparti

Si xAPI met l'accent sur la synchronisation des traces entre LRS, c'est qu'il y a une raison. Cela remet en question la vision classique d'un LRS central, unique dépôt de traces d'un écosystème. A l'inverse, on peut commencer à imaginer des LRS connectés les uns aux autres.

Des LRS locaux, proches des applications émettrices de traces, voire complètement intégrés à ces applications. Cela résoudrait le problème de disponibilité que nous avons évoqué en introduction.
Des LRS fédéraux dont le but serait de mutualiser les traces issues des LRS locaux. Seules certaines traces très normalisées seraient mutualisées. Les traces trop spécifiques resteraient dans les LRS locaux. Cela résoudrait les problèmes de volumétrie et d'hétérogénéité que nous avons évoqués en introduction.

Cette multitude de LRS constituerait ce que l'on pourrait appeler un LRS "réparti" ou "distribué", et nous voyons que cette approche présente de nombreux avantages.

La confirmation par TLA

L'idée d'un LRS réparti est séduisante et elle est confirmée par le projet TLA (Total Learning Architecture) proposé par ADL. En effet, selon TLA, plusieurs LRS sont à l'oeuvre :

Des LRS locaux appelés "noisy LRS" contiennant toutes sortes de traces spécifiques aux applications émettrices ;
Des LRS fédéraux de 1er niveau appelés "transactional LRS" contenant uniquement un jeu de traces bien normalisé ;
Des LRS fédéraux de 2nd niveau appelés "authoritative LRS" contenant essentiellement des traces liées aux compétences.

Tout s'éclaircit. xAPI a été conçu dans un esprit de stockage distribué des traces d'apprentissage et cela change radicalement notre vision des choses.