xAPI, pour un meilleur suivi de l'apprenant

2015-06-03

L’architecture d’xAPI, - Expérience API-, nécessite l’utilisation d’un entrepôt de stockage des apprentissages (LRS). Ce LRS offre la possibilité de collecter, valider et restituer les différentes données sur les expériences d’apprentissage des apprenants, fournies ou demandées par les fournisseurs d’activités (Acivities provider) et le  système de gestion des apprentissages (LMS). Il peut être implanté à l’intérieur ou à l’extérieur d’un LMS.

En collaboration avec le GTN-Québec, l’équipe TI de la SOFAD vous invite  à découvrir comment tirer parti d’un large éventail d’activités en formation à distance.

Implémentation de la spécification xAPI (Expérience API) au sein de l’environnement auteur de la SOFAD

par Moussa Traoré, chef d’équipe TI à la SOFAD. Février 2015.

Cette expérimentation a été réalisée dans le cadre des activités régulières du GTN-Québec et grâce à l’appui technique de l’équipe TI de la SOFAD [Société de formation à distance (SOFAD) des commissions scolaires du Québec]. L’expérimentation vise à mettre à la disposition de la communauté éducative, des recommandations sur l’implémentation de ce nouveau standard du domaine de l’apprentissage en ligne. Les lignes qui suivent présentent brièvement la démarche suivie pour l’implémentation de la spécification xAPI au sein de notre environnement auteur; nous expliquons dans un premier temps pourquoi nous avons décidé de concevoir notre propre extension (SOFAD/auteur); nous décrivons les limitations que nous avons rencontrées avec SCORM; nous montrons comment l’implémentation de xAPI dans notre environnement auteur nous a permis de résoudre les limitations rencontrées avec SCORM; nous dégageons quelques enjeux et contraintes possibles avec ce nouveau standard et finalement nous proposons quelques recommandations.

SOFAD/auteur, une extension Wordpress

De toutes les extensions que nous avons consultées (Namaste LMS, Sensei, WP Courseware, etc), pratiquement aucune n’était vraiment conforme à un standard en particulier; les extensions qui annonçaient un aspect  « auteur » l’étaient dans une infime mesure; aussi toutes les extensions consultées ne permettaient que d’utiliser Wordpress comme système de gestion des apprentissages LMS [Learning Management System / Système de gestion des apprentissages]  (ex.: SCORM Cloud, LearnDash) et non comme un outil auteur à proprement parler. C’est à cet instant que nous avons décidé de concevoir notre propre extension SOFAD/auteur. Pour plus d’information sur SOFAD/auteur et ce qu’est réellement un outil auteur, cliquez ici.

La SOFAD a développé une extension (plug-in) autour de l’environnement Wordpress pour lui permettre de concevoir et de produire ses cours en ligne.

Cette extension SOFAD/auteur comprend un moteur d’interactivité lui permettant de produire plusieurs interactivités d’apprentissage et de les déployer au format SCORM [Sharable Content Object Reference Model/Modèle de référence pour le partage de contenu d’apprentissage] 1.2 vers plusieurs systèmes de gestion des apprentissages conforme à ce standard. (ex: Moodle, Desire2Learn, Blackboard, etc.).

Les raisons ayant motivé cette expérimentation

Certaines de nos interactivités d’apprentissage ( ex: Voter et test à correction manuelle) ne sont pas réalisables avec la spécification SCORM . En effet, il n’est pas possible avec SCORM de collecter certaines données sur les expériences d’apprentissage des apprenants vu le mode de communication limité entre le contenu et le LMS. Aussi, avec SCORM, tous les apprentissages doivent être initialisés à partir d’un système de gestion des apprentissages (LMS); les contenus doivent résider sur le même domaine que le LMS; de plus les contenus SCORM doivent obligatoirement fonctionner dans un navigateur (impossible sur des applications mobiles); de plus, il est impossible de suivre les activités des apprenants hors ligne et il est très facile pour un apprenant aguerri de pirater des contenus SCORM. Enfin, les supports utilisés de nos jours pour apprendre (plates-formes sociales, tablettes, livres numériques, téléphones intelligents, etc.)  ont grandement changé ce qui n’a pas été le cas pour SCORM, puisque la spécification date de plus de dix ans!

La solution envisagée

Fig 1: Architecture xAPI

