Apprendre le code à nos étudiants : la recherche de la Piscine parfaite

Dans cette nouvelle série d’articles, nous allons discuter de certains choix que nous avons faits depuis la création de Rbean.

Ce premier article va plonger dans les “Piscines”, une période charnière de nos parcours d’apprentissage du code.

Note : J’ai suivi trois Piscines en tant qu’étudiant, il y a bientôt 20 ans. J’en ai également co-créé/mis à jour une bonne dizaine : de la première Piscine de C de 42 à la Piscine C++ d’Epitech, en passant par la Piscine Python d’Intek, j’ai donc pu me forger un avis sur les Piscines !

Bon, c’est quoi une Piscine ?

Une Piscine, utilisée dans le sens de bootcamp informatique, est une période, généralement de plusieurs semaines, où un étudiant va pratiquer très intensément un langage de programmation, dans le but de le maîtriser.

Le terme Piscine remonte (à ma connaissance) à l’Epita, qui, dans les années 90, organisait déjà des Piscines de code. Il viendrait du fait que quand on suit une Piscine, on s’immerge dans l’informatique.

Plusieurs écoles d’informatique françaises utilisent ce terme, les plus grosses étant Epitech et 42.

En fonction des besoins, le format d’une Piscine peut varier : elle peut inclure une pause au milieu ou non, s’adresser à un public débutant ou non, être sélective ou non, inclure les week-ends ou non, etc.

Mais la base commune est simple : apprendre un langage informatique par la réalisation de séries de petits exercices. Chaque Piscine est découpée en journées, où chaque journée introduit une nouvelle notion. Environ 80% du temps de l’apprenant est passé devant son ordinateur, à tenter de résoudre les problèmes donnés dans les exercices.

Les termes Piscine et bootcamp étant synonymes, j’utiliserai l’un ou l’autre indifféremment dans cet article.

Plusieurs formats de Piscine pour différents publics

Comme nous avons pu le constater et le reconstater au cours de nos nombreuses itérations, le format strict de la Piscine n’est pas adapté à tous les publics.

Par exemple, certaines personnes n’ont pas le temps de passer 60 heures par semaine devant leur écran, certaines n’ont pas besoin de tout comprendre ou de tout connaître, certaines auront besoin de plus de théorie, etc.

Une autre problématique récurrente est la gestion de l’hétérogénéité des promotions d’étudiants : comment faire pour que les bons ne s’ennuient pas, et que les moins bons ne se démoralisent pas en voyant une montagne d’exercices non finis ?

Également, la présence ou non d’un assistant pour aider les étudiants change énormement la donne : la Piscine doit prévoir plus de filets de sécurité s’il n’y a pas d’assistants.

C’est pourquoi, nous sommes très vite arrivés à la conclusion qu’il fallait avoir un format de Piscine qui s’adapte. Cela demande un peu plus de travail, mais c’est obligatoire pour ne pas laisser une bonne partie des étudiants au bord de la route.

Maintenant, on adapte les Piscines aux écoles, en fonction de leur public !

Commencer l’apprentissage du code par un bootcamp de C ?

Plusieurs grandes universités/écoles d’informatique commencent leur parcours par du C (Piscines ou pas), un langage créé dans les années 70. Il est plutôt complexe à utiliser comparé aux langages plus récents :

En faisant du C, vous devez allouer la mémoire de votre programme vous-même, aucun mécanisme ne vous empêchera de faire n’importe quoi avec cette mémoire, aucun mécanisme ne vous aidera en cas de plantage, etc.

Alors pourquoi ces écoles ont-elles fait le choix de commencer avec C ?

Un des arguments souvent avancés est que, comme le C est très bas niveau (très proche de la machine, ce qui oblige à gérer beaucoup de choses soi-même), on apprend comment un langage de programmation fonctionne “sous le capot”. Et quand on continue nos études, on a une meilleure compréhension des choses.

Un autre argument qui revient souvent est que la syntaxe très rigide du C force à la rigueur.

