Partager ses questions, QTI un language pivot?

De nombreux outils proposent la fonction de création de tests, que ce soient les outils dédiés – LimeSurvey, Hot Potatoes – ou les outils génériques comme les LMS (Learning Management System) – Moodle, Chamilo.

La question du partage des données se pose dès que de nombreux outils proposent cette même fonction. Quoi de plus frustrant, en effet, que de devoir ressaisir manuellement son travail, simplement parce que la nouvelle application ne supporte pas le format de l’ancienne? Si le problème est simple les solutions, elles, le sont beaucoup moins. On peut diviser les problèmes rencontrés en deux grandes catégories: la question du format et celle des fonctionnalités.

La question du format

Pour les documents statiques, c’est à dire ne contenant pas d’interactions, il existe de nombreux formats: les formats d’impression comme PDF, Postscript ou PCL, les formats images comme TIFF et JPEG, etc. C’est différent avec les tests: il faut non seulement pouvoir afficher le contenu mais aussi décrire comment l’utilisateur ou l’utilisatrice peut interagir avec ce contenu.

Pour répondre à ce problème la plupart des applications ont développé un format pour le stockage des questions qui leur est propre. C’est le cas par exemple de Hot Potatoes. Le problème de cette solution est que chaque application possède alors un format spécifique qui est incompréhensible par les autres. On ne peut donc pas importer dans une application les tests créés dans une autre.

Pour le faire, il faut exporter les questions vers un format actif comme le Flash ou le HTML + JavaScript. Comme ces formats sont exécutables par un moteur de rendu indépendant de l’application source, on peut aisément les intégrer dans une application tierce. Problème: seule l’exécution du contenu est possible. Il est généralement impossible d’extraire les données de départ. Si on veut modifier la question il faut alors avoir accès à l’application source, modifier la question et refaire un export au format désiré. On le voit, il s’agit plus d’une « impression » vers un format actif que d’une exportation réelle, les données de départ étant perdues.

Les solutions relèvent toutes des deux grandes catégories de langages informatiques:

• les langages déclaratifs
• les langages impératifs

Pour faire simple: les langages déclaratifs sont ceux qui spécifient de façon explicite le but à atteindre sans expliquer comment obtenir ce résultat. La décision de la méthode appartient au programme traitant le langage. C’est le cas par exemple dans l’extrait suivant

<question_name>La distance de la terre à la lune?</question_name>

Ici on associe une valeur avec une clef pour donner de façon non-ambigüe le nom de la question. Cependant on n’explique pas dans cet extrait comment traiter cette information. Un programme doit donc connaître la signification de la clef afin de pouvoir traiter cette ligne.

Les langage impératifs sont ceux qui, au contraire des langages déclaratifs, spécifient non pas ce qu’on veut obtenir mais comment l’obtenir. C’est généralement le cas de la plupart des langages de programmation dont le JavaScript. A titre d’exemple on imprimerait le titre de la question de la façon suivante:

echo « La distance de la terre à la lune? »;

Ici on ne dit pas quel est le nom de la question mais on effectue une opération d’impression. Le langage est porteur de son propre sens puisqu’il explique ce qu’il convient de faire pour obtenir un résultat. Par contre il n’y a pas d’information permettant de reconnaître que la valeur « La distance de la terre à la lune? » est le titre de la question.

Un bon exemple de la distinction entre déclaratif et impératif est donné par la solution HTML+JavaScript. Le HTML est la partie déclarative du format pour ce qui est de l’affichage. Quant au JavaScript, il est la partie impérative qui décrit le comportement à adopter en fonction des réponses de l’utilisateur. Il faut noter cependant que le HTML est un langage déclaratif pour ce qui est de la représentation du document. Ses primitives sont les paragraphes, les hyperliens, etc. Le HTML n’est donc pas une solution pour décrire de façon déclarative la structure d’une question ou d’un test.

Il existe deux limitations aux solutions proposées:

1. La solution déclarative est fermée. Pour l’étendre, c’est-à-dire ajouter un champ, il faut également modifier le programme qui lui donne un sens et, par conséquent, modifier tous les programmes d’import. A contrario la solution impérative est ouverte parce qu’elle contient sa propre signification. On peut donc facilement ajouter de nouvelles fonctionnalités sans devoir modifier tous les programmes.
2. La solution impérative est opaque. Pour « comprendre » le format il faut exécuter son contenu. Extraire de l’information du format, comme par exemple le nom de la question, revient à déduire des informations du code ce qui est notoirement compliqué. A contrario la solution déclarative est facile à interpréter puisqu’on possède une liste de valeurs dont on connaît le sens.

La question des fonctionnalités

