Cours de Philippe Roussille

Cours

Anciens cours

Ma méthode : comment j'organise mes cours

Cette page décrit comment mes cours sont organisés, et pourquoi. Je l'ai écrite pour mes étudiants, qui ont le droit de savoir comment on les évalue, et pour les collègues qui se posent les mêmes questions que moi.

D'où je pars

Un assistant de code produit aujourd'hui en quelques minutes un projet d'étudiant complet, avec sa documentation et ses diagrammes. Un projet rendu ne me dit donc plus grand-chose sur la personne qui le rend. Je ne le vois pas comme de la triche. Quand le projet compte beaucoup dans la note et qu'un outil sait le faire, s'en servir est un choix raisonnable. Et l'interdire n'aurait pas de sens : je ne pourrais pas le vérifier en dehors de la salle, et mes étudiants sont des apprentis qui utilisent ces outils en entreprise.

Le problème existait avant les assistants. En 2021, Lehtinen, Lukkarinen et Haaranen montraient déjà qu'une part importante des étudiants d'un cours d'introduction n'arrivaient pas à expliquer le code qu'ils avaient eux-mêmes rendu. Les assistants ont surtout rendu la situation beaucoup plus fréquente.

Deux évaluations séparées

Dans une matière d'ingénieur comme celles que j'enseigne, il y a deux choses à évaluer, et elles ne s'évaluent pas de la même façon.

La première est le jugement : lire du code, voir ce qui ne va pas, décider où intervenir, justifier un choix de conception, estimer ce qu'un changement va coûter. L'assistant ne le fait pas à la place de l'étudiant. La seconde est la capacité à construire quelque chose de conséquent avec les outils actuels, assistant compris, sans perdre la main sur ce qui est produit.

La seconde dépend de la première. Quelqu'un qui ne sait pas lire le code que l'assistant lui propose ne peut pas le vérifier. Plusieurs études vont dans ce sens. Bastani et ses collègues (2025) ont suivi des lycéens en mathématiques : avec un accès libre à un assistant, leurs résultats progressaient pendant l'entraînement, puis baissaient à l'examen, une fois l'accès retiré. Une version de l'assistant qui donnait des indices plutôt que des réponses évitait cette baisse. Chez des programmeurs débutants, Prather et al. (2024) et Kazemitabaar et al. (2023) observent que l'assistant profite surtout à ceux qui ont déjà des bases, et qu'il entretient chez les autres des idées fausses sur le fonctionnement du code.

J'ai donc deux évaluations, que j'appelle avec mes étudiants le permis et la conduite.

• Le permis est une épreuve individuelle, sur papier ou hors ligne, sans IA. Il faut y lire du code, trouver ce qui ne va pas, le modifier et justifier ses choix.
• La conduite est le projet. L'assistant y est autorisé, et même attendu. J'y regarde si l'étudiant sait cadrer ce qu'il demande, vérifier ce qu'il obtient, assembler le travail de plusieurs personnes dans un code cohérent, et expliquer n'importe quelle ligne.

La note de projet est pondérée par celle de l'épreuve : sans le permis, la conduite ne compte pas pleinement.

Je ne suis pas le seul à séparer les choses ainsi. L'Université de Sydney distingue une évaluation surveillée et une évaluation ouverte, et l'AI Assessment Scale (Perkins, Furze, Roe et MacVaugh, 2024) propose des niveaux d'usage autorisé de l'IA selon l'évaluation. Bearman et ses collègues (2024) appellent jugement évaluatif la capacité à juger de la qualité d'un travail, le sien comme celui d'un outil. C'est ce que vise la seconde évaluation.

Ce que j'ai abandonné

Je ne fais plus de cours magistral en amphi, ni de TP guidé pas à pas avec un squelette à compléter. Le cours magistral transmet des informations qu'on trouve aujourd'hui partout. Le TP guidé se termine en trente secondes avec un assistant, et il ne demandait déjà aucune décision.

En séance, je garde trois choses : des explications courtes, données au moment où elles servent ; des exercices qui partent d'un problème et obligent à choisir ; et mes retours sur ce que les étudiants produisent. La méta-analyse de Freeman et al. (2014), sur 225 études, trouve qu'en faisant travailler les étudiants pendant la séance plutôt qu'en les faisant écouter, les résultats progressent d'environ un demi écart-type, et le taux d'échec passe de 34 % à 22 %.

Comment se déroule une séquence

Chaque cours est découpé en séquences de 45 minutes, avec une notion par séquence, deux au plus. Une séquence suit toujours le même ordre :