Et tout ça, c’est vrai. Mais cela ne justifie pas la difficulté qu’engendre l’apprentissage du C. On a constaté que de nombreux étudiants abandonnent dès les 2ème ou 3ème jour (dès qu’on commence à entrer dans le dur). Ce sont des étudiants qui auraient sûrement pu apprendre à coder s’ils avaient persévéré, mais la courbe d’apprentissage du C est bien trop raide.

Nous avons donc préféré commencer par des langages plus simples (quitte à ce que les étudiants refassent une Piscine de C après un an de code, une fois mieux préparés).

Pourquoi avoir choisi Python ou Javascript pour nos bootcamps ?

Nous avons deux bootcamps pour débutants, un en Python et un en Javascript.

Ces deux langages sont probablement les plus utilisés dans les entreprises aujourd’hui. Ils ouvrent la porte à des métiers dans le web, le mobile, la data, l’IA, etc.

Ce sont également des langages plus récents (ou du moins qui ont été mis à jour régulièrement) et assez haut niveau. C’est selon nous un bien meilleur choix pour commencer l’apprentissage du code.

Quand on apprend le vélo, on commence avec les petites roues. Quand on apprend le code, on commence avec Python !

Dernier point important (dans le cadre de l’apprentissage par la pratique) : ces deux langages ont énormément de cours en ligne, que les étudiants peuvent utiliser pour les aider si quelque chose n’est pas clair pour eux. Attention tout de même à ce qu’ils ne soient pas noyés d’informations !

Mais au-delà du choix du langage, nous avons également changé pas mal de choses par rapport au format plus traditionnel des Piscines.

Les différences de nos Piscines

Comme dit plus tôt, nous avons plusieurs formats de Piscine. Mais elles ont évidemment une philosophie commune, qu’on a fait évoluer au fil du temps :

D’abord, nous laissons de la place à la théorie. Le but de ces phases de théorie est de créer un vocabulaire commun et d’établir une base commune.

Nous essayons également de retirer le plus d’informations annexes possibles, pour nous concentrer sur l’apprentissage du code. En effet, un problème récurrent des bootcamps est la quantité d’informations à apprendre et à digérer en un temps généralement court, mais suffisamment long pour devenir épuisant.

Par exemple, pour éviter à nos apprenants d’installer un environnement de code, d’apprendre à utiliser un terminal, un compilateur, GitLab, etc., ils codent directement dans notre LMS.

Les exercices réalisés par les étudiants sont corrigés automatiquement par notre outil, la Sentinel. La Sentinel teste leur code, crée un rapport d’erreurs complet et l’affiche directement aux étudiants.

Mais nous avons décidé de laisser aux étudiants la possibilité de lancer la Sentinel quand ils le souhaitent, même au milieu d’un projet. Cela évite les (grosses) frustrations une fois le projet rendu, de ne pas avoir bon pour une faute d’inattention.

Si possible, un débrief par un professeur est aussi encouragé. Laisser les étudiants construire leur connaissance sur des bases bancales n’est jamais une bonne chose !

Dernier exemple, la séquence d’une journée est capitale pour nous :

• faire des exercices très unitaires au début ;
• ne pas toujours faire des exercices de plus en plus durs, pour ne pas démoraliser les étudiants en difficulté ;
• ajouter des parties bonus aux exercices ou des exercices bonus complets pour occuper les meilleurs ;
• etc.

Le format de bootcamp parfait ?

Vous vous en doutez, la notion de bootcamp parfait n’existe pas !

Il faut régler les problèmes de triche. Il faut voir comment adapter le format avec l’IA générative qui résout les exercices pour nous. Il faut itérer régulièrement pour essayer d’améliorer les choses.

Par exemple, depuis peu, au lieu de mettre un étudiant devant une série de 10 exercices, nous en cachons la moitié et ne débloquons les derniers qu’aux étudiants qui ont de l’avance.

Une des prochaines pistes que nous allons explorer est de faire une première journée sans écrire de code du tout, où les étudiants assembleront des blocs représentant le code pour travailler leur logique sans s’embarrasser de la syntaxe dès le premier jour.

Nous réfléchissons également à un format où nous pousserions un peu plus le peer learning (et pas juste “demande à ton voisin”), mais ça, nous en parlerons une prochaine fois !