Le problème de l’enseignement classique du code
Cours 1 : variables. Cours 2 : boucles. Cours 3 : fonctions. Cours 8 : “maintenant, faites un projet créatif.”
Résultat : les étudiants savent ce qu’est une boucle for mais n’ont aucune idée de comment la transformer en œuvre. La technique et le geste créatif sont enseignés séparément — comme si on apprenait la grammaire pendant 3 mois avant d’écrire une seule phrase.
Le principe : prototype d’abord, théorie ensuite
Ma méthode inverse l’ordre :
Jour 1 (4h) : On construit un truc qui marche. Un sketch interactif, un générateur visuel, un jeu simple. Le code est minimal, copié-collé quand nécessaire, l’important est que ça tourne et que ça réagisse.
Jour 2 : On le montre à des gens (les autres étudiants, les passants, n’importe qui). On observe : est-ce qu’ils comprennent ? Est-ce qu’ils interagissent ? Est-ce qu’il se passe quelque chose ?
Jour 3 : On itère. On corrige ce qui ne marche pas. On retire ce qui est superflu. On renforce ce qui provoque une réaction.
La théorie arrive quand l’étudiant en a besoin — pas avant. “Comment faire tourner ce cercle plus vite ?” → maintenant on parle de frameRate et de variables.
Pourquoi ça marche
Motivation immédiate. L’étudiant voit un résultat en 4h. Il a créé quelque chose de visible, de montrable. La satisfaction est immédiate.
Feedback réel. Le test avec de vrais utilisateurs remplace la correction par le prof. L’étudiant voit directement si son truc fonctionne — pas besoin d’une note.
Tolérance à l’erreur. Le prototype “moche qui marche” est explicitement valorisé. Pas de perfectionnisme bloquant. On peut toujours améliorer après.
Apprentissage contextuel. Chaque concept technique est découvert dans un contexte de besoin. “J’ai besoin de X pour faire Y” — pas “apprenez X, un jour vous en aurez besoin.”
Structure d’un module type
Module 2 jours (découverte)
| Temps | Activité | |
Accueillir ou découvrir cette œuvre ?
Discutons des conditions d'accueil ou de diffusion.