1. une situation de départ, sur du code existant : un bug, un audit, une demande de modification ;
2. une explication de cinq à sept minutes, faite en direct sur ce code ;
3. une pause, où chacun choisit un exercice parmi trois niveaux ;
4. un exercice de base, vérifié par des tests ;
5. un exercice d'approfondissement, pour ceux qui ont fini ;
6. une courte question de sortie.

Entre les séances, il y a un chapitre à lire, parfois une vidéo de six minutes au plus suivie d'une question, et un quiz.

Cet ordre (prédire, exécuter, examiner, modifier, puis créer) vient de la méthode PRIMM (Sentance, Waite et Kallia, 2019). Elle s'appuie sur un constat : savoir suivre et expliquer du code vient avant savoir en écrire, et les deux vont de pair (Lopez et al., 2008 ; Xie et al., 2019). C'est pour cela que mes exercices partent presque toujours d'un code qui existe déjà. C'est aussi le terrain où l'assistant aide le moins, et en entreprise, on passe bien plus de temps à modifier du code qu'à en écrire.

Trois niveaux, au choix

Après chaque explication, je laisse quatre minutes et trois exercices sur la même idée. Le niveau 1 refait ce qui vient d'être montré, avec l'exemple sous les yeux. Le niveau 2 correspond à ce qu'il faut savoir faire à l'épreuve. Le niveau 3 est une question plus ouverte, pour ceux qui veulent creuser. Chacun choisit son niveau à chaque pause, et peut en changer à la suivante. Il n'y a pas de groupes de niveau.

L'exercice de base propose des indices gradués, qu'on peut ouvrir sans pénalité. Au-delà, l'exercice d'approfondissement se fait sans aide. Deux résultats justifient ce choix. Pour des débutants, les explications explicites et les exemples résolus marchent mieux que la découverte libre (Kirschner, Sweller et Clark, 2006 ; l'article est discuté, mais il tient sur ce point). Et ce qui aide un débutant peut gêner quelqu'un de plus avancé (Kalyuga et al., 2003).

Les votes en séance

Chaque explication commence par une question : que va faire ce code ? Tout le monde vote. Quand la salle se partage, entre 30 et 70 % de bonnes réponses, chacun discute deux minutes avec son voisin, puis on revote. En informatique, Porter, Bailey Lee et Simon (2013) rapportent que cette méthode a fait passer le taux d'échec de 20 % à 7 % sur dix ans de cours. Porter et al. (2011) ont aussi vérifié que les étudiants apprennent réellement pendant la discussion, et qu'ils ne se contentent pas de reprendre la réponse du voisin.

Entre les séances

Mes étudiants sont en alternance et passent plusieurs semaines en entreprise entre deux séances. Pour ces périodes, je donne une feuille de route avec des échéances datées. À chaque échéance, un quiz se ferme, et 40 % de ses questions reviennent sur les notions ratées aux quiz précédents. C'est la partie la mieux étayée de tout le dispositif : se tester aide davantage à retenir que relire (Roediger et Karpicke, 2006 ; Adesope, Trevisan et Sundararajan, 2017, une méta-analyse de 217 études).

L'épreuve

L'épreuve pose huit à douze questions approfondies plutôt que trente questions courtes. Chacune donne du code, et demande d'y trouver un défaut, de proposer une modification et de la justifier. L'une porte sur du code produit par un assistant, dans lequel j'ai glissé des erreurs, parce que relire ce code fait désormais partie du métier. Une autre porte sur le domaine du projet : l'étudiant qui a compris son projet y est avantagé, celui qui l'a entièrement délégué ne l'est pas.

Une mise en garde

Deslauriers et ses collègues (2019) ont comparé, en physique, un cours magistral et un cours où les étudiants travaillent en séance. Les seconds apprenaient davantage, mais avaient l'impression d'apprendre moins. Il est probable que mon cours donne la même impression à mes étudiants. Je le leur dis dès la première séance.

Ce qui n'est pas démontré

Deux de mes choix ne reposent, à ma connaissance, sur aucune étude publiée : la pondération de la note de projet par celle de l'épreuve, et l'épreuve où chaque étudiant modifie son propre dépôt, hors ligne et en temps limité. Ce sont des paris, qui me semblent cohérents avec le reste. Je recueille des données sur ce cours, de façon anonyme et avec l'accord des étudiants, et je publierai ce qu'elles montrent, même si elles me donnent tort.

Plusieurs des études citées portent sur d'autres publics que le mien : des lycéens, des étudiants en physique, des collégiens. Leurs résultats ne s'appliquent pas forcément tels quels à des apprentis ingénieurs. Le tableau ci-dessous indique la limite de chacune.

Références