A) Introduction
Dans un article du N°48, j’avais fait part de ma stupéfaction devant le volet algorithmique de la réforme 2016 tellement il était ambitieux sur le papier et difficile à mettre en œuvre. A l’époque, ce n’était qu’un projet, mais ses grandes lignes ont ensuite été conservées :
Les ambitions affichées dans le programme officiel ne sont-elles pas un nouveau leurre, comme la réforme du lycée de 2009 qui a abouti à des sujets simplistes au bac sur des suites récurrentes ? Il est d’autant plus légitime de le craindre qu’il y a eu un énorme fossé entre le programme officiel et les sujets du brevet 2017 : par exemple, quelles compétences algorithmiques évalue-t-on quand on demande aux élèves ce que dessine un programme Scratch qu’ils n’ont pas eu à écrire ?
Le second thème que je traiterai est lié à l’omniprésence de Scratch dans les sujets du brevet 2017, alors que le programme officiel précise pourtant qu’aucun logiciel de programmation visuelle n’est imposé : un enseignant de collège peut-il, sans risque de léser ses élèves au brevet, utiliser une extension mathématique de Blockly en plus ou à la place de Scratch ?
Les extensions mathématiques illustrées dans cet article (SofusPy et tableur) sont accessibles depuis ma page web consacrée à Blockly (voir lien).
B) Quelles compétences algorithmiques au cycle 4 ?
Dans le programme officiel, au début de la partie « Attendus de fin de cycle 4 », il y a un attendu que j’approuve sans réserve : « écrire, mettre au point et exécuter un programme simple ».
Aucun de ces 3 points ne me semble avoir été évalué au brevet 2017, alors que le premier aurait pu l’être dans « l’épreuve papier » : c’est dommage et, sans trop y croire, j’espère que ça ne perdurera pas comme pour le bac depuis la mise en place de la réforme de 2009.
J’espère aussi que cela ne sera pas interprété comme une incitation à enseigner le codage de façon minimaliste : en effet, des enseignants de collège allergiques au codage pourraient être tentés de faire des impasses… J’ai d’ailleurs l’impression que c’est ce qui s’est passé au lycée : j’observe en effet que j’ai de plus en plus d’étudiants d’IUT qui m’affirment n’avoir utilisé qu’une calculatrice lors de leur scolarité dans le secondaire. Heureusement, l’arrivée de Python devrait inverser cette tendance.
Pour commencer, je conseillerai de ne pas trop chercher la réponse dans le programme officiel, où il y a beaucoup de termes « pompeux » comme « programmer des scripts se déroulant en parallèle », « décomposer un problème en sous-problèmes », « reconnaître des schémas » : c’est une façon pas très simple d’expliquer à des enseignants de mathématiques comment apprendre à des collégiens à « écrire et à mettre au point des programmes simples » !
Je préfère de loin l’approche d’Emmanuel Malgras, dans une ressource intitulée « somme de plusieurs entiers consécutifs » qui est publiée sur le site pédagogique de l’académie de Nantes (voir lien) :
- elle est pertinente d’un point de vue algorithmique et d’un point de vue mathématique [1].
- elle respecte une progressivité pédagogique en algorithmique dans ses activités.
- elle analyse la production de plusieurs groupes d’élèves.
- elle montre qu’on peut proposer des activités intéressantes avec Scratch sans se sentir obligé de demander aux élèves d’échanger des messages entre plusieurs lutins sous couvert de modernisme.
Les deux premières activités (somme de 3 entiers consécutifs et test de divisibilité par 3) sont clairement des programmes simples que des élèves devraient savoir écrire et mettre au point à la fin du cycle 4. Pour la dernière activité (somme de n entiers consécutifs), je n’en dirai pas de même : c’est une activité légitime au collège, surtout après plusieurs activités préparatoires comme ici, mais ce n’est pas une compétence qu’on peut exiger à la fin du cycle 4.
Avant de tenter de répondre à cette question, je vais revenir sur une erreur fondamentale dans la façon d’aborder le codage dans le secondaire, que ce soit au lycée depuis 2009 ou au collège depuis 2016 : on met en vrac toutes les notions algorithmiques fondamentales (variables, entrées-sorties, instructions conditionnelles, boucles, sous-programmes), sans réfléchir à la façon dont on va les enseigner et sans se soucier d’une quelconque progression pédagogique !
Plutôt que de survoler de nombreuses notions, il serait préférable de laisser aux collégiens le temps d’acquérir de réelles compétences de base en algorithmique, comme on le fait à l’école primaire pour l’apprentissage du calcul : il ne suffit pas de quelques exercices sur l’addition pour apprendre la multiplication, pas plus qu’on ne peut aborder la division sans maîtriser la multiplication et la soustraction…
En d’autres termes, j’aimerais qu’on fasse au collège suffisamment d’exercices pour que les affectations, les entrées-sorties et les instructions conditionnelles soient maîtrisées. Même en IUT, je consacre plusieurs séances où je pose des exercices d’algorithmique portant sur des notions mathématiques de niveau primaire-collège, comme l’illustrent ces quelques exemples :
- Écrire un algorithme prenant un temps en secondes que l’on transcrira en heures, minutes et secondes.
- Une agence de location de voitures propose à ses clients deux tarifs : tarif essence (15 euros par jour de location et 85 centimes par kilomètre) et tarif diesel (16 euros par jour de location et 66 centimes par kilomètre). Ecrire un algorithme calculant les deux tarifs, et indiquant au client quel type de location est le plus rentable pour lui.
- Un papetier vend des feuilles de format A4 par cartons. Pour une quantité commandée ne dépassant pas 20 cartons, chaque carton est facturé 10 euros. Au delà, du 21ième au 50ième carton, le prix unitaire des cartons supplémentaires passe à 9 euros et, à partir du 51ième carton, à 8 euros. Ecrire un algorithme pour aider le papetier.
Et les boucles, me direz-vous ? J’y viens enfin, en citant un extrait d’un cours d’algorithmique en ligne de Christophe Darmangeat (voir lien) :
Les boucles, c’est généralement le point douloureux de l’apprenti programmeur. C’est là que ça coince, car autant il est assez facile de comprendre comment fonctionnent les boucles, autant il est souvent long d’acquérir les réflexes qui permettent de les élaborer judicieusement pour traiter un problème donné.
Et comme c’est un point douloureux, on a « habilement » trouvé la parade au bac, en proposant des programmes à compléter, dans un cadre stéréotypé de surcroît lorsque le sujet porte sur des suites récurrentes…
Au collège, les boucles « répéter n fois » peuvent être utilisées de façon indolore pour écrire des programmes réalisant des figures géométriques avec une tortue (pardon, un lutin Scratch !). Mais il est difficile d’en espérer beaucoup plus de la plupart des collégiens dans la maîtrise des boucles.
Par exemple, le comité de rédaction de MathémaTICE m’a demandé d’illustrer la partie algorithmique d’un article sur les cryptarithmes dans le N°58 (voir lien). On peut y constater que l’imbrication de boucles « Répéter n fois » pour résoudre NON+NON=OUI ou OUI+OUI=NON n’est pas simple en Scratch, parce qu’il n’y a pas de boucles « Pour », ce qui m’a conduit à envisager une alternative avec une seule boucle faisant varier un entier de 100 à 999.
Puisque les sous-programmes figurent dans le programme officiel et que de nombreux professeurs de mathématiques n’ont pas été formés à l’enseignement du codage, il serait logique d’en déduire que c’est une notion simple à enseigner. Hélas, ce n’est ni mon avis ni celui de mes collègues d’IUT, lorsque nous constatons les surprenantes difficultés d’un nombre croissant de nos étudiants.
Mais mes étudiants ne sont apparemment pas les seuls à être fâchés avec les paramètres, quand je constate qu’il y a des sujets de brevet avec une procédure non paramétrée pour dessiner un carré (Amérique du sud) ou un triangle (Métropole). Même si les programmes proposés fonctionnent, l’utilisation de variables globales est une pratique depuis longtemps déconseillée par les informaticiens car elle est risquée.
Suis-je favorable à l’enseignement des sous-programmes au collège ? Ma réponse est non, à l’exception de cas simples et intuitifs dont font partie les sous-programmes dessinant des figures géométriques : de tels exemples sont en effet accessibles sans qu’il soit nécessaire de formaliser le concept de sous-programme, et leur intérêt pratique est évident pour les élèves.
Est-il souhaitable de présenter non seulement des cas simples de procédures (carré ou triangle par exemple), mais aussi des cas simples de fonctions (sous-programmes retournant une valeur) ? Ma réponse est plutôt non, car il y a un risque de confusion entre les deux notions, comme je le constate hélas chez bon nombre de mes étudiants d’IUT. Ceci étant, la question ne se pose pas vraiment si on utilise Scratch : il n’y a que des procédures, y compris les « pseudo-fonctions » de Scratch (voir brève) !
On peut très bien en faire de façon minimaliste comme dans les sujets de brevet, où il y a un drapeau vert pour activer un lutin qui dessine des figures géométriques … comme cette bonne vieille tortue Logo qui n’est en rien démodée !
On peut très bien en faire plus, en proposant des activités ludiques avec plusieurs lutins, mais en ayant la modestie et la lucidité de ne pas laisser entendre comme dans le programme officiel qu’on enseigne la programmation parallèle au collège ! Si par ce moyen on parvient à donner une image positive du codage, j’y suis évidemment favorable tant que cela est fait à dose homéopathique : un enseignant de mathématiques a d’autres priorités en matière de codage et, comme le souligne Anne Héam dans le N°56 (voir lien), c’est souvent moins simple qu’il n’y paraît à première vue.
Par exemple, j’ai découvert sur le site pédagogique de l’académie de Reims une ressource de G. Valance sur la conversion de nombres (voir lien) :
Autant je suis convaincu par l’utilité d’écrire un programme « classique » de conversion, autant je suis réservé [2] sur l’intérêt pédagogique (dans un enseignement de mathématiques) de le faire avec 2 lutins échangeant des messages. Cette activité me paraît même être une fausse « bonne idée » :
- si on veut faire travailler les élèves sur des conversions mathématiques, mieux vaut le faire « classiquement ».
- si on veut illustrer l’intérêt pratique d’utiliser plusieurs lutins, mieux vaut choisir un exemple [3] mettant en lumière le côté attractif de Scratch : poursuite de chats (vidéo 1) , canon envoyant une balle vers un chien (vidéo 2)…
En regardant les vidéos, je me suis dit que j’avais de la chance d’enseigner l’algorithmique en IUT : c’est bien plus simple qu’au collège, à moins bien sûr de n’envisager ces activités que comme une succession de manipulations portant sur des blocs dont les noms sont certes évocateurs, mais sans que les élèves en comprennent réellement les concepts sous-jacents.
Je ne nie pas l’intérêt de telles activités : elles donnent une idée attrayante du codage et valorisent les élèves qui sont fiers de leurs réalisations. Mais il n’y a pas ici de savoirs algorithmiques que des collégiens peuvent et doivent maîtriser : donc, si on ne fait pas aussi suffisamment d’exercices permettant de maîtriser plusieurs savoirs de base (entrées-sorties, instructions conditionnelles et boucles « répéter n fois »), l’enseignement du codage au collège sera un leurre comme l’est celui du codage au lycée depuis 2009 [4].
C) Scratch : incontournable au collège ?
Existe-t-il un autre logiciel de programmation visuelle capable de faire de la programmation événementielle et de la programmation parallèle ? La réponse est oui : Snap ! le peut, contrairement à Blockly.
Sachant que les sujets du brevet 2017 ont été rédigés en Scratch, est-il indispensable de donner au collégiens quelques rudiments de Scratch ? Je pense que oui, mais cela ne doit pas dissuader les enseignants de collège d’utiliser d’autres logiciels, notamment les extensions mathématiques de Blockly qu’Alain Busser et moi avons développées et présentées dans de nombreux articles.
A priori, il n’y a pas besoin d’avoir étudié Scratch pour savoir interpréter un programme dessinant une figure géométrique. Par contre, c’est moins évident quand on observe le « programme de calcul » proposé à Pondichery :
Il me semble en effet indispensable de familiariser les élèves de troisième au « vocabulaire Scratch » pendant quelques séances : par exemple, le fait d’utiliser une variable globale nommée « réponse » pour récupérer le résultat d’une saisie n’est pas une manière standard de procéder. J’ai donc ajouté dans mes extensions Blockly un bloc « demander » se rapprochant de la philosophie de celui de Scratch : il offre une alternative à la combinaison de deux blocs (« fixer » et « saisir ») et, par défaut, nomme la variable saisie « réponse » :
J’ajouterai que j’ai été désagréablement surpris par la façon étrange d’écrire ce programme : pourquoi introduire 3 variables (nommées étape1, étape2 et étape3), au lieu de faire évoluer la variable x ? D’ailleurs, il semblerait que les rédacteurs aient aussi eu un doute concernant leur approche, puisqu’ils ont artificiellement introduit des instructions « dire » afin d’expliquer la signification des affectations ! En plus, cela dénature l’intérêt algorithmique de la question puisque les élèves n’ont ainsi plus besoin de comprendre la signification d’une affectation.
Si certains enseignants souhaitent n’utiliser que Scratch, je n’y vois aucune objection : c’est un excellent logiciel, à condition de ne pas l’utiliser à contre emploi.
Néanmoins, je me permettrai de rappeler quelques arguments expliquant pourquoi Alain Busser et moi avons développé des extensions mathématiques de Blockly. Par exemple, elles proposent des blocs permettant de transformer des variables, ce qui permet ici d’écrire une version bien plus claire du « programme de calcul » du sujet de Pondichery :
Dans un article publié par l’IREM de la Réunion (voir lien), Alain Busser reprend plusieurs sujets de brevet en les réécrivant en Blockly avec SofusPy. Cela lui permet également d’en obtenir automatiquement la traduction en Python, ce qui peut être utile aux enseignants de seconde.
J’ai aussi développé une extension tableur, accessible depuis ma page web consacrée à Blockly (voir lien). Avec cet outil, un enseignant a 3 options lors d’une activité sur ordinateur :
- utiliser le tableur (formel) du logiciel Xcas
- utiliser Blockly pour faire de la programmation visuelle
- combiner Blockly et le tableur
Par exemple, le tableur peut suffire pour aider à trouver quelle expression algébrique calcule le « programme de calcul » du sujet de Pondichery :
On peut aussi adapter le programme Blockly initial pour qu’il affiche les résultats intermédiaires dans le tableur :
Une autre adaptation possible du programme Blockly initial consiste à renommer la variable « nombre » en « _A », si bien que les diverses affectations seront interprétées à l’exécution comme des formules dans la colonne A du tableur :
Et si on remplace 7 par x dans A1, les diverses formules seront réévaluées et les valeurs des cellules correspondantes seront exprimées formellement en fonction de x.
SofusPy a été créé pour faciliter le passage de la programmation visuelle (au collège) à la programmation Python (au lycée), grâce à un traducteur. Mais à quoi peut servir le passage inverse, puisqu’on n’apprend pas Python pour se perfectionner en programmation visuelle ? Je vais donner quelques éléments de réponse pour cette nouvelle fonctionnalité.
Par exemple, la programmation visuelle n’est pas très pratique pour ajouter trois entiers consécutifs puisqu’il faut créer de nombreux blocs, alors que c’est direct en Python. Je propose donc une approche hybride, où on commence par créer deux blocs, avant de sélectionner le premier : c’est entre lui et son successeur que seront insérés les blocs résultant de la traduction d’un code Python.
Cela fait apparaître un éditeur, où on peut écrire une (ou plusieurs) instruction(s), avec un menu spécifique qui a un bouton les transformant en blocs :
Pour produire des blocs plus en rapport avec ceux d’Emmanuel Malgras, on aurait aussi pu utiliser des commandes textuelles que j’avais introduites dans un prototype de programmation visuelle avec reconnaissance vocale (voir lien ) :
Tout ceci peut être expérimenté dans la dernière version de SofusPy. En compléments, je montre dans l’annexe ci-dessous qu’il est possible d’aller plus loin dans la transformation d’instructions textuelles (algorithmiques ou Python) en blocs. Ils ne sont donnés qu’à titre indicatif : non seulement le développement n’est pas terminé, mais je dois encore chercher à mieux cerner les apports pédagogiques que peut avoir cette nouvelle fonctionnalité au collège ou au lycée.
- Transformation d’instructions textuelles en blocs
De nombreuses ressources pédagogiques disponibles sur Internet sont accompagnées de fichiers Scratch (au format « sb2 ») à télécharger. Pour les rendre exploitables par un adepte de SofusPy, j’ai développé un utilitaire permettant de les traduire en Blockly. Voici le résultat obtenu (via le bouton « Ouvrir ») à partir du fichier Scratch qui vérifie si la somme de 3 entiers consécutifs est divisible par 3 :
D) Conclusion
En cherchant « activités Scratch » avec un moteur de recherche, on se rend compte que de nombreuses ressources intéressantes ont été développées. Néanmoins, faute d’objectifs clairement identifiés dans le programme officiel, rien ne garantit qu’à la fin du cycle 4 les élèves seront capables « d’écrire, mettre au point et exécuter un programme simple ».
J’ai donc tenté dans cet article d’établir une distinction entre les savoirs à maîtriser au collège et les notions pouvant y être survolées : si on ne veut pas que Scratch (ou un autre logiciel de programmation par blocs) au collège soit un nouveau leurre, il faut changer la façon d’envisager l’enseignement du codage et ne plus tout survoler sans veiller à ce que les élèves aient réellement des acquis.
L’informatique, qui n’est pas reconnue comme une discipline à part entière, souffre probablement encore plus que d’autres matières de ce que Bruno Suchaut appelle un « manque de régulation » dans un article du Café Pédagogique (voir lien) :
On remarque que les pays qui ont mis en place des « standards » qui définissent précisément ce que les élèves doivent savoir aux différents niveaux de la scolarité et qui utilisent des standards comme instrument de pilotage, ont plutôt progressé. C’est en effet la régulation du système qui est la dimension la plus porteuse d’efficacité alors que les réformes françaises ont davantage visé des aspects relatifs à l’organisation du système. Ce sont précisément des modalités de régulation efficientes du système éducatif qui font défaut en France.