Avant de proposer mes services, j’ai consulté la documentation du site http://j3p.devsesamath.net afin d’avoir une idée de la nature du travail à réaliser. J’ai notamment récupéré un document pdf intitulé « Stage J3P, le 17-18 mai 2014 » , qui était destiné à des enseignants ne participant pas au stage en présentiel.

Le document m’ayant paru intéressant mais complexe et long (34 pages), je l’ai imprimé pour mieux l’analyser. J’ai aussi récupéré un fichier zippé contenant divers exemples et, surtout, un environnement permettant de tester hors LaboMep les ressources que j’ai créées en suivant les instructions de la documentation du stage.

Ma première impression a été qu’il fallait vraiment être motivé pour développer une ressource car le modèle à suivre est loin d’être simple ! En effet, sans rentrer dans les détails, l’apprenti-développeur doit apprendre :

• à comprendre la notion de section (qui sera un noeud d’un graphe de parcours dans J3P).
• à l’implémenter, en adaptant une section modèle (définie dans un fichier javascript nommé sectionmodele.js).

Heureusement, il n’y a pas besoin de comprendre tout le code Javascript d’une section. La priorité, pour l’apprenti-développeur, est de savoir à quels endroits stratégiques il faut modifier le code, en particulier pour l’aspect visuel de la ressource, l’analyse des réponses des élèves et l’affichage du diagnostic. Cela suffit pour faire preuve d’un début d’autonomie et adapter (de façon cosmétique) les exemples du document de formation.

Cela peut aussi suffire si, dans le catalogue d’exemples de l’environnement de tests, on trouve une section pas très éloignée de celle qu’on souhaite créer. Hélas pour moi, je n’ai pas pu procéder par mimétisme pour créer des ressources algorithmiques, comme je vais l’expliquer...

Dans un article du N°35 datant de 2013 (lien), Jean-Philippe Vanroyen a évoqué en conclusion l’intégration d’outils externes dans J3P, dont celle du logiciel Proglab qui permet de programmer en AlgoBox (copie d’écran). Comme il y a une ressource nommée « proglab » dans l’environnement de test, je l’ai essayée. Elle n’a pas fonctionné, ce qui n’est pas très grave … puisqu’AlgoBox est passé de mode au lycée !

En tapant ensuite « J3P algorithmique » dans un moteur de recherche, j’ai découvert l’existence de l’outil Psylvia (Programmation à Syntaxe Libre et Versatile pour l’Initiation à l’Algorithmique). Et, bonne nouvelle, il y a dans l’environnement de test une ressource nommée « psylvia » qui est opérationnelle.

Moins bonne nouvelle, j’ai trouvé le code de la ressource bien difficile à comprendre pour pouvoir l’adapter. De plus, ce langage algorithmique ne semble pas adapté aux pratiques pédagogiques actuelles dans le secondaire.

Après cette première étude de l’existant, j’ai contacté plusieurs membres de Sésamath s’occupant de J3P. Avec surprise [1] et déception, j’ai découvert qu’à leur connaissance aucune ressource algorithmique n’aurait été intégrée dans LaboMep ! Donc ma proposition de créer des ressources algorithmiques en m’inspirant de ressources existantes est de fait devenue caduque.

J’aurais pu en rester là, mais j’avais envie de faire évoluer les choses : non seulement je suis enseignant d’informatique (en IUT), mais j’ai surtout acquis des compétences spécifiques dans l’intégration d’outils (interpréteur Python, Blockly) dans un environnement Javascript en développant plusieurs logiciels pédagogiques. Donc, par curiosité intellectuelle et dans l’espoir que mes idées soient un jour mises en pratique dans LaboMep, j’ai décidé de faire une étude de faisabilité avec un prototype que j’ai ensuite présenté à Sésamath.

Son accueil a été excellent puisqu’en quelques jours il a même été intégré, après quelques retouches, dans l’environnement de développement de J3P (lien). Dans la fenêtre qui apparaît alors, il suffit d’entrer le nom d’une section (python_skulpt, testblockly...) et de cliquer sur le bouton « lancer la section ».

Des liens directs seront aussi donnés par la suite pour chaque exemple. Attention, cela peut ne pas marcher car il y a actuellement de nombreux essais effectués, au risque d’introduire accidentellement des erreurs temporaires sur des exemples qui fonctionnaient jusque là.

Comme je l’ai indiqué dans la partie B, la création d’un nouvel exercice interactif consiste à réaliser un fichier Javascript (appelé section) respectant un modèle à suivre. Les divers composants graphiques d’une section peuvent être des composants de base de Html (zones de textes, boutons de commandes…) ou des composants plus spécifiques (calculatrice, graphique interactif…) que J3P met à la disposition du développeur.

