Autres articles à propos de Tracenpoche dans MathémaTICE

J’ai rejoint l’équipe des développeurs de Mathenpoche en septembre 2003. Jusqu’au printemps 2004, j’ai développé quelques exercices pour le niveau seconde. En ce qui me concerne, ce fut le début de mon aventure au sein de Sésamath.

A cette époque, le besoin d’un « module » de géométrie dynamique développé par Sésamath se faisait de plus en plus pressant. L’idée consistait en effet à intégrer de la géométrie dynamique dans les exercices de Mathenpoche (Mep) 4ème. Et comme Mep était programmé en Flash, il était nécessaire de développer un tel logiciel en Flash, afin de pouvoir l’intégrer dans le modèle permettant de programmer des exercices. Comme j’avais déjà, mais de manière assez confidentielle, travaillé sur un logiciel mélangeant instruments virtuels et géométrie dynamique, c’est moi qui fus chargé de travailler sur ce projet. Nous sommes alors début mai 2004. A vrai dire, si nous pensions alors que développer un tel logiciel en Flash était possible, du moins théoriquement, de nombreuses questions restaient sans réponse. Est-ce qu’un programme Flash comportant des dizaines de milliers de lignes serait d’une rapidité suffisante ? (La suite montrera que oui). Est-ce que nous disposerons de tous les outils afin de gérer les nombreux événements : clavier, bouton gauche, bouton droit, double clic ? (La suite montrera que non) Est-ce que le moteur interne de calcul du lecteur Flash est suffisamment puissant pour digérer chaque dixième de seconde toute la masse de calculs nécessaires pour un affichage dynamique d’une figure ? (La suite montrera que pas vraiment).

Nous avions en effet quelques raisons de nous inquiéter. Un programme Flash n’est pas un programme autonome (ce que l’on appelle un exécutable) mais un programme exécuté par un lecteur, en l’occurrence ici le lecteur Flash, qu’il est nécessaire d’installer sur la machine pour pouvoir lire les animations Flash. C’est par exemple le cas pour le langage Basic du tableur.

Or ces programmes écrits avec ces langages s’exécutent bien moins rapidement (le rapport peut aller de 1 à 10 au moins). En outre, le langage permettant de programmer des applications Flash, qui a pour nom ActionScript, était le fruit d’une évolution axée sur la vocation de publication d’animations dans des pages web. Ce qui fait que ce langage n’était sans doute pas très adapté pour l’écriture d’un logiciel de géométrie dynamique.

Malgré toutes ces incertitudes, nous n’avons pas hésité à nous lancer dans ce projet puisque l’enjeu était de taille : intégrer de la géométrie dynamique dans un exerciseur !

Par hasard, Emmanuel Ostenne qui n’était alors pas membre de Sésamath mais voulait proposer ses services à l’association côté MathenPoche par exemple, me contacte par mail pour en savoir plus. Emmanuel a écrit le programme de géométrie dynamique Déclic et nous nous connaissons très bien puisque nous avions travaillé ensemble au sein de Lilimath. Je lui propose donc de participer à l’aventure, ce qu’il accepta immédiatement. Nous sommes alors en juin.

Emmanuel ne connaissait pas le langage Flash, il s’est donc formé sur le tas. Quant à moi, je connaissais les bases du langage et je serai amené à comprendre beaucoup de choses sur ce dernier dans les deux années qui suivirent...J’en profite ici pour remercier Emmanuel pour sa précieuse relecture de ce bref article.

Voici une version préhistorique de Tracenpoche, datant de mai 2004.

( ce programme avait pour nom geodyn, en attendant le Tracenpoche trouvé par Katia Hache quelques semaines plus-tard).

Les points et les segments peuvent être déplacés et l’ensemble est très fluide. La zone script n’était pas encore développée.

Même s’il restait tout à écrire et inventer, ce premier prototype nous a donc montré qu’un tel logiciel était possible.

