Les nouvelles technologies pour l’enseignement des mathématiques
Intégration des TICE dans l’enseignement des mathématiques

MathémaTICE, première revue en ligne destinée à promouvoir les TICE à travers l’enseignement des mathématiques.

L’algorithmique en mathématiques au lycée vue d’un IUT
Article mis en ligne le 12 juin 2015
dernière modification le 2 juillet 2017

par Patrick Raffinat

Cet article peut être librement diffusé à l’identique dans la limite d’une utilisation non commerciale suivant la license CC-by-nc-nd http://creativecommons.org/licenses/by-nc-nd/3.0/fr/legalcode.

A) Introduction

Enseignant l’algorithmique en IUT, j’ai tout naturellement été amené à m’intéresser à son introduction au lycée en 2009-2010 : que devrai-je changer dans mes enseignements pour en tenir compte ?

Cela m’a conduit à étudier le contenu des programmes officiels et à consulter de nombreux documents (sujets de bac, formations dans les IREM, articles dans MathemaTICE...) pour tenter de déterminer les connaissances qu’auraient mes futurs étudiants à leur arrivée en IUT.

C’est pourquoi je ferai part dans cet article de mon point de vue sur l’enseignement de l’algorithmique au lycée (hors ISN) et sur la continuité des programmes entre lycée et premier cycle universitaire.

Je détaillerai également quelques choix pédagogiques que je ferais si j’enseignais au lycée : langages, gain de temps dans le codage grâce à la version en ligne de PluriAlgo...

B) Compétences des étudiants à leur arrivée en IUT

A priori

Quand j’ai vu cet extrait du programme officiel de seconde, qui reprend une bonne partie d’un module d’initiation en premier cycle universitaire, j’ai eu deux réactions contradictoires :

  • satisfaction à l’idée de pouvoir faire une initiation plus approfondie, puisque les lycéens auraient donc dès la seconde un solide acquis algorithmique, acquis ne pouvant qu’être renforcé par les années de première et de terminale.
  • regret de devoir changer radicalement mes enseignements, ne pouvant garder des séances dont le contenu paraîtrait trop enfantin à mes futurs étudiants.

En lisant divers documents (formations dans les IREM, articles dans MathemaTICE...), j’ai été conforté dans l’opinion que mes futurs étudiants auraient vraiment un solide bagage algorithmique à leur arrivée en IUT.

Cependant, l’extrême simplicité des sujets de bac m’a rendu perplexe : pourquoi proposer des sujets aussi élémentaires si les lycéens ont réellement de telles bases algorithmiques ?

A posteriori

Le constat n’est guère réjouissant après trois années d’observation : je n’ai quasiment pas eu à adapter mes enseignements, les connaissances algorithmiques de mes étudiants se révélant très modestes à leur arrivée en IUT.

Cela rejoint les observations d’enseignants de l’option ISN  [1] :

En première année d’IUT, je pars toujours du même principe de (quasi) absence de connaissances : quel gâchis !

A la rentrée prochaine, je réviserai peut-être mon postulat si les nouveaux arrivants passent avec succès « l’Algotest » [2] proposé par l’IREM de Strasbourg, mais je n’y crois guère pour des raisons que je développe dans la section suivante.

C) L’algorithmique au lycée

Un compromis économique

J’enseigne dans un DUT STID (Statistique et Informatique Décisionnelle), filière dont les caractéristiques ont été présentées dans le N°39 de MathémaTICE [3].

La répartition des activités entre mathématiques et informatique y est claire, avec des modules de mathématiques, des modules d’informatique et des modules mixtes (programmation statistique, projets tuteurés).

Dans les modules de mathématiques, des outils informatiques (tableur, logiciels de statistique presse-boutons...) sont bien sûr utilisés. Mais il n’y a pas d’algorithmique.

Au lycée, l’algorithmique a été introduite dans une discipline existante, en l’occurrence les mathématiques, pour des raisons qui paraissent plus économiques que pédagogiques.

A l’arrivée, il en résulte un enseignement de l’algorithmique qui n’en n’est pas vraiment un puisqu’on n’y demande pas de concevoir des algorithmes [4], mais de savoir interpréter et coder des algorithmes fournis par les enseignants.

Manque de directives

