Ce billet présente pourquoi et comment, en 2020-2021, je suis passé au contrôle continu intégral pour mon cours de programmation en C, en première année de Licence informatique.
Motivation, contraintes
Faire programmer les étudiant⋅e⋅s. La programmation s’apprend en programmant, il fallait trouver un moyen d’y inciter les étudiant⋅e⋅s. Traditionnellement, leur seule occasion de programmer est lors des TD, à supposer qu’iels y participent activement, ce qui est plutôt maigre.
D’habitude on résout ça en ajoutant des projets. Mais ça n’était pas possible sur notre première année de licence dont la maquette était déjà pleine, et la dotation complètement utilisée. De plus, les effectifs importants auraient rendu l’évaluation de projets très lourde à assumer.
Passer à l’échelle de grandes promotions. L’effectif justement est une contrainte importante. Des devoirs maisons, des contrôles, ou des examens sur table, génèrent une masse énorme de travail de correction. Il fallait une solution qui n’augmente pas ce travail, voire le diminue.
Ne pas augmenter le coût de la formation. Tout se faisant de nos jours à moyens constants, il n’était pas question d’ajouter des heures pour des projets, ou de rémunérer un lourd travail de correction.
S’accommoder du démerdentiel. Dès la rentrée 2020, on pouvait se douter que des enseignements auraient lieu à distance, totalement ou partiellement. Il fallait donc trouver un moyen de travailler mieux avec des étudiant⋅e⋅s à distance.
Un vrai contrôle continu plutôt que des points de contrôle éparses. Bien souvent, le contrôle dit continu consiste en un devoir unique, complété d’un examen. Pour le contrôle continu intégral, mon université exige deux devoirs au lieu d’un seul. C’est loin d’être continu et ça laisse peu de marge de progression. Par ailleurs, on a vu que multiplier les devoirs n’est pas une solution convenable à cause du temps de correction que ça engendre, mais aussi du temps d’enseignement que ça consomme (le devoir se passant en séance).
Mettre en cohérence l’apprentissage et l’évaluation. Si le cours de programmation a pour objectif d’apprendre à programmer, il faut aussi que les étudiant⋅e⋅ soient évalué⋅e⋅s sur leur capacité à programmer. Un examen sur table ne semble pas la meilleure façon d’y arriver. On peut certes en discuter mais ici l’idée était d’évaluer la programmation effectivement réalisée par les étudiant⋅e⋅s (et non les programmes, on verra la nuance).
Outillage
Pour permettre ce passage au contrôle continu intégral, j’ai développé l’outil badass
: (not so) bad assessments.
Il propose trois fonctions importantes: soumission en ligne des solutions aux exercices, évaluation automatique des programmes ainsi soumis, rapport synthétique des soumissions à destination des enseignant⋅e⋅s.
Soumission en ligne. Les étudiant⋅e⋅s peuvent déposer sur un site dédié leurs solutions aux exercices du TD. Iels sont identifié⋅e⋅s et tout ce qu’iels envoient est mémorisé pour garder la trace de leur activité et lever toute contestation possible sur le travail effectivement rendu. Chaque soumission engendre un rapport d’analyse avec un lien permanent que l’étudiant⋅e peut conserver pour revoir le rapport.
Évaluation automatique. Chaque programme soumis est automatiquement analysé par un script correspondant à l’exercice que le programme résout. Ce script permet de réaliser divers tests:
- est-ce que le programme compile
- est-ce qu’il se lance et s’exécute
- est-ce qu’il lit ou écrit certaines chaînes sur la console (on peut ainsi dialoguer avec le programme)
- est-ce qu’il contient certaines constructions attendues (par exemple telle ou telle fonction, une boucle avec un test à l’intérieur, etc.)
- est-ce qu’une fonction renvoie un résultat attendu (tests fonctionnels)
- est-ce que le programme fait des erreurs mémoire (fuites, variables non initialisées, double free, débordements de tampons, etc.)
Chaque test donne permet d’obtenir un score d’erreur: 0 (succès), 1 (alerte), 2 (erreur), et le script agrège les tests pour former un score global. Les résultats de ces tests sont donnés dans le rapport montré aux étudiant⋅e⋅s.
Rapports synthétique. Chaque enseignant⋅e peut télécharger un rapport sur les soumissions d’un groupe d’étudiant⋅e⋅s pour un ou plusieurs exercices. Ce rapport est une archive dans laquelle se trouvent tous les programmes envoyés par les étudiant⋅e⋅s des groupes sélectionnés pour les exercices sélectionnés, plus un tableau qui donne pour chaque soumission le résultat de chaque test et le score global, comme illustré ci-dessous:
En filtrant sur la colonne best=TRUE
, on peut se limiter à la meilleure soumission de chaque étudiant⋅e pour chaque exercice.
Organisation
Tout se déroule dans le cadre des séance de TD, sauf la résolution des exercice qui est faite dans le cadre du travail personnel de chaque étudiant⋅e, avant le TD, comme dans une classe inversée.
La première séance est consacrée à la prise en main de l’outil de soumission avec des exercices triviaux: recopier des programmes vus en cours et y faire des modifications mineures pour voir comment l’outil réagit, se confronter à des diagnostics d’erreurs, etc.
À la fin de chaque séance l’enseignant⋅e donne le travail à préparer pour la prochaine séance, avec une échéance de rendu.
Les étudiant⋅e⋅s s’organisent sur leur temps de travail personnel pour résoudre les exercices et soumettre leurs solutions en ligne. Chaque soumission étant automatiquement évaluée, iels ont un retour immédiat sur leur travail. Iels sont explicitement encouragé⋅e⋅s à soumettre plusieurs solutions si les diagnostics fournis par l’outil montrent des problèmes. On constate que certain⋅e⋅s soumettent de nombreuses versions et engagent un vrai travail d’amélioration progressif grâce aux diagnostics automatiques.
À l’échéance, l’enseignant⋅e récupère le rapport synthétique et peut préparer sa séance en sélectionnant les étudiant⋅e⋅s qu’iel souhaite interroger. Sur des séances de TD de 3h avec des groupes d’une trentaine d’étudiant⋅e⋅s, il n’est pas toujours possible de discuter avec chacun⋅e, en particulier à distance. On s’arrange alors pour ne pas voir toujours les mêmes de façon à avoir plusieurs évaluations régulières pour tout le groupe. Les quelques séances qu’on a pu faire à l’université avec les étudiant⋅e⋅s montrent qu’on peut faire plus d’entretiens dans ce cadre qu’à distance, ce qui n’est pas surprenant.
La séance est alors organisée en deux parties:
- L’enseignant⋅e s’entretient avec les étudiant⋅s en tête-à-tête, sur la base du travail rendu. Il s’agit de discuter le programme, de demander des explications sur la façon dont il est écrit ou comment il fonctionne, de demander des corrections, etc. L’objectif est d’évaluer la compréhension de l’étudiant⋅e sur l’exercice à résoudre et de vérifier qu’iel comprend ce qu’iel a rendu. Il est particulièrement rapide de découvrir qu’un programme a été récupéré ailleurs et rendu sans être compris.
- L’enseignant⋅e fait la correction des exercices, dans une forme de TD plus classique.
La première phase est l’occasion de comprendre ce qu’à fait chaque étudiant⋅e, de répondre à ses questions, et de l’accompagner dans la correction de ses erreurs et vers une meilleure solution. Un point délicat est de bien doser la part d’accompagnement et d’évaluation: j’ai tendance à commencer par des questions et des demandes d’explications, puis demander des changements, en accompagnant progressivement l’étudiant⋅e vers une amélioration pour voir s’iel y parvient seul⋅e ou avec quel degré d’aide.
Bilan
Plus d’investissement des étudiant⋅e⋅s. Le même cours a été organisé l’année précédente sous une forme de TD classique, avec aussi de l’enseignement à distance dans le cadre de l’opération mondiale Covid-19. Avec cette nouvelle organisation, on a constaté une très nette amélioration du travail des étudiant⋅e⋅s, qui sont plus investi⋅e⋅s dans le TD et de façon plus régulière. Pour certain⋅e⋅s, la peur du gendarme à joué puisqu’iels pouvaient être interrogé⋅e⋅s potentiellement à chaque séance. Mais d’autres réclamaient de passer pour discuter de leur travail et se sont déclaré⋅e⋅s très satisfait⋅e⋅s d’avoir des échanges réguliers avec leurs enseignant⋅e⋅s, et sur leur travail.
Un lien plus fort. L’équipe enseignante a été unanime pour constater que nous connaissons mieux les étudiants avec cette façon de travailler. Nous connaissons leurs aptitudes de façon plus fines, leurs qualités, leurs défauts, et même leur personnalité. Cette organisation a permis, de réduire la distance malgré des TD se déroulant en visio, en créant une relation personnelle avec chaque étudiant⋅e. De leur côté, les étudiant⋅e⋅s ont déclaré s’être senti⋅e⋅s mieux encadrés et mieux accompagnés qu’avec une forme de TD plus classique.
Une réorganisation du temps de travail. Cette organisation déplace une partie du travail: la résolution des exercices se fait sur le temps personnel et non plus sur le temps de TD. C’est sûrement souhaitable puisqu’on veut que les étudiant⋅e⋅s travaillent plus, mais il faut en tenir compte dans l’organisation globale de la formation pour ne pas saturer le temps de travail personnel.
La fin des copies à corriger. Quelle joie de ne plus corriger ces centaines de copies remplies de programmes écrits à la main et pleins de fautes de syntaxe! (Forcément, pas de compilateur en examen.) Quel plaisir de ne plus avoir à inventer de nouveaux sujets à chaque examen! Le TD peut être le même chaque année, l’effet de surprise devient inutile: de toute façon les étudiant⋅e⋅s ont les sujets avant d’être évalué⋅e⋅s dessus, s’iels veulent tricher iels le peuvent; simplement ça se verra à l’entretien.
Des étudiant⋅e⋅s satisfaits. Le retour des étudiant⋅e⋅s sur cette organisation a été très positif. Iels se déclarent unanimement satisfait⋅e⋅s par la possibilité d’avoir un retour constant et personnalisé, avec une évaluation adaptée au niveau de chacun⋅e. En revanche, certain⋅e⋅s ont eu plus de difficulté à comprendre leur note finale car certains entretiens peuvent se dérouler très cordialement, avec des perches tendues pour corriger des erreurs mais jamais saisies, et des erreurs constatées mais non relevées par l’enseignant⋅e. Il est donc important de pointer explicitement les problèmes lors des entretiens, et de se baser sur une grille d’évaluation précise (nous y reviendrons).
Programmer et parler programmation. Grâce aux entretiens, on se concentre beaucoup moins sur la présentation et l’explication d’une solution à un exercice. On parle de la solution de chacun⋅e, on la décortique, et on peut avancer vers une amélioration. La présentation d’une solution canonique en fin de séance et toujours utile, mais devient moins importante dans le déroulé du TD.
Évolutions
Occuper les étudiant⋅e⋅s pendant la phase d’entretiens. Un défaut de cette organisation est que, lors de la première phase d’une séance de TD, les étudiant⋅e⋅s qui attendent de passer en entretien avec l’enseignant⋅e n’ont pas d’activité assignée. Beaucoup trouvaient à s’occuper, par exemple en commençant les exercices suivants, ce qui leur permettait aussi de nous questionner dessus et de prendre de l’avance sur le TD suivant. Mais il faudra trouver un moyen de formaliser cela, peut être par des exercices supplémentaires, en lien avec ceux préparés pour la séance, et dont la correction serait donnée aussi à la fin mais sans évaluation.
Diversifier l’évaluation. À l’issue de cette année, l’équipe enseignante a ressenti le besoin d’ajouter des évaluations courtes et régulières (typiquement des QCM) sur des éléments plus classiques pour diversifier l’évaluation. Cela permettra en particulier d’évaluer des points de cours, de compréhension ou de connaissance, de façon mieux calibrée que lors des entretiens. Cela permettra aussi d’améliorer le ressenti des étudiants face à leur évaluation par une forme d’objectivation des résultats. Enfin, cela permettra de détecter des biais potentiels de l’évaluation à base d’entretiens: recours à une aide extérieure, difficultés d’expression orale, etc.
Améliorer la grille d’évaluation. Une difficulté cette année a été de donner des notes aux étudiants à l’issue de tous ces entretiens. Nous avions des comptes-rendus des entretiens et il nous a fallu définir un barème avec des points à évaluer à posteriori. Ce n’était pas facile. D’autant plus que certain⋅e⋅s étudiant⋅e⋅s avaient été absent⋅e⋅s, ce qui limitait notre visibilité sur leur travail.
L’an prochain, nous aurons une grille de compétences précises à évaluer, avec pour chacune un état non évalué, non acquis, en cours d’acquisition, ou acquis que nous pourrons ajuster à l’occasion de chaque entretien. Cela nous permettra de mieux cibler nos questions lors des évaluations et nous donnera une meilleur vision du niveau de chaque étudiant⋅e.
Centraliser le suivi des entretiens. Cette année, chaque enseignant⋅e était responsable de choisir les étudiant⋅e⋅s à évaluer lors de chaque séance. La grille d’évaluation pourra être partagée et mise à jour à l’issu de chaque séance et le tableau de synthèse pourra suggérer des étudiant⋅e à interroger à en fonction de l’état de cette grille selon les exercices effectivement soumis.
En conclusion
Fort de ce bilan très satisfaisant, je vais adopter le même mode d’évaluation pour mon cours de programmation système en deuxième année. C’est toujours de la programmation en C, on retrouvera les mêmes étudiants, on est en terrain connu.
Un autre enseignant va l’utiliser dans un autre cours de programmation en première année.
Cette fois ce sera de la programmation en processing.
Le défi va être de construire des exercices dont on pourra évaluer les solutions automatiquement (même de façon limitée), sachant qu’il sera difficile (voir impossible) de demander à badass
de regarder le résultat.
Par la suite, j’envisage de tenter l’expérience sur d’autres cours que de la programmation, mais il faut alors avoir des sujets de TD dont les réponses sont évaluables automatiquement, ce qui n’est pas forcément facile.