Ce que l'IA change dans un cours de développement

Un assistant de code écrit aujourd'hui, en quelques minutes, le projet que je donnais l'an dernier à mes étudiants : le code, le README, les diagrammes. Je ne dis pas ça pour m'en plaindre. Je le dis parce qu'une partie de mon métier devient caduque, et que mieux vaut la regarder en face que l'interdire.

Beaucoup d'enseignants réagissent en deux temps : d'abord la détection et l'interdiction, puis, plus tard, l'intégration. C'est ce que montre l'enquête de Lau et Guo auprès d'enseignants de programmation de neuf pays (Lau et Guo, 2023). Les deux réflexes se comprennent. Le premier échoue, parce que les détecteurs sont peu fiables et qu'un projet fait à la maison est invérifiable. Le second s'arrête en chemin : « laisser les étudiants utiliser l'IA » n'est pas une pédagogie.

Voici ce que je retiens de cette lecture, et le cours que je vais refaire à partir de là.

Ce que l'assistant fait aux débutants

Le résultat le plus solide vient d'un essai contrôlé mené auprès de près d'un millier de lycéens turcs en mathématiques (Bastani et al., 2025). Pendant les séances d'exercices, les élèves qui avaient accès à un assistant type ChatGPT réussissaient nettement mieux que les autres. L'accès retiré pour l'examen, ils faisaient moins bien que ceux qui n'avaient jamais eu l'outil. Seule une version bridée, qui donnait des indices au lieu des réponses, préservait l'apprentissage. Ce sont des lycéens en maths, pas des étudiants en informatique, et je transpose avec prudence ; le mécanisme, lui, est celui que tout enseignant de programmation observe chaque année : la réponse générée donne l'impression d'avoir compris. J'avais déjà cité cet essai dans le texte du stage de pré-rentrée en prépa, où je m'adressais aux élèves ; ce que j'en tire ici concerne la conception du cours.

Chez les programmeurs débutants, Prather et ses collègues ont observé deux populations qui divergent, en laboratoire et avec suivi oculaire (Prather et al., 2024). Ceux qui maîtrisent déjà les bases se servent de l'assistant pour aller plus vite et savent rejeter une suggestion fausse. Les autres s'enfoncent : ils acceptent du code qu'ils ne comprennent pas et se construisent de faux modèles mentaux. L'étude est qualitative, l'échantillon petit, mais elle confirme ce qu'une expérience antérieure avec Codex laissait déjà voir : les élèves les mieux préparés sont ceux qui profitent le plus de l'outil (Kazemitabaar et al., 2023).

J'en tire un principe de travail : on ne vérifie pas ce qu'on ne comprend pas. Savoir piloter une IA suppose de savoir lire, diagnostiquer et modifier du code sans elle.

Deux choses à enseigner, dans cet ordre

Ce principe a une conséquence que je n'avais pas mesurée en commençant. Un cours de développement doit désormais enseigner deux choses distinctes, et les enseigner toutes les deux.

La première, ce sont les bases sans IA : lire du code, y trouver ce qui cloche, le modifier, justifier un choix. Rien de nouveau dans la liste ; ce qui est nouveau, c'est qu'il faut les certifier explicitement, dans des conditions où l'assistant n'est pas là, parce que rien d'autre ne les certifie plus.

La seconde, c'est l'usage de l'IA pour aller au-delà des bases. Cette compétence n'est pas le prompt, qui se périme en six mois. Ce sont quatre choses plus durables : cadrer un problème avant de déléguer, en commençant par les interfaces ; vérifier ce qui a été produit, par la relecture et par des tests conçus pour attraper les erreurs de l'outil ; intégrer vingt contributions générées dans une base de code qui reste cohérente ; et répondre de chaque ligne, c'est-à-dire pouvoir l'expliquer et la faire évoluer. Bearman et ses collègues appellent la deuxième « jugement évaluatif », la capacité à juger de la qualité d'un travail, le sien et celui des autres, et ils en font l'acquis central d'une formation à l'ère de l'IA générative (Bearman et al., 2024).

L'ordre compte. Les points deux et quatre sont impossibles sans la première compétence. Un étudiant qui ne sait pas lire du code ne pilote pas l'IA, il la subit. Enseigner la seconde sans avoir certifié la première, c'est former des gens qui acceptent ce qu'ils ne comprennent pas ; c'est exactement la population que Prather décrit.

Ce que prouve un rendu