Une des solutions que nous avons envisagées à la SOFAD pour contourner les limitations de SCORM a été d’implanter le standard xAPI dans notre environnement auteur. L’implémentation de xAPI a nécessité l’utilisation d’un nouveau système, le LRS [Learning Record Store/Entrepôt de stockage des apprentissages]. Le LRS fait partie intégrante de l’architecture de xAPI, c’est le lieu où les données des différentes expériences d’apprentissage sont validées, stockées et rendues disponibles. À cet effet, une présentation détaillée  sur le LRS est disponible ici. Aussi, nous avons retenu la solution open source Learning Locker pour les besoins de notre expérimentation étant donné qu’il nous semblait plus avancé en termes de développement que le LRS de ADL. (Il s’agit des deux seules solutions open source à notre connaissance sur le marché actuellement, les autres étant des solutions propriétaires ou hébergées). De plus, la conception d’un LRS allait au-delà du mandat de notre expérimentation et notre LRS se devait d’être public, c’est-à-dire non implanté au sein d’un LMS puisqu’il se pourrait que les autres institutions membres du GTN-Québec envoient aussi leurs données vers ce LRS. À noter qu’un LRS peut résider à l’extérieur ou à l’intérieur d’un LMS.

La démarche d’implémentation

Notre expérimentation a porté sur deux interactivités qui ne sont pas  réalisables avec la spécification SCORM.

La première interactivité est un test à correction manuelle, dans lequel un apprenant répond à une série de questions qui lui sont posées et soumet ensuite ses réponses pour évaluation à un correcteur (Enseignant et/ou collègue de classe). Suite au dépôt de son test, le correcteur peut comparer les réponses aux corrigés fournis, les annoter et les noter en fonction du barème établi. Il peut aussi ajouter un commentaire global, s’il juge l’évaluation insuffisante; aussi, le correcteur  peut demander à l’apprenant de reprendre son test.

La seconde interactivité est un sujet de débat, accompagné d’une question sur laquelle l’apprenant doit se prononcer en votant. Dans cette interactivité de vote, une compilation de l’ensemble des votes des apprenants s’affiche à l’écran en même temps que la rétroaction à l’apprenant.

Dans un premier temps, nous avons essayé de décrire les cas d’utilisation, c’est-à-dire identifier les différents systèmes concernés et préciser le rôle de chacun des acteurs, sachant que la spécification xAPI (Expérience API) encadre la communication entre plusieurs systèmes et implique plus ou moins directement plusieurs intervenants. Le diagramme 1 ci-dessous illustre les différents cas d’utilisation.

Diagramme 1: Les cas d’utilisation

 

Dans un second temps, pour clarifier le déroulement chronologique typique d’utilisation d’une interactivité, nous avons produit un diagramme de séquence pour chacune des  interactivités concernées. Par exemple, pour l’interactivité « voter » , l’interaction entre les objets a lieu du côté de l’apprenant, en JavaScript, dans un cours déployé au format  xAPI au sein d’un LMS. Le diagramme 2 ci-dessous, illustre le diagramme de séquence de l’interactivité « voter ».

Diagramme 2: Diagramme de séquence

Lorsqu’un apprenant se prononce sur une question en votant , les opérations du système se résument a deux grandes étapes : l’enregistrement de la réponse de l’apprenant et l’affichage à l’apprenant de l’ensemble des réponses obtenues jusqu’à présent.

L’interactivité votée (Poll) adresse une demande d’enregistrement de la réponse de l’apprenant (answer) au système SOFAD/auteur (l’implémentation xAPI de l’interface SOFAD/auteur).

SOFAD/auteur exécute cette requête en interagissant avec le xAPI Wrapper.js. Celui-ci envoie alors un énoncé (statement)  au LRS. L’interactivité voter (Poll) demande ensuite toutes les réponses (getallAnswers) des apprenants à SOFAD/auteur.

SOFAD/auteur interagit à nouveau avec le xAPI Wrapper pour répondre à cette requête. xAPI Wrapper obtient les énoncés du LRS par ajax. Une fois que l’interactivité voter (Poll) obtient les réponses, il affiche à l’écran les réponses à l’apprenant. Rappelons que xAPI Wrapper est un fichier javascript utilisé pour faciliter la communication avec le LRS.

Ensuite, nous avons défini les classes qui modélisent les entités ou les concepts présents dans le domaine de l’application, tout en gardant à l’esprit que les énoncés (statements) sont  au centre de l’architecture xAPI. Le diagramme 3 ci-dessous est une représentation non exhaustive de l’ensemble des composantes possibles d’un énoncé, il illustre plutôt les composantes incontournables (celles que nous avons retenues de l’ensemble de la version 1.0.0 de la spécification xAPI) pour les besoins de nos interactivités.

Diagramme 3: Modèle du domaine

