Dans un article intitulé « Initier les élèves à la pensée informatique et à la programmation avec Scratch », P. Tchounikine explique qu’il y a schématiquement deux façons d’aborder l’enseignement de la pensée informatique : une approche orientée « algorithmique » et une approche orientée « créativité ». Je reprends ici brièvement ses propos :

• Une première approche (et/ou conception) possible de l’enseignement de la pensée informatique est de l’aborder sous l’angle disciplinaire. Le point d’entrée est la discipline informatique telle qu’elle existe (dans l’industrie, dans la recherche), et est enseignée à l’Université. Dans cette approche, et en se focalisant sur le primaire, l’idée centrale est que le cœur de ce qu’il faut enseigner, c’est l’algorithmique et les notions/compétences sous-jacentes (notions d’action, variable, boucle, conditionnelle, etc.).
• Une seconde approche (et/ou conception) possible de l’enseignement de la pensée informatique et de la programmation est de prendre un point d’entrée différent, plus général. L’idée est de placer l’élève en situation de créativité et de proposer l’informatique comme un moyen pour exprimer cette créativité. L’objectif est que les élèves développent ainsi un lien personnel avec l’informatique, que ce soit pour eux une façon de s’exprimer (et, par suite, de penser, de comprendre, en faisant appel aux notions ou façons de faire de l’informatique). Cette approche met l’accent sur d’autres dimensions que l’algorithmique donc.

L’approche « créativité », que j’illustrerai dans la suite de cette section, est l’approche préconisée par les concepteurs de Scratch. Mais P. Tchounikine note que « la plupart des arguments en faveur de l’enseignement de l’informatique et des propositions de programmes que l’on peut lire en France sont plutôt ou essentiellement sous-tendus par l’approche algorithmique » : paradoxal, une fois de plus, puisqu’on n’aurait pas « fortement recommandé » Scratch au collège pour de bonnes raisons pédagogiques ?

Je ne suis nullement en train de prétendre que Scratch ne serait pas un bon langage pour une approche purement « algorithmique ». Toutefois, dans cette optique, d’autres langages sont au moins aussi pertinents, à commencer par Blockly pour lequel ont été développées plusieurs extensions adaptées aux mathématiques [1].

Ce que je veux dire, c’est qu’il est regrettable que Scratch ait été choisi sans qu’on sache réellement intégrer ses atouts dans le système éducatif français. Je pense notamment à certains thèmes abordés en mathématiques au collège (programmation de scripts parallèles, programmation événementielle, jeux) sur lesquels je reviendrai dans la section C.

Un des atouts mis en avant par les concepteurs de Scratch est que ce langage permet de raconter des histoires. De prime abord, on conçoit aisément que Scratch soit très apprécié des enfants, mais le lien avec l’enseignement de la pensée algorithmique est moins évident. Et on devine aisément pourquoi cet atout n’est guère mis en avant dans les programmes officiels : c’est clairement moins « prestigieux » que d’écrire qu’on introduit la programmation parallèle au collège ! Il serait plus honnête intellectuellement de dire que des lutins échangent des messages au cours d’une histoire ou d’un jeu…

Lorsque j’ai tapé « raconter une histoire Scratch » sur un moteur de recherche bien connu, il m’a renvoyé vers une fiche de la formation Class’Code  [2] : c’est la preuve que le sujet est plus sérieux qu’il n’y paraît, et qu’il relève bien de l’apprentissage de la pensée algorithmique. Le moteur de recherche m’a aussi renvoyé vers des projets de CM1/CM2 : c’est la preuve que l’approche « créativité » peut être compatible avec le système éducatif à l’école primaire. Pour sa place au collège, je suis en revanche plus sceptique : j’y reviendrai dans la section C.

Dans son article qui est principalement destiné à des enseignants d’école primaire, P. Tchounikine illustre l’intérêt pédagogique de raconter des histoires avec Scratch :

Soit l’objectif de faire travailler la compétence « production d’écrits ». Il est possible d’utiliser Scratch pour créer un contexte ludique, par exemple en définissant une tâche (un exercice) du type « soit le contexte (…), imaginer le dialogue entre Alice et Paul et l’animer sur l’écran » ; complément possible : « exploiter les différentes attitudes des personnages qui sont proposées. »

Comme le montre le petit aperçu ci-dessous, c’est très facile de créer un dialogue puisqu’il suffit copier/coller des séquences « attendre / dire », puis de modifier le texte des blocs.

C’est très rudimentaire du point de vue algorithmique, mais parfaitement justifié à l’école primaire où la production d’écrits est une compétence importante à acquérir. Ensuite, P. Tchounikine montre qu’on peut prolonger l’exercice en incluant des notions algorithmiques plus élaborées (instructions conditionnelles, blocs événementiels…)

Reprenons le même exercice en ajoutant : faire saisir des textes à l’utilisateur et faire en sorte que Alice et Paul disent des choses selon ce que tape l’utilisateur (par exemple : son âge, ses préférences sur un sujet donné, etc.) ; variante : l’utilisateur agit sur la situation en cliquant sur un objet, appuyant sur une flèche du clavier ou en bougeant la souris. Cet exercice va maintenant amener à utiliser la notion algorithmique de conditionnelle Si-Alors-Sinon et à l’écriture d’expressions logiques, et éventuellement à définir/utiliser des variables. La création de situations avec plusieurs personnages amène par ailleurs assez rapidement à dépasser une synchronisation simpliste (en utilisant des « Attendre x secondes ») pour utiliser des envois de messages par exemple.

P. Tchounikine poursuit en évoquant des objectifs plus ambitieux montrant l’essence pluridisciplinaire de l’approche « créativité », ainsi que la nécessité un cadre éducatif permettant de la mettre en place (disposer de suffisamment de temps, par exemple dans le cadre d’un projet) :

Un exercice plus ambitieux maintenant : réaliser une fiction interactive ou un jeu. Il faut pour cela construire un schéma narratif (situation initiale, présentation des personnages, lieu, but, éléments déclencheurs, déroulement, situation finale) ; détailler chaque scène (personnages/lutins, scènes, arrière plans, décors, sons, comportements des objets, etc.) ; créer des consignes, des dialogues, des aides ; inventer des énigmes à résoudre (et créer les bouts de programme permettant de tester les réponses de l’utilisateur !) ; etc. Tout ceci peut se faire en travaillant papier-crayon tout d’abord (ce peut être à différents niveaux de précision, de l’idée générale à un scénario ultra-précis) puis sur machine, ou directement sur machine. C’est bien évidemment un projet sur plusieurs séances...

Lorsqu’il y a 3 ans j’avais découvert le thème E (« Algorithmique et programmation ») du programme officiel de mathématiques au cycle 4, j’avais été très surpris d’y voir figurer les termes « programmation événementielle » et « programmer des scripts se déroulant en parallèle », pour plusieurs raisons :

• pas de rapport évident avec l’enseignement des mathématiques !
• initiation à l’algorithmique ne correspondant guère à ma pratique en IUT : au cours des 2 années d’enseignement (spécialité « Statistique et Informatique Décisionnelle »), la programmation parallèle n’est jamais évoquée et la programmation événementielle est à peine abordée (en plus, pas dans le module d’initiation à l’algorithmique)
• par quel miracle serait-il facile, en 5ième, de programmer des jeux (pong, labyrinthes…) ?

Je n’aurais pas employé le terme « miracle » si j’avais mieux connu Scratch à l’époque, dont je savais surtout qu’il proposait des blocs algorithmiques permettant de s’affranchir de la syntaxe contraignante des langages textuels. A ma décharge, je n’avais aucune raison de penser spécialement à Scratch puisque le programme officiel précise qu’on ne vise pas « une connaissance experte et exhaustive d’un langage ou d’un logiciel particulier »…

A ce sujet, je me demande d’ailleurs si les sujets du brevet des collèges sont bien en adéquation avec le programme officiel : bizarrement, on n’y voit que des blocs Scratch, et le bloc « quand drapeau vert cliqué » ne correspond pas à un concept algorithmique universel… Mais bon, à part cette petite excentricité visant à démontrer qu’on prend en compte la programmation événementielle au brevet, les sujets correspondent à une approche algorithmique classique et sont donc accessibles à des non spécialistes de Scratch.

C’est cette approche classique qui est privilégiée dans les manuels de cycle 4, ce qu’on peut constater dans un document de synthèse de l’IREM Paris-Diderot (voir lien). Cela montre que l’intégration de scripts événementiels et/ou parallèles dans un enseignement de mathématiques pose problème, ce dont il aurait fallu se préoccuper avant de mettre hâtivement ces notions dans le programme officiel. Pour être cohérent, je ne vois que deux solutions raisonnables :

• soit on progresse dans la réflexion en montrant pratiquement comment ces notions peuvent être rendues compatibles avec un enseignement de mathématiques
• soit on les fait disparaître du programme officiel de mathématiques de cycle 4

Personnellement, je ne sais pas trop comment il faudrait procéder pour que la solution 1 soit viable, mais j’applaudirai des deux mains si on me démontre qu’elle est réaliste.

Si Scratch n’était pas un langage « fortement recommandé » au collège, les termes « programmation événementielle » et « programmer des scripts se déroulant en parallèle » n’apparaîtraient probablement pas dans les programmes officiels, contrairement aux concepts algorithmiques de base (variables, instructions conditionnelles, boucles, sous-programmes). Pédagogiquement, ce choix peut être légitime si on place les enseignants dans un cadre propice pour le mettre en œuvre, mais devient inapproprié (voire absurde) dans le cadre d’un enseignement de mathématiques : il y a, contrairement au cadre de l’enseignement primaire, de nombreuses contraintes (horaires, objectifs mathématiques légitimement prioritaires…) rendant très compliquée la mise en place d’une approche « créativité » souhaitable pour ce type d’activités.

Il y a un risque que les enseignants négligent cet aspect du programme officiel (par manque de connaissances, démotivés par un lien pas évident avec les mathématiques et/ou par pragmatisme puisque ça ne figure pas dans les sujets de brevet), ou le fassent de façon stéréotypée en récupérant des ressources sans en percevoir réellement l’intérêt pédagogique.

Il y a aussi le risque que des enseignants zélés cherchent à tout prix un lien entre « programmation événementielle et/ou parallèle » et mathématiques, alors que les rédacteurs du programme officiel de mathématiques ont artificiellement intégré cet aspect de Scratch dans le seul enseignement disponible (avec la technologie) puisqu’on ne veut pas créer des enseignements spécifiques d’informatique. Par exemple, une ressource du site pédagogique de l’académie de Reims a été élaborée afin de découvrir la programmation parallèle et de travailler sur les conversions (voir lien) :

Autant je suis convaincu par l’utilité d’écrire un programme « classique » de conversion, autant je suis réservé sur l’intérêt pédagogique (dans un enseignement de mathématiques) de le faire avec 2 lutins échangeant des messages.

Une autre fausse « bonne idée » pourrait être, puisque le programme officiel parle de la programmation de labyrinthes dans un enseignement de mathématiques, d’en concevoir un où des portes s’ouvriraient après que les joueurs aient répondu à des questions sur les fractions (voir lien pour tester le jeu) :

J’ai découvert ce labyrinthe dans l’article de P. Tchounikine, qui voulait illustrer la différence entre l’utilisation d’un programme ludique (pour améliorer une compétence non informatique, ici le calcul avec des fractions) et l’écriture d’un programme Scratch. Et il ajoute fort logiquement :

On peut noter que, vu le design, il est probable que ce soit un élève qui ait fait le programme. Si c’est le cas, cet élève-concepteur a, lui, fait de la programmation (mais il a passé plus de temps à gérer le labyrinthe qu’à travailler sur les fractions : le programme est composé de 33 objets et de 238 scripts !).

Heureusement, je n’ai pas encore vu d’enseignants de collège tomber dans cet excès, mais le risque est non négligeable compte-tenu de la rédaction hasardeuse du programme officiel. Par curiosité, on peut jeter un coup d’oeil au code (bouton « voir à l’intérieur »). On s’apercevra par exemple que la plupart des lutins sont des nombres, ce qui ne correspond pas vraiment à l’image d’Epinal (personnages ou personnes) qu’on s’en fait ! C’est à la fois une force de Scratch puisque ça permet de développer avec des moyens accessibles des jeux très variés, mais aussi une faiblesse : ces « astuces » spécifiques à Scratch ne sont en effet pas souhaitables si l’objectif principal est de former à la pensée algorithmique, et pas de créer le jeu.

Dans le programme officiel de cycle 4, plusieurs jeux sont cités : labyrinthe, pong, bataille navale, nim, tic tac toe. Certains ont clairement un intérêt indépendant de Scratch : par exemple, le jeu de nim est une excellente activité débranchée, et il y a même une théorie mathématique pour décrire et justifier les situations gagnantes.

Concernant le labyrinthe, il me semble que l’objectif principal est de le faire programmer. Il est certes utile de savoir qu’on peut associer des scripts aux flèches du clavier, mais ça ne me paraît pas être une information capitale dans une initiation à l’algorithmique. Quant aux évènements « quand une couleur est touchée », ils me semblent anecdotiques car trop « scratchiens ». Côté élèves, je ne vois pas bien comment ils peuvent travailler avec une approche « créativité » : personnellement, si je n’avais pas vu les solutions, je n’y aurais probablement pas pensé !

Par contre, côté enseignants, la créativité de certains d’entre eux m’impressionne. Par exemple, j’invite les lecteurs à jeter un coup d’oeil sur cette activité intitulée « jeux de Pâques » sur le site pédagogique de l’académie de Nantes (voir lien) : les auteurs arrivent non seulement à la relier aux mathématiques, mais aussi aux tableurs ! En plus, ils ont la lucidité et l’honnêteté de ne par survendre leur activité, en précisant qu’elle n’est pas adaptée à tous leurs élèves :

Nous avons tous des élèves qui vont plus vite que les autres, des élèves qui en demandent plus. Cette activité permet dès le collège d’aller plus loin avec eux...

Si ça me passionnait, ce qui n’est pas le cas, j’arriverais probablement à programmer un labyrinthe sans plagier une ressource existante. Mais pour ce qui est du jeu de pong, je n’ai pas le choix et ai fait appel à un moteur de recherche qui m’a renvoyé vers un document (voir lien) qui m’a l’air très pédagogique, mais que je n’ai pas eu la curiosité de mettre en application : j’ai la ringardise de préférer de loin les vrais jeux de raquettes ! De plus, en tant qu’élève, je serais consterné qu’on me demande de suivre un mode d’emploi : en effet, quelle marge créatrice aurais-je, si ce n’est de changer la couleur de la raquette ou de dessiner un autre labyrinthe ?

Heureusement, tous les élèves n’ont pas les mêmes réactions extrêmes, mais il est bien connu que tout le monde n’aime pas les mêmes jeux : il faudrait sans doute y réfléchir avant de proposer tel ou tel jeu à des élèves.

Par ailleurs, en tant qu’enseignant, je préfère le concept d’activité ludique qui est plus large que celui de jeu et qu’on peut plus facilement adapter à des objectifs disciplinaires ciblés qui, il ne faudrait pas le perdre de vue, devraient être le moteur de toute activité pédagogique. Par exemple, on trouvera des activités ludiques et réalistes dans un ouvrage collectif intitulé « Scratch pour le collège », dont on peut récupérer le pdf et les programmes à partir d’une brève de MathémaTICE (voir lien).

Sans dévoiler le scénario du sketch, je peux néanmoins souligner ici qu’il y est à un moment question de simulation d’un tir parabolique avec Scratch. Cela m’a amené à adapter un exercice de l’ouvrage collectif « Scratch pour le collège » mentionné à la fin de la section C :

Rassurez-vous, cet ouvrage présente auparavant des exercices plus simples à traiter au collège ! A partir de ce lien, vous pourrez récupérer le fichier Scratch final ainsi qu’une fiche au format pdf dans le chapitre « plusieurs lutins ». Les explications sur la simulation m’ont laissé quelque peu perplexe :

• comment les exploiter concrètement avec des élèves, que ce soit au collège voire au lycée ?
• sont-elles suffisantes pour prouver, au moins intuitivement, que l’algorithme simule bien un tir parabolique ?

Sur la fiche, on y trouve notamment cet algorithme :

Ensuite, il y a des explications un peu alambiquées où on informe par exemple les élèves que chaque segment de la trajectoire est la somme deux vecteurs (c’est à dire deux flèches !) : une fixe et une autre verticale. Et à l’arrivée, on aboutit au schéma suivant :

Même à l’époque des « mathématiques modernes » où, en tant que collégien, j’en savais bien plus sur les vecteurs, je crois que ces explications ne m’auraient guère éclairé sur le bien fondé de l’algorithme ! Ce n’est qu’au lycée, dans l’enseignement de physique, que j’aurais pu avoir plus de recul, notamment grâce à une étude théorique :

Et en remplaçant x’(t) (respectivement y’(t)) par dx/dt (respectivement dy/dt), puis dt par 0.1, on en déduit [4] le principe de la simulation… L’écart entre la trajectoire simulée et la trajectoire théorique peut être visualisé dynamiquement avec un programme DGPad (tester).

En poussant la réflexion, il s’avère que la simulation Scratch met en œuvre la méthode d’Euler, qui permet de résoudre numériquement une équation différentielle. Cette méthode est détaillée par exemple dans un document (voir lien) de préparation au Capes, duquel j’ai extrait ce passage correspondant au cas particulier du tir parabolique (y’(t) = f(t) ) :