Plateforme Wims : étapes de création d'un exercice interactif

Plateforme Wims: étapes de création d’un exercice interactif

Un exercice interactif doit aussi générer ses variables, contrôler chaque format de réponse, traiter les erreurs prévisibles et fournir un retour cohérent.

La plateforme WIMS sépare ces opérations. Createxo aide à construire l’exercice. Le format OEF décrit sa logique. Modtool organise et publie les exercices dans un module. Chaque outil a donc une fonction précise. Les confondre produit des ressources instables ou invisibles pour les élèves.

L’interface Createxo: choisir son mode de conception

Createxo est le point d’entrée pour créer du contenu pédagogique WIMS. Dans une classe, l’interface est accessible depuis « Ajouter un exercice » ou « Nouvel exercice ». Hors d’une classe, le travail peut être réalisé localement, mais il ne sera sauvegardé que sur l’ordinateur.

Cette distinction est simple:

• dans une classe, l’exercice peut être enregistré dans l’espace de travail;
• hors d’une classe, il faut conserver le fichier source localement;
• dans une classe, l’envoi du contenu ne suffit pas: il faut encore activer « mettre cet exercice dans votre classe ».

Donc, un exercice visible dans l’éditeur n’est pas nécessairement disponible pour les élèves. L’état de l’édition et l’état de publication dans la classe sont deux variables distinctes.

Createxo propose plusieurs chemins de création.

Le mode guidé réduit les erreurs de syntaxe initiales. Il ne remplace pas la vérification pédagogique. Un formulaire peut produire un exercice techniquement valide mais mathématiquement faible: valeurs fixes, correction trop opaque, réponse acceptée selon un format non maîtrisé.

Le mode brut impose davantage de rigueur. En échange, il donne accès à la logique réelle: variables, conditions, réponses multiples, commentaires ciblés, tirages aléatoires.

Un exercice WIMS n’est pas une fiche numérisée. C’est un programme qui exécute une correction.

Pour un exercice de collège, le bon point de départ est souvent très limité: une notion, une variable didactique, une réponse contrôlée. Par exemple, calculer une somme d’entiers relatifs, identifier un coefficient dans une expression littérale ou résoudre une équation du premier degré. Ajouter trois compétences dans une même question complique l’analyse des erreurs. Donc, il faut d’abord fixer l’objectif.

Avant de saisir quoi que ce soit dans Createxo, définir les quatre éléments suivants:

1. La compétence exacte. Par exemple: « appliquer les priorités opératoires avec des nombres relatifs ». Pas: « travailler le calcul ».

2. La variable qui peut changer. Les nombres, les signes, le nombre de parenthèses, le type d’écriture fractionnaire.

3. La forme de réponse attendue. Un entier, une fraction, une expression, une sélection, une fonction.

4. L’erreur que l’exercice doit détecter. Oubli des parenthèses, signe mal distribué, réduction impossible, ordre de calcul incorrect.

Sans cette préparation, le paramétrage exercice WIMS devient un empilement de commandes. Or, une commande ne corrige pas un objectif mal défini.

Structure et syntaxe d’un fichier OEF: les fondamentaux

Le format OEF organise un exercice en trois parties. Cet ordre correspond à l’exécution du programme.

1. La préparation: définir les variables

La préparation est exécutée lors du chargement de l’exercice. Elle sert notamment à:

• générer des nombres;
• calculer une valeur attendue;
• imposer des contraintes;
• construire des variantes d’énoncé;
• préparer les messages de correction.

Une variable ne doit pas être tirée au hasard sans contrôle. Si un exercice demande une soustraction d’entiers relatifs, certains tirages peuvent créer un calcul trop simple, trop lourd ou hors objectif. Le programme doit donc limiter son domaine.

La commande rand_int(-50..50) permet, par exemple, de générer un entier compris entre −50 et 50. Mais cette plage n’est pas une décision pédagogique. Elle ne garantit ni une difficulté homogène ni des résultats pertinents.

Supposons un objectif: faire travailler la somme de deux nombres relatifs de signes contraires. Tirer deux entiers indépendamment peut produire:

• deux nombres positifs;
• deux nombres négatifs;
• un zéro;
• une somme nulle;
• un résultat trop immédiat.

Ces cas ne sont pas forcément faux. Ils ne travaillent pas la même opération mentale. Donc, les conditions de génération doivent être écrites avant l’énoncé.

Une bonne préparation sépare nettement les données:

• variables affichées à l’élève;
• variables intermédiaires utilisées pour le calcul;
• résultat attendu;
• paramètres de contrôle.

Cette séparation évite une erreur classique: réutiliser une même variable pour deux rôles différents. Si la variable est ensuite modifiée, le résultat attendu devient incohérent.

2. L’affichage: produire un énoncé sans ambiguïté

La commande \statement{...} écrit l’énoncé. Elle doit apparaître exactement une fois dans le fichier OEF. Une seule. Ce n’est pas une convention esthétique. C’est une contrainte de structure.

L’énoncé doit indiquer l’action demandée, pas seulement le thème. « Calculer » est souvent insuffisant si la forme du résultat compte. Il faut préciser, selon le cas:

• donner une valeur exacte;
• écrire le résultat sous forme de fraction irréductible;
• répondre par un entier relatif;
• développer puis réduire;
• saisir l’abscisse du point;
• donner l’ensemble solution.

La consigne doit correspondre au type de réponse programmé. Si l’élève peut répondre avec une écriture décimale alors que l’objectif porte sur une fraction irréductible, le contrôle doit être pensé en conséquence. Sinon, l’exercice corrige autre chose que ce qu’il annonce.

Les commandes \hint{...} et \help{...} permettent d’ajouter une aide. Elles ne doivent pas répéter l’énoncé.

Une indication utile réduit une difficulté secondaire. Une aide utile explicite une méthode sans livrer la valeur finale. La différence est nette:

• indication faible: « Relis la question. »
• indication opérationnelle: « Commence par calculer le produit entre parenthèses. »
• aide excessive: « Le résultat est négatif et vaut presque −12. »

Dans les exercices interactifs maths collège, l’aide doit cibler une étape de raisonnement. Elle ne doit pas servir de deuxième correction générale.

3. L’analyse: contrôler ce que l’élève a réellement écrit

La commande \answer{...}{...}{type=...} définit une réponse attendue et son type. C’est le centre logique de l’exercice. L’analyse ne compare pas seulement un résultat; elle interprète une saisie selon les règles du type choisi.

Ensuite, \feedback{...}{...} peut associer un retour à une réponse ou à une erreur particulière. Enfin, \solution{...} fournit une correction complète.

Un mauvais exercice WIMS possède une solution correcte et des retours inutiles. Un bon exercice distingue les erreurs typiques.

Exemple sur une équation: \(3x - 5 = 16\).

Les réponses ci-dessous n’ont pas la même signification pédagogique:

Le résultat seul ne suffit donc pas. L’auteur doit décider si l’exercice évalue la réponse finale, les étapes, ou les deux. WIMS peut guider l’élève, mais seulement si le scénario d’erreurs a été anticipé.

Paramétrage des réponses et gestion de la précision

La création d’un exercice interactif sur la plateforme WIMS échoue souvent sur un détail: la réponse mathématique est juste, mais le critère de comparaison est mal réglé.

Il faut distinguer trois cas.

Réponse exacte

Pour un entier, une fraction ou une expression algébrique, on cherche généralement une équivalence mathématique. Le type de réponse doit donc être choisi en fonction de l’objet demandé.

La question préalable est toujours la même: deux écritures différentes doivent-elles être acceptées?

Pour \( \frac{1}{2} \), accepter 0,5 dépend de l’objectif. Si l’exercice porte sur les écritures fractionnaires, accepter seulement une valeur décimale retire une partie de l’apprentissage. Si l’objectif est le calcul d’une probabilité, les deux écritures peuvent être recevables.

Donc, la règle de correction découle de la compétence, pas de la commodité de saisie.

