La première réunion rassemblant les développeurs de Mathenpoche et les membres des groupes IREM intéressés (lors du colloque au CRDP de Lille) a montré qu’il existait une réelle volonté de travailler ensemble. Cette volonté commune n’élude pas les difficultés du parcours. En effet, il existe sûrement une grande différence d’approche entre la démarche habituelle d’un groupe IREM et celle des développeurs de Mathenpoche. Gommer cette différence ne permettrait pas d’aboutir à un travail commun réellement efficace. Aussi il semble important, pour les uns et les autres, d’essayer de bien préciser les orientations prises par les développeurs de Mathenpoche pour que les débats qui auront lieu au sein des IREM puissent se dérouler en « connaissance de cause », c’est à dire, en connaissant au mieux l’historique, les finalités, les enjeux.
Pour être viable, le projet Mathenpoche devait répondre à une double injonction :
– Couvrir l’ensemble des programmes et proposer pour chaque notion un choix à l’utilisateur.
– Proposer rapidement des versions fiables et utilisables par les collègues et terminer le logiciel en un temps raisonnable.
L’origine « exercicielle » de Mathenpoche ne doit pas cacher son évolution actuelle.
Sans nul doute, il y aura un module de géométrie dynamique, un traceur de courbe, un tableur, un éditeur de texte mathématiques, un éditeur de figure aux instruments virtuels dans Mathenpoche (pour le calcul formel, il faudra sans doute attendre les extensions au Lycée).
A ce niveau, 2 choses semblent essentielles :
– aller de l’exerciseur vers le logiciel Outil n’a de sens que s’il y a un retour vers l’exerciseur. Ainsi tous ces outils auront une autonomie mais seront exercisés (ou le sont déjà) dans Mathenpoche. C’est important, car cela ouvre considérablement la gamme d’utilisation de ces outils et cela a des conséquences sur leur utilisation réelle et effective (en particulier les logiciels de géométrie dynamique ne sont pas si utilisés que ce que l’on croit… )
– maîtriser le développement intégral de tous ces outils (plutôt que de sous-traiter des outils déjà faits) est la seule solution pour les intégrer les uns aux autres de façon optimale : faire des ponts, changer de registres… les applications sont vastes et encore peu connues, du fait de la segmentation actuelle de tous ces outils.