Un problème supplémentaire vient de l’absence de standards et d’accord quant aux fonctionnalités des tests. Ce même pour des types de questions simples comme celles à choix multiples. Pour s’en convaincre, on peut examiner Moodle et Hot Potatoes. Moodle a une notion de pénalité: un utilisateur peut être autorisé à réessayer plusieurs fois la même question. Dans ce cas la note maximum qu’il peut obtenir se voit réduite d’une pénalité pour chaque tentative infructueuse. Cette fonctionnalité, même si elle peut paraître simple, n’existe pas dans Hot Potatoes.

La question se complique dès l’instant où on ne traite plus seulement le cas de deux applications mais de N. Dans ce cas les fonctionnalités supportées par un ensemble de N applications deviennent le plus petit dénominateur commun.

L’approche des formats multiples

Une première solution pour résoudre l’import de questionnaires venant d’applications tierces, consiste à écrire des programmes d’import pour chacun des formats déclaratifs qu’on veut importer. C’est typiquement le cas de Moodle qui supporte l’importation de questions depuis plusieurs formats: Hot Potatoes, Blackboard, etc. Si une fonctionnalité n’est pas supportée elle est au mieux ignorée. Au pire cela rend l’import impossible – c’est par exemple le cas si un type de question n’existe pas dans Moodle.

Cette approche a le mérite d’être simple mais elle souffre de plusieurs inconvénients:

• Il n’est pas possible d’importer des questions venant d’un programme inconnu. Il faut que le cas ait été prévu.
• Il faut écrire un programme d’import pour chacun des formats supportés. C’est un gros travail.
• La même démarche doit être appliquée pour chacun des programmes important les données des autres programmes. Si on a N programmes à faire communiquer entre eux, il faut écrire NxN programmes d’import, ce qui fait exploser la somme de travail.

L’approche des formats actifs

Une autre solution consiste à exporter – imprimer en fait – les questions vers un format actif – Flash, HTML+Javascript ou autre – et à importer ce format. L’avantage de cette approche est qu’on peut exécuter les questions sans avoir recours à l’application source et, par conséquent, importer ces questions en n’écrivant qu’un seul programme d’import. On peut alors se contenter de n’écrire que N programmes d’import pour N applications. Un autre avantage vient du fait qu’on n’est plus limité par les fonctionnalités de l’application importatrice puisque ces dernières sont programmées dans le format lui-même.

Malheureusement cette approche a de gros inconvénients:

• Il est au mieux difficile, au pire impossible, d’inclure les questions de façon transparente. Cela vient du fait que les applications exportatrices ne supportent guère que leur propre « look-and-feel ». Certes, on peut afficher les questions mais on remarque aisément qu’elles proviennent d’une autre application.
• Si l’on veut pouvoir séparer les questions d’un test et les réutiliser dans un autre contexte il faut pouvoir extraire le résultat de la question: réussi ou raté, valeur de la note, etc. Le seul fait d’exporter un test vers un format actif n’est en soit pas suffisant: il faut également prévoir des moyens de communication entre l’application appelante et le test.
• Pire: l’import ne permet pas de modifier les questions. En effet les questions ne sont plus stockées de façon déclarative mais impérative. On ne connaît donc plus leurs propriétés. Pour en modifier une il faut alors avoir accès à l’application source, modifier la question et la réexporter au format voulu. En ce sens, il ne s’agit pas réellement d’un export puisqu’on est toujours dépendant de l’application source.

L’approche des standards de fait

Une troisième solution pourrait être de se calquer sur un standard dit « de fait ». C’est-à-dire sur le format d’export d’une application suffisamment populaire pour être bien supportée à l’import par les autres applications. C’est le cas par exemple de Hot Potatoes. Cette solution est séduisante sur le papier mais peu mise en pratique dans les faits. Si des programmes d’export existent bien vers des standards de fait c’est généralement pour permettre l’export vers l’application supportant le format et non pour servir de langage pivot. Le problème essentiel vient du fait qu’en utilisant un langage pivot non conçu pour cela on limite les fonctionnalités supportées. En effet, on ne peut exporter que les fonctionnalités supportées par le langage et, comme celui-ci est limité par les fonctionnalités de l’application dont il est issu, il impose une limite supplémentaire.

La norme QTI

Pour répondre à ces problèmes le consortium IMS a développé dans les années 2000 la norme QTI – pour Question & Test Interoperability. Le but cette norme est de servir de langage pivot pour l’export de tests et de questions. C’est-à-dire de permettre l’export vers un langage unique suffisamment riche pour couvrir l’ensemble des fonctionnalités supportées par les applications existantes.

La norme QTI cherche à atteindre cet objectif de plusieurs façons :