Pour disposer de ces composants spécifiques, le programmeur doit indiquer dans une section le nom des outils (« calculatrice », « mathgraph »…) qui les implémentent. Comme je ne disposais pas d’outils adaptés, j’ai dû outrepasser ma fonction de développeur de sections en créant auparavant un outil pour Python.

Concrètement, en mentionnant le nom de ce nouvel outil dans une section, cela signifie que J3P chargera :

• la bibliothèque Javascript d’un interpréteur Python (Skulpt).
• la bibliothèque Javascript d’un éditeur syntaxique colorisé (Ace).
• un fichier Javascript personnel, dont le rôle est de faciliter l’utilisation de ces deux bibliothèques dans J3P, et d’offrir au développeur de la section un moyen simple de tester la validité des programmes des élèves en comparant la sortie de leur exécution à celles de programmes (secrets pour les élèves) résolvant les exercices posés.

L’élève doit compléter le programme ci-dessus, afin de calculer delta (tester). Je lui ai généreusement octroyé deux tentatives pour trouver la bonne formule, ce qui va me permettre ici d’expliquer ce qui se passe en cas d’erreur. S’il valide une réponse (bouton OK) alors qu’il y a une erreur syntaxique dans son programme, une de ses deux chances lui sera retirée. Mais comme l’objectif pédagogique n’est pas de le pénaliser pour cette raison, il y a un bouton d’exécution qu’il peut utiliser (autant de fois qu’il le souhaite) avant de valider sa réponse.

Je vais supposer que, pour sa première tentative, l’élève ajoute l’affectation « delta = b-4*a*c ». Dans ce cas, il verra cet écran où sa formule est comparée à la bonne formule pour a=2, b=2 et c=1.

Pourquoi ce test avec ces valeurs ( a=2, b=2 et c=1) ? La raison est que 3 tests avaient été spécifiés dans le code de la section, que le premier test (a=1, b=1 et c=2) a trouvé le résultat attendu bien que la formule (b-4*a*c) soit fausse, si bien que c’est le premier des deux autres en échec qui a été choisi. A titre indicatif, voici grosso-modo le code qui a été entré dans la section :

Ce code évoluera probablement. L’important est de noter la souplesse qu’il permet à un développeur de section, et qu’il peut le faire en quelques lignes grâce à la fonction vérifierPython (qu’il n’a pas à écrire, car intégrée à l’outil que j’ai créé). Il pourra donc facilement l’adapter pour ajouter de nouveaux tests à cet exemple, ou pour traiter d’autres exercices d’algorithmique :

• le second paramètre de la fonction verifierPython donne la liste des entrées à tester (a, b, c) et leur attribue des valeurs fixes ou aléatoires (J3PRandom est un générateur aléatoire fourni par J3P)
• le premier paramètre de la fonction verifierPython est un programme Python permettant de calculer le bon résultat, afin de le comparer au résultat obtenu en lançant le programme de l’élève (modifié en remplaçant les instructions de saisie par le jeu de données)

Le programme de correction a ici une seule instruction (« print b*b-4*a*c »), mais cela n’a pas d’importance pour le mécanisme de vérification : il n’y aurait par exemple aucune difficulté particulière pour contrôler un programme de calcul du PGCD. Néanmoins, certains types de programmes posent des problèmes spécifiques :

• programmes avec plusieurs sorties : pour analyser la trace d’exécution d’un jeu de données, il faut extraire la valeur de chaque sortie, ce que je n’ai pas cherché à faire pour l’instant.
• programmes avec instructions conditionnelles : ce cas est examiné dans l’exemple suivant (nombre de solutions d’une équation du second degré)

Après cette première formule fausse (b-4*a*c), il ne reste donc plus qu’une seule chance à l’élève puisque je lui avais permis deux tentatives. Donc, dans tous les cas la section se terminera (avec un score de 0 ou 1) et le bouton OK sera remplacé par « section suivante ». Dans l’environnement de test, un clic sur le bouton terminera l’activité car la section fait partie d’un graphe composé d’un seul nœud.

Mais si la section était intégrée dans LaboMep, un enseignant pourrait très bien l’associer à d’autres sections en construisant un graphe : dans le cas présent, si un élève ne sait pas écrire un programme calculant delta, c’est probablement parce qu’il ne connaît pas la formule du discriminant et pas parce qu’il est mauvais en programmation ! Donc, comme il y a dans dans LaboMep des exercices (de mathématiques) sur ce sujet, il est possible de réorienter les élèves vers un de ces exercices…

Comme l’exemple 1 (calcul du discriminant) ne mérite guère de figurer au catalogue de ressources de LaboMep, il faut l’étoffer un peu, par exemple en calculant le nombre de solutions d’une équation du second degré.

Plutôt que de faire résoudre directement ce problème, je vais ici proposer une section à deux questions (dans le jargon J3P, on parle de section à deux étapes et une répétition) :

