Rudolf Bkouche vient de publier un article intitulé Des tice dans l'enseignement des mathématiques. Je ne suis pas trop au courant du curriculum français au regard des mathématiques. Mais la critique de l'auteur par rapport à l'intégration (attention, ce mot n'est jamais utilisé dans l'article) des TIC en maths est intéressante.

D'abord quelques citations :
  • Le terme « formation », qui tend aujourd'hui, à remplacer le terme « enseignement », n'est pas anodin, il signifie qu'on forme la matière humaine comme les métallurgistes donnent forme au métal en fusion pour construire un objet fini. (P.4)
  • [...] le culte de l'évaluation est devenu l'un des premiers obstacles à l'enseignement. (P.5)
  • [...] l'institution, soucieuse de réussite des élèves, ce qu'on appelle aujourd'hui l'obligation de résultats [...]. (P.7)
  • L'usage à tout va de ces machines a conduit à deux attitudes opposées que nous pourrions appeler la technolâtrie et la technophobie. (P.12)
Passé outre quelques expressions cyniques du genre « thuriféraires » (p.1) et « poncifs » (p.12) de l'informatique pédagogique qui encadrent le texte, on peut s'attarder sur l'idée de l'article qui est assez répandue chez plusieurs enseignants de maths : pour comprendre, tu dois pratiquer. Dans ce contexte, l'ordinateur peut apparaître comme une menace pédagogique, car plusieurs logiciels sont maintenant capables de prendre la place de l'élève qui doit « pratiquer ». Pour M. Bkouche, sens et technique sont intimement liés. Pour lui, par exemple, la compréhension des opérations est inséparable de leur pratique.

Voir un ordinateur d'abord comme un objet technique amène, je crois, ce genre de réflexions. Mais l'ordinateur n'est pas qu'un objet technique. Et il me semble que depuis le début des années 80, des hommes comme Seymour Papert (Mindstoms), Mitchel Resnick et Hal Abelson (Turtle Geometry) entre autres l'ont très bien démontré : l'ordinateur utilisé comme machine de programmation par les élèves leur permet de développer des « idées puissantes ». Cet aspect est complètement absent de l'article de M. Bkouche.

Quelques exemples suffiront, je pense, à monter toute la force d'une approche de la mathématique à l'aide d'un ordinateur.

1. Les nombres décimaux

En troisième année, les enfants ont 8 ans et n'ont pas encore appris le concept de nombre décimal.

Dans un projet Scratch, les enfants doivent animer un personnage. Pour ce faire, le lutin (c'est un objet) prend, disons, 2 formes différentes. (Dans Scratch, on les appelle des costumes). Le lutin, en exécutant une boucle, modifiera son costume et, ainsi, donnera l'illusion d'une animation.

Cependant, les choses se corsent et tout ne va pas comme on le voudrait. En effet, le lutin change beaucoup trop vite de costume ce qui enlève un peu de réalisme à l'animation. L'enfant doit donc ralentir le passage d'un costume à l'autre. Il le fait à l'aide de la brique ATTENDRE qui, par défaut, est initialisée à 1 seconde.

Mais attendre une seconde entre chaque changement de costume rend l'animation beaucoup trop lente. Cependant, après plusieurs expériences, l'enfant va sentir qu'il doit y avoir quelque chose entre 0 et 1. Le besoin d'une nouvelle catégorie de nombres est alors créé.

2. Les angles

Le passage du tracé du carré au tracé du triangle est un questionnement classique en LOGO. Comme j'en ai déjà discuté récemment, je réfère le lecteur intéressé au billet en question.

3. Les entiers

Un peu de la même manière qu'on peut susciter un certain besoin des nombres décimaux, on peut le faire pour les entiers. En Scratch, la brique « avancer de ... pas » permet d'avancer un lutin. Assez rapidement, l'élève voudra que son lutin puisse aussi reculer. Or, aucune brique reculer n'existe. Vous aurez compris qu'il suffit d'avancer d'un nombre négatif de pas.

On peut alors assez facilement amener l'élève à opérer sur ces nombres. En effet, par défaut, un lutin pointe vers une certaine direction (à droite). Cependant, si on modifier cette option par défaut (par exemple, gauche) et qu'on ordonne au lutin d'avancer d'un nombre négatif de pas, ce dernier ira vers la droite ! Les deux actions, en quelque sorte, se multiplient. Bien sûr, l'enseignant amènera ensuite l'élève plus loin avec, entre autres, le formalisme mathématique associé à tous ces concepts. Je crois que ce formalisme, ayant un ancrage dans le projet personnel de l'élève, sera beaucoup plus simple à faire comprendre.

4. Le concept de variable

L'algèbre élémentaire n'est qu'une généralisation utile de l'arithmétique. Au lieu de dire le nombre 2, on parle d'un nombre quelconque. Via un projet de programmation informatique, il est très aisé d'introduire le concept de variable, car on désire généralement de la flexibilité. Par exemple, faire un carré de côté 100, puis un autre de côté 101, et un autre de côté 102, etc. est un peu fastidieux. Au lieu de cela, on crée un carré de longueur variable, et on situe la variable dans un intervalle choisi.

Puis, assez rapidement, l'élève utilisera à son insu la notion de « fonction » (concept d'entrée/sortie) et ce, encore une fois, par nécessité pratique. Bien sûr, l'enseignant devra monter à l'élève comment formaliser la chose, mais, au moins, l'élève comprendra l'origine et la force et la nécessité de cette notion.