Le manque de directives (pas de volume horaire spécifique, aucun langage imposé...) n’incite guère les enseignants à développer des activités algorithmiques s’ils manquent de temps en mathématiques ou de formation en algorithmique, d’autant plus que les épreuves de bac sont trop élémentaires.

Le manque de directives est aussi un inutile casse-tête pédagogique. A ce sujet, je me suis demandé quels langages je choisirais si j’enseignais au lycée.

Si j’enseignais en seconde dans le contexte actuel, j’opterais pour AlgoBox malgré la lourdeur de ses notations : en effet, grâce à la fonction F1, j’éviterais l’écueil [5] de devoir définir une fonction dans un langage de programmation. De plus, cette lourdeur ne nuit pas trop à la lisibilité des programmes car ceux-ci sont très courts.

Si j’enseignais en première ou en terminale scientifique, je ferais également de la programmation avec un logiciel scientifique (voir section suivante).

Mes choix seraient donc guidés prioritairement par des objectifs mathématiques et non algorithmiques...

Calculatrice

Le programme officiel de seconde indique que les élèves doivent être « entraînés à réaliser quelques algorithmes à l’aide d’un tableur ou d’un petit programme réalisé sur une calculatrice ou avec un logiciel adapté ». Je suppose que les « ou » sont inclusifs et non exclusifs, car sinon cela voudrait dire qu’une calculatrice n’est pas un logiciel adapté pour programmer !

J’arrête là mon ironie pour déplorer que l’on y suggère d’utiliser une calculatrice programmable : non seulement cela n’apporte rien à l’enseignement de l’algorithmique, mais cela en donne une image peu attractive et faussée.

Logiciels programmables

L’utilisation de logiciels scientifiques (géométrie, calcul formel, statistiques...) est devenue incontournable dans l’enseignement des mathématiques.

On peut y développer de nombreuses activités pédagogiques pertinentes sans programmer. Mais ces logiciels étant généralement programmables et les programmes officiels demandant de faire de l’algorithmique, il est tentant d’y développer des activités combinant programmation et mathématiques.

Cependant, il y a le risque de vouloir trop en faire, ce que j’illustre avec un exemple que j’ai traité dans un article précédent : un algorithme de simulation d’une loi binomiale, prolongé par une illustration graphique du théorème de Moivre-Laplace. L’illustration graphique est à mon avis suffisamment complexe (passage du discret au continu) pour qu’on ne surenchérisse pas dans la difficulté avec un algorithme non trivial, d’autant plus qu’il pouvait être évité [6].

Le paradoxe de cet exemple est qu’on peut aussi renverser le point de vue en ne traitant que la partie algorithmique, parce que l’illustration graphique du théorème de Moivre-Laplace est peut-être trop subtile pour qu’un lycéen moyen puisse en tirer parti : décidément, rien n’est simple avec ces programmes où l’on privilégie les mathématiques expérimentales [7] !

Pour clore ce sujet délicat, je suis favorable à l’enseignement de la programmation avec un logiciel scientifique, à condition de bien choisir ses exemples et de ne pas le faire en seconde. Et, si j’enseignais en première ou terminale scientifique, je pense que je le ferais avec Scilab ou avec la version en ligne de Xcas : je montre comment dans la section suivante.

D) PluriAlgo sous un angle très pragmatique

Introduction

Même si je ne l’avais pas indiqué dans mes deux premiers articles sur PluriAlgo, ceux-ci s’adressaient plutôt à des enseignants de l’option ISN.

La version en ligne de PluriAlgo, introduite dans un troisième article (voir lien), en simplifie notablement l’utilisation, rendant ainsi le logiciel accessible à un plus large public. En outre, depuis la parution de cet article, un cours d’algorithmique a été ajouté dans la documentation afin de renforcer l’attractivité du logiciel.

Donc, si j’enseignais l’algorithmique au lycée, j’utiliserais bien sûr la version en ligne de PluriAlgo ! Par souci d’efficacité, je privilégierais quelques fonctionnalités du logiciel : les entrées-sorties et deux techniques usuelles sur les boucles (sommation et comptage). L’avantage serait triple :

  • apprentissage quasi-immédiat de PluriAlgo.
  • gain de temps dans le codage (voire la résolution) de nombreux algorithmes.
  • mise en relief de quelques points fondamentaux en algorithmique.

