Concevoir un examen de programmation

Concevoir un examen de programmation
(et le corriger)

Laurent Bloch

Cet article fait suite à celui intitulé « Enseigner l'informatique aux biologistes » [1].

Enseigner la programmation à des débutants

Depuis quelques années j'enseigne avec quelques collègues la programmation dans un cursus de bio-informatique au Cnam. Au premier semestre l'unité d'enseignement (UE) Initiation à la programmation comporte 36h de cours et 36h de travaux dirigés, l'UE du second semestre, de mêmes dimensions, est intitulée Algorithmique de la bio-informatique, le tout pour un total de 12 ECTS (l'unité de compte européenne standard des enseignements du supérieur). La doctrine des enseignements du Cnam veut que le volume horaire soit plus faible que dans les universités, au motif que ce déficit d'enseignement serait compensé par la pratique professionnelle des auditeurs (on ne dit pas étudiants) dans l'entreprise où ils ont, en principe, un emploi (le Cnam s'adresse à un public d'auditeurs engagés dans la vie professionnelle). Chacune de ces UE est sanctionnée par un examen.

Une caractéristique des auditeurs de ces UE est que ce sont des biologistes. La première conséquence à en tirer, ce dont une expérience précédente à l'Institut Pasteur [2] m'avait déjà donné l'occasion, est la nécessité d'éviter les exemples ou les applications mathématiques, parce que l'auditoire risque d'y être peu réceptif. Chaque année j'annonce la liste limitative des chapitres mathématiques pour lesquels des notions très élémentaires pourront être utiles, outre l'addition et la multiplication :

les ensembles ;
la logique des prédicats ;
les fonctions ;
les systèmes de numération et la représentation des nombres ;
l'analyse combinatoire ;
l'algèbre linéaire.

Ici j'insiste : il ne s'agit pour chacun de ces domaines que de notions élémentaires, telles que les connaît un bon élève à la fin de l'enseignement secondaire, inutile de charger la barque. On me dit que les programmes du secondaire abandonnent peu à peu tout ce qui a trait aux nombres et à ce que l'on nomme « algèbre abstraite », c'est-à-dire les notions de base de théorie des ensembles : c'est très regrettable, pas seulement pour l'informatique.

Une autre caractéristique du public biologiste à considérer est la différence de nature entre biologie et informatique : la biologie est une science de la nature, qui décrit et tente d'expliquer des phénomènes naturels. Le rôle de l'étudiant est de retenir les descriptions et les explications et d'être en mesure d'en parler intelligemment (il y a belle lurette que les universités ne sont plus en mesure de mettre à la disposition de leurs étudiants des laboratoires dignes de ce nom où ils pourraient s'adonner au versant expérimental de la biologie, en tout cas dans le premier cycle ; c'est misérable mais c'est ainsi ; si je pouvais être démenti j'en serais ravi).

L'informatique ne décrit aucune réalité, elle construit des objets abstraits auxquels elle donne une capacité d'agir. L'important n'est donc pas que l'auditeur retienne ce que dit l'enseignant, mais qu'il soit capable de construire ses propres objets. Si en cours l'enseignant passe le plus clair de son temps à écrire des programmes au tableau (c'est ce que je fais), ce n'est pas pour que les auditeurs les apprennent, mais pour qu'ils les imitent.

Il est donc indispensable de programmer soi-même, par ses propres moyens, en tête à tête avec son ordinateur. Sauf à consentir à cet exercice, point de succès. Convaincre les auditeurs de cette nécessité, et obtenir qu'ils agissent en conséquence, est le plus difficile. Cette difficulté n'est pas propre à ce public en particulier, des collègues qui enseignent dans des cursus d'informatique pure et dure m'ont dit la rencontrer également. Ce qui est sûr, c'est que seuls atteindront le but ceux qui auront programmé, et que c'est à eux seuls qu'il convient d'accorder le visa de l'examen. Le donner à ceux qui n'ont jamais programmé serait un très mauvais service à leur rendre, et risquerait de donner naissance à une population de pseudo-informaticiens, il en existe déjà assez comme cela par génération spontanée, ou du fait de certains enseignements qui sont des escroqueries intellectuelles.

Comment enseigner

Aujourd'hui la mode est aux MOOC, il en est d'ailleurs d'excellents comme celui-ci [3]. Ce n'est pas si nouveau que cela, déjà dans les années 1980 j'ai participé au Cnam à des projets de ce que l'on appelait alors Enseignement à distance, et les résultats étaient significativement bons. Mais je ne crois pas que ces méthodes qui opèrent par le truchement d'ordinateurs et de réseaux soient suffisantes. L'enseignement, me semble-t-il, est fondamentalement une entreprise de séduction, et d'ailleurs de séduction réciproque (c'en est d'ailleurs un danger, vis-à-vis duquel l'enseignant scrupuleux doit toujours se tenir sur ses gardes) ; or la séduction opère mieux en situation de présence réelle du séducteur.

Il y a aussi la question du vidéo-projecteur : chaque fois que la paresse d'écrire au tableau m'a poussé à son usage, force m'a été de constater que je n'avais plus qu'à recommencer le cours. Autant cet appareil est bien adapté à un exposé cursif d'une heure ou deux, autant lorsqu'il s'agit d'apprendre vraiment à faire des choses il ne convient pas. Certes, l'usage pour mes cours d'un langage de programmation concis à la syntaxe très sobre (Scheme) [4] m'aide à pouvoir tout écrire au feutre ou à la craie. Et en outre j'ai reçu, pour ce choix démodé, un soutien de poids, de Cédric Villani [5], qui explique que l'avantage de la craie, c'est qu'elle va, sur le tableau, à la même vitesse que la pensée. On ne saurait mieux dire.

Depuis déjà quelques années le dernier mot de l'enseignement de la programmation semblerait être la conduite de projet par les étudiants. Oui, sans doute, mais pas partout ni tout le temps. Un étudiant qui débute en programmation doit d'abord ingurgiter un certain volume de connaissances techniques avant de voler de ses propres ailes. L'auto-apprentissage et les échanges de pair à pair peuvent occasionner beaucoup de pertes de temps et de mauvais choix comme j'ai eu l'occasion d'en faire moi-même l'expérience [6]. Un débutant aura du mal à déterminer l'objet de son projet. Et de toute façon, avec le petit nombre d'heures dont nous disposons pour ces enseignements du Cnam, le mode projet est impossible : de par mon expérience à l'Institut Pasteur, il faut au moins 200 heures d'enseignements avant de pouvoir lancer les étudiants dans un projet, pour lequel il leur faudra encore 200 heures de travail. Les licences d'informatique et les écoles d'informatique disposent peut-être de tels budgets horaires, mais pas le Cnam.

Pour la remise en cause du tout-projet dans l'enseignement de la programmation je dispose aussi d'un allié ; Mark Guzdial, professeur au Georgia Institute of Technology, a publié dans le numéro de février 2015 des Communications of the ACM (CACM) un article intitulé « What's the Best Way to Teach Computer Science to Beginners ? » [7], où il défend un peu le même point de vue que moi : placer des étudiants débutants en situation d'avoir à découvrir par eux-mêmes l'information dont ils ont besoin, en les lançant dans le grand bain comme s'ils étaient déjà des professionnels, est une mauvaise idée.

Concevoir un examen de programmation

Venons-en à la question de l'examen. Puisqu'il conclut un cours de programmation, il consistera en écriture de programmes.

Examen sur ordinateur

L'écriture de programmes par les candidats peut avoir lieu sur ordinateur. C'est ce qui semble le plus logique, mais l'organisation pratique de l'examen ne va pas sans difficultés :

il faut équiper le centre d'examens en ordinateurs, dotés de tous les logiciels nécessaires mais dépourvus de moyens de communication propres à permettre la fraude ; lorsque j'étais à l'université Paris Dauphine l'équipe du Centre d'Ingénierie pédagogique dirigé par Cécile Chevalier avait mis en œuvre une plate-forme adéquate, mais cela n'avait été ni facile ni bon marché ;
pour bien faire il faut une plate-forme logicielle qui permette la correction automatique des épreuves ; Christian Queinnec a présenté en 2010 aux Journées francophones des langages applicatifs (JFLA) une telle plate-forme [8], réalisée par lui et dont l'expérience est poursuivie par le MOOC cité ci-dessus : c'est sûrement plus de 1 000 heures de travail, parce qu'il faut, en sus des contraintes évoquées ci-dessus, pouvoir fournir au candidat des réponses telles que « la question était <...>, la réponse correcte était <...>, vous avez répondu <...>, ce qui diffère de la réponse correcte ainsi : <...> » ; on mesure la difficulté de l'exercice, qui en plus demande des ajustements pour chaque épreuve particulière, pour chaque langage proposé aux candidats ; l'entreprendre n'est raisonnable que pour de grands effectifs et pour des épreuves qui comportent l'écriture de programmes d'une taille certaine ; pour nos cours du Cnam, qui plafonnent à quarante candidats, la tâche était démesurée.

Examen sur papier avec documents

Après renonciation à l'examen sur ordinateur restait à imaginer un examen sur papier. Cette idée peut sembler saugrenue à quiconque connaît surtout de l'informatique l'art de promener judicieusement une souris sur un cliquodrome, ce qui a aussi peu à voir avec l'informatique que l'examen du permis de conduire a à voir avec la thermodynamique.

En fait la programmation avec crayon et papier est un exercice exigeant et formateur, parce que le programmeur y est privé de l'aide de l'ordinateur, cet ami fidèle qui sait vous indiquer vos erreurs de syntaxe et indenter correctement pour vous les textes de vos programmes, ce qui les rend lisibles, et donc compréhensibles. L'excellente école russe de programmation doit en partie sa qualité au fait que sous le régime soviétique les ordinateurs étaient fort rares, et que les étudiants recevaient, en quelque sorte pour compenser, un fort enseignement théorique.

Reste le problème de la syntaxe : écrire un programme, c'est écrire un texte selon un langage à la syntaxe rigide. Comme l'a bien expliqué Matthias Felleisen [9], l'apprentissage de la syntaxe d'un langage est bien sûr une étape obligée, mais dépourvue de tout intérêt intellectuel, vers l'exercice de la programmation, il convient de la réduire au minimum.

Si l'examinateur autorise les candidats à se munir de documents, il concevra le sujet en conséquence. Il sera notamment fondé à exiger que les programmes fournis soient syntaxiquement corrects, puisque les candidats auront eu accès au manuel de référence du langage. Le sujet pourra ainsi être plus difficile.

D'expérience, pour un examen d'informatique avec documents autorisés, les candidats arrivent avec des tonnes de manuels dans lesquels ils perdent un temps considérable à chercher des solutions aux problèmes posés par l'examinateur. Ce n'est pas un service à leur rendre que de leur donner une telle autorisation.

Examen sur papier sans documents

Notre choix se porta vers la solution la plus simple tant pour les candidats que pour les examinateurs : épreuve sur papier sans aucun document autorisé. Et pour élaborer les épreuves je me fonde, comme pour bien d'autres choses, sur les conseils de Jacques Arsac, prodigués en l'occurrence par le canal d'un article de Technique et Science informatiques (TSI) dont malheureusement je ne dispose plus, et que l'on ne trouve pas sur le Web, ce qui serait toujours bien utile.

Comme l'expliquait donc Jacques Arsac, puisque les candidats ne disposent ni d'ordinateur ni de documents pour les aider, il faut tolérer que les textes des programmes comportent des erreurs, et notamment des erreurs de syntaxe. En effet sinon ils seraient conduits à apprendre le manuel de référence par cœur, exercice punitif et peu productif. Afin de limiter les erreurs de syntaxe, les sujets que je donne en examen comportent toujours des exemples de programmes où figurent les constructions dont les candidats auront besoin pour élaborer leurs solutions, ainsi ils peuvent s'en inspirer.

Pour corriger, je cherche d'abord à savoir jusqu'à quel point le candidat a compris en quoi consistait la programmation, et cela mérite déjà quelques points si c'est suffisant. Par exemple un programme écrit n'importe comment, sans indentation, illisible en un mot, atteste que le candidat n'a jamais vraiment programmé pendant le semestre, et ne mérite donc pas d'être reçu. Ensuite seulement je m'attache à la façon dont le candidat a compris et réalisé l'algorithme demandé. Là aussi il peut y avoir des erreurs, par exemple aux bornes de l'intervalle parcouru par une répétition conditionnelle : ce type d'erreur serait facilement (enfin, cela dépend...) détecté et corrigé par un programmeur muni de l'appareil expérimental que constitue l'ordinateur, mais avec son seul cerveau c'est très difficile. Comme l'écrit Emmanuel Saint-James : « La programmation est une transmission d'un raisonnement à une machine, capable de le reproduire. Par cette reproduction, sans laquelle il n'est point de science, l'ordinateur s'affirme comme un instrument d'objectivation du raisonnement. Il s'inscrit dans la lignée des appareils qui ont permis de passer de l'expérience empirique à l'expérimentation scientifique : l'informatique se distingue des mathématiques par un outil d'expérimentation permettant d'observer, vérifier, réfuter un raisonnement. »

Dévoiler des parties de la solution ?

Examen n'est pas concours : il ne s'agit pas de classer les candidats selon une relation d'ordre la plus rigoureuse possible, mais de les séparer en deux groupes, ceux dont les acquisitions intellectuelles justifient le succès et ceux qui doivent persévérer parce qu'il n'ont pas acquis ce qu'il fallait, et qui sont donc recalés. Ensuite, au sein de chaque groupe, les notes servent surtout à féliciter ceux qui ont été brillants, à mettre en garde ceux qui ont été reçus de justesse et qui doivent travailler pendant les vacances s'ils veulent échapper à une déconvenue lors du semestre suivant, à redonner du courage à ceux qui ont échoué par incompréhension du but à atteindre mais qui ont fait preuve de bonne volonté, enfin à manifester à ceux qui n'ont rien fait qu'ils ne peuvent espérer tromper leur monde.

Pour savoir auquel des deux groupes appartient l'auteur d'une copie, le plus souvent il suffit d'une fraction de seconde : la présentation du texte des programmes (ou de ce qui est censé en tenir lieu) suffit pour savoir à qui on a affaire. En fait, souvent je donne en sujet d'examen un problème que j'ai traité en cours. Au début j'agissais ainsi prudemment, et je me suis rendu compte que cela ne changeait rien au résultat, en considérant bien sûr qu'il ne s'agit pas d'un concours. Et même en plaçant dans l'énoncé de la question numéro n+1 la réponse à la question numéro n, cela ne change rien : ceux qui doivent échouer échouent, parce que pour eux le langage de la programmation est de toute façon incompréhensible. Et pour ceux qui doivent réussir, cela évite les accidents dus par exemple à la panique de l'examen qui saisit parfois certains candidats.

En tout cas, pour mes prochains cours, je prendrai plus de temps à expliquer en quoi l'informatique diffère de la biologie, pourquoi il faut absolument programmer, et j'espère ainsi convaincre un plus grand nombre d'auditeurs.

Laurent Bloch
http://www.laurentbloch.org/MySpip3/spip.php?auteur1

Paru sur le site de Laurent Bloc le lundi 8 février 2016.
http://www.laurentbloch.org/MySpip3/spip.php?article326
http://www.laurentbloch.org/MySpip3/IMG/pdf/corrige-exam-bnf102-2016.pdf

Cet article est sous licence Creative Commons (Attribution 3.0 non transposé = Paternité). http://creativecommons.org/licenses/by/3.0/deed.fr

NOTES

[1] http://www.laurentbloch.org/MySpip3/spip.php?article244

[2] http://www.laurentbloch.org/MySpip3/spip.php?article244

[3] http://programmation-recursive.net/

[4] http://www.laurentbloch.org/MySpip3/spip.php?article48

[5] http://www.laurentbloch.org/BlogLB/spip.php?article168

[6] ttp://www.laurentbloch.org/MySpip3/spip.php?article253

[7] http://cacm.acm.org/blogs/blog-cacm/45725-how-we-teach-introductory-computer-science-is-wrong/fulltext

[8] http://jfla.inria.fr/2010/actes/PRESENTATIONS/invite-queinnec.pdf