La formulation minimale d’un énoncé est la suivante « Acteur / Verbe / Objet / ». Un acteur peut être une personne, un apprenant, ou un système. Alors qu’un objet est une activité quelconque. À noter qu’un objet peut jouer deux rôles dans un énoncé.

  • Il peut être l’objet d’un énoncé, exemple “Jean a complété le test de mathématiques”, test de mathématique est l’objet de l’énoncé.
  • Il peut aussi être le parent de l’objet d’un énoncé, exemple dans l’énoncé “Jean a complété le test de mathématiques de son cours d’algèbre”  “cours d’algèbre”est le parent de l’objet test de mathématiques. De plus, le concept d’objet est assez large, allant d’une question à un cours complet.

L’identification (id) des verbes, ainsi que l’id et le type des objets sont tous représentés par des IRI [Internationalized resource identifier] et contrairement aux URI’s [uniform resource identifier], ils  ne se limitent pas à un sous-ensemble de caractères ASCII. Dans le cas d’une ressource en ligne, l’id d’un objet est simplement l’adresse à partir de laquelle on peut accéder à la ressource en question. La figure ci-dessous est la représentation en JSON [JavaScript Object Notation] de l’énoncé de l’interactivité « voter » d’un apprenant.

Fig 2: Représentation JSON de l’énoncé du “voter”

En réponse à cette requête, le LRS répond en transmettant tous les énoncés incluant l’id du verbe et l’id de l’activité correspondante.

Finalement, nous avons identifié les principales classes impliquées dans le mécanisme de sauvegarde et restauration des données pertinentes à l’apprentissage de l’apprenant et à l’encadrement par un formateur. Les classes représentées sont implémentées en JavaScript et exécutées côté client. Le diagramme 4 ci-dessous illustre ce concept.

Diagramme 4 : Diagramme des classes  

L’interface SOFAD/auteur (au milieu) existe afin de limiter autant que possible les dépendances entre les deux parties de la solution: nos sous-plugiciels (interactivités, questions et tests) et nos cibles de déploiement (xAPI, SCORM, eduSOFAD, etc). De plus, des ajouts sont à prévoir (nouveaux types de questions, nouvelles interactivités et cibles de déploiement) tout au long de la vie de l’environnement.