Réponse numérique approchée

La commande \precision{n} fixe une tolérance égale à \(1/n\) pour une comparaison numérique.

Si \precision{100} est utilisé, l’écart admis est de \(0,01\). Ce réglage est cohérent pour une consigne demandant un arrondi au centième. Il est incohérent pour une valeur exacte.

Le problème habituel est double:

• une précision trop large valide des réponses approximatives alors que l’exercice exige une exactitude;
• une précision trop stricte refuse une réponse arrondie pourtant demandée dans l’énoncé.

La consigne et le paramètre doivent être alignés. Si l’élève doit arrondir au dixième, le programme ne doit pas comparer comme si une écriture exacte était requise.

Réponse fonctionnelle

Pour comparer des fonctions, WIMS utilise notamment \range{n1..n2}. L’intervalle \([n1,n2]\) sert à effectuer la comparaison.

Ici, l’erreur est plus discrète. Deux expressions peuvent coïncider sur quelques valeurs et différer ailleurs. Le choix de l’intervalle participe donc au contrôle. Un intervalle trop étroit peut laisser passer une réponse qui n’est pas équivalente dans le domaine étudié. Un intervalle mal adapté peut aussi tester des valeurs hors cadre pédagogique.

Pour une fonction affine étudiée au collège, il faut déterminer ce qui est réellement évalué:

• reconnaître une forme algébrique;
• développer et réduire;
• trouver une expression équivalente;
• lire une image ou un antécédent;
• manipuler une expression valable sur un domaine donné.

Le paramètre technique suit cette décision. Il ne la remplace pas.

La tolérance n’est pas un détail d’interface. C’est une règle de correction écrite dans le programme.

Concevoir des variantes sans rendre l’exercice aléatoire

WIMS recommande de tirer parti de l’aléatoire. C’est utile. Ce n’est pas obligatoire. Un exercice fixe peut être préférable lorsqu’il sert à introduire une méthode précise ou à diagnostiquer une erreur donnée.

L’aléatoire devient pertinent lorsqu’il empêche la mémorisation mécanique d’une réponse. Il faut alors garantir que toutes les variantes restent équivalentes du point de vue didactique.

Prenons un exercice sur les priorités opératoires. Les valeurs peuvent changer, mais la structure doit rester stable. Si une version contient uniquement une multiplication puis une addition, tandis qu’une autre ajoute parenthèses, puissances et nombres négatifs, les élèves ne résolvent pas le même type de problème.

La variation doit porter sur des paramètres contrôlés:

1. Les nombres changent, la procédure reste identique. Exemple: même séquence parenthèses, produit, addition.

2. La difficulté numérique reste bornée. Des calculs mentalement accessibles au niveau visé restent accessibles après tirage.

3. Les cas limites sont traités. Pas de division par zéro, pas de dénominateur nul, pas d’ambiguïté de signe.

4. Le résultat conserve une forme adaptée. Si une réponse entière est attendue, la génération ne doit pas produire une fraction imprévue.

5. Les rétroactions restent valables. Un commentaire sur l’oubli d’un signe ne doit pas être affiché dans une variante où aucun signe n’est en jeu.

Cette dernière contrainte est souvent négligée. Un retour ciblé dépend des valeurs générées. Si les variables changent, les conditions de feedback doivent changer avec elles.

Une stratégie simple consiste à construire d’abord une version fixe. Tous les calculs sont vérifiés. Toutes les réponses erronées prévues sont testées. Ensuite seulement, une variable est rendue aléatoire. Puis une deuxième. Cette progression limite les erreurs de dépendance entre variables.

De l’exercice local au module public via Modtool

Créer un exercice dans Createxo ne signifie pas le publier publiquement. La plateforme distingue le travail dans une classe et la diffusion par module.

Pour rendre une ressource publique dans l’environnement prévu à cet effet, il faut utiliser Modtool. Modtool nécessite un compte développeur. Les exercices OEF y sont regroupés dans des modules. Ce sont les modules qui peuvent être publiés.

La logique est la suivante:

• l’exercice est écrit au format OEF;
• il est intégré dans un module;
• le fichier source est placé dans le répertoire src;
• son extension est .oef;
• le module est testé;
• le module suit ensuite le processus de publication disponible avec les droits nécessaires.

Un fichier peut donc porter un nom tel que src/calcul_relatifs.oef. Le nom doit rester lisible. Un module contenant test1.oef, nouveau2.oef et versionfinale_bis.oef devient rapidement impossible à maintenir.

Le classement doit refléter la progression pédagogique. Pour un module de calcul littéral au collège, une organisation cohérente peut séparer:

• réduction d’expressions;
• distributivité simple;
• double distributivité;
• priorités opératoires;
• développement suivi de réduction;
• exercices de remédiation par erreur typique.

Le module n’est pas seulement un conteneur technique. Il impose un ordre de lecture, de test et de maintenance. Si plusieurs enseignants doivent l’utiliser, les intitulés, les variables et les consignes doivent être homogènes.

Dans Modtool, l’option « Tester le module » intervient avant toute publication. C’est une étape de contrôle, non une formalité finale. Elle vérifie que les exercices du module sont exécutables dans leur structure de diffusion.

Stratégies de test et validation pédagogique

Un exercice correct doit survivre à des réponses fausses. C’est le test principal.

Tester uniquement la bonne réponse valide le calcul attendu. Cela ne valide ni les messages ni l’analyse. Or, l’élève rencontre précisément l’exercice lorsqu’il hésite, saisit une forme inattendue ou applique une règle au mauvais moment.

Le protocole de test doit suivre un ordre strict.

1. Tester plusieurs chargements. Si l’exercice contient de l’aléatoire, recharger l’activité et examiner les variantes. Les variables générées doivent rester dans le domaine prévu.

2. Calculer chaque version indépendamment. Ne pas faire confiance à la variable résultat définie dans le fichier. Reprendre le calcul à la main ou avec une méthode distincte.

3. Saisir la réponse juste sous plusieurs formes. Entier, fraction équivalente, écriture décimale, expression réduite: selon ce que le type de réponse est censé accepter.

4. Saisir les erreurs probables. Erreur de signe, oubli de parenthèses, priorité opératoire inversée, division prématurée, arrondi trop tôt.

5. Tester une saisie hors format. Texte, symbole inutile, réponse vide, valeur non demandée. Le comportement doit rester compréhensible.

6. Lire le feedback comme un élève. Le retour indique-t-il la prochaine opération ou répète-t-il seulement « faux »?

7. Vérifier la solution. La solution doit utiliser la même notation que l’énoncé et mener au résultat effectivement attendu.

Un bon tutoriel WIMS enseignant ne se limite donc pas à l’édition de commandes. Il doit faire apparaître la chaîne complète: objectif, variables, énoncé, réponse, analyse, test, diffusion.

Les erreurs les plus coûteuses sont prévisibles:

• déclarer une valeur attendue avant d’avoir stabilisé les variables;
• écrire plusieurs blocs \statement{...};
• accepter une réponse numérique avec une précision incompatible avec la consigne;
• confondre « exercice envoyé » et « exercice mis dans la classe »;
• publier un module sans tester ses variantes;
• prévoir une solution générale mais aucun feedback pour les erreurs élémentaires.

La logique est identique à celle d’un algorithme. Une variable mal définie contamine le résultat. Une condition incomplète laisse passer un cas non prévu. Une sortie mal formulée rend le programme inutilisable, même si le calcul interne est juste.

La création de contenu pédagogique WIMS doit donc être traitée comme une construction contrôlée. Createxo sert à produire l’exercice. OEF fixe son comportement. Modtool organise sa diffusion. Mais la qualité ne vient ni du formulaire ni du code seul. Elle vient de l’analyse des réponses possibles.

Test final, rapide: rechargez l’exercice cinq fois, résolvez chaque variante, entrez une erreur de signe et une réponse au mauvais format. Si l’énoncé, la correction et le feedback restent cohérents, l’exercice peut être proposé aux élèves.