Enseigner le développement web à 85 étudiants sans s’arracher les cheveux ✌️
C’est plus compliqué que je croyais ! Quelques idées reçues, expérimentations, et conseils pratiques.
Pendant mes derniers mois comme responsable des développements dans la startup parisienne Whyd, j’avais une envie pressante de transmettre mon expérience, d’enseigner. Depuis, j’ai exprimé cette envie de trois manières:
- en partageant mes expériences sur Medium,
- en co-réalisant un MOOC sur la création de startup: Startup Tour,
- et en rejoignant une école post-BAC comme enseignant en programmation JavaScript, pour des étudiants en début de cursus.
Chacune avait ses défis, mais enseigner en école était de loin l’expérience de transmission la plus contre-intuitive, et donc la plus fascinante pour moi.
Idée reçue nº1: compréhension par défis pratiques
Je pensais que mes étudiants, issus de la génération Z, maitrisaient tous l’informatique et l’usage du web. Je pensais que, dopés à Wikipedia et aux MOOC gratuits depuis des années, il me suffirait de leur donner un défi pratique pour qu’ils trouvent d’eux même les informations nécessaires.
J’ai alors conçu un plan de cours “fun”, basé sur la pratique et l’expérimentation, et ponctué de défis comme: “modifier la page de google”, “développer son propre twitter”, ou encore “implémenter le jeu chi-fou-mi en JavaScript”. Chaque défi servait d’excuse pour découvrir au fur et à mesure les concepts nécessaires de programmation: structures conditionnelles, fonctions, manipulation d’une page web, requêtes AJAX…
Pourtant très bien équipés (la plupart avec des MacBook Pro) et bien connectés (Facebook, Snapchat, forum de classe mis en place par l’école…), il s’est avéré que la plupart de mes étudiants bloquaient très vite sur les premières difficultés de mise en oeuvre. Au lieu de trouver une solution sur Google ou de me demander de l’aide, beaucoup préféraient se changer les idées en visitant leur fil Facebook…
À ma grande surprise, j’ai changé la vie de plus d’un étudiant en faisant découvrir le raccourci clavier Cmd-F (ou Ctrl-F, sur PC), après avoir constaté qu’ils perdaient du temps à scroller dans mes supports de cours, à la recherche d’un mot-clé !
En fin d’année, ma conclusion était claire: les défis, c’est bien pour susciter l’attention, mais je ne dois pas compter sur mes étudiants pour découvrir les bases d’eux-mêmes.
J’ai donc:
- Conçu un plan de cours plus traditionnel: expliquer les bases avant de lâcher les étudiants sur des défis plus excitants (mais plus complexes).
- Fourni des supports de cours complets, ainsi que des liens alternatifs de référence pour ceux qui cherchent une manière différente d’expliquer.
- Demandé aux étudiants de fermer leur ordinateur pendant mes explications du début de cours (20–30 minutes max sur 2 heures de TP), pour pas qu’ils ne se laissent distraire.
Idée reçue nº2: étudiants déterminés à progresser
J’ai eu la chance de me passionner très jeune pour l’informatique et la programmation. Après avoir été contraint de suivre plus de 10 ans de tronc commun (primaire, collège, lycée), vous imaginez ma joie quand j’ai enfin pu commencer mes études d’informatique !
En signant comme enseignant dans une “École du Web”, j’étais persuadé que mes étudiants seraient assoiffés de connaissances et de pratique sur ce domaine passionnant, et qu’ils m’épuiseraient sous leurs questions et demandes incessantes de défis supplémentaires !
J’avais oublié quelques facteurs, dans mon raisonnement:
- L’informatique est devenu un marché extrêmement attractif. Mes étudiants ne sont donc pas là juste par pure passion pour le domaine. D’ailleurs, ils ne sont même pas surs de ce qu’ils comptent faire après la formation, pour la plupart.
- Mes étudiants ne se sont pas offerts un bootcamp de 2 mois focalisé sur le développement web. Ils ont intégré un cursus de 3 ans couvrant à la fois le développement, le design et le marketing web. Ils ont donc des motivations variées et incertaines. Et ils savent qu’ils ne pourront pas s’investir à 100% dans toutes les matières du cursus, la mienne comprise.
- Enfin, même si créer une application mobile ou un jeu peut leur paraitre attractif, ils n’ont pour la plupart jamais tapé une ligne de code. Il faut donc s’attendre à ce que certains se démotivent très vite, dès les premières incompréhensions.
Attention réduite, étudiants perturbateurs, cours non révisés, désengagement… Je me suis vite rendu compte que donner un cours très pratique et “fun” ne suffisait pas, il fallait que j’adapte ma méthode de transmission.
J’ai alors appliqué les conseils d’Eduvoices (notamment sur l’usage de différents styles de transmission), me suis documenté sur les pratiques pédagogiques innovantes et les ai expérimentées: classe inversée, apprentissage actif (basé sur le questionnement), entre autres… en vain.
Force est de constater que:
- Mes étudiants ont un comportement trop scolaire pour adhérer à certaines de ces pratiques. Ils focalisent leurs efforts sur les travaux notés, en défaveur des autres activités pourtant nécessaires pour un bon apprentissage sur la durée. (ex: relecture du cours entre deux TPs, refaire les exercices pour s’entrainer, projets perso…)
- Ils ont beaucoup de progrès à faire en termes de rigueur, une aptitude très importante pour la programmation informatique, mais apparemment trop peu développée par les méthodes pédagogiques que j’ai testées.
J’ai alors mis en place deux changements dans ma pédagogie:
- Renforcé mes styles de transmission secondaires: rationnel et émotionnel. (sachant que mon style principal est opérationnel)
- Ajouté plus de contrôle continu, pour aider les étudiants à repérer leurs acquis et lacunes. Je leur propose désormais de remplir un QCM rapide (non noté) au début de chaque TP, pendant que je fais l’appel, puis réponds à leurs questions. Et j’ai ajouté des contrôles individuels courts mais notés, pour les inciter à réviser.
Astuce: Placer un contrôle individuel noté en milieu de TP aide pour augmenter l’attention et inciter les étudiants à poser des questions sur ce qu’ils ne sont pas surs d’avoir compris. C’est aussi moins stressant pour les étudiants.
Idée reçue nº3: corriger les copies est chronophage
Certes, augmenter le nombre de contrôles individuels (notés ou pas) permet d’inciter les étudiants à mieux s’engager dans le processus d’apprentissage.
Mais, en tant qu’intervenant à mi-temps, et rémunéré seulement pour les heures de cours données en classe, la correction systématique des copies de 85 étudiants revient vite cher, non ?
Oui, si vous décidez de tout faire à la main.
Heureusement, l’informatique peut nous rendre bien plus efficaces !
Par exemple, saviez-vous que Google Forms permettait de générer gratuitement des QCMs avec notation automatique ? Pour dissuader la triche, vous pouvez ordonner les questions de manière aléatoire. Et, en plus, vous pourrez mesurer en un clin d’oeil quels sont les concepts à ré-expliquer à vos étudiants, grâce aux graphiques produits instantanément par l’outil !
Les QCMs sont un excellent outil pour aider les étudiants à auto-évaluer leur compréhension des concepts du cours. Mais quid de leur maitrise pratique ?
Encore une fois, il existe nombreux outils gratuits sur internet pour aider vos étudiants à mesurer leur progression par la pratique. Par exemple, je les fait travailler sur l’excellent CodinGame, pour visualiser de manière ludique le fonctionnement d’un algorithme, et s’habituer à tester leur code en variant les paramètres.
Même si mes étudiants apprécient cet outil, certaines contraintes m’empêchent de l’utiliser comme outil de contrôle individuel des connaissances:
- Je n’ai pas trouvé de moyen de générer une note et/ou une liste d’acquis et de lacunes de manière automatique pour chaque étudiant.
- Il est trop facile pour les étudiants de copier le code d’un autre, ou de trouver les solutions des exercices sur internet.
- Enfin, il y manque des exercices pour couvrir certains concepts vus dans mon cours.
Alors j’ai développé mon propre outil.
J’écris les énoncés d’exercices au format texte Markdown, afin de pouvoir les ré-utiliser rapidement d’une classe à l’autre, et d’une promotion à l’autre. J’inclus des variantes pour décourager le copiage, et des tests automatisés pour valider les acquis à partir du code écrit par chaque étudiant.
Grace à cet outil, corriger les copies d’un examen de 2 heures passé par 75 étudiants ne me prend désormais pas plus d’une heure.
Voici les grandes étapes d’usage de mon outil pour évaluer le code de mes étudiants, en 3 minutes:
Pour résumer cette partie, voici mes conseils:
- En plus d’enseigner un cours bien construit, assurer un contrôle continu riche est important pour engager les étudiants dans une démarche d’apprentissage et de pratique.
- Pour éviter que le temps de correction du travail des étudiants ne vous décourage d’ajouter du contrôle continu, n’hésiter pas à vous aider d’outils.
Et vous, comment vous y prenez-vous ? 🤔
Dans cet article, j’ai partagé quelques idées reçues sur l’enseignement de la programmation à des étudiants post-bac, ainsi que les pratiques que j’ai fini par adopter. J’espère que ce retour d’expérience vous aura intéressé !
À mon tour, je serais ravi de lire vos retours d’expérience, votre manière de faire. Au plaisir de vous lire en commentaires de cet article !