L’interface SOFAD/auteur offre tous les services de persistance nécessaires à nos sous-plugiciels (dans le diagramme, les interactivités Poll (voter) et Assignment (Test à correction manuelle). Pour chaque cible de déploiement, il existe une implémentation de l’interface SOFAD/auteur.

L’objectif visé est d’être en mesure de rendre compatibles de nouvelles cibles de déploiement sans intervenir dans les sous-plugiciels et, inversement, de développer de nouveaux sous-plugiciels qui soient immédiatement fonctionnels pour toutes les cibles de déploiement.

 → Cliquez sur le lien suivant pour une démonstration complète de l’interactivité voter.

Les premiers avantages constatés

La portabilité des données

Les apprenants et les systèmes peuvent partager des données sur la “performance” de l’apprenant en dehors des LMS et avec d’autres applications.

xAPI supporte une variété de types de contenu, les expériences d’apprentissage peuvent se produire partout et les conditions pour suivre à la trace ces activités d’apprentissage ne se limitent plus simplement au LMS. Le standard fournit une méthode de suivi des activités d’apprentissages et celles-ci peuvent avoir lieu sur de multiples supports (Tablettes, téléphones intelligents, etc.). De plus, l’apprentissage hors ligne (sans connexion réseau) est désormais possible.

Approche centrée sur les apprenants

xAPI est au centre de toutes les activités et expériences d’apprentissages rapportés, ce qui n’était pas le cas avec SCORM (approche plutôt centrée sur le cours); la spécification soutient les scénarios d’apprentissage en équipe et les scénarios d’évaluation avancés. Un concepteur peut décider du niveau de détail à rapporter en termes d’expérience d’apprentissage.

Flexibilité des rapports, de l’analyse et du design

L’introduction du nouveau standard xAPI permet aux organisations de rassembler, visualiser et analyser les données d’apprentissages structurés et non structurés qui n’étaient auparavant pas accessibles.

Les enjeux et les défis à relever

La sécurité et la confidentialité

xAPI ne présume rien quant à l’authentification préalable d’un utilisateur et ne prévoit aucune méthode à cet effet. C’est l’activité qui est entièrement responsable de l’authentification et donc de l’identité de l’apprenant. Cette flexibilité se traduit par le fait que xAPI prévoit plusieurs façons d’identifier un apprenant (acteur) lors de l’envoi d’un énoncé: courriel ou URI OpenID [OpenID Foundation website, 2005].

Par ailleurs, les apprenants ne sont plus nécessairement connus à l’avance par le LRS comme c’est le cas dans un LMS avec SCORM, le LRS accepte un énoncé qui est correctement formulé même s’il s’agit d’un apprenant qu’il ne connait pas. Lorsqu’un LMS consulte un LRS, il doit être en mesure de relier efficacement les identifiants des apprenants (acteurs) trouvés dans les énoncés du LRS avec ses propres comptes utilisateurs.

Cela contraste avec SCORM API où l’apprenant doit être préalablement authentifié.

Aussi, xAPIWrapper.js offre tout de même un modèle d’authentification très semblable à SCORM. Il propose deux façons d’indiquer à un contenu quel LRS utiliser et qui est l’acteur courant. Cependant, il est peu probable que tous les LMS compatibles xAPI adoptent cette façon de procéder.

Dimension sémantique des verbes et des types d’activités

Un élément important dans la formulation des énoncés est le choix et l’utilisation des verbes et des types d’activités ; les communautés de pratique ou certains ordres professionnels qui utilisent une terminologie qui leur est propre devront peut- être mettre en place, partager et maintenir des répertoires de verbes et de types d’activités avec leur définition exacte et leur contexte pour éviter toute ambiguïté dans l’interprétation des résultats et des données. L’industrie devra tenir à jour un répertoire central avec un vocabulaire commun pour s’assurer que les énoncés soient bien compris et conformes aux définitions convenues. Aussi, il est peu probable que chaque organisation rapporte volontairement vers ce répertoire central leurs verbes et types d’activités. Sans oublier la dimension linguistique; traduction (d’une langue à l’autre), d’une même expérience d’apprentissage avec des énoncés différents. Il y lieu de s’inquiéter de la concordance entre les contenus, si chacun utilise des IRI différents pour identifier des mêmes activités. Cependant, une piste de solution semble se pointer à l’horizon avec le concept de « recipes ».

L’évolution et la conformité

Avec le temps tous les systèmes vont générer une quantité énorme de données qui ne peuvent être réinitialisées. Les organisations devront choisir des LRS capables d’évoluer dans le temps pour rencontrer la demande de stockage et le traitement des données. Il faudra aussi assurer la conformité des nouvelles et anciennes versions de la spécification xAPI.

xAPI permettant la granuralité des données, il est possible de suivre des informations de façon plus détaillée et cela introduit  de nouveaux défis, il faudra éviter de collecter des données inutiles.

Les recommandations

Cette expérimentation a permis de démontrer comment ce nouveau standard pour les logiciels d’apprentissage en ligne facilite la communication entre les contenus d’apprentissage et les différents systèmes de façon à enregistrer et suivre à la trace tout type d’expériences d’apprentissage des apprenants y compris sur des appareils mobiles (iPad/Tablettes) ce qui n’était autrefois pas possible avec le standard SCORM.

xAPI est bien une alternative à SCORM, cependant, pour une implémentation réussie, nous suggérons fortement d’intégrer votre LRS  au sein de votre LMS, pour une sécurité accrue. Contrairement à la croyance populaire, le LRS ne remplacera pas le LMS, le LRS doit être plutôt vu comme un complément au LMS.

Adoptez le répertoire des verbes et des types d’activités de ADL afin d’éviter toute ambiguïté dans l’interprétation des énoncés et donc des données. Si vous devez créer de nouveaux verbes et types d’activités, n’hésitez pas à les soumettre  à ADL pour approbation. Aussi, prévoyez avoir plusieurs LRS dans votre architecture pour ne pas avoir à mélanger vos données; car comme vous le savez,  il n’est pas possible pour l’instant de réinitialiser les données générées. Enfin, optez pour un LRS installé (derrière votre pare-feu) ou hébergé, car les solutions dans le « nuage » reviennent chères en termes de coût/énoncé.

En terminant, j’espère que cette expérimentation permettra de lever le doute et l’incertitude que vivent plusieurs institutions d’enseignement et organisations quant à l’adoption et l’utilisation de ce nouveau standard encore peu connu du monde de l’éducation.

Lire le rapport intégral

Pour aller plus loin

Experience API Version 1.0.0 Released! - Advanced…  2013
Introduction to xAPI - RISC Inc.  2014
Anatomy of a Tin Can Statement - Tin Can API. 2013
Building a Learning Record Store - Tin Can API. 2013
Learning Record Store - Tin Can API. 2013
SCORM vs Tin Can - Tin Can API. 2013
Experience API Basics for L&D Professionals. 2013
Experience API (aka Tin Can API) Demystified - YouTube. 2014
The Experience API—Liberating Learning Design. 2014
The xAPI and the LMS: What Does the Future Hold? by steve Foreman, 2013
Tin Can API 0.9 (REST + JSON binding) Client Quick Start … 2012
The Open Source Landscape - Tin Can API. 2013
Incorporating a TinCan LRS into an LMS - SCORM.com. 2012
Anatomy of a Tin Can Statement - Tin Can API. 2013
Learning Locker – the open source learning record store… 2006