Un projet rendu ne dit plus grand-chose sur celui qui le rend. Le problème existait avant les LLM : une étude finlandaise montrait qu'une part notable d'étudiants ne savaient pas expliquer le fonctionnement du code qu'ils avaient eux-mêmes soumis (Lehtinen et al., 2021). L'IA en a changé l'échelle.

Plusieurs universités en ont tiré un cadre, celui de l'Université de Sydney étant le plus explicite : deux voies d'évaluation. Une voie sécurisée, en présentiel et sans IA, qui certifie les acquis. Une voie ouverte, où l'IA est autorisée puisqu'on ne peut pas l'interdire, et qui sert à apprendre. L'échelle AIAS de Perkins et ses collègues formalise la même idée en niveaux d'usage autorisé, à fixer pour chaque évaluation selon ce qu'elle mesure (Perkins et al., 2024).

Je résume ça par une image : le permis et la conduite. L'épreuve sans IA délivre le permis, le projet avec IA note la conduite, et une note de conduite sans permis ne certifie rien. L'image a ses limites, dont une qui compte : on ne repasse pas son permis chaque semestre, alors qu'un étudiant progresse pendant qu'on l'évalue. Mon partiel se fera donc sur papier, et demandera de lire du code, d'y trouver le défaut, de proposer la modification et de la justifier. Y compris du code généré par une IA, avec des défauts plantés, puisque la relecture est devenue une compétence centrale.

Sur ce dernier point, une étude de METR mérite d'être citée avec ses limites. En 2025, seize développeurs expérimentés ont mis 19 % de temps de plus sur leurs tâches avec un assistant IA, tout en ayant l'impression d'être allés plus vite (Becker et al., 2025). L'échantillon est minuscule et l'intervalle de confiance large ; la réplication de 2026, avec 57 développeurs, ne trouve plus qu'un effet proche de zéro. Reste l'écart entre le ressenti et la mesure, et c'est lui qui m'intéresse comme enseignant. Un développeur ne sait pas, de l'intérieur, si l'IA l'aide. Il faut donc lui apprendre à vérifier au lieu de se fier à son impression.

Deux formats qui meurent

Deux formats ne survivent pas à ce qui précède, et je préfère le dire nettement.

Le cours en amphi, d'abord. Sa fonction était de transmettre de l'information, et c'est devenu la ressource la moins rare qui soit. Un assistant explique le polymorphisme aussi bien qu'un amphi, à la demande, à trois heures du matin, et il répond aux questions. Ce qu'il ne donne pas, c'est un retour sur ce que l'étudiant produit, et un jugement exercé devant lui. Le format consacrait l'essentiel du temps en présence à ce qui est abondant, et presque rien à ce qui est rare.

Le TP guidé, ensuite. Un énoncé pas à pas, avec le squelette fourni et le nom du patron dans le titre, se résout en trente secondes avec un assistant. Même avant, il produisait du code qui marche sans que l'étudiant ait pris une seule décision. Il n'a plus de valeur formative, puisqu'on n'y apprend rien qu'on ne puisse déléguer, ni de valeur évaluative, puisque le résultat ne dit rien sur son auteur.

Ce qui meurt, c'est la transmission orale longue et l'exercice d'application sans décision. Ce qui ne meurt pas, c'est l'explication, quand elle est courte et arrive au moment où le besoin vient d'être ressenti, et la pratique sur machine, quand elle part d'une situation et exige un choix.

Mes vidéos, et l'investissement pour rien

J'avais déjà basculé mes cours en ligne, sous forme de vidéos. Beaucoup d'heures de tournage. Ma première réaction en lisant tout ceci a été de me dire que c'était de l'investissement perdu : si l'assistant explique mieux que l'amphi, il explique aussi mieux que l'amphi filmé.

C'est en partie vrai, et il faut le dire. Une vidéo qui reproduit un cours magistral reproduit ses défauts, sans même la présence de l'enseignant. L'étude de référence sur le sujet, menée sur près de sept millions de sessions de visionnage de cours en ligne, montre que l'attention chute après six minutes quelle que soit la longueur de la vidéo, que les cours filmés en salle engagent peu, et que les formats où l'on résout un problème à l'écran font mieux que les diapositives commentées (Guo, Kim et Rubin, 2014). Elle mesure l'engagement, pas l'apprentissage, et sur des MOOC, pas en formation initiale. Mais le message est sans ambiguïté : le tunnel filmé n'est pas meilleur que le tunnel en salle.

En partie seulement. Ce qui perd sa valeur, c'est l'idée que la vidéo remplace le cours. Ce qui en garde, c'est la vidéo comme ressource à la demande : six minutes sur un point précis, qu'un étudiant regarde parce qu'il a buté dessus, suivies d'une question à laquelle il doit répondre. Dans le cours que je refais, elle devient la moitié hors séance : le support de celui qui a décroché pendant l'explication, celui que l'avancé saute, et le point de renvoi quand un quiz révèle une notion faible. Mes heures de tournage ne sont pas perdues ; je vais les redécouper, et personne ne les regardera plus passivement. Regarder une vidéo produit la même illusion de maîtrise que lire une réponse générée. Sans tâche derrière, elle ne vaut rien.

Le temps en présence

Ce que l'IA rend obsolète, c'est la transmission d'information. Le temps en présence va désormais au retour et au jugement.

La recherche le disait avant les LLM. La méta-analyse de Freeman et ses collègues, sur 225 études en sciences et en ingénierie, trouve un gain d'environ un demi écart-type aux examens pour les pédagogies actives, et un taux d'échec qui passe de 34 % à 22 % (Freeman et al., 2014). En informatique, l'instruction par les pairs, où l'on vote, on discute avec son voisin, puis on revote, réduit le taux d'échec de moitié environ sur quatre cours suivis pendant dix ans (Porter, Bailey Lee et Simon, 2013).

Une réserve, de taille. « Actif » ne veut pas dire « débrouillez-vous ». Pour des novices, l'enseignement explicite et les exemples résolus font mieux que la découverte (Kirschner, Sweller et Clark, 2006). Cet article est contesté, et il se lit comme une position forte plutôt que comme un consensus, mais son cœur tient : le guidage aide ceux qui ne savent pas encore, et gêne ceux qui savent déjà. D'où le format que j'adopte : des apports courts de cinq à sept minutes, en direct sur du code, suivis d'une tâche à trois profondeurs au choix. Tout le monde avance à la même heure, pas à la même profondeur.

Et un avertissement que je donnerai à mes étudiants dès la première séance : dans une expérience randomisée à Harvard, les étudiants en pédagogie active apprenaient plus, mais avaient l'impression d'apprendre moins (Deslauriers et al., 2019). Le confort de l'amphi est une illusion de maîtrise, comme la réponse générée.

Lire avant d'écrire

La page blanche est le terrain où les LLM sont les meilleurs. Un code existant, avec ses contraintes, ses bugs et une demande de changement, oblige à comprendre avant d'agir. C'est aussi le quotidien du métier : on maintient beaucoup plus de code qu'on n'en écrit.

La didactique de la programmation va dans ce sens depuis longtemps. Savoir tracer et expliquer du code prédit la capacité à en écrire (Lopez et al., 2008 ; Xie et al., 2019), et les approches qui font prédire, exécuter, examiner puis modifier avant de créer donnent de meilleurs résultats en classe hétérogène (Sentance, Waite et Kallia, 2019). Ces travaux portent souvent sur des débutants plus jeunes que mes étudiants, et les premiers sont corrélationnels ; ils convergent quand même.

Mes exercices commenceront donc par un bug, une revue de code ou une demande de changement, jamais par « créez une classe ».

Ce qui reste à prouver

Je ne vais pas prétendre que tout ce que je viens de décrire est validé. Deux de ces choix n'ont, à ma connaissance, aucune étude publiée : pondérer la note d'un projet fait avec IA par celle d'une épreuve individuelle sans IA, et faire modifier à chaque étudiant son propre dépôt, hors ligne, en temps limité. Ce sont des hypothèses cohérentes avec ce qui précède, pas des résultats. Je les mets en place, je recueille les données, et je dirai ce qu'elles montrent, y compris si elles me donnent tort.

Ce qui est établi tient en quelques lignes. L'IA amplifie l'écart entre ceux qui ont les bases et ceux qui ne les ont pas. Il faut donc enseigner les deux, les bases sans l'outil, puis l'outil pour les dépasser, et certifier la première avant de noter la seconde. Le rendu ne prouve plus rien ; l'explication et la modification prouvent encore quelque chose. Le temps en présence vaut plus quand il sert au retour et au jugement qu'à la transmission. Et la sensation d'apprendre est un mauvais indicateur, chez l'étudiant comme chez l'enseignant.

Il me reste à écrire le sujet de janvier. Il tiendra sur deux pages de code que je n'ai pas écrites, et la première question sera : qu'est-ce qui ne va pas, ici ?

Références