On pourrait continuer avec plusieurs autres idées mathématiques où la programmation informatique arrive au secours de l'enseignant en plaçant l'élève dans des contextes qui feront émerger des concepts mathématiques essentiels. Ainsi, les mathématiques feront sens pour l'élève. L'ancrage des apprentissages se faisant dans des projets propres à l'élève, il me semble que ces apprentissages auront beaucoup plus de chances de garder une certaine permanence dans le cerveau des enfants.

L'article de M. Bkouche occulte complètement cet aspect essentiel de l'informatique pédagogique. Bien sûr, on peut se servir de l'informatique pour pratiquer des concepts, mais la grande force de l'informatique est surtout de permettre la (re)découverte de concepts fondamentaux. Évidemment, il faut les bons logiciels pour ce faire ; il faut aussi un pédagogue d'abord centré sur l'élève et non sur le programme à passer ; de plus, il est bien certain qu'il faut faire un certain deuil de la hiérarchisation des connaissances.

Les erreurs du passé

Le constructionnisme associé au LOGO a été (et il l'est toujours) très mal compris par les pédagogues. Plusieurs le dénaturaient. Comme, par exemple, ce conseiller pédagogique de l'époque qui rédigea un manuel de l'élève rempli d'instructions que l'élève devait suivre pas à pas. Pour moi, on peut apprendre un langage en construisant son projet. L'idée principale ici étant de permettre à l'élève de construire « quelque chose » de manière à ce qu'il puisse s'appuyer sur sa construction pour démontrer et expliquer les différents processus qu'il a utilisés pendant sa réalisation.

Il ne s'agit donc plus ici pour un enseignant de transmettre une certaine matière et de la vérifier à l'aide d'un examen mais bien de laisser l'élève « apprendre » pendant la réalisation de son projet.

La mode LOGO passée, certains penseurs de l'informatique pédagogique ont décidé qu'au Québec, il suffisait de montrer aux enseignants à programmer en BASIC. Cela pour leur permettre d'écrire des logiciels de type exerciseurs pour les élèves. À l'époque, plusieurs enseignants craignaient que l'ordinateur, un jour, prenne « leur place ». Il ne faut pas oublier qu'on était dans les beaux jours de l'enseignement par objectifs. Or, on imaginait assez bien une machine qui enseignerait dans ce mode : (voix de robot) Élève, fais étape 1 ; Élève, vérifie étape 1 ; Désolé ! Élève refait étape 2 avec autres exercices ; Élèves, revérifie ; Bravo ! Élève, fais étape 2, etc.

Ce fut un échec total. Certains ont bien acquis une attestation universitaire APO, (application pédagogique de l'ordinateur), mais ils ont à peu près tous mis leur diplôme dans le tiroir et sont retournés à la bonne vieille tradition : j'enseigne, tu écoutes, tu fais les exercices, je te teste, et on recommence : j'enseigne, tu écoutes,... Fort peu ont remarqué qu'en programmant, ils apprenaient ! Et donc, fort peu ont eu l'idée d'utiliser de faire utiliser la programmation par les élèves ! Il faut dire qu'il y en avait une bonne quantité qui avait été complètement écoeurée par les exercices stupides que l'université imposait. Donc, personne ne comprenait la force de l'informatique pédagogique, car on l'associait à de l'enseignement programmé.

Et aujourd'hui ?

Quelques personnes croient toujours que l'ordinateur doit être dans les mains des élèves pour qu'ainsi, ils demeurent actifs dans leurs apprentissages. Mais force est de constater que cette croyance n'est pas très répandue ; on gaspille actuellement des milliers de dollars à acheter des tableaux blancs interactifs électroniques au lieu d'acheter des ordinateurs qui seraient disponibles et utilisables en tout temps par les élèves.

Pour la grande majorité des enseignants, un élève qui utilise une suite bureautique est un élève qui intègre les TIC. Pourquoi ? Parce que les enseignants, les directeurs d'écoles et les conseillers pédagogiques n'ont pas encore appris à détecter ce que les élèves apprennent avec les TIC. On se contente donc de penser papier à l'aide d'un ordinateur. Et, ne sachant observer les apprentissages des élèves, ils peuvent difficilement en rendre compte à l'élève lui-même, à ses parents et aux administrateurs scolaires. Cela est le grand malheur. Et cela est sans doute l'apprentissage qu'ils devront le plus rapidement possible réaliser. Sinon, je ne donne pas cher de l'école. Car la réussite des élèves n'est pas, comme le dit M. Bkouche, une obligation de résultats. D'après moi, un élève qui réussit est un élève qui prend conscience des forces et des défis dans les apprentissages qu'il réalise et des processus qu'il actualise quand il apprend.