J'ai rebâti mes cours sur la science de l'apprentissage

J'avais déjà construit les cours. Interactifs, avec éditeur de code en direct, quiz, schémas, bilingues. J'en étais plutôt fier. Puis j'ai lu une étude EEG du MIT sur la dette cognitive, et une autre sur l'écart qui se creuse entre apprenants à l'ère de l'IA. Elles m'ont mis mal à l'aise, parce qu'elles décrivaient un piège dans lequel mes propres cours tombaient peut-être : donner l'illusion d'apprendre sans rien ancrer durablement.

Alors j'ai tout repris. Voici ce que j'ai changé, pourquoi, et comment j'ai déployé ces changements sur 109 leçons sans y passer trois mois. C'est un retour d'expérience autant pédagogique que technique. (Pour la science elle-même, j'en parle dans cet article dédié.)

Le problème que mes cours ne voyaient pas

Mes leçons étaient fluides. On lisait une explication claire, on regardait un exemple qui marchait, on cochait un QCM, on passait à la suite. Agréable. Et c'est exactement le piège : la science de l'apprentissage est formelle, la fluidité ressentie n'est pas de l'apprentissage. Plus c'est facile sur le moment, moins ça reste.

Mes quiz tombaient juste après la théorie : ils testaient la mémoire de travail, pas la mémoire durable. Mes éditeurs montraient la solution avant que l'apprenant ait fait l'effort de la chercher. Mes QCM relevaient de la reconnaissance (choisir la bonne réponse) et pas de la production (l'écrire de tête). Et je n'avais aucun retour des notions dans le temps. Bref, je gommais toutes les frictions, alors que ce sont justement les bonnes frictions qui gravent.

Cinq mécanismes, cinq difficultés désirables

Robert Bjork appelle ça les difficultés désirables : des efforts volontaires qui rendent l'apprentissage plus dur sur le moment et bien plus durable ensuite. J'en ai implémenté cinq, chacun branché sur le bon moment d'une leçon.

Les cinq mécanismes ajoutés aux leçons : prédire avant d'exécuter, rappel libre, ré-explication après l'IA, journal accepter ou rejeter, et révision espacée. 1. Prédire avant d'exécuter 2. Rappel libre restituer de mémoire 3. Ré-explique après l'IA 4. Accepter / rejeter le code IA 5. Réviser répétition espacée
Chaque mécanisme cible un moment précis : on prédit, on produit, on ré-explique, on juge, puis on revient.

1. Prédire avant d'exécuter. Avant de lancer un bout de code, l'aperçu est flouté et l'apprenant doit écrire ce qu'il pense que ça va afficher. C'est l'effet de génération : tenter avant de voir prépare le cerveau à encoder, même quand on se trompe.

2. Le rappel libre. En fin de leçon, une question à laquelle on répond de mémoire, sans regarder, puis on s'auto-évalue honnêtement. Récupérer une information la grave bien plus que la relire.

3. La ré-explication après l'IA. Après chaque encadré où l'apprenant interroge une IA, on lui demande de réexpliquer avec ses mots. Ça ferme la boucle : vérifier qu'on a compris la réponse, pas juste qu'on l'a lue.

4. Le journal accepter / rejeter. On présente un extrait de code produit par l'IA, parfois subtilement bancal, parfois bon. L'apprenant tranche et justifie, puis compare à l'avis d'un dev senior. C'est l'expertise négative : apprendre à dire non au code généré.

5. La révision espacée. Les notions auto-évaluées reviennent dans un hub de révision, reproposées à intervalles croissants, juste au moment où on allait les oublier.

Un hub de répétition espacée sans backend

Le plus gros morceau, c'est le cinquième. Une vraie répétition espacée a besoin de mémoriser l'état de chaque notion : quand elle a été vue, son intervalle, sa prochaine échéance. Sans base de données ni compte utilisateur, j'ai tout posé dans le localStorage du navigateur.

La clé a été de figer un contrat de données : chaque carte de révision est auto-suffisante. Quand l'apprenant s'auto-évalue, on enregistre non seulement le verdict, mais la question et la réponse dans les deux langues, le lien vers la leçon, et l'état de planification. Le hub peut alors rejouer la carte hors de sa leçon d'origine, entièrement côté client. La contrepartie assumée : l'historique reste sur l'appareil. Pour un parcours gratuit sans inscription, c'est le bon compromis.

Industrialiser sur 109 leçons avec des agents

Ajouter ces blocs à la main sur 109 leçons, dans deux langues, en écrivant un contenu spécifique à chaque sujet, c'était des semaines. J'ai d'abord validé les composants sur une leçon pilote, puis j'ai orchestré le reste avec des agents IA : un agent par leçon, chacun lisant la leçon pilote comme référence, appliquant une grille de pertinence, et rédigeant le contenu adapté.

La règle d'or : ne pas coller les cinq mécanismes partout par réflexe. Un rappel libre presque toujours ; un « prédis » seulement s'il y a un éditeur exécutable ; une ré-explication seulement s'il y a un encadré IA ; un journal seulement si un extrait jugeable existe dans le périmètre. Mieux vaut deux composants excellents que quatre tièdes.

Le résultat m'a surpris par sa justesse contextuelle. Sur une leçon Git, le journal ne juge pas du « code » mais une commande ou un commit. Sur une leçon SQL, il pointe un DELETE sans WHERE. Sur du PHP, une requête concaténée vulnérable à l'injection. Chaque agent a adapté l'extrait au sujet exact de sa leçon. L'ironie ne m'a pas échappé : j'ai utilisé l'IA pour industrialiser des cours qui enseignent, précisément, à ne pas lui déléguer aveuglément.

Ce que les tests ont attrapé

J'ai tout vérifié en production avec des tests automatisés qui interagissent vraiment avec le site : la prédiction qui débloque l'aperçu, la réponse qui se révèle, le verdict qui persiste après rechargement, la parité français / anglais, zéro erreur console. Au total, plus de 230 tests verts sur l'ensemble des cours.

Et ils ont attrapé de vrais pièges, tous du même genre sournois : un attribut hidden écrasé par un display: flex, donc une zone qui s'affichait avant l'heure. Un détail invisible à la lecture du code, évident au test. Un audit d'accessibilité a aussi révélé un éditeur sans label et des contrastes trop faibles, corrigés dans la foulée. La leçon méta : les tests de comportement ne disent rien de la lisibilité d'une couleur. Il faut aussi regarder.

Conclusion

Le plus dur n'était pas d'écrire le code des composants. C'était d'accepter que mes cours, que je trouvais bons, étaient trop confortables pour faire apprendre. La qualité perçue et l'efficacité réelle sont deux choses différentes, et seule la seconde compte.

Reste la vraie question, celle qu'aucun test ne tranche : est-ce que les gens vont revenir réviser ? La répétition espacée ne vaut que si on revient. C'est pour ça que la dernière brique n'est pas un algorithme, mais une simple pastille « À réviser » qui rappelle qu'une notion vous attend. Le meilleur moteur d'apprentissage ne sert à rien si on oublie de le démarrer.

Commentaires (0)