• Tout d’abord le catalogue des types de questions supportés – choix multiples, matrice, à trous, etc. – se veut exhaustif.
• Ensuite les règles d’affichage et d’évaluation – c’est-à-dire le calcul des notes – peuvent être décrites dans le dialecte QTI au travers de constructions déclaratives classiques – if then, sum, etc.
• Enfin les règles de composition sont souples: on peut par exemple mélanger plusieurs types de questions dans la même question, cacher ou afficher du contenu en fonction des réponses de l’utilisateur, etc.

Pour illustrer cela, prenons comme exemple la fonctionnalité « pénalité » de Moodle. La norme QTI ne supporte pas la notion de pénalité de façon déclarative. En effet il n’existe pas de champ permettant de spécifier qu’une question doit voir sa note maximum diminuée d’une pénalité pour chaque réponse fausse. Cependant le langage est suffisamment riche pour permettre de décrire cette fonctionnalité au travers de constructions déclaratives: « si l’utilisateur a échoué alors diminuer la note maximum du montant de la pénalité ».

La norme QTI est donc constituée de deux parties: une partie déclarative qui décrit les questions et une partie impérative que l’on peut utiliser pour étendre les fonctionnalités.

Une application qui voudrait intégrer le standard QTI se composerait à haut niveau des modules suivant:

• Un système de stockage pour les fichiers QTI
• Un moteur QTI pour le rendu et pour l’interprétation des règles
• Une interface entre le moteur QTI et l’application hôte pour extraire les résultats – les notes entre autres.

Avantages de la norme QTI

Par rapport aux solutions existantes la norme QTI  présente plusieurs avantages intéressants:

• La norme est suffisamment riche pour supporter presque tous les types de questions à l’export. Cela tient d’une part à son catalogue mais surtout à l’inclusion de règles de calcul non prévues au moment de sa conception.
• Les questions QTI s’intègrent aux applications hôtes. En effet le moteur de rendu peut formater les questions en respectant la charte graphique de l’application.
• Les résultats – notes – peuvent être extraits à la fin de l’exécution pour être utilisés par une autre application, par exemple pour calculer une moyenne semestrielle.
• Les questions sont décrites de façon déclarative. On peut par exemple extraire leur nom pour les inclure dans un catalogue et les réutiliser avec des questions provenant d’autres sources.
• On peut constituer des banques de questions pour créer de nouveaux tests.

Désavantages de la norme QTI

Si les avantages apportés par la norme sont nombreux il convient cependant d’être attentif à ses inconvénients.

Le principal problème de la norme QTI concerne l’import. Il faut bien comprendre que le standard ne permet pas de traduire une question du format QTI vers le format natif de l’application. L’objectif est de stocker la question dans son propre format et de la faire exécuter par un moteur spécifique. En cela la norme se rapproche d’une solution impérative de type Flash ou HTML+JavaScript. Certes elle résout plusieurs problèmes d’intégration mais elle ne règle pas le problème fondamental: il est impossible de modifier une question au format QTI sans avoir accès à l’application source pour les mêmes raisons que les autres formats impératifs:

• La richesse du format dépasse largement les fonctionnalités proposées par les applications
• La norme impose de donner un sens à des règles de calcul, ce qui est difficile

Il faut également noter que la norme est vaste et par conséquent lourde à implémenter. Enfin certaines parties ont tendance à privilégier les constructions impératives au détriment des constructions déclaratives, plus facile à importer. C’est le cas par exemple des réponses sous forme d’expressions régulières – regex.

Une approche: le cas de Chamilo

Chamilo est un LMS (Learning Management System) de nouvelle génération développé en partenariat par plusieurs universités dont l’Université de Genève.  Chamilo fait le choix de supporter de façon native la norme QTI. C’est à dire que Chamilo ne définit pas pour les questions un format d’export qui lui est propre mais utilise à la place la norme QTI. L’export est simple à réaliser puisque la norme supporte l’ensemble des fonctionnalités de la plateforme.

Dans sa première version l’import se faisait sous la contrainte de retrouver dans le fichier la même structure que celle exportée. A ce titre il ne s’agissait pas tant d’un import que d’un réimport, puisqu’en pratique les seuls fichiers QTI qui pouvaient être importés étaient ceux issus de l’application elle-même. Il faut également noter que cette approche introduit un sous-format de fait. C’est la sous-partie de la norme QTI qui est comprise par Chamilo à l’import. Ce faisant le problème de l’import entre applications demeure entier, puisque chaque application qui utilise cette approche introduit un dialecte propre. On peut comparer cette problématique à celle de XML. XML définit des règles communes pour le formatage des fichiers mais chaque application qui utilise ses propres balises introduit un nouveau dialecte. A ce titre, XML est moins un langage qu’une famille de langages partageant des règles grammaticales communes.

En conclusion, l’approche est limitante mais non dénuée d’intérêts. En effet les fichiers générés au format QTI peuvent être lus par les applications supportant la norme.