David Madore's WebLog: Débriefing de mon cours Logique et Fondements de l'Informatique

Le contexte

Comme je l'ai expliqué dans les billets déjà liés ci-dessus (celui-ci et celui-là), la France a récemment créé une filière MPI (maths, physique et informatique) dans ses classes préparatoires scientifiques[#]. En particulier, les élèves entrant à Télécom par le concours commun peuvent arriver avec trois niveaux de formation en informatique : le socle commun MP/PC (où il n'y a pas grand-chose en info), l'option informatique en MP (qui existait déjà), et la nouvelle filière MPI (qui va encore plus loin). Les programmes de toutes ces filières sont trouvables par exemple sur ce site). Ceci nous a imposé une réforme de nos enseignements en première année : jusqu'à l'été 2023 notre première année était complètement uniforme (en gros, tout le monde avait les mêmes cours, le choix d'une filière de spécialisation se faisant en seconde année), mais ce mode de fonctionnement devenait intenable, au moins pour ce qui est de l'informatique, avec de telles différences de formation à l'entrée (si on s'adapte à ceux qui en ont fait le moins, ceux qui en ont fait plus s'ennuient, et si on s'adapte à ceux qui en ont fait le plus, ceux qui en ont fait le moins sont largués).

[#] Au niveau de la reconnaissance de l'informatique comme une science à part entière, il y a aussi eu création d'une agrégation d'informatique pour le recrutement des enseignants alors que l'informatique était jusqu'alors considérée comme une option de l'agrégation de mathématiques. Et, un peu avant, des changements au niveau lycée avec la création d'une spécialité NSI, c'est-à-dire numérique et sciences informatiques, mais ça ne me concerne que beaucoup plus indirectement : de ce que je comprends, à cause de la limitation à deux spécialités en terminale, la (grande ?) majorité des élèves de prépa, y compris MPI, n'ont pas suivi cette spécialité NSI en terminale, mais bien maths et physique-chimie.

Mais ce n'est pas, en fait, qu'une question de niveau en entrée : les élèves ayant choisi la filière MPI semblent avoir des attentes et des intérêts différents de ceux de la filière MP (même « option info »), au sens où ils semblent généralement plus intéressés par l'informatique pour elle-même et pas juste comme un outil dans un travail d'ingénieur (parce qu'évidemment tout le monde utilise l'informatique de nos jours). Et un des buts de la réforme que nous avons mise en place est de rentre Télécom plus attirante pour les préparationnaires vraiment intéressés par l'informatique, avec notamment l'idée qu'il ne faut pas qu'ils s'ennuient en cours.

La première année à Télécom est (maintenant) divisée en quatre périodes. Pour ce qui est de l'enseignement d'informatique, voici comment nous avons organisé l'année. La période P1 (septembre–octobre) a été dédiée à une introduction générale à la programmation, du matériel au haut niveau, tandis que les élèves venus de la filière MPI (et uniquement eux) ont un cours spécifique sur la compilation. La période P2 (novembre–janvier) est consacrée à la théorie de l'informatique, et c'est celle qui me concerne et dont je vais reparler. La période P3 (février–avril) propose le choix entre différents paradigmes de programmation. Et la période P4 (avril–juin) est consacrée aux réseaux. Sur chacune de ces périodes, les élèves ont environ 40h d'informatique (sauf en P3, moitié moins), c'est-à-dire environ 4h½ par semaine pendant les 9 semaines que dure la période. (Pendant le même temps, les élèves ont bien sûr aussi des cours dans les autres domaines : maths, physique+électronique, sciences économiques et sociales, langues et humanités ; plus des projets et stages variés, notamment entre les périodes. Je dis ça pour situer un peu l'enseignement dans son volume global.)

Pour ce qui est de l'enseignement d'informatique de la période P2 de première année, donc, nous avons divisé la population d'élèves en deux sous-populations inégales : ceux qui sont entrés par les filières MPI ou MP option info du concours commun ainsi que les admis sur titres après une licence d'informatique, soit au total ~90 élèves, et tous les autres, qui doivent représenter à peu près ~120 élèves. Les premiers ont eu le cours INF110 dont je me suis chargé et dont je parle ici, tandis que les seconds ont eu un cours (INF109) plus général sur l'algorithmique fondamentale et quelques rudiments de la calculabilité (recouvrant notamment une partie de ce que les autres élèves avaient déjà vu en prépa).

Bref, s'agissant de INF110, j'avais à m'occuper de 39 heures d'enseignement (contrôle de connaissances non compris), étalées sur 9 semaines, pour ~90 élèves. Nous avons décidé de séparer ces 39h en 21h de cours magistraux, et 18h de TD+TP lesquels ont été pris en charge par mon collègue Théo Z. Pour des raisons d'organisation de l'emploi du temps global de la première année, il n'était pas possible de regrouper les élèves tous ensemble pendant les cours magistraux, donc j'ai donné deux fois chaque séance (on arrive donc à 42h pour moi, si vous suivez).

De l'opportunité d'enseigner des sujets théoriques

Il faut que je dise ici un mot pour évoquer la question qui revient de façon récurrente dès qu'on parle de dispenser des cours assez « théoriques » (whatever that means) à des élèves majoritairement[#2] futurs ingénieurs. J'avais déjà droit à ce genre de remarques quand j'enseignais l'analyse de Fourier (cf. par exemple ce billet) : à quoi ça sert d'expliquer à des futurs ingénieurs la différence entre la transformée de Fourier dans L¹ et dans L² ? ce n'est pas ça qui va leur servir : de toute façon leur signal sera un ensemble fini de valeurs. Donc inévitablement on peut se demander pourquoi enseigner la calculabilité ou la logique intuitionniste quand ce même temps pourrait être employé à faire des cours de JavaScript et de Python, parce que c'est ça qui va leur servir — ou bien d'IA puisque maintenant tout le monde se rue sur l'IA comme des lemmings sur la falaise.

[#2] Je précise que majoritairement ne signifie pas exclusivement. Même sans parler des cas vraiment exotiques, et il y en a toujours (après tout, j'ai dans ma promo à Normale Sup un camarade qui a décidé que la passion de sa vie c'était le cirque, et qui a donc fait carrière dans les arts du spectacle après une thèse de physique quantique), il y a quand même une proportion, faible mais non complètement négligeable, d'élèves à Télécom qui décident de faire de la recherche plus ou moins théorique, c'est-à-dire de faire une thèse et éventuellement d'en faire carrière. Néanmoins, j'entends bien l'argument selon lequel l'enseignement ne doit pas se construire en fonction des intérêts d'une minorité. Donc ce n'est pas l'argument que j'invoque ici pour justifier l'intérêt de mon cours.

J'avais déjà répondu à cette objection, mais je ne sais pas si ma réponse me satisfait beaucoup. Disons que si un ingénieur n'est pas un chercheur (dont le métier consiste à proposer de nouvelles théories), il n'est pas non plus un technicien (dont le métier consiste à appliquer des techniques existantes) : l'ingénieur est justement là pour faire le pont entre les deux, pour appliquer la théorie à la création de nouvelles techniques ou au perfectionnement de celles qui existent, ce qui implique de bien maîtriser la théorie de son domaine, avec un certain recul sur celle-ci, pas juste comme des recettes de cuisine apprises par cœur. (Je devrais, ici, faire référence à la nouvelle Profession d'Asimov, mais c'est un peu difficile à faire sans divulgâcher ; donc je vais me contenter de dire : lisez-la.)

On se trompe gravement, je pense, en voulant centrer l'enseignement sur ce qui sert (ou plutôt, on se trompe gravement en ne mesurant pas toutes les manières dont quelque chose peut servir) : le but de l'enseignement, quel que soit son niveau, n'est pas principalement, ou en tout cas pas exclusivement, de fournir des outils qui serviront mais aussi des clés de compréhension de phénomènes, des cadres dans lesquels analyser ce à quoi on est confronté. Les outils, ce n'est pas qu'il ne faut pas les apprendre, mais ils ont tendance à être hautement spécifiques à une tâche précise, les outils nécessaires à tel ou tel métier s'apprennent normalement en entrant dans ce métier, ce n'est tout simplement pas le rôle de l'enseignement de former à s'en servir (sauf dans la mesure où ces outils sont extrêmement transverses). S'agissant de l'informatique, donc, on se trompe par exemple en pensant qu'il faut enseigner les langages de programmation qui seront utilisés ensuite : un langage de programmation, ça s'apprend rapidement, l'intérêt de les enseigner n'est pas d'enseigner ce qui servira mais d'enseigner ce qui permet de comprendre les différentes approches[#3] de la programmation et les différentes façon de concevoir une tâche.

[#3] Sur les langages de programmation, ce que je dis c'est que ça n'a, selon moi, aucun intérêt de se dire je vais apprendre/enseigner JavaScript et Python parce que c'est ce qui me/leur servira après ; il faut plutôt se dire je vais viser un échantillon représentatif des différents styles de langages de programmation pour comprendre les différentes approches : un langage bas niveau pour comprendre comment fonctionne la gestion de la mémoire, un langage purement fonctionnel et paresseux pour comprendre comment conceptualiser les tâches par une programmation d'ordre supérieur, un langage orienté objet pour comprendre le concept d'héritage, un langage distribué pour comprendre les difficultés de la programmation asynchrone et la manière dont on les résout, etc.

Donc l'intérêt d'enseigner la calculabilité, ce n'est certainement pas parce que ça va servir (même s'il est certainement utile qu'un ingénieur sache que certaines tâches ne sont pas réalisables algorithmiquement — et qu'en gros toute tentative d'analyser le comportement d'un programme devra reposer sur des heuristiques qui seront fatalement imparfaites), mais aussi parce que cela amène à prendre du recul sur les concepts fondamentaux de l'informatique (la récursion, l'auto-référence, la nature de l'évaluation dans les langages de programmation, la raison pour laquelle on se retrouve si facilement à être Turing-complet par accident — et peut-être aussi le fait que ce n'est pas très pertinent de chercher à l'éviter). À titre d'exemple, s'agissant de l'auto-référence, je dirais que quelqu'un qui a du recul sur la calculabilité et le théorème de récursion de Kleene ne sera absolument pas surpris par le fameux hack de Ken Thompson[#4] (d'ailleurs, Thompson lui-même explique le lien entre les quines et son hack), et c'est pertinent pour pouvoir prétendre maîtriser la sécurité informatique. Je peux dire quelque chose d'analogue pour le typage : ce n'est pas juste que c'est utile de comprendre les bases du typage et du polymorphisme parce que certains langages réellement utilisés en ont, mais c'est aussi nécessaire pour comprendre ce qui se passe (par exemple quand on cache des valeur dans une clôture, quand on passe des valeurs par continuation — ce qui sont des paradigmes de programmation qui servent vraiment).

[#4] Dans Reflections on Trusting Trust, Thompson explique qu'il avait introduit une backdoor dans le programme login, puis modifié le compilateur C pour introduire lui-même cette backdoor si elle ne s'y trouvait pas, puis pour introduire cette backdoor dans le compilateur C lui-même, si bien qu'au final il pouvait recompiler le compilateur avec les sources d'origine et la backdoor persistait dans le binaire. Voilà quelque chose qui, au minimum, ne doit pas surprendre un ingénieur en sécurité informatique.

Maintenant, prendre du recul n'est pas quelque chose qui se fait en un jour, ni même en un trimestre : c'est une maturation progressive (et j'ai dit que j'avais moi-même pris conscience de certaines choses en préparant ce cours), donc je ne peux certainement pas m'attendre à ce qu'après ce que je leur ai raconté pendant 21h ces élèves aient été Éclairés quant à la nature de l'auto-référence ou du passage par continuations, qui sont des questions méritant une réflexion assez prolongée[#5], mais j'espère au moins leur avoir donné des clés pour comprendre (et des directions dans lesquelles chercher) des choses qui ne s'apprennent pas aussi facilement qu'un (++n)-ième langage de programmation.

[#5] À un certain niveau, j'ai été tenté de renvoyer mes élèves au livre Gödel, Escher, Bach de Hofstadter, et d'ailleurs j'y ai quelquefois fait référence. Dans une autre direction, j'ai aussi fait référence au Wizard Book, et peut-être que certains auront la bonne idée d'aller le lire, ce qui est indiscutablement une expérience enrichissante. (Dans mon cas ces deux livres ont profondément transformé ma perception de l'informatique et de la programmation.)

Le point est potentiellement contentieux, ce qui est la raison pour laquelle j'ai pris l'espace de le développer ici, mais en fait j'ai été agréablement surpris de voir que, dans les retours (anonymes) que les élèves nous ont faits sur ce cours, les reproches du style c'est trop abstrait, c'est trop théorique, je ne vois pas à quoi ça sert ne revenaient pas trop souvent. Je ne dis pas qu'ils étaient absents, mais ils sont loin d'être majoritaires. Au contraire, il y avait plus de commentaires selon lesquels le sujet du cours était intéressant (et par ailleurs, un collègue qui a eu certains des mêmes étudiants après mon cours m'a dit que certains étaient vraiment fascinés par le λ-calcul[#6]). Et ce n'est pas forcément surprenant : on parle d'élèves qui sont (pour l'essentiel) sortis de classes préparatoires, où l'enseignement (qu'il s'agisse de maths, d'info ou de physique) est tout de même très théorique dans toutes les disciplines, et qui y ont souvent pris goût[#7] : il serait assez idiot de passer brutalement de là à un enseignement exclusivement tourné vers « ce qui sert ». Et de fait, j'ai essayé de concevoir le programme de mon cours dans la suite de ce qu'ils ont déjà vu en info en prépa.

[#6] Comme je l'ai écrit dans une note d'un billet passé, j'avais moi-même été complètement fasciné par la simplicité et l'élégance du λ-calcul quand j'ai appris le concept. (Je crois me souvenir que j'ai passé plein de temps à faire des expansions de λ-termes juste pour jouer avec.)

[#7] Pour ce qui est des maths, il y a à Télécom des élèves qui se réunissent de temps en temps pour réfléchir à des problèmes de maths pour le plaisir. On aurait donc tort de penser que ce genre de choses n'existe que dans les ENS.

Contenu et structure du cours

En concertation avec mes collègues, j'ai décidé de concentrer mon cours INF110 sur la logique, la calculabilité et le typage. C'est faire complètement l'impasse sur d'autres domaines essentiels de l'informatique théorique : algorithmique et complexité, notamment (alors que mes collègues qui enseignaient le cours parallèle INF109 se concentrent justement là-dessus) ; ce choix peut paraître surprenant (et on peut certainement le critiquer), mais il est notamment justifié, à nos yeux, par le fait que les élèves concernés ont déjà eu des cours d'algorithmique assez avancés en prépa et qu'ils auront d'autres occasions d'en faire dans le cadre d'autres cours à Télécom (soit dans le cadre d'un langage de programmation particulier, soit de façon plus abstraite pour ceux qui choisissent une filière théorique en seconde année) ; en outre, la logique, la calculabilité et le typage me semblent plus difficiles à apprendre par soi-même que tel ou tel algorithme standard.

J'ai essayé de trouver une cohérence d'ensemble (je ne sais pas si j'ai réussi à la faire passer aux élèves ni à les convaincre de son bien-fondé), ainsi que beaucoup de ponts entre les sous-sujets abordés. Le pont entre la logique et le typage, c'est la correspondance de Curry-Howard qui nous apprend que les preuves dans certains systèmes logiques correspondent exactement aux programmes dans certains langages de programmation fortement typés (encore une fois, je ne rentre pas dans le fond du sujet ici, je l'ai fait dans ce billet). Le pont entre la calculabilité et le typage, c'est le λ-calcul : si le λ-calcul non typé est équivalent à la calculabilité de Church-Turing en général, le λ-calcul typé (celui qui intervient dans Curry-Howard) peut garantir la terminaison des programmes, mais cette garantie de terminaison implique forcément une perte d'expressivité en raison du théorème de l'arrêt. Le pont entre logique et calculabilité, c'est le théorème de Gödel (qui est, après tout, aux racines de l'informatique puisque Turing était parti pour attaquer l'Entscheidungsproblem — et montrer qu'il n'existe pas d'algorithme décidant si un énoncé est ou n'est pas un théorème — quand il a introduit le concept de machine de Turing) : j'ai donc conclu le cours en donnant une preuve du théorème de Gödel dans l'esprit de Rosser et de Turing, qui s'appuie fortement sur les notions de calculabilité vues au début du cours[#8].

[#8] En gros, on écrit un programme g qui cherche en parallèle une preuve (dans l'arithmétique de Peano) que g termine et une preuve que g ne termine pas, et s'il trouve la première, il fait immédiatement une boucle infinie triviale, tandis que s'il trouve la seconde il termine immédiatement. (L'existence d'un tel programme autoréférent est garantie par l'« astuce de Quine », c'est-à-dire par le théorème de récursion de Kleene, et cette idée de preuve est très proche de celle qui m'a servi pour le théorème de l'arrêt. Il est assez facile de voir que, si l'arithmétique de Peano est cohérente, g ne va trouver ni l'une ni l'autre sorte de preuve.)

Plus en détails, et dans l'ordre dans lequel j'ai présenté les choses (en gros, sur 21h de cours magistral, j'ai passé 7h sur la grande partie ①, puis 10h sur la grande partie ②, et 4h sur la partie ③) :

Préparation et présentation

Vers mai 2023, j'avais décidé les grandes lignes du contenu que je voulais enseigner, en concertation avec mon collègue qui allait se charger des TD/TP. Je me suis dit que j'avais le temps de rédiger à la fois un jeu de transparents (le plus urgent), et un poly de cours avec des exercices. Famous last words! Comme le dit la loi de Hofstadter, ça prend toujours plus de temps que prévu, même quand on tient compte de la loi de Hofstadter. À force d'être toujours débordé, je me suis retrouvé à n'écrire que des transparents et exercices, et les transparents avaient de moins en moins d'avance sur le cours que je donnais, donc étaient écrits de plus en plus en vitesse, parfois même la veille au soir (donc forcément bourrés d'erreurs, dont certaines ont été corrigés en les lisant en cours, d'autres plus tard, et beaucoup restent encore à traquer). En matière de poly, tout ce que j'ai pu fournir est une version imprimable des transparents, et donc ça va constituer une de mes missions pour la rentrée prochaine que de transformer ça en un texte correctement rédigé.

Enseigner sur transparents demande une habitude que je n'ai pas vraiment. Sur certains contenus, quand il y a beaucoup de matière à couvrir et qu'on ne compte pas entrer dans les détails (ici je n'ai fait que très peu de preuves complètes), c'est difficile de faire autrement, mais personnellement je n'aime pas trop, ni comme orateur ni comme public.

En tant que public, au moins, je suis en désaccord profond avec beaucoup de conseils qu'on donne souvent sur comment faire de bons transparents. Par exemple, celui de ne pas mettre trop d'information dedans : or je trouve que c'est encore pire quand l'information n'est communiquée qu'à l'oral (si on cesse d'écouter une seconde, on perd le fil) ou bien si elle est étalée sur trop de transparents (comme on n'en voit qu'un à la fois, ça fait qu'on a une fenêtre d'attention artificiellement réduite). Je trouve aussi complètement insupportable (en tant que public) les transparents qui révèlent progressivement leur contenu : c'est infantilisant, et c'est horripilant quand je veux jeter un coup d'œil à ce qu'il y a en avant, sans compter que c'est extrêmement agaçant parce que ça me distrait de voir le texte apparaître ou changer de couleur. Personnellement, la présentation qui me plaît le plus, c'est quand le transparent liste clairement les points-clés et les informations nécessaires[#13] pour garder le fil du passé et pouvoir passer à la suite, et que l'orateur les lit (pas forcément verbatim, mais en substance) en insérant les détails nécessaires pour approfondir ou pour mieux comprendre ou pour rendre l'exposé plus vivant, mais qui peuvent être ignorés si on veut juste la substantifique moelle.

[#13] Ajoutons que, comme je n'ai pas eu le temps de faire un véritable poly, mes transparents convertis sous forme imprimable devaient en quelque sorte faire double fonction et pouvoir aussi servir de succédané de poly. Forcément, ça oblige à mettre quelque chose de pas trop elliptique sur les transparents !

Donc, un problème, déjà, c'est que je sais que la façon d'appréhender les transparents n'est pas universelle (beaucoup de gens ne sont pas d'accord avec ce que j'ai dit au paragraphe précédent), mais de l'autre je me vois mal suivre un mode de présentation que je trouve moi-même insupportable.

Je me suis retrouvé largement à lire mes transparents, et à commenter ce que je venais de lire (ou à digresser dessus). Je comprends que ça n'ait pas plu. Mais je ne sais pas vraiment comment améliorer sans faire violence à ce que je ressens moi-même comme spectateur potentiel.

Deuxième problème : je ne sais pas faire de figures. Je ne sais pas utiliser d'interfaces graphiques, et je sais encore moins utiliser TikZ correctement (à chaque fois que j'essaie de faire une figure avec TikZ, je prends cinq minutes à faire presque ce que je veux, puis cinq heures en m'arrachant les cheveux pour le persuader de faire en sorte que machin et truc aient la même taille, ou que bidule soit aligné avec chose, ou que telle flèche passe à tel endroit, ou que tel label soit bien placé). Rien que pour les malheureux arbres de preuve de mes transparents, j'en ai bavé pour qu'ils ne dépassent pas à gauche ou à droite, que les étiquettes ne se chevauchent pas, etc.

Or au moins pour illustrer des choses aussi bêtes que le fonctionnement d'une machine de Turing, les illustrations apportent vraiment une valeur ajoutée. (A posteriori je me dis que j'aurais dû proposer des points bonus pour les élèves capables de me fournir une illustration réutilisable pour éclairer un concept expliqué en cours.) À défaut, j'ai parfois gribouillé des choses très moches à la main sur ma tablette graphique.

Troisième problème, intrinsèque aux transparents : on n'en voit qu'un à la fois. Là au moins j'ai pu proposer un palliatif, qui est de donner aux élèves le lien vers un PDF avec l'ensemble du contenu (ce qui permet, au moins, de revenir à la page précédente si on a oublié de lire quelque chose). Je ne sais pas dans quelle mesure ça a vraiment servi, mais ça ne peut pas faire de mal.

Un autre défaut de ma façon d'exposer, pas exactement lié aux transparents mais néanmoins à ranger dans ce coin, c'est que je n'ai souvent pas été clair (dans ma présentation, et parfois dans ma tête) sur quelles parties du cours étaient des connaissances dont la compréhension[#14] était attendue à l'examen, lesquelles étaient présentées à titre d'explications dans l'espoir de rendre plus claires les premières, et lesquelles étaient de simples remarques culturelles obiter dicta. Par exemple, certains semblent avoir inféré du fait que je donnais de temps en temps des exemples en Haskell pour illustrer mon propos sur le typage, qu'ils devaient connaître le Haskell. J'ai éclairci ça en communiquant une liste un peu précise des attendus du cours (et de certains non-attendus explicites), mais évidemment il aurait été préférable que je dissipasse cette confusion[#15] dès le début.

[#14] L'examen était « tous documents autorisés », chose que je préfère sur le principe, mais qui présente évidemment ses propres inconvénients (par exemple celui d'encourager à imprimer des zillions de pages de cours, notes, exercices, livres apparentés, et que sais-je encore, et de se noyer dedans).

[#15] La question que tous les enseignants détestent est certainement il y aura ça à l'examen ? — et certains étudiants en abusent en faisant semblant de ne pas comprendre que quelque chose peut aider à aborder l'examen sans être explicitement dedans — mais il faut quand même reconnaître que c'est à nous de donner l'information pour devancer ce genre de question.

Mais le gros problème posé par la préparation à l'arrache de ce cours, c'est surtout celui de la coordination entre cours et TD+TP. Pendant que j'étais débordé par la préparation du cours, mon collègue a fait comme il a pu : une séance de TD sur la calculabilité, une séance de TP sur les machines de Turing, et le reste des TP en Coq pour se familiariser avec la logique et le typage[#16]. Même dans la mesure où le cours était cohérent et où les TP l'étaient, la coordination entre les deux était assez inexistante puisque nous étions chacun trop préoccupé par la préparation de notre partie pour suivre sérieusement ce que l'autre faisait : ça s'est vu, et les élèves nous l'ont (justement) reproché dans les évaluations. (Enfin, c'est surtout moi qui suis à blâmer en l'occurrence, parce que c'est moi qui suis censé être responsable de l'unité, et c'est moi qui aurais dû avoir des transparents prêts plus tôt pour que mon collègue puisse se baser dessus.)

[#16] Autrement dit, mon collègue a surtout structuré ses TP comme des exercices d'interaction avec Coq de difficulté graduée : pure logique propositionnelle d'abord, puis en allant de plus en plus vers ce qui pouvait ressembler à de la preuve de programmes.

J'ai rédigé pas mal d'exercices d'application du cours (avec corrigés), mais comme je les imaginais au fur et à mesure, ils n'étaient pas du tout prêts pour que mon collègue puisse en faire quoi que ce soit. Donc tout ce que j'ai pu en faire c'est dire aux élèves qu'ils étaient là (ça a quand même permis de dissiper le reproche qu'ils n'avaient pas de modèle[#17] sur lequel préparer l'examen).

[#17] Un retour d'élève me dit quand même estimer que l'examen n'était pas sur le modèle des exercices. C'est toujours difficile d'estimer ce genre de choses !

J'ai ajouté deux séances libres à la fin du cours, en mode venez avec vos questions, j'essaierai de répondre à tout ce que je peux, qui ont eu beaucoup de succès (en termes de nombre d'élèves qui sont venus, et de nombre de questions posées). Mais évidemment on peut voir ça comme quelque chose de moins positif : ça veut aussi dire que ces explications supplémentaires étaient nécessaires, et que ces séances auraient peut-être dû trouver leur place à un autre moment du cours.

☞ Moralité : ce que je dois surtout changer pour l'an prochain, c'est d'avoir un poly rédigé, alléger le cours en retirant ce qui est mal passé, ajouter des illustrations à mes transparents et réussir à les rendre plus digestes, et mieux me coordonner avec mon collègue pour faire, notamment, plus de TD.

Bilan

Malgré ces différents reproches que je me fais à moi-même ci-dessus, je ne crois vraiment pas que cette première itération de ce cours ait été un échec, loin de là.

C'est sûr que certains ont été un peu affolés par la densité du cours, et ont dû fournir beaucoup de travail pour suivre, mais au final les résultats étaient tout à fait satisfaisants. La moyenne de l'examen écrit a été de 14/20, ce qui ne veut rien dire en soi (surtout qu'en vrai c'était noté sur 25 et tronqué à 20 — mais ça c'est surtout parce que le sujet était long —, et il est vrai que j'avais prévu quelques questions extra faciles pour sauver les meubles), mais disons que c'est plus que ce à quoi je m'attendais a priori, et que ça montre que très peu étaient véritablement complètement largués (il n'y a eu que 6 notes <10 sur 87 copies). À juger par les questions que j'ai eues pendant les cours et par les copies que j'ai moi-même corrigées, certains ont même vraiment bien compris.

Symétriquement, les retours des élèves (qui sont anonymes, et par ailleurs collectés avant le rendu des notes ce qui exclut l'effet ils sont contents parce qu'on leur a mis des bonnes notes) sont globalement positifs : par exemple, 70% de ceux qui ont répondu se déclarent plutôt d'accord ou bien tout à fait d'accord avec l'affirmation j'ai apprécié le contenu de cette UE, et à part la partie sur le call/cc et les continuations qui comme je le reconnais ci-dessus a été un désastre, les autres parties du cours ont été plutôt appréciées individuellement (la préférée ayant été celle sur le λ-calcul, dont 67% nous disent être tout à fait d'accord avec l'affirmation qu'ils y ont réalisés des apprentissages significatifs). Bien sûr, ces sondages ne veulent pas dire énormément, et je ne cache pas qu'il y a quelques avis clairement négatifs et d'autres qui regrettent de ne pas avoir réussi à suivre, mais la plupart des critiques sont plutôt constructives (le cours gagnerait à être facultatif, les TP devraient être mieux coordonnés avec le cours, il faut plus de TD, telle partie devrait être allégée, et ma façon de lire les transparents n'est pas très utile…). Il y a quelques avis qui sont carrément enthousiastes, et ça fait toujours plaisir à lire.

Une chose dont je suis à peu près sûr, c'est que j'ai au moins rempli cette mission qu'un collègue m'a confiée : il ne faut pas que nos élèves s'ennuient en cours.

Bref, je ne pense certainement pas avoir fait quelque chose de parfait, mais ce n'était pas du tout un échec, et je crois que j'ai les pistes nécessaires pour améliorer les choses l'an prochain :

• Supprimer les parties les plus indigestes du cours (notamment ce qui concerne les continuations, les subtilités sur le rapport entre arithmétiques de Heyting et de Peano, et les explications sur l'élimination des coupures voire tout le calcul des séquents), et mieux équilibrer mon temps sur le reste (il y a des parties où je délayais un peu parce que j'avais l'impression d'avoir trop de temps).
• Rédiger un poly complet, et en profiter pour alléger les transparents (reste à trouver un bon équilibre à ce sujet).
• Prévoir de vraies séances de TD au lieu de juste mettre à disposition des élèves des feuilles d'exercices corrigés.
• Mieux me coordonner avec mon collègue pour que les TP ne semblent pas indépendants du cours.

Coda : un stage LIESSE

Télécom organise de temps à autre, en lien avec l'Union des professeurs de classes préparatoires scientifiques, des stages LIESSE (j'avoue que je ne sais pas ce que l'acronyme veut dire) d'échange avec les enseignants de classes prépa (ou éventuellement d'autres enseignants ou enseignants-chercheurs intéressés du secondaire ou du supérieur), le but étant d'exposer un sujet scientifique et de garder une interaction entre enseignants avant et après les concours des grandes écoles. J'avais déjà proposé un tel stage en 2021 (voir ce passage de ce billet (sur la théorie des langages formels (langages rationnels, langages algébriques, et automates), en 2018 (voir ce billet) sur la factorisation des entiers, et en 2015 (cf. ce billet) sur les réseaux euclidiens. J'aime bien ces rencontres parce que ça me permet de faire quelque chose d'intermédiaire entre un exposé de recherche et de la vulgarisation (cf. ce que je racontais dans ce billet) sur l'importance de tels exposés, et aussi d'exercer un peu mon éclectisme mathématique (que les sujets que je viens de lister doivent illustrer un minimum).

J'ai donc proposé de faire un stage Logique, Calculabilité, Typage, qui aura lieu jeudi 16 mai (9h30–12h et 14h–16h) à Télécom (à Palaiseau[#18]). Le but est à la fois de parler du fond du cours (mais évidemment, en 2×2h je ne vais pas refaire la totalité du cours que j'ai exposé en 21h aux étudiants ! donc il y aura beaucoup de survol) et aussi des circonstances de sa mise en place à Télécom, c'est-à-dire en gros de ce que je viens de raconter dans ce billet. Les personnes intéressés à participer peuvent s'inscrire via ce lien[#19] (a priori ça concerne les enseignants, enseignants-chercheurs et chercheurs, et particulièrement les profs de prépa, mais on n'a pas l'intention de faire les difficiles ; par contre, l'inscription est obligatoire).

[#18] J'espère pouvoir mettre en place une retransmission vidéo (je mettrai sans doute le lien ici ultérieurement), mais le but est aussi de faire la pub de l'école, donc on cherche avant tout à attirer les gens sur place.

[#19] Je n'ai pas choisi l'outil d'inscription (outil qui, d'ailleurs, a été en panne vendredi et tout le week-end derniers), donc je suis désolé s'il est malcommode.