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
A) Introduction
La réforme du collège m’a conduit à m’intéresser à la programmation visuelle, a priori fort éloignée de mes préoccupations en IUT. Mais petit à petit, je me suis rendu compte qu’elle pouvait m’être utile à divers stades du module d’algorithmique que j’enseigne en première année, point que je développerai dans la première partie de cet article.
La création, par A. Busser et F. Tobé, de l’extension Sofus [1] de Blockly est le facteur déclenchant qui m’a conduit cette année à intégrer la programmation visuelle dans mes enseignements :
- un premier atout est sa tortue, qui me permet de rendre plus attractif et concret l’apprentissage des sous-programmes, sans pour autant avoir à introduire la syntaxe Logo.
- un second atout est d’inciter mes étudiants à utiliser des notations algorithmiques intuitives telles qu’augmenter ou diminuer une variable, ce qu’ils acceptent plus volontiers s’ils ont à leur disposition un environnement qui les implémente.
En « empruntant » la programmation visuelle à la réforme du collège, je ne baisse pas mes exigences en matière de contenu, mais profite d’une opportunité pour rendre plus abordable l’enseignement de l’algorithmique et de la programmation : pourquoi en effet faire compliqué quand on peut faire simple ? Normalement, c’est un principe qui devrait aller de soi en pédagogie. Or, quand je regarde certains aspects de la réforme du collège, j’ai parfois l’impression d’assister au mouvement inverse : donc, je consacrerai la seconde partie de l’article à la réforme du collège, dans l’espoir d’inciter mes collègues de collège à privilégier la simplicité pour le plus grand bien de leurs élèves.
B) Utilisation de la programmation visuelle en IUT
Objectifs
J’enseigne depuis de nombreuses années un module d’initiation à l’algorithmique en IUT, dans une spécialité (Statistique et Informatique Décisionnelle) où l’informatique occupe une place importante. Pourtant, je n’ai pas hésité cette année à introduire la programmation visuelle, alors que beaucoup de gens considèrent qu’elle est destinée aux enfants ou aux jeunes adolescents.
Si j’ai introduit la programmation visuelle, c’est bien sûr parce que j’estime qu’elle peut faciliter l’apprentissage de l’algorithmique également en IUT. C’est aussi parce qu’elle permet de rompre la routine, et est plus attractive que la programmation dans un langage textuel « austère » (Javascool).
Si je l’ai fait cette année, c’est parce que j’avais désormais l’opportunité de le faire, avec notamment l’apparition de l’extension Sofus de Blockly. Comme elle est intégrée dans ma suite logicielle Mathém@ALGO, j’ai pu compenser partiellement le temps alloué à la programmation visuelle en gagnant du temps [2] dans le codage en Javascool.
Si je parle de cet enseignement en IUT à un public composé essentiellement d’enseignants du secondaire, c’est pour légitimer la recommandation suivante : n’allez pas trop vite en besogne, certaines notions citées dans les programmes officiels du secondaire posant problème en IUT, alors que je dispose d’un volume horaire bien plus élevé. Ma recommandation s’adresse tout particulièrement aux enseignants de collège, pour qui l’enseignement du codage est une nouveauté, et qui risquent de faire un excès de zèle par manque de recul pédagogique.
Organisation du module
Chaque semaine, les étudiants ont eu une heure de cours magistral en amphithéâtre, 1 heure 30 de travaux dirigés (par groupes d’au plus 30 étudiants, dans une salle sans ordinateurs) et 1 heure 30 de travaux pratiques (demi-groupes d’au plus 15 étudiants, dans une salle avec ordinateurs).
Pour fixer les idées, j’ai suivi approximativement la progression pédagogique suivante :
- semaine 1 : affectations et entrées-sorties
- semaine 2 : instructions conditionnelles
- semaines 3 à 4 : boucles
- semaine 5 à 6 : sous-programmes
- semaines 7 à 8 : tableaux
- semaines 9 à 10 : exercices de synthèse
Cours
Bien évidemment, j’ai avant tout utilisé la programmation visuelle lors des séances de travaux pratiques (soit 1 heure 30 par semaine, avec ordinateur). Mais elle a aussi impacté dans une moindre mesure mes cours.
- quelques documents distribués en cours
Jusqu’à présent, mes exemples étaient présentés avec deux notations : algorithmique et Javascool. J’ajouterai qu’aux yeux de beaucoup de mes étudiants, seul Javascool était « crédible » car exécutable.
L’introduction de la programmation visuelle m’a permis de rendre plus « crédible » et attractif l’enseignement de l’algorithmique : en effet, un programme visuel peut être considéré comme étant un algorithme exécutable, dont les notations sont parfois plus intuitives que celles couramment utilisées en algorithmique !
Pour illustrer ceci, je vais reprendre un exemple que j’avais étudié dans le N°44, qui conduit à chercher le plus petit entier N à partir duquel la somme des N premiers entiers dépasse un seuil donné :
En partie gauche, l’algorithme est exprimé avec des notations classiques. Il est certes relativement intelligible mais, contrairement au lycée, je ne demande pas à mes étudiants d’exécuter un algorithme donné ou de compléter un algorithme à trous, mais de résoudre un problème : j’ai donc fait évoluer mes notations pour les rendre plus intuitives, en introduisant des notations telles qu’augmenter (diminuer...), sans pour autant interdire leur équivalent plus technique [3] avec une affectation.
En d’autres termes, j’adopte des notations algorithmiques plus intuitives pour essayer de rendre mes étudiants plus créatifs et efficaces pour résoudre les exercices posés.
Travaux pratiques
Pendant mes dix séances de travaux pratiques, mes étudiants ont programmé soit avec Blockly, soit avec Javascool. Trois séances ont été consacrées à la programmation visuelle :
- séance 1 : premières applications avec la tortue
- séance 2 : instructions conditionnelles
- séance 5 : sous-programmes avec la tortue
- séances 1 à 6
De nombreux exemples avec la tortue ont été piochés dans la vaste bibliothèque de ressources pédagogiques [4] proposée par l’IREM de Paris-Nord.
Lors de la séance 1 de travaux pratiques, certains exercices proposés avaient été traités préalablement sur papier en travaux dirigés, ce qui permettait aux étudiants de se concentrer sur la manipulation de blocs qu’ils découvraient. En voici un échantillon :
Ces exemples ont été repris en séance 5 avec une procédure Triangle. Lors de cette séance, j’ai tenu à proposer un exercice plus spectaculaire et pour lequel l’usage de sous-programmes (ici un parallélogramme plein [5]) est quasi-indispensable :
La séance 2, consacrée aux instructions conditionnelles, n’utilisait pas la tortue. Elle reprenait quelques exemples traités en travaux dirigés ou en cours, et en proposait aussi de nouveaux bien évidemment : bref, la routine d’une séance de travaux pratiques ordinaire comme j’en faisais les années précédentes avec Javascool.
Javascool
Il reste sept séances de travaux pratiques consacrées à Javascool. Au fait, pourquoi ai-je choisi Javascool depuis quatre ans ? Cela résulte en partie d’un changement de programme officiel, qui m’a conduit en concertation avec un collègue à chercher à gagner du temps dans un module de seconde année consacré à la programmation objet et illustré en Java.
D’autre part, Javascool était un langage qui avait été développé spécialement pour l’option ISN de terminale, avec des extensions (appelées « proglets ») dont une tortue. Enfin, j’avais décidé d’abandonner Larp, un pseudo-code exécutable qui donnait toute satisfaction … si ce n’est que de nombreux étudiants n’arrivaient plus à faire la distinction entre algorithmique et programmation !
Avec Javascool, ils font désormais très bien la différence grâce à un compilateur intraitable quand il manque un point virgule, une accolade fermante … et dont les messages d’erreurs ne sont pas toujours très explicites ! C’est alors l’occasion d’en profiter pour insister sur l’intérêt d’une indentation claire dans les programmes : non seulement cela aide à les concevoir, mais cela se révèle aussi très utile a posteriori pour détecter les erreurs.
Le problème est que, comme je le constate encore en seconde année d’IUT, l’indentation n’est pas une notion intuitive pour tous les étudiants. Donc, pour ceux qui sont fâchés avec les indentations, je leur fais utiliser le reformateur de code disponible dans l’environnement Javascool.
Les années passées, j’utilisais la proglet tortue de Javascool dans une à une séance et demi, notamment pour montrer l’intérêt des sous-programmes. Puisque j’ai introduit cette année l’extension Sofus de Blockly, j’ai donc abandonné sans regret la proglet tortue : en effet, l’intérêt pédagogique de l’approche tortue était dramatiquement amoindri par les contraintes du langage Javascool (syntaxe, compilation, détection d’erreurs...).
C) Codage au collège : privilégiez la simplicité !
Introduction
Dans le N°48 de MathémaTICE, J. Pavageau a présenté son expérimentation avec GéoTortue [6] en classe de cinquième et a lancé des pistes sur l’avenir de l’algorithmique au collège. Il montre que la « bonne vieille tortue » est tout à fait compatible avec les nouveaux enseignements de collège, tout en craignant que ses atouts soient négligés en pratique au détriment de « personnages de Scratch ou de robots ». Comme c’est une crainte que je partage aussi, j’argumenterai moi aussi en faveur de cette « bonne vieille tortue ».
Je m’intéresserai également au bien fondé de l’utilisation d’un langage textuel, en plus d’un ou plusieurs langages visuels. Cette question me conduira à évoquer l’ouvrage de cycle 4 de Sésamath et, plus particulièrement, les exemples Python qui y sont présentés.
Vive la tortue !
J. Pavageau a utilisé le logiciel GéoTortue, une des nombreuses implémentations de la tortue Logo. Pour ma part, je n’ai pas testé GéoTortue : je milite pour l’utilisation de la tortue en général, et la tortue de l’extension Sofus de Blockly m’a suffi amplement pour mes besoins en IUT.
GéoTortue a été développé par l’IREM de Paris-Nord, qui propose une bibliothèque très fournie d’activités, toutes éprouvées en classe. J’y ai puisé quelques exemples pour mes enseignements en IUT, tout comme J. Pavageau qui a expérimenté en classe de 5ième plusieurs activités relatives aux parallélogrammes et aux angles.
Comme l’explique l’IREM de Paris-Nord [7], la tortue facilite l’enseignement de notions algorithmiques non triviales, sans les introduire artificiellement :
[La tortue] initie l’élève à la notion de procédure ou d’algorithme : il apprend vite à utiliser des boucles simples (la commande « répète »), et surtout à écrire des procédures, et ce dès le CM2... Et rien n’est introduit gratuitement : les notions mathématiques apparaissent comme une réponse à un besoin des élèves, lorsqu’ils butent sur la réalisation d’un dessin. Ainsi, la variable devient assez vite un outil indispensable, que l’élève emploie de lui-même pour réaliser certains dessins qui seraient bien trop longs, voire impossibles à réaliser autrement.
Un autre intérêt de la tortue est qu’elle est « propice à provoquer une attitude de recherche », comme le signale l’IREM de Paris-Nord qui développe ensuite ce point de vue pédagogique que je partage pleinement :
La situation typique est la suivante : on donne à l’élève un dessin qu’il doit faire reproduire par la tortue. Il doit s’agir d’un dessin figuratif, d’un joli motif, d’une frise... bref, de tout sauf d’une figure austère : l’expérience a prouvé que la très grande majorité des élèves se livrent alors de bon coeur à ce genre d’activité, dans laquelle ils ont la liberté de faire des essais et se passent de l’enseignant pour les évaluer.
Donc, utilisez la tortue sans modération [8], il n’y a aucune contre-indication pour vos élèves contrairement à certaines autres possibilités du programme officiel, utopiques au collège ou d’une utilité pédagogique discutable.
Manuel de cycle 4
Un chapitre unique est consacré au thème E (Algorithmique et programmation) du programme officiel de cycle 4. Deux langages (Scratch et Python) sont présentés, en plus des notations algorithmiques.
Ce chapitre très dense est découpé en quatre parties : activités de découverte (dont des activités débranchées), cours, exercices (partie intitulée « je m’entraîne ») et projets. Je me suis penché plus particulièrement sur la partie principale, un cours d’une quinzaine de pages dans lequel les auteurs réussissent le tour de force de parler de variables, de tests, de boucles (Pour, Tantque et répéter n fois), d’évènements et de scripts simultanés, de tableaux (à une ou deux dimensions) et de sous-programmes (procédures et fonctions). En plus, les exemples sont illustrés en notations algorithmiques, en Scratch et en Python !
Cette densité me laisse pantois puisque j’y retrouve toutes les rubriques de mon enseignement d’IUT, sans la moindre impasse. Mais elle ne m’étonne qu’à moitié puisque le programme officiel suggère d’aborder toutes ces notions, sans l’imposer toutefois puisque l’objectif (ça me rassure) n’est pas de former des informaticiens au collège.
Ce qui me rassure moins, c’est de me demander quelle interprétation mes collègues de collège vont faire du programme officiel et de ce chapitre de manuel de cycle 4 : ce chapitre ne risque-t-il pas d’inciter des néophytes à un excès de zèle ? Comme je le crains, il m’arrivera donc parfois de conseiller aux lecteurs de ne pas suivre certains exemples du manuel.
Ce sont juste des conseils de quelqu’un qui a l’expérience de l’enseignement de l’algorithmique, qui a de ce fait découvert des difficultés de compréhension inattendues … ce que vous avez probablement déjà expérimenté dans vos enseignements de mathématiques ! Je ne cherche nullement à faire une analyse critique d’un manuel qui s’en tire relativement bien pour faire face aux aberrations du programme officiel, à l’exception notable de la partie consacrée aux sous-programmes : pour traiter de façon plus progressive et pédagogique les nombreux points abordés dans le chapitre, il faudrait un manuel et des enseignements spécifiques...
Sous-programmes
Le manuel introduit deux types de sous-programmes (procédures et fonctions), sans établir clairement la différence fondamentale entre les deux. Il y a même un exemple du cours qui me plonge dans un abîme de perplexité :
Ne voyant pas d’instruction « Retourner » pour le langage algorithmique, j’en déduis que le sous-programme « Dem » est une procédure, d’autant qu’il est ensuite utilisé en tant que tel dans l’algorithme principal. Mais quand je jette un œil au programme Python, je vois un « return » qui prouve que le sous-programme est une fonction … tout en étant utilisé comme si c’était une procédure [9] dans le programme principal !
Je suis d’autant plus perplexe sur le « return » qu’une fonction n’a ici aucun intérêt pratique : elle ne peut que retourner le second paramètre (valeur) puisque la saisie de la variable retournée (N) est effectuée tant que N est différent de valeur !
Je suis encore plus perplexe quand je lis les commentaires bien énigmatiques accompagnant la version Scratch : « avec Scratch, la fonction ne peut pas retourner une valeur, on doit utiliser une variable ». Les auteurs veulent-ils dire que puisqu’on ne peut pas définir de fonctions en Scratch, on doit utiliser une variable globale pour transmettre une information au programme principal ?
A l’arrivée, je suis désolé de le dire, je ne peux que conseiller aux lecteurs de ne surtout pas enseigner les sous-programmes comme dans le manuel. Alors, comment bien faire percevoir aux collégiens la distinction entre fonctions et procédures, me direz-vous ?
La solution la plus sage serait, à mon avis, de ne parler que de procédures au collège, d’autant qu’elles suffisent pour traiter la quasi-totalité des applications utiles au collège. Si vous n’êtes pas convaincu, je vous invite à vous poser la question suivante : pourquoi les concepteurs de Scratch, un logiciel dont le succès est incontestable, ont-ils décidé de ne pas permettre la création de fonctions ?
Au collège, je préfère des élèves ayant parfaitement assimilé le concept de procédure à des élèves faisant la confusion entre fonctions et procédures, comme c’est malheureusement encore le cas pour certains étudiants de seconde année d’IUT.
Listes et tableaux
L’utilisation des tableaux me paraît prématurée au collège, d’autant qu’il y a plus prioritaire. Et puis, il faut bien laisser un peu de grain à moudre aux enseignants de lycée !
Dans le manuel, plusieurs exemples du cours me confortent dans cette conviction :
Quant aux exercices, ils me conviennent bien … pour mes enseignements d’IUT ! Même s’il y en a certains qui me semblent accessibles au collège, leur thématique ne me paraît guère palpitante : donc, pourquoi parler de tableaux au collège, alors que le programme officiel ne l’impose pas et qu’on manque de temps pour bien le faire ?
Et pour des exercices comme le N°48, je me suis demandé si les auteurs du manuel n’avaient pas l’habitude (en mathématiques) d’enseigner à des élèves triés sur le volet !
Il est demandé aux élèves de corriger ces programmes, pour qu’ils génèrent 10 entiers aléatoires distincts. Or, si ma mémoire est bonne, on recommande actuellement en lycée d’éviter d’imbriquer les boucles. En plus, la boucle intérieure qui recherche si le dernier nombre aléatoire engendré a déjà été engendré auparavant, n’a rien d’une évidence [10].
D) Conclusion
En mathématiques, serait-il possible d’enseigner au collège un module d’IUT, en respectant le programme officiel de collège ? La réponse est bien évidemment non, car les différences de contenu sont très nettes.
Mais en algorithmique, les contenus sont à la base les mêmes : variables, instructions conditionnelles, boucles et sous-programmes. Donc, il serait indispensable que le programme officiel de collège se démarque clairement de celui d’un module d’IUT, avec notamment un moindre niveau de difficulté parfaitement établi. C’est a priori le cas puisque l’attendu de fin de cycle 4 est « écrire, mettre au point et exécuter un programme simple », mais on peut fortement en douter quand on consulte Eduscol [12] :
Cet enseignement a pour objectif de développer chez les élèves les compétences suivantes :
- décomposition : analyser un problème compliqué, le découper en sous-problèmes, en sous-tâches ;
- reconnaissance de schémas : reconnaître des schémas, des configurations, des invariants, des répétitions, mettre en évidence des interactions ;
- généralisation et abstraction : repérer les enchaînements logiques et les traduire en instructions conditionnelles, traduire les schémas récurrents en boucles, concevoir des méthodes liées à des objets qui traduisent le comportement attendu ;
- conception d’algorithme : écrire des solutions modulaires à un problème donné, réutiliser des algorithmes déjà programmés, programmer des instructions déclenchées par des évènements, concevoir des algorithmes se déroulant en parallèle.
Tout cette complexité pour arriver à écrire des programmes simples en fin de cycle ?! Je recommande au contraire plus de simplicité pour le plus grand bien des collégiens…
Une façon d’y parvenir est d’utiliser cette « bonne vieille tortue », qui a depuis longtemps fait ses preuves en mathématiques et en algorithmique, et pour laquelle l’IREM de Paris-Nord propose de nombreuses ressources pédagogiques testées en classe. En plus, elle a su s’adapter à la modernité, puisqu’on peut maintenant l’utiliser en programmation visuelle sous la forme d’un lutin de Scratch ou, je préfère, comme tortue de l’extension Sofus de Blockly.
Epilogue
A la fin de plusieurs de mes articles précédents, j’ai fait appel à mes deux personnages fictifs Casquette d’informatique et Casquette de mathématiques pour analyser les thèmes que j’avais développés. Cette fois-ci, cela les conduit à organiser un concours avec le logiciel Scratch : y aura-t-il des lecteurs relevant le défi ?
- Pourquoi faire simple quand on peut faire compliqué ?