Il restait deux questions : jusqu’où pourrons nous aller dans les fonctionnalités de ce logiciel et surtout comment allons nous l’ intégrer dans l’exerciseur Mep ? La suite nous le dira.

Dès le départ, Emmanuel et moi nous étions mis d’accord sur un grand principe de ce logiciel : une zone script permettant de construire la figure avec une syntaxe du type :

var s1 = segment(A,B) rouge

car elle nous semblait très pédagogique et simple.

Par ailleurs cette description textuelle de la figure allait bien dans le sens d’une intégration future dans Mathenpoche.

Comme on peut le vérifier, les bases étaient posées : une figure, des boutons, une zone script et une zone analyse. Les boutons permettent de construire des objets et le script s’actualise. Une saisie dans le script permet de construire des objets et la figure s’actualise également. J’ai toujours eu la conviction que ce script pouvait jouer un rôle pédagogique important (voir article Script et Tracenpoche) en plus d’être très pratique pour des échanges (un simple texte est très lisible).

Je me rappelle très bien l’été 2004. A part une brève semaine de vacances dans le Vercors pour faire de l’escalade, je passais l’été sur ce projet. Il faisait très chaud et j’avais donc descendu l’ordinateur dans une annexe attenant à mon garage. La fenêtre ouverte donnait directement sur le jardin. Je crois bien avoir passé tout l’été dans cette annexe.... Mes enfants venaient dans cette pièce et finissaient par s’y installer également, si bien qu’il y régnait une ambiance unique. Je programmais tout le temps, et quand je ne programmais pas, je ne pensais qu’au programme. Période unique. De son côté , Emmanuel travailla également avec acharnement sur Tracenpoche. Si bien que fin août la version suivante fut développée :

Les bases du logiciel sont maintenant présentes. En l’état, il constitue un logiciel de géométrie dynamique très frustre certes, mais fonctionnel quand même.

Comme on peut le voir, nous ne nous soucions pas encore de l’apparence...

C’est d’ailleurs à peu près cette version que nous avons présentée à l’équipe Mathenpoche (lors d’une de ces fameuses réunions chez les Hache) en novembre 2004. Je ne crois pas mentir en écrivant qu’elle a suscité un enthousiasme général !

C’est à cette époque que nous avons étudié avec Rafael Lobato comment intégrer ce programme au sein même d’un exercice Mathenpoche. Nous en vînmes à bout mais cela ne fut pas simple.

Nous pouvons en effet nous heurter à de nombreux problèmes, qu’il faut résoudre un à un, et en particulier :

• conflits entre les noms de variables,
• conflits dans la gestion des événements (par exemple la touche entrée dans Tracenpoche est capturée par l’exercice Mep qui valide la réponse et affiche la correction !).

Il faut avouer que nous naviguions en mer inconnue et que nous étions amenés à corriger des erreurs dans les deux logiciels que des pros n’auraient sans doute pas commises. Quoiqu’il en soit, quelques semaines plus tard, Tracenpoche était intégrable dans Mathenpoche. Mais j’ai dû développer pour cela une version spécifique (appelée TepNoyau). Dans les années qui ont suivi, je passais beaucoup de temps afin de mettre à jour le TepNoyau en partant du « dernier » TracenPoche. C’est seulement en 2007 que le programme Tracenpoche intégra en son sein la version TepNoyau : concrètement, il suffit maintenant de changer la valeur d’une variable pour obtenir à la compilation soit Tracencpoche, soit TepNoyau, mais cela a demandé du développement.

Ci-dessous, on peut voir TepNoyau au sein d’une exercice Mep :

Du point de vue du programmeur Mep, les choses sont assez simples. Il se contente d’appeler une fonction contenant en paramètre le fichier texte de la figure. Ensuite il dispose d’une batterie de fonctions permettant de questionner l’état de la figure à chaque instant.

Parallèlement, fin 2004, Rafael a travaillé sur un nouveau look de Tracenpoche : nouveaux boutons, nouvelles couleurs, nouvelles boîtes de dialogues :