Entrées-sorties

Que ce soit au lycée ou en premier cycle universitaire, un algorithme est présenté comme étant un ensemble de traitements qui, à partir d’entrées, produit des sorties.

Dans l’exemple illustré ci-dessus, les entrées sont le prix unitaire d’un article et la quantité achetée, et la sortie est le prix total de l’achat. Le programme obtenu, ici est en AlgoBox, est à gauche.

Un copier-coller permet de récupérer le code pour le placer dans l’éditeur d’AlgoBox, à condition d’y choisir le mode d’édition « éditeur texte ». Il ne reste plus qu’à calculer le prix total, ce qui peut être fait avec le bouton AFFECTER d’AlgoBox :

La même démarche peut être reprise avec plusieurs langages scientifiques (Xcas, Scilab, R et CaRMetal), mais nécessite des adaptations pour Xcas en ligne : voir pdf ci-dessous.

PluriAlgo et la version en ligne de Xcas

Heureusement, ces adaptations (usage de sous-programmes) sont très simples à mettre en œuvre (modification de la valeur de l’option « calculs » de PluriAlgo), ce que j’illustre également pour Scilab : voir pdf ci-dessous.

PluriAlgo et Scilab

Boucles

Les options de l’onglet Boucles de PluriAlgo facilitent le codage de deux techniques (sommation et comptage) couramment utilisées dans les algorithmes mathématiques au lycée.

Par exemple, on obtient ici directement les instructions permettant de compter le nombre de piles (nbPiles) lors d’une simulation de n lancers d’une pièce ayant la probabilité p de tomber sur pile.

Le reste du programme provient de la gestion des entrées-sorties avec PluriAlgo (voir indications).

Corollaire

PluriAlgo facilitant le codage dans plusieurs logiciels scientifiques (Scilab et Xcas notamment), j’espère que cela incitera plus d’enseignants à y développer des activités algorithmiques.

Parmi les logiciels que j’ai étudiés, j’ai une nette préférence pour Scilab puisqu’il combine plusieurs atouts :

  • polyvalent (même s’il n’y a ni géométrie ni calcul formel)
  • ergonomique
  • très bien documenté
  • langage de programmation élégant

J’invite le lecteur qui ne connaîtrait pas un document intitulé « Scilab pour l’enseignement des mathématiques » [8] à le consulter. On y trouve en effet une cinquantaine d’exercices corrigés, transposables à d’autres langages (exemple) ou s’appuyant sur des primitives de Scilab (exemple).

E) Conclusion

Le seul vrai remède aux problèmes évoqués semble être l’introduction de l’informatique en tant que discipline au lycée, ce qu’a réclamé l’Académie des Sciences [9]. En attendant que cela finisse par arriver dans une société de plus en plus numérique, les enseignants de mathématiques devront composer avec les imperfections des programmes actuels (hors ISN).

Il est donc important de les y aider : c’est pourquoi j’ai montré dans la dernière partie de cet article comment gagner facilement du temps dans l’activité de codage grâce à la version en ligne de PluriAlgo. C’est aussi pourquoi j’ai intégré dans la documentation du logiciel un cours d’algorithmique et des exercices corrigés.

Plusieurs logiciels scientifiques (Scilab et Xcas notamment) sont pris en compte par PluriAlgo : cela traduit ma volonté d’encourager le développement d’activités algorithmiques avec ces logiciels en première et terminale scientifiques.

AlgoBox étant couramment utilisé, je l’ai intégré à PluriAlgo pour un autre motif : compléter ses fonctionnalités (boutons Lire, Ecrire, Pour...) avec des fonctionnalités moins « atomiques ». Par exemple, PluriAlgo facilite l’usage de techniques usuelles sur les boucles (sommation, comptage) et permet de traiter en une seule étape les entrées-sorties et les déclarations de variables.

Les autres langages gérés (Javascool, Javascript, Visual Basic, Python...) répondent à des besoins actuels ou passés dans mes enseignements en IUT. Mais je ne les utiliserais pas si j’enseignais en lycée (hors ISN), car mes choix seraient guidés prioritairement par des objectifs mathématiques.