Premiers retours - Foademplois

CN36 AFNOR GE2 Premiers retours sur l'appel à contributions pour l'interopérabilité des
systèmes d'apprentissage collaboratif en ligne Michel Arnaud
CRIS SERIES
Université Paris X
Michel.arnaud@u-paris10.fr
Cet appel à contribution provenant du groupe français AFNOR GE2 (miroir du
WG2 de l'ISO SC36) fait partie de son plan d'action qui se concentre sur le
domaine "des technologies collaboratives et des architectures
d'environnement d'apprentissage". Il s'adresse à toutes les équipes de
développement système, de concepteurs, d'administrateurs et d'enseignants,
intéressées par l'interopérabilité des systèmes d'apprentissage
collaboratif en ligne Les architectures d'environnement d'apprentissage sont étudiées par le
groupe GE2 de l'AFNOR en particulier en vue de définir les niveaux
d'interopérabilité entre composants système et la standardisation des
éléments correspondants, en appliquant une approche modulaire aux systèmes
d'apprentissage collaboratif en ligne. Ce plan d'action ayant été adopté,
le groupe a décidé de renforcer son approche sur la base la plus large
possible pour produire des recommandations nécessaires à la standardisation
d'interfaces entre composants de systèmes d'apprentissage en ligne.
1. Analyse des premiers retours
Une centaine de retours d'enquête sont déjà parvenus et ont pu être
analysés. Il s'agit d'une première vague qui devrait pouvoir être complétée
au fur et à mesure que l'accent sera porté sur tel ou tel aspect des
échanges de données sur une plateforme : gestion des métadonnées, des
informations sur l'apprenant (compétences, résultats, etc...), gestion des
interactions sur le LMS. Les premiers retours à cet appel montrent
l'intérêt pour ce domaine très vaste et qui reste difficile à appréhender
dans sa totalité et sa complexité. Une partie des réponses témoignent que des communautés entières de
développeurs ne se sentent pas concernées par les normes et standards,
encore moins par les problèmes d'interopérabilité. En effet, elles
privilégient des approches plus innovantes à leurs yeux parce que plus
réactives et mieux adaptées à leurs besoins, l'interopérabilité étant
assurée par le respect des standards du W3C. Des doutes se font jour du
côté de certains pédagogues et les administratifs, confrontés à la
difficile migration d'une plateforme à l'autre quand l'une des deux ou les
deux ne répondent pas aux standards de fait du marché, empêchant ainsi
toute réutilisation de contenus de l'une à l'autre, sans opération de
reformatage coûteuse en temps et en énergie. Des pistes de développement se dégagent concernant la gestion des retours
de l'apprenant sur la plateforme afin d'enrichir les échanges collaboratifs
qui jusqu'à présent ont été peu suivies en tant que telles dans les
principales instances de standardisation. En effet, le modèle
d'apprentissage collaboratif n'a pas été jusqu'à présent la référence pour
le développement des standards de fait qui se sont appuyés sur le modèle
transmissif (simple sequencing). Par ailleurs, il apparaît nécessaire de faire l'état des lieux des
interfaces développées à des fins d'interopérabilité jusqu'à présent afin
de tirer profit de ce qui a été réalisé et peut être intégré dans une
démarche normative concernant les échanges collaboratifs entre apprenants.
2. La définition du niveau de collaboration et des flux de données entre
outils utilisés
La collaboration au sein d'un groupe d'apprenants fait que chaque membre du
groupe atteigne son but en puisant dans l'espace collaboratif, constitué
d'un ensemble de ressources : experts, des documents, des outils
méthodologiques, des outils technologiques. Parmi les ressources, le groupe
joue un rôle clé. Le modèle collaboratif de la communauté virtuelle
d'apprenants, repose sur la communication de groupe, synchrone et
asynchrone, la participation, le partage et l'entraide. L'apprentissage collaboratif en ligne repose essentiellement sur les
échanges écrits (chat, forum, emails, etc..). Cependant, il est important
de considérer les échanges vocaux et en vidéoconférence, au-delà des
échanges écrits et prévoir les évolutions à venir vers des interfaces plus
conviviales. Il existe aussi des outils spécifiques permettant l'exercice
de pratiques collectives distribuées : pages personnelles, liste de
participants avec leurs caractéristiques, espaces de discussions et de
rencontres, zones de stockage pour les documents communs, moteurs de
recherche adaptés au domaine concerné, outils de gestion
communautaire permettant de savoir qui participe activement, quels
documents sont téléchargés le plus, quelle est l'intensité des échanges,
etc.. A partir de l'analyse des échanges de données entre l'apprenant et le
système (LMS) et avec d'autres apprenants et l'enseignant intervenant en
ligne, il est possible de représenter les scénarios collaboratifs comme une
série de choix d'activités constituées d'une ou plusieurs procédures. Par
exemple, l'utilisateur d'un dispositif d'apprentissage en ligne décide
comme activité de participer à une classe virtuelle qui est inscrite dans
son agenda. Il doit suivre les procédures de connexion à la plateforme,
d'identification, d'accès et de participation au chat. Ces procédures
impliquent l'activation de composants logiciels qui vont s'acquitter des
fonctions spécifiques de connexion à la plateforme, d'identification,
d'ouverture des droits d'accès à la zone de chat. Ces composants activent
eux-mêmes des outils logiciels qui eux-mêmes vont déclencher des routines
informatiques. Ainsi il est possible de dresser les tableaux des procédures
de base avec la liste des composants appelés lorsqu'elles sont activées,
puis de montrer quels outils sont appelés par les composants dans le cadre
de ces procédures. 3. Les domaines couverts par les travaux d'interfaces
Les interfaces correspondent à des procédures d'échanges de données entre
briques logicielles qu'il convient de définir avec soin pour pouvoir rendre
ces dernières interopérables lorsqu'elles respectent les spécifications de
ces mêmes interfaces.
3.1 Les trois niveaux d'interfaces
On peut décrire les 3 niveaux de données échangées : le premier concerne le
socle technique qui permet de gérer l'identification, l'accès, le SSO,
etc., le deuxième la mise en ?uvre des outils de communication, le
troisième les contenus des applications. Ces deux derniers niveaux
constituent la couche métier propre à l'apprentissage en ligne. Figure 1 : 3 niveaux d'interface [pic] 3.1.1 La couche communication système W3C
Parmi les très nombreux standards développés dans le cadre du W3C, nous en
extrayons seulement deux pour expliquer la démarche générale prise à ce
niveau de la couche communication système. 3.1.1.1 Analyse des interfaces Portlet JSR36 et WSRP (OASIS)
Les portlets sont des composants Web, comme les servlets, conçus
spécialement pour être assemblés dans le contexte d'une page Web.
D'habitude, de nombreux portlets sont activés quand une page est appelée
par le système. Les spécifications des portlets définissent les composants
pour la gestion des portails, leurs modes d'interaction, leurs cycles de
vie et leur sémantique. Ces composants comprennent les portlets proprement
dit, le descripteur et les interfaces portlet pour leurs connexions à des
produits extérieurs, pour la sécurité, pour l'individualisation de l'usage,
pour un format satisfaisant pour leur gestion. L'objectif de portabilité des portlets entre plates-formes semble atteint
avec la publication récente de deux spécifications d'interfaces. Ces
spécifications permettent l'utilisation de composants logiciels enfichables
dans des containers de portlets. Nombre d'acteurs, outre Sun, tels
qu'Oracle, Plumtree, IBM, respectent ces futurs standards. JSR36
La JSR36 développée par la JCP27 (organisation internationale dont le but
est de définir des spécifications autour des technologies Java)[1] est une
spécification d'API pour les portlets. Purement orientée java, le respect
de cette spécification assure une portabilité entre portails J2EE. Il
s'agit dans ce cas de portlet local : lorsque le portail doit générer une
page, il appelle le composant en utilisant cette API. WSRP
Le consortium OASIS[2] est l'instigateur de cette seconde spécification.
L'objectif de WSRP [3] est de définir les spécifications de cette
interface : il s'agit de gérer des portlets distants, c'est-à-dire exécutés
sur un autre serveur, depuis un serveur donné. WRSP ne se limite pas au
monde J2EE, chaque utilisateur du WSRP peut publier ou utiliser des
services d'autres portails distants. 3.2.2 La couche métier
Il existe des développements en cours dont témoignent les retours à l'appel
à contribution. Mais il convient d'abord de mentionner les standards de
fait AICC et SCORM ainsi que les spécifications d'IMS venant se superposer
et intégrer les précédents. 3.2.2.1 Limites de l'interface AICC [4]
La spécification d'AICC distingue deux catégories de données, parmi les
informations qui doivent être communiquées entre une leçon (CBT (Computer
Based Training) Lesson) et un système de gestion de l'apprentissage (CMI
system), selon qu'elles sont échangées dans le sens CBT à CMI ou CMI à CBT.
C'est l'API (Application Programming In