La version ci-dessus ne pèse que 192 ko, ce qui est microscopique ! Cela permet un chargement quasiment « immédiat » dans les pages web. Ce qui est possible parce que le lecteur, d’une taille bien plus importante, est inclus dans la plupart des navigateurs.

Début 2005, nous avons décliné Tracenpoche vers une version encore plus légère (de l’ordre de 70 ko ) : un Tracenpoche sans bouton et sans zones scripts, mais permettant l’affichage de figures dynamiques au sein de pages web. Nous avons baptisé ce module TepWeb.

En voici un exemple d’insertion :

Ceci est la copie d’écran d’une page web proposant des exemples d’utilisation de l’objet médiatrice.

Sur la partie droite, on ne trouve pas des images, mais bien des figures dynamiques, d’une taille de 70 ko, c’est à dire parfois moins qu’une image !

C’est Emmanuel qui a créé et géré le site. Boris Sissoeff (ancien membre de Sésamath) est venu en renfort car il était fastidieux d’être sur tous les fronts : réaliser un site pour les utilisateurs, mettre à jour le site par rapport aux développements de TeP, mettre à jour le site par rapport aux ressources des différents utilisateurs qui produisaient beaucoup, mettre à jour le site techniquement (présentation, noyau SPIP à maîtriser).

Voici l’adresse du site du logiciel
(Cliquez en haut à a gauche sur Utiliser en ligne pour le tester).

TepWeb a été massivement utilisé dans ce site. Vous trouverez d’ailleurs ici toute l’historique de Tracenpoche.

Notons que c’est Boris qui a rédigé l’unique mode d’emploi de Tracenpoche consistant en un manuel de plus de 100 pages. Cela constitue un très gros travail, souvent ingrat.

Comme on peut le constater, au premier trimestre 2005, le projet était donc déjà très avancé : une version 2.0 relookée, un site, un mode d’emploi, et deux extensions TepWeb et TepNoyau.

Comme tout projet Sésamath, les échanges concernant ce projet ont lieu sur une liste dédiée. On retrouve sur cette liste les développeurs, mais également quelques personnes (non nécessairement membres de Sésamath) participant activement à la vie du projet par leurs remarques, relectures et tests.

En particulier le retour de témoignages d’expériences vécues en classe est très précieux et souvent très motivant. En outre, le degré d’exigence y est assez élevé car on trouve dans cette liste des spécialistes d’autres logiciels de géométrie dynamique, et qui souhaitent que Tracenpoche fasse aussi bien, sinon mieux !

Une liste active est le signe indéniable d’un projet vivant et dynamique. L’engagement et l’énergie des développeurs enthousiasment la liste. Le soutien, les remarques (et les remerciements) motivent les développeurs. C’est un cercle vertueux, mais fragile, car l’expérience montre que cette dynamique se brise aisément. Il faut toujours être attentif, réactif... en un mot prendre le plus grand soin de cette liste.

Voici une copie d’écran des mails du projet Tracenpoche. Comme on peut le constater, il y en a plus de cinq mille et concernent de nombreux sujets....

Deux années de développement intense furent nécessaires pour améliorer les fonctionnalités du logiciel.

Parmi elles, on peut citer :

• Macros

• Mode Pas à Pas

• Gestion plus fine des intersections

• OOoTep

• Changement d’état

• Boucles

• Variables complexes

• Variables conditionnelles

• Point aimanté

• Aperçu de la construction en cours

• Tracenpoche multilingue

• TexteMath

OOoTep est un outil très particulier : il permet d’insérer des figures Tracenpoche dans OpenOffice.org Writer. Une fois une figure insérée, il y a la possibilité d’éditer à nouveau le source de la figure, c’est-à-dire son script, afin d’éventuellement la modifier à nouveau. C’est Gilles Daurat (auteur de l’extension mathématiques GDMath pour OOo) qui a développé ce module à l’aide des commandes de dessin du Basic d’OpenOffice. Pour cela, il utilisait un script « spécial » adapté du script Tracenpoche que nous lui fournissions, et contenant toutes les coordonnées nécessaires à la construction des différents composants la figure dans OpenOffice.

Les variables de Tracenpoche ont nécessité un gros travail de développement puisqu’il est possible de saisir par exemple ce calcul :

var rapport = AB/v*cos(DEF) ;

Dans une même expression mathématique, on trouve des variables définies dans le script (ici v) et des variables géométriques (AB pour la longueur du segment [AB], DEF pour une mesure de l’angle DEF).

Les varsi combinés avec la fonction µ ont posé de sérieux problèmes de programmation et constituaient pour nous de vrais défis ! Voilà en quoi ils consistent.

Un varsi est une variable spéciale prenant telle ou telle valeur selon que telle ou telle condition est réalisée ou non. Par exemple, voici deux disques et un point M.

La commande varsi z = [AM<=3,[BM<=4,1,0],0] 0  ; permet de savoir si M appartient aux deux disques ou non. Si c’est le cas, alors la variable sera égale à 1 (0 dans le cas contraire).

Ensuite si on combine cet objet avec la fonction µ (héritée de Geoplan car réclamée par des utilisateurs) comme ceci :

var trAMB = µ(z)polygone(A,M,B) ;

alors le triangle trAMB ne sera construit que si la variable z vaut 1 autrement dit c’est M appartient aux deux disques.

Le µ(z), présent devant la définition de l’objet, conditionne donc sa construction.

Il serait hélas trop long d’énumérer toutes les fonctionnalités intéressantes.
Mais vous les trouverez sur le site, dans les rubriques aides et ressources. De très nombreux exemples y sont proposés. Voici par exemple la page présentant les  varsi .

Ce qui nous semble intéressant de faire remarquer, c’est le problème de la complexification croissante dans le développement d’un logiciel. Les premières semaines voient un développement très rapide puis les choses se ralentissement très sérieusement par la suite pour deux raisons.

Tout d’abord parce que souvent l’on aborde les points les plus difficiles dans un second temps, en réservant pour le début les éléments « faciles » à implémenter. Ensuite parce que le programme grandit en se complexifiant. Les éléments nouveaux entrent parfois, sans que l’on sache forcément pourquoi tout de suite, en contradiction avec le reste. Quand le programme atteint par exemple 30 000 lignes, et que l’on modifie en profondeur le code, comme cela a par exemple été le cas lorsque nous avons implémenté les macros et les boucles, alors il faut s’attendre à de très sérieuses difficultés, ce qui n’a évidemment pas manqué d’être le cas !

C’est dans ces moments que l’on voit que le programme n’a pas été suffisamment bien pensé au départ, mais comment faire autrement ?

Il y a aussi la résolution des bugs. Il faut savoir que programmer c’est passer au moins la moitié de son temps à corriger des bugs. Il n’est pas facile d’écrire 50 lignes de code correct d’une traite... On saisit les 50 lignes et on corrige ce qui ne va pas. Or si cela se fait très rapidement au départ, les choses peuvent parfois se gâter quand la taille du programme grandit. C’est pour cette raison qu’on conseille à tous les jeune programmeurs de programmer des modules, des fonctions, afin de découper leur programme en sections élémentaires, chacune jouant un rôle précis. Comme si cela ne suffisait pas, les outils de debogage livrés avec Flash nous semblant insuffisants, nous deboggions donc à l’ « ancienne », c’est à dire en glissant des traces un peu partout dans le code (concrètement on demandait l’affichage de certaines variables dans une fenêtre sortie).

Emmanuel et moi étions bien conscients de cela ; malgré tout la résolution de bugs reste une tâche quotidienne. Puis un jour, nous sommes tombés sur un plantage de Tracenpoche qui venait régulièrement mais aléatoirement. Et pour la première fois, nous n’avons pas trouvé l’origine du problème, les techniques habituelles de traque de bugs étant toutes successivement mises en échec... Au bout d’un an, j’en étais à me demander si ce n’était pas un bug de Flash, quand, tout à fait par hasard, dans une fonction très importante du programme (celle qui à partir du script construit l’arbre de tous les objets), je remarquai une ligne de code bizarre... et c’était l’origine du bug.