• la première question (qui sera numérotée 1-a) reprend l’exemple 1 en demandant de calculer delta.
• la seconde question (qui sera numérotée 1-b) démarre en affichant un programme où le calcul de delta est déjà effectué, ce qui permettra d’évaluer l’aptitude de l’élève à utiliser des instructions conditionnelles (pas uniquement certes car l’élève doit aussi avoir une connaissance mathématique sur le nombre de solutions).

Sur la copie d’écran ci-dessous, on peut voir que l’élève s’apprête à répondre à la question 1-b, et qu’il a correctement répondu à la question 1-a puisque son score est de 1 :

Le fait de passer de une étape à deux étapes a compliqué significativement mon travail, surtout parce que je suis un développeur de sections débutant et autodidacte. De plus, même avec une grosse batterie de tests aléatoires, il y a un risque (acceptable ?) de conclure à tort que le programme de l’élève est valide pour la question 1-b : en effet, on ne teste qu’un nombre fini de valeurs de delta, si bien qu’on peut passer à côté de certaines erreurs [2].

Pour en finir avec cet exemple, j’ai créé un graphe permettant de réorienter les élèves ayant échoué aux deux questions algorithmiques vers un exercice interactif sur les équations du second degré : cliquez ici, puis échouez aux deux questions Python afin de le vérifier...

Que les enseignants de lycée se rassurent, l’outil final tiendra compte des préconisations en vigueur. Voici une première évolution qui a été faite par l’équipe J3P (tester) :

Le prototype Python permet d’envisager la création de ressources algorithmiques pour le lycée dans LaboMep. Mais, pour le collège, il faudrait pouvoir recourir à un langage de programmation par blocs. Je n’ai pas de solution à proposer pour Scratch, mais Blockly est une alternative qui se prête très bien à une intégration dans J3P :

• Blockly est programmé en Javascript
• avant d’être exécuté, un programme par blocs est traduit en Javascript, et ce code Javascript peut être modifié afin de tester le programme de l’élève avec divers jeux de données

Donc, sans rentrer dans les détails techniques, créer un outil pour Blockly revient en partie à créer un outil pour un langage textuel (en l’occurrence Javascript) si bien que je peux m’inspirer de l’outil Python présenté dans la section C.

Pour illustrer le prototype Blockly, je vais changer d’exemple, les équations du second degré ne figurant pas au programme du collège. Je vais m’inspirer d’une ressource intitulée « somme de plusieurs entiers consécutifs » qui est publiée sur le site pédagogique de l’académie de Nantes. Elle y est présentée de façon progressive en 3 étapes :

• activité 1 : somme de 3 entiers consécutifs
• activité 2 : divisibilité de cette somme par 3
• activité 3 : somme de n entiers consécutifs (et divisibilité de cette somme par n)

L’objectif mathématique de cette ressource pédagogique est d’arriver à conjecturer pour quelle valeurs de n cette somme est divisible par n. Dans le N°60, j’avais disserté sur ses difficultés algorithmiques et conclu que seules les activités 1 et 2 relevaient de « compétences qu’on peut exiger à la fin du cycle 4 » : donc, si on désire intégrer l’activité 3 dans une section LaboMep, elle devra être fortement guidée.

Au démarrage, l’écran suivant est proposé  :

L’élève doit trouver que le successeur de l’entier n est n+1 (tester). S’il ne donne pas la bonne réponse, cette vérité mathématique lui est rappelée à la fin pour qu’il puisse traiter les questions suivantes.

Pour la question 2 (numérotée 1b dans J3P), l’élève doit mettre en application cette information pour calculer la somme de 2 entiers consécutifs :

On m’objectera peut-être que le code initial donne trop d’informations (somme fixée à n et bloc « incrémenter » à compléter), mais je répondrai alors qu’il ne s’agit ici que d’une ressource de démonstration, à adapter en fonction d’impératifs pédagogiques (que je ne connais pas). De plus, je cherche à préparer les élèves à la question finale (calculer la somme de 10 entiers consécutifs avec une boucle), ce qui me conduit à introduire une nouvelle question préparatoire (somme de 4 entiers consécutifs) :

A vrai dire, j’ignore si c’est une bonne idée ou non d’indiquer que la première incrémentation est de « n+1 » ou s’il faut laisser les élèves la trouver. Concernant la vérification du code final, seule la somme est contrôlée : donc, si les élèves incrémentent de « n-50 » (au lieu de « n+2 ») et de « n+55 » (au lieu de « n+3 »), cela sera aussi accepté.

Et voici la dernière question, qui demande de calculer la somme de 10 entiers consécutifs avec une boucle :

Actuellement, seule la somme est contrôlée : donc rien n’empêche les élèves de « filouter » en supprimant la boucle et en utilisant 9 blocs « incrémenter » : incrémenter de n+1, incrémenter de n+2 … incrémenter de n+9. Une parade simple à mettre en œuvre est de fixer un nombre maximum de blocs autorisés dans la réponse.