Utilisez l'IA comme élève sceptique puis comme examinateur pour localiser au mot près les endroits où votre compréhension casse.
Ouvrir cette leçon dans KodokonLa technique de Feynman repose sur un constat impitoyable : on ne découvre ses lacunes qu'en essayant d'expliquer. Tant qu'une notion reste dans votre tête, le cerveau maquille les trous avec du flou confortable ; dès que vous devez la formuler simplement pour quelqu'un d'autre, chaque trou devient un mur. La recherche en pédagogie confirme l'intuition sous le nom d'effet protégé : enseigner une notion produit un gain de rétention supérieur à la réviser, même face à un élève fictif. L'IA est l'élève fictif idéal - disponible, infatigable, et surtout paramétrable : vous pouvez lui interdire ce qu'un humain poli ferait spontanément, combler vos silences.
Tu joues le rôle d'un développeur junior curieux et sceptique. Je vais t'expliquer [NOTION, ex. l'event loop de Node.js] comme si tu ne la connaissais pas du tout.
Tes règles :
1. Interromps-moi dès que j'utilise un mot de jargon sans l'avoir défini : demande simplement « c'est-à-dire ? ».
2. Exige un exemple concret à chaque affirmation abstraite.
3. Repère mes formulations d'évitement (« en gros », « c'est un peu comme », « techniquement ») et force-moi à préciser ce qu'elles cachent.
4. À la fin, note mon explication sur 10 et liste les points précis où j'ai été flou, faux ou incomplet - c'est la seule chose qui m'intéresse vraiment.
Interdiction absolue : ne complète jamais mon explication à ma place, même si je me trompe. Ton rôle est de révéler mes lacunes, pas de les combler.
Je commence : [VOTRE EXPLICATION]Pendant que vous expliquez, apprenez à reconnaître les trois signaux de lacune. Le premier est le jargon-bouclier : vous employez un terme technique précisément parce que vous seriez incapable de le déplier (« c'est géré par le garbage collector » - comment, exactement ?). Le deuxième est l'analogie fuyante : « c'est un peu comme une file d'attente » sans pouvoir dire où l'analogie casse. Le troisième est le saut logique : entre deux phrases, un « donc » qui masque trois étapes que vous ne sauriez pas détailler. Notez chaque signal dans votre journal d'apprentissage : ce sont vos prochaines cibles de révision, bien plus précises que « revoir le chapitre 4 ».
Change de rôle : tu es maintenant examinateur technique senior pour un poste de staff engineer. Le sujet est [NOTION] et mon explication figure ci-dessus dans la conversation.
Ta mission : la mettre à l'épreuve, pas la compléter.
1. Pose-moi 3 questions sur des cas limites que mon explication ne couvre pas.
2. Construis un contre-exemple qui semble contredire ce que j'ai affirmé, et demande-moi de le résoudre.
3. Identifie une hypothèse implicite de mon explication et demande-moi ce qui se passerait si on la retirait.
Une seule question à la fois. Après chaque réponse, rends un verdict en un mot - solide, fragile ou faux - suivi d'une phrase de justification. Ne donne la réponse correcte que si j'ai échoué deux fois de suite sur la même question.Intégrez enfin la méthode aux moments où elle rapporte le plus. Après chaque débogage non trivial : expliquez la cause racine à l'IA en mode élève sceptique ; si votre explication ne tient pas, vous avez corrigé le symptôme, pas compris le bug - il reviendra. Avant chaque revue de code que vous demandez : expliquez votre conception en trois phrases ; si vous n'y arrivez pas, le problème est en amont du code. Cette gymnastique de dix minutes transforme chaque incident du quotidien en séance d'apprentissage - c'est exactement l'inverse de faire générer une explication qu'on lit passivement, où le confort de lecture se fait passer pour de la compréhension.