Donc chaque ajout, chaque fonctionnalité supplémentaire demande davantage de temps, à moins d’avoir parfaitement conçu et pensé pour les cinq ans à venir, la structure du programme. Mais on ne pense pas à tout au début, loin de là. J’en donne un dernier exemple. Tracenpoche ne permet pas la construction de plusieurs figures communiquant entre elles, via plusieurs onglets par exemple. Or cela aurait été très utile : par exemple d’un côté la figure, dans la seconde les textes et les paramètres et dans la troisième une courbe représentative d’une grandeur étudiée dans la première figure. Ajouter cette fonctionnalité maintenant est extrêmement coûteux en temps car il faudrait reprendre tout le code. Si nous avions envisagé dès le départ cette fonctionnalité les choses auraient été beaucoup plus simples.

Début 2007, on pouvait considérer que le logiciel était abouti.

Il restait malgré tout quelques questions de fond concernant les orientations futures.

La première était la 3D. Implémenter de la vraie 3D, avec traitement des parties vues et cachées d’objets non convexes, demande un travail considérable. Nous n’avons même pas essayé, faute de temps suffisant.

La seconde concernait l’implémentation d’un langage script dans la zone script. Nous avions implémenté certaines boucles. Le SI pouvait parfois être simulé à l’aide d’une utilisation astucieuse de la fonction µ(). Cependant, l’idéal aurait été de pouvoir écrire un algorithme complet dans la zone script. D’ailleurs certains logiciels le permettent, comme Carmetal par exemple. La raison est que le langage Java (et le langage C) disposent d’une fonction extraordinaire qui est la fonction eval. Carmetal utilise un outil appelé Rhino pour exécuter un script, peut-être en est-il de même pour GeoGebra.

Toujours est-il qu’avec ces technologies, il devient possible de saisir un programme dans une grande zone de texte, puis de demander au compilateur de l’évaluer, de l’exécuter, comme si ces lignes avaient été écrites dans le programme même ! Hélas, cette technologie n’existe pas sous Flash.

Derrière tout cela se pose une question qui gagne en importance avec le temps : est-il pertinent de poursuivre la programmation de Tracenpoche en Flash, sachant que tout développement, toute amélioration substantielle, demanderait un temps de plus en plus conséquent ? Ce logiciel ne remplit-il pas son office dès lors qu’on l’utilise principalement au collège ?

Si on ajoute à cela le problème de l’avenir de Flash, la question devient vraiment sérieuse.

A ces questions, s’ajoutait en ce qui nous concerne, le problème de manque de temps. Pour Emmanuel, outre d’autres projets (commun comme CasenPoche par ex), les engagements dans son collège comme personne ressource informatique devenaient lourds avec la montée en puissance du réseau pédagogique, sa participation à l’IREM de Lille étant aussi prenante. Pour moi, mon engagement au sein du CA de l’association allait croissant (j’étais vice président de novembre 2005 à novembre 2008, puis ensuite président). Il devenait de plus en plus difficile de concilier ces deux engagements.

Ce qui fait que depuis 2007-2008, Tracenpoche vivote, avec quelques corrections de bugs épisodiques, et microscopiques ajouts.

Aujourd’hui, Sésamath s’oriente vers le tout JavaScript et html, .
Ce projet, appelé J3P , permettra de développer des ressources de type Mathenpoche, en HTML et Javascript. Plus global, il s’appuiera sur des modules existants ou actuellement en développement par différentes équipes ou personnes qui croient en la mise à disposition d’outils puissants et libres au service de l’enseignement des mathématiques. En ce qui concerne la géométrie dynamique, il permettra d’insérer dans des ressources, à l’instar de TepNoyau, des figures grâce à des outils comme JSXGraph, ou encore la version (future) javascript de GeoGebra.

PS :
Merci à Emmanuel (Ostenne) pour son aide et sa précieuse relecture de cet article.