Enseigner, une passion, un métier... avec des outils si possible.

Le système de contrôle de connaissance de mes rêves… est peut-être un peu compliqué (c’est, en puissance, un système d’EAO – Enseignement Assisté par Ordinateur – ou encore un LMS – Learning Management System). Mais il me tarabuste depuis des années… Ci-dessous quelques débuts d’ébauches de spécifications informelles de ce que j’aimerai qu’il fasse/supporte/offre. C’est brut, cela aborde de nombreux aspects par le petit bout de la lorgnette et je ne détaille pas le cadre pédagogique dans lequel j’entrevois vivre ces outils (cela demanderait beaucoup de réflexion et de travail - je n’ai pas le temps de m’y consacrer pleinement).

Le contrôle de connaissance passe par la gestion nécessaire d'un stock de Questions. Ce n'est pas très original, mais il faut bien commencer par un bout. Une Question est définit par :

  • Un énoncé multimédia
  • Des réponses qui peuvent être de type
    • QCM (1 parmi N, N parmi M).
    • Ordonnancement des réponses
    • Un fragment de code, du Java, du C#, du SQL, etc.
    • Autres...
  • Une durée normale de réponse (en minute).
  • Des évaluateurs de réponses qui projettent leur évaluation sur un modèle simple :
    • Une valeur flottante [0,1] - Oui, c'est l'horrible "note"... (On peut aussi l'appeler CES - "Coefficient d'Evaluation du Savoir", ou EON - "Estimateur d'Objectifs Normé".)
    • Une liste de chaînes étiquetées chacune par un type { par exemple: Error, Warning, Comment }
  • Certaines évaluations doivent pouvoir être faites par un être humain (cas des textes libres), mais autant que possible, les évaluateurs sont… du code.
  • Les « indices » :
    • une liste optionnelle d’aides constituée d’énoncés multimedia supplémentaires dont les accès sont traqués
    • à l’issue de l’examen, on connait le nombre d’indices consommés pour répondre à la question.

Les relations inter-questions sont multiples (et relativement subtiles). Commençons par la plus simple : une question ne peut avoir de sens qu’au sein d’un groupe de questions. C’est un « scenario » qui enchaîne des questions dépendantes les unes des autres.

Nous sommes devant une alternative classique du design pattern du Composite : doit-on appliquer le « vrai » Composite dans lequel une Question est susceptible de contenir d’autres Questions, ou introduit-on une entité différente qui permet de structurer des paquets de Questions ?

En l’occurrence, il existe une entité du domaine évidente qui regroupe des Questions : l’Exercice.
On introduit donc la notion d’Exercice : un Exercice est composé d’une ou plusieurs Questions. Et pendant que l'on y est, on obtient le schéma de composition plutôt naturel suivant : Un Examen est composé d’un ou plusieurs Exercices, eux-mêmes composés d’une ou plusieurs Questions. Et c'est tout.

La composition d’un Examen se fait donc en manipulant des Exercices : ce sont ces Exercices qui sont les éléments de contenus sélectionnables (les Questions ne sont manipulées directement que dans le cadre d’un Exercice).

Les Exercices peuvent avoir certaines relations entre eux relativement à leur sélection au sein d’un Examen :

  • Si deux exercices sont sélectionnés dans un examen, l’une doit suivre l’autre mais retenir l’un n’entraîne pas la sélection de l’autre. C’est un pré requis d’ordre de présentation uniquement.
  • Un Exercice peut en requérir réellement un ou plusieurs autres.
    • Si l’Exercice est sélectionné, cela entraîne nécessairement la sélection de ses prérequis dans l’Examen. (Note : ce type de prérequis implique celui de l’ordre de présentation.)
    • Une piste à creuser: un pré-requis pourrait-être remplacé par son "résultat" (s'il existe). C'est l'idées des "lemmes" en mathématique (un résultat intermédiaire qui participe à la démonstration d'un théorème plus important).
  • Un Exercice peut requérir que le candidat ait précédemment réussi un ou plusieurs autres Exercices. Ce point soulève la problématique de la mémoire du système… et on voit poindre l’artillerie lourde (bon, c’est un simple serveur).

Le choix d’un tel référentiel (arborescent) est tout à fait discutable, mais je le considère comme un compromis acceptable (suffisamment expressif - correctement opérationnel).

Voilà, cela suffit pour aujourd’hui. Pour continuer il faut introduire la « catégorisation de l’apprenant » (par rapport au référentiel), qui est assimilable aux caractéristiques de son avatar, la fonction d’Evaluation qui fait évoluer les caractéristiques des apprenants, la carte du territoire des compétences à conquérir, etc.

Cela ressemble à un jeu ? Oui, c’est une des idées-forces qui, je pense, devrait être intégrée dans ce type d’outils pédagogiques.

Cela existe déjà ? Tant mieux cela m'intéresse ! Mais ne serait-ce pas une usine à gaz ? Ce ne serait guère étonnant car ce Système dans sa globalité intègre tellement d'aspects (CMS, KM) que je l'imagine bien comme une agglutination de machins divers... Ce qui me motive est de penser le système "from scratch", de modéliser ce qui est nécessaire et uniquement ce qui est nécessaire à la mise en oeuvre de ces idées.

Si d’aventure, cher lecteur, vous êtes intéressé, ou connaissez des systèmes – ou approches – similaires ou approchant(es), quel que soit leur maturité, nous sommes intéressés. Invenietis a les compétences nécessaires au développement/adaptation du système ainsi que le partenaire pédagogique pour l’expérimenter (l’école Intech’Info)… Mais nous ne sommes aucunement spécialistes de ces questions, de l'offre en la matière, des outils existants. N’hésitez pas à me contacter.

Ajouter un commentaire

  Country flag

biuquote
  • Commentaire
  • Prévisualiser
Loading