Quelle est la meilleure manière d'apprendre l'informatique ?

Notre avis: construis des projets, mais pas n'importe comment

La meilleure manière d'apprendre l'informatique, c'est de construire des projets réels. Pas de regarder quelqu'un les construire.

Le souci, c'est que "fais des projets" est un conseil qui traîne partout, et qu'on le comprend souvent de travers. Lancer un clone de Twitter sans plan, seul, sans personne pour relire ton code, ça ne marche pas mieux qu'un tuto. Tu bloques au même endroit, tu abandonnes à 40 %.

Un projet qui fait progresser a trois choses que le side project improvisé n'a pas:

1. Une spec, qui implique la qualité du code, la gestion d'erreurs, la résilience du système, comme en entreprise, qui couvre tous les détails. Tu sais ce que "terminé" veut dire avant d'écrire la première ligne.
2. Une difficulté juste au-dessus de ton niveau actuel. Assez dure pour t'obliger à chercher et approfondir tes connaissances, pas au point de te noyer.
3. Du feedback sur ta solution. Quelqu'un ou quelque chose qui te dit si elle tient la route, et pas seulement si elle compile.

C'est ça, le project based learning (l'apprentissage par projets): apprendre en résolvant un vrai problème de bout en bout, avec un cadre. Le mot important, c'est "cadre".

Pourquoi apprendre par projets marche mieux que les cours

Regarder n'est pas faire

Quand tu suis un tuto, ton cerveau fait surtout de la reconnaissance. Tu vois une ligne de code, tu la comprends, tu passes à la suivante. Reconnaître une solution et la produire depuis une page blanche, ce sont deux compétences différentes. La deuxième est la seule qui compte quand tu bosses.

Le problème, c'est que la première donne une très bonne sensation de progrès. Tout est fluide, rien ne casse. Alors qu'apprendre, en vrai, c'est plutôt l'inverse: ça casse, tu ne comprends pas pourquoi, tu fouilles, et c'est là que ça rentre.

Ce que dit la recherche

En 2014, Scott Freeman et son équipe à l'Université de Washington ont publié dans PNAS une méta-analyse de 225 études qui comparent les cours magistraux à l'apprentissage actif dans les matières scientifiques, technologie et ingénierie comprises. Une méta-analyse, c'est une étude qui agrège les résultats de nombreuses autres pour en tirer une tendance plus fiable qu'une étude isolée.

Les chiffres sont assez nets. En cours magistral, environ 34 % des étudiants échouent. Avec de l'apprentissage actif, on tombe à 22 %. Les notes aux examens montent aussi d'environ 6 % en moyenne.

Petite précision pour rester rigoureux: « apprentissage actif » est plus large que « projet ». Ça inclut aussi les exercices en classe ou la résolution de problèmes en groupe. L'étude montre que faire bat écouter. Elle ne dit pas que n'importe quel projet bat tout le reste.

Le piège du projet sans cadre

En 2006, trois chercheurs en sciences de l'éducation, Kirschner, Sweller et Clark, ont publié un article au titre peu diplomatique: pourquoi l'enseignement avec un guidage minimal ne fonctionne pas.

Leur argument tient à la mémoire de travail, la partie de ta mémoire qui garde en tête ce que tu manipules en ce moment. Elle est très limitée. Un débutant lâché sans aide face à un problème complexe la sature: il passe son énergie à chercher dans le noir au lieu de construire des schémas qui restent. D'après eux, l'avantage du guidage ne s'efface que quand l'apprenant a assez de connaissances pour se guider lui-même.

Un an plus tard, Hmelo-Silver, Duncan et Chinn leur ont répondu dans la même revue. Leur point: l'apprentissage par problèmes bien fait n'est pas du guidage minimal. Il repose sur de l'échafaudage (scaffolding), c'est-à-dire une structure qui t'aide à avancer sans te donner la réponse, puis qui s'efface au fur et à mesure.

Les deux camps ont raison, et c'est toute notre position. Le projet seul, sans cadre, ne suffit pas. Le projet avec un échafaudage, si. Un cahier des charges, des étapes, un retour sur ton code: c'est ça, l'échafaudage.

Quel projet faire pour apprendre le backend, le réseau ou le RAG ?

C'est la question qu'on voit passer le plus souvent. Quel projet faire pour apprendre le backend, Docker, les bases de données, le RAG. Et les réponses se ressemblent toutes: une to-do list, un clone de Twitter, une app météo.

Le problème de ces réponses, c'est qu'elles partent de l'application et pas de la compétence. Tu peux finir un clone de Twitter sans jamais toucher à ce que tu voulais apprendre, parce que la partie dure a été réglée par un framework ou un tuto. Tu as un projet de plus sur GitHub, et le même trou dans tes compétences.

Un bon projet pour apprendre X, c'est un projet où tu ne peux pas éviter la difficulté centrale de X. Quatre exemples, parmi les demandes qu'on voit le plus:

Quel projet pour apprendre le réseau ?

Un reverse proxy HTTP avec load balancing et health checks, écrit directement au-dessus des sockets. Tu dois parser des requêtes qui arrivent en morceaux, gérer le keep-alive et les timeouts, et décider quoi faire quand un backend tombe au milieu d'une requête. C'est là que tu comprends vraiment TCP et HTTP.

Quel projet pour apprendre les bases de données ?

Un moteur de stockage clé-valeur basé sur un LSM-tree, avec un journal d'écriture (WAL) et de la compaction. Tu ne peux pas éviter les vraies questions: quand appeler fsync, comment reconstruire l'état après un crash en rejouant le journal, comment compacter sans bloquer les lectures.

Quel projet pour apprendre le backend ?

Un service de jobs asynchrones avec une API, une file et plusieurs workers. Faire tourner un job, c'est facile. Ce qui t'apprend le backend, c'est le worker qui meurt au milieu d'un traitement, le job exécuté deux fois qu'il faut rendre idempotent, les retries qui ne doivent pas noyer un service déjà en panne, et les logs qui te permettent de comprendre ce qui s'est passé.

Quel projet pour apprendre le RAG ?

Un RAG sur une base documentaire hétérogène (PDF, tableaux, pages mal formatées), avec un jeu de questions annotées pour l'évaluer. Une démo qui répond à peu près, ça se monte en une heure. Le vrai travail, c'est de découper des tableaux sans perdre leur sens, de combiner recherche par mots-clés et recherche vectorielle, de reclasser les résultats, et de mesurer à chaque changement si les réponses s'améliorent ou se dégradent.

Comment savoir si un projet est le bon ?

Pour savoir si un projet fait l'affaire, pose-toi trois questions. Est-ce qu'il m'oblige à faire moi-même la partie que je veux apprendre ? Est-ce que je sais dire quand il est terminé, avec un critère que je peux tester ? Est-ce qu'il a des contraintes qui l'empêchent d'être un jouet, comme des pannes, de la charge ou des données mal formées ?

Si tu réponds non à l'une des trois, change de projet ou redécoupe-le.

Et au fond, quand quelqu'un demande « quel projet faire », il demande souvent autre chose: un cahier des charges et un ordre. Quoi construire d'abord, quoi ensuite, et comment savoir si c'est bien fait. C'est pour ça qu'on a construit Kairo comme on l'a construit: des parcours de projets qui se suivent, avec un cahier des charges qui simule une situation pro et un feedback automatique sur la qualité du code, pas juste sur le résultat.