Conception des chaînes éditoriales

PENS (AICC 2006^[1]) est un standard développé par l'Aviation Industry Computer-based training Committee (AICC), l'organisme américain de normalisation des technologies d'apprentissage à distance pour le domaine de l'aviation. Son objet est d'encadrer le déploiement d'un fichier SCORM (ADL^[2]) sur une plate-forme de formation à distance.

PENS constitue l'initiative la plus proche du problème exposé dans la section précédente. Son étude nous permet de déterminer si son usage peut être étendu à des contextes plus génériques que le déploiement de paquet SCORM.

PENS standardise un principe d'échanges de notifications qui permet à un logiciel de production de documents (le client) de déployer un paquet SCORM sur une plate-forme LMS (le serveur). Le client envoie une première notification au serveur contenant une URL vers une ressource produite (accessible via les protocoles HTTP, HTTPS, FTP ou FTPS), une description du contenu, les identifiants permettant de récupérer la ressource et une URL permettant au serveur d'envoyer des notifications d'avancement. Le serveur collecte le contenu et envoie une notification de collecte réussie si l'URL de notification de retour à été spécifiée. Le serveur peut alors déployer le contenu et à nouveau envoyer une nouvelle notification.

Le standard PENS pose l'hypothèse d'une possible automatisation du déploiement d'un contenu SCORM à partir de sa description et des identifiants de l'usager. Nous réfutons cette hypothèse ; quand bien même son application est limitée à un spectre fonctionnel réduit, la médiation de l'usager nous semble souvent nécessaire.

Tout en considérant le spectre fonctionnel restreint du standard, les modalités techniques de PENS semblent peu judicieuses. Elles nécessitent un client et un serveur adressables sur le réseau, soit deux logiciels fonctionnant sur une machine disposant d'une IP publique. L'usage d'une plate-forme LMS implique son adressabilité sur le réseau. En revanche, il est courant que des logiciels de production soient des logiciels personnels pouvant être utilisés sur un sous-réseau invisible de la plate-forme LMS (par exemple, derrière un routeur depuis une connexion internet personnelle), ou ne soient pas conçus pour écouter les requêtes issues du réseau (comme par exemple un logiciel de bureau de type outil-auteur de contenus pédagogiques).

À l'instar de débats ayant déjà eu lieu sur les standards d'encapsulation des contenus pour en permettre l'interopérabilité (Crozat, Delestre, Qyeyrut, Baillon, Vanoirbeek Velut & Hennequin, 2006^[3]), nous soutenons que la diversité des contextes ne permet pas l'adoption d'un standard définissant un procédé de déploiement universel. Le standard a pour rôle d'accompagner la diversité des contextes et non d'imposer leur uniformisation. Un standard pour le déploiement de ressources pédagogiques doit proposer un cadre, certes universel, mais également spécialisable pour être adapté à chaque contexte.