Ce que j'ai appris de mon année en lycée

Cette année, j'ai enseigné l'informatique au lycée Charlemagne, à Paris. Ce qui aura été ma première expérience de l'enseignement m'a appris beaucoup de choses ; j'ai continué d'en apprendre sur ma propre discipline, mais surtout, j'ai pris conscience d'éléments pédagogiques que j'avais sous-estimés, voire complètement ignorés.

Cet article est donc une occasion de rassembler ces points, de leur donner de l'ordre, en espérant pouvoir me servir de ces enseignements pour la suite.

La programmation

S'il fallait choisir une seule difficulté que j'ai sous-estimée à mes débuts, ce serait celle de l'apprentissage des bases de la programmation.

Mes premiers contacts avec la programmation, en dehors de quelques bribes au lycée, se sont faits en prépa. Des quelques souvenirs que j'en ai, le niveau général des élèves de ma classe faisait que les difficultés syntaxiques que nous rencontrions étaient légères. Comme l'enseignement se faisait en Python, les classiques problèmes d'indentation, d'oubli des deux points se sont évidemment manifestés ; les difficultés liées à la syntaxe du langage n'étaient donc pas inexistantes, mais elles étaient assez minimales et surmontables pour que nous puissions nous concentrer essentiellement sur la mise en place des algorithmes demandés. Par la suite évidemment, j'ai oublié au fond de ma mémoire toutes ces difficultés que j'ai pu rencontrer, et la syntaxe est devenue naturelle, tout comme dans une langue on bute d'abord sur la grammaire de base avant de pouvoir écrire des phrases élaborées, et alors on ne se pose plus la question du placement du complément.

Syntaxe et charge cognitive

Le problème, c'est que je n'ai pas réfléchi en profondeur à la manière dont cette syntaxe devrait être enseignée, et je ne me suis pas projeté chez un élève qui rencontre un langage pour la première fois. Naturellement, la syntaxe de Python est bien la première chose que j'ai présentée aux élèves de première NSI (numérique et sciences informatiques) lors de la première séance de travaux pratiques : dans la console vous pouvez écrire des opérations comme dans une calculatrice, puis vous pouvez affecter des valeurs à une variable en écrivant a = 4, puis afficher a + 3 qui vaut bien 7. Puis j'ai enchaîné avec les conditions. Je n'ai absolument pas pris le temps de décomposer l'opération d'affectation de variable. Ce n'est qu'ensuite, devant les difficultés de certains élèves, que j'ai dû faire un point sur le sens d'affectation (a = 4 ; b = 2 ; a = b laisse les variables a et b avec quelles valeurs ?), et ainsi de suite. Je dis bien certains élèves, car les meilleurs ne rencontrent virtuellement aucune difficulté de syntaxe, et peuvent se lancer dans des exercices directement. Mais ce n'est pas le cas de tout le monde ; en réalité, c'est même deux moitiés de classes qui se sont dessinées au fil de l'année et malgré les corrections apportées à mon enseignement : la moitié dont les difficultés étaient d'abord syntaxiques, et les autres, dont les problèmes, s'il existaient, étaient liés aux algorithmes et à leur sens (on pourrait dire la sémantique).

En parallèle du lycée, je suivais moi-même des cours à l'INSPE (formation des enseignants), où j'ai pu apprendre le concept de charge cognitive, qui est très pertinent dans le contexte dont nous parlons. Appliquons-le à une situation, qui s'est présentée tôt dans l'année, où un élève doit écrire un programme affichant l'écriture binaire d'un nombre (à l'envers, grâce à l'algorithme des divisions par 2).

while n > 0:
    print(n % 2)
    n = n // 2

Rien de compliqué, peut-on se dire. Pourtant, pour le néophyte, il faut comprendre comment fonctionne la syntaxe d'une boucle conditionnelle, celle de l'affectation de variable, comment récupérer un quotient et un reste (à supposer que ces notions soient maîtrisées, ce qui n'est pas certain)... Puis cette troisième ligne semble vraiment étrange ! L'essentiel des efforts de compréhension de l'élève se porte donc en tout premier sur la manière dont il faut écrire le programme, quand bien même l'algorithme en lui-même est très simple, voire donné intégralement au tableau sous une forme textuelle similaire.

La difficulté vient peut-être de mon refus de faire des exercices purement syntaxiques dans l'apprentissage des langages de programmation : par exemple, j'ai vu passer de la part de collègues des questions à choix multiples où l'on demande quelle boucle est syntaxiquement correcte. Indépendamment donc de ce que fait le programme, l'élève doit remarquer que for i in range 12 ne possède pas les parenthèses requises. Je trouve cette abstraction un peu artificielle, et continue malgré tout à penser que l'apprentissage de la syntaxe doit se faire aussi par des erreurs en pratique, et qu'un éditeur écrivant des messages d'erreur assez parlants réaliserait cette tâche mieux qu'un exercice dédié. Il reste donc à trouver le juste milieu entre deux approches. Par exemple, demander aux élèves de tenir un compte-rendu des erreurs de syntaxe rencontrées serait une idée. Mes formateurs de l'INSPE proposent aussi de faire programmer les élèves par deux : un qui écrit, l'autre qui regarde et conseille, ce qui permet d'avoir collectivement du recul sur ce qui est écrit.

Les fonctions et les boucles

Un autre concept que je pense avoir introduit beaucoup trop tôt est celui de fonction. Après avoir introduit l'instruction print, les élèves doivent faire face au mot-clé return. Pour le coup, je ne pense pas avoir éludé le problème, mais une partie non négligeable des élèves semblent tout de même encore avoir des difficultés avec le principe de valeur de retour. Je n'ai pas suffisamment insisté, sans doute, sur le fait que les variables n'ont pas besoin d'être redéfinies si elles sont déclarées en argument. J'ai encore une fois pris trop peu de temps à anticiper des difficultés et à décomposer les problèmes, mais c'est aussi parce que je n'avais pas conscience de ces problèmes, que je rencontrais pour la première fois.

Pour toutes les critiques très à propos que l'on peut faire à Python, sa facilité d'exécution reste un atout à un niveau introductif, pour un "grand public" comme celui de la première NSI. En revanche, la manière dont on introduit une boucle for est tout simplement affreuse à un tel niveau. Je ne peux absolument pas en vouloir à mes élèves qui, en fin de première, ont encore du mal à écrire un parcours de tableau par une boucle, sous toutes ses variations. Pour un débutant, l'enchaînement de mots-clés dans for i in range(len(tab)) peut être très lourd ! Si c'était donc à refaire (et ça le sera, même si c'est à un autre niveau ou dans un autre langage), je commencerais uniquement par les boucles while, jusqu'à ce qu'elles soient parfaitement maîtrisées, et même si le parcours par valeur (for elem in tab) des tableaux n'est plus possible. J'ai pu observer de plus que le parcours par valeur, même s'il est très pratique, contribue à dénaturer dans l'esprit de certains élèves l'aspect fondamentalement procédural, itératif d'une boucle. Avec le recul, certains élèves, au lieu de comprendre que la variable de l'itérateur prend les valeurs successives du tableau, voient cette syntaxe comme quelque chose de déclaratif qui va réaliser quelque chose sur tout le tableau. C'est ce qui pourrait expliquer pourquoi ces élèves introduisent des for à des endroits où une boucle n'a pas de sens. Au moins, la sémantique de while, même si elle peut alourdir le code, est transparente.

La part du par-cœur

Malgré ces accrocs dans mon approche, après un an de pratique, on pourrait quand même penser que les problèmes de syntaxe ont disparu, que la majorité des élèves possède un certain recul sur des programmes types. Mais il n'en est rien. Prenons deux exemples en contrôle cette année.

Dans mon dernier contrôle de l'année, certains élèves n'ont eu aucun point ou presque aux questions de programmation. Ce contrôle n'était pas simple, mais était néanmoins accessible. Par exemple, on cherche à trier un tableau films de paires (valeur, poids) par poids croissant. Je fournis le code d'un tri par sélection avec des trous, car il n'a pas été vu depuis longtemps :

n = len(films)
for i in range(0, n − 1) :
    minimum = 10 ** 12 # infini
    indmin = i
    for j in range(...) :
        if ... :
            minimum = ...
            indmin = ...
    echanger(films, ..., ...) 

Je ne suis pas particulièrement adepte des codes à trous, mais cela me paraissait tordu de demander de l'écrire intégralement alors qu'il n'avait pas fait l'objet d'une révision. Le résultat a malheureusement été qu'une dizaine d'élèves au maximum (sur 30) ont réussi à compléter le code avec réussite. Surtout, un grand nombre d'élèves ont semblé perdus, en répondant complètement à côté, ce qui montre que la syntaxe même du programme a été un obstacle à la compréhension de l'exercice.

D'autre part, dans un contrôle plus ancien (fin décembre), je demande d'écrire la fonction echanger, présente dans le tri précédent, qui échange de place les valeurs situées à deux indices dans un tableau. Cette fonction a été bien réussie pour la grande majorité. Pourquoi ? Parce que la semaine précédente, j'avais demandé à tout le monde d'apprendre cette fonction par cœur, puis j'avais demandé à trois élèves de l'écrire au tableau, et insisté à nouveau devant les erreurs. La fonction du contrôle n'avait aucune différence avec celle vue en cours. Cela signifie que les élèves m'écoutent, et révisent, et c'est une bonne chose. Je voulais qu'ils aient tous bon, et cela a été le cas.

Mais alors pourquoi aussi peu de réussite sur un code à trous ? L'exercice que j'ai proposé sur le tri par sélection est un exercice de variation sur quelque chose de déjà connu, c'est-à-dire qu'on demande à l'élève de mobiliser quelque chose de (normalement) su, et de le modifier légèrement pour l'adapter au problème (ici, trier les éléments du tableau selon la deuxième coordonnée). Mais j'avais fait trop peu d'exercices précisément sur les variations du tri par sélection. Dans mon esprit, une fois que le tri par sélection est maîtrisé (je ne m'en étais pas assuré, j'avais surtout évalué le tri par insertion), que l'on a vu les tris selon différentes coordonnées, alors l'effort cognitif supplémentaire pour les mélanger ne devrait pas être trop grand, si ? Et pourtant !

Je pense m'être rendu compte assez tardivement que l'apprentissage des programmes comme echanger par les élèves restait superficiel. Il aurait suffi de modifier un petit paramètre, et le taux de réussite à cette question aurait sans doute baissé. Et en même temps, il ont fait exactement ce que je leur avais demandé : apprendre la fonction par cœur. Je me heurte donc là à une difficulté que je n'ai pas encore résolue : certains élèves comprennent très vite les programmes du cours, et leur adaptation à une situation particulière ne représente qu'un palier de difficulté. Les autres ont un palier supplémentaire à franchir en premier : leur compréhension des programmes du cours est soit superficielle, soit simplement insuffisante. Je ne sais pas si c'est ma faute, de ne pas leur avoir suffisamment fait répéter l'écriture de fonctions variées jusqu'à ce qu'elles soient maîtrisées ; ou si c'est simplement un manque de travail de leur part. Sans doute un peu des deux ; ou plutôt, les élèves de première n'ont pas encore appris à travailler au-delà des notions qu'on leur demande très explicitement d'apprendre pour tel contrôle.

Même problème que pour l'acquisition de la syntaxe de base, donc : j'aurais pu rentrer dans une pédagogie très guidée, en explicitant de jour en jour les attendus, en faisant des points hebdomadaires. Mais je n'aime pas cette approche. 1) C'est fastidieux pour moi, 2) Cela prendrait nécessairement une grosse partie du temps de cours et m'empêcherait en contrepartie d'approfondir, 3) Ce genre d'approches dépossède les élèves de leur autonomie dans le travail, et remplace l'apprentissage par un simulacre, où le contrat devient de réaliser machinalement certaines tâches en échange d'une garantie d'une bonne note. À la limite, il faudrait demander aux élèves de maintenir une liste personnelle de programmes à connaître, leur recommander de les réécrire chaque semaine, sans que le professeur ait un rôle de prescription. Très peu de professeurs prennent le temps nécessaire de cette formation à la formation, et je m'inclus dedans ; soit les élèves sont laissés complètement à eux-mêmes, soit ils sont guidés outre mesure.

L'engagement des élèves

En réalité, c'est assez difficile d'évaluer la part de travail des élèves. Bien des fois, j'ai été tenté de conclure que les élèves ne révisent simplement pas assez, et il y a une part de vérité chez certains ; mais j'ai aussi eu plusieurs angles morts dans ma manière d'apprécier cet aspect.

Tout au long de l'année, j'ai complètement ignoré la question de la prise de notes par les élèves. En effet, j'ai été habitué à un mode d'enseignement où si on dit (ou écrit) quelque chose une fois, alors cette chose sera écoutée, puis notée, et enfin, on l'espère, apprise. Au lycée, c'est à peu près totalement faux. J'ai donc malheureusement dû me résoudre à accepter l'inefficacité des cours "magistraux". Pourtant, j'ai réussi à me bercer dans une certaine illusion pendant plusieurs mois : mes cours étaient très vivants, et une bonne dizaine d'élèves intervenait très fréquemment pour poser des questions, manifestait un vif intérêt. Il a bien fallu un, ou deux contrôles pour que je me dise que les autres n'avaient pas retenu grand chose. J'ai bien été conforté dans mon illusion, par l'absence de réponse à mes rappels réguliers de poser des questions sur les points les moins clairs : la majorité silencieuse, comme par un certain blocage, n'a jamais pris la parole pour signaler ses difficultés.

Au fil de l'année, je me suis donc résolu à rendre mes cours plus interactifs, en faisant régulièrement passer des élèves au tableau, en donnant des exercices en cours tout en leur laissant le temps de réfléchir. Cette deuxième approche a eu des résultats mitigés. De la même manière, j'ai eu du mal à engager plus d'une dizaine d'élèves volontaires sur ce genre d'exercices. Certains aiment simplement se laisser guider... Je n'ai donc pas encore trouvé la solution.

Une chose qui fonctionne bien et que j'ai mise en place depuis le début de l'année, ce sont des courtes interrogations régulières. C'est simplement mon expérience d'élève qui m'y a poussé, et sans regrets : cela me permet de repérer rapidement quels points ont été mal compris par la plupart, et de les corriger. En plus, quelque chose que je savais un peu mais qui s'est illustrée avec une force que je n'avais pas anticipée, c'est à quel point l'évaluation est une source de motivation pour les élèves. J'ai pu l'observer en seconde : il me suffisait presque de commencer le cours en disant qu'il y aurait un contrôle sur le même sujet la semaine suivante pour capter deux fois plus d'attention de la part des élèves.

À l'inverse, je n'ai donné que très peu de devoirs à la maison (autres que des révisions). Un seul TP noté à finir chez soi m'a vacciné : corriger trois fois le même code, voire lire des choses générées par ChatGPT... Tout le monde dit qu'il faut aujourd'hui tenir compte de ces technologies dans la manière d'évaluer les élèves. Pour ma part, cela voulait sans doute dire que le travail demandé était trop exigeant pour le début d'année (écrire une fonction qui dit si un nombre est premier ; avec le recul, c'était inaccessible). Mais par ailleurs, de moins en moins de professeurs de lycée donnent des devoirs à réaliser chez soi, pour cette raison.

Enfin, les deux projets par groupes que les élèves ont réalisé cette année m'ont globalement bluffé. Contrairement à ce que j'aurais pu penser, la grande majorité s'est impliquée et a produit des jeux ou des sites plutôt satisfaisants. La meilleure partie là-dedans, c'est que les élèves les moins à l'aise en programmation ont pu s'illustrer par leur créativité, et donc participer à leur manière au projet de groupe. En plus, ces projets n'ont rien d'artificiel, comme pouvait l'être (à mon humble avis) ce gros exposé qu'était le TPE. Et c'est sans aucun doute ce qui motive les élèves ! Il y a quelque chose de fondamental selon moi dans la discipline informatique, c'est de vouloir plonger les mains dans le cambouis, de faire les choses soi-même, de décomposer ce que l'on connait pour le reproduire. Il faut s'imaginer la satisfaction que doit ressentir un élève de première quand il réussit à reproduire un jeu snake, ou à programmer une animation sur un site : tout est visuel, le résultat est immédiatement palpable. Au passage, l'organisation de la nuit du code est peut-être la meilleure expérience de l'année pour moi : les différents groupes d'élèves s'entraidaient, et ceux qui n'ont pas réussi à déposer un jeu fonctionnel au bout des six heures n'étaient pas déçus. Au contraire, ils étaient simplement heureux de leur journée. Point négatif pour l'odeur dans la salle...

Les difficultés de la SNT

Jusqu'à présent, j'ai surtout parlé de ma classe de première. Mais les plus grosses difficultés, je les ai rencontrées en seconde, dans la matière SNT (sciences numériques et technologie). Contrairement à la spécialité de première, tous les élèves suivent cette enseignement de 1h30 par semaine. Cela a déjà beaucoup été fait de critiquer les prémices de la matière, je ne vais pas en rajouter ici. Pour ce qui est de mon cas personnel, les premières difficultés auront d'abord été de trouver des choses à raconter aux élèves. Puisque la SNT n'est pas enseignée au bac et que le poids horaire est si faible, je me devais d'intéresser le plus grand nombre, et de contribuer un tant soit peu à la culture numérique de mes 36 élèves. Mon approche en "cours magistraux" était peu concluante en première ; en seconde, elle était presque catastrophique. Je devais pratiquement me battre pour obtenir une minute d'attention. J'ai alors essayé diverses choses au fil de l'année : activités, feuilles d'exercices... Avec parfois un peu de réussite, parfois pas du tout. Il faut dire que malgré tous les efforts d'un professeur, la curiosité du public reste un prérequis pour pouvoir transmettre quelque chose.

Mais enfin, après tout je n'ai pas le sentiment d'un échec : ce sont des difficultés que rencontrent tous les professeurs (d'informatique, de maths, de physique, de SI...) qui se retrouvent devant une classe de SNT. Certains élèves se sont aussi découvert un attrait pour la programmation, tant mieux. Et surtout, je pense que c'est un très bonne expérience pour la suite, d'avoir pu me frotter à une classe légèrement difficile, d'apprendre à enseigner des sujets nouveaux pour moi (la photographie numérique, la géolocalisation), de devoir varier les approches en cours.