La méthode IA à trois couches de Karpathy : ce qu'il a dit
Le cadre spec, vérificateur et environnement est la mise en ordre, par Austin Marchese, d'idées tirées de la conférence d'avril 2026 d'Andrej Karpathy. Karpathy n'a pas nommé ce cadre dans cette conférence. Sa valeur pratique est simple : définir l'objectif avant de déléguer, vérifier si le résultat l'atteint, et donner à l'IA le contexte permanent et les limites dont elle
La vidéo YouTube de 13 minutes d’Austin Marchese, publiée le 9 juin 2026, présente une façon pratique de travailler avec Claude. Il y affirme que la méthode de Karpathy « peut se décomposer en trois couches simples ». Savoir quelles idées viennent de Karpathy et lesquelles Marchese a ajoutées rend le conseil plus facile à évaluer et
Karpathy a cofondé OpenAI, a été responsable de l’IA chez Tesla et a forgé l’expression « vibe coding » pour désigner la création de logiciels en les décrivant à une IA. Marchese s’est appuyé sur la conversation informelle entre Karpathy et Stephanie Zhan, associée de Sequoia Capital, lors de l’événement AI Ascent 2026 de la firme. Karpathy a publié un résumé et une transcription révisée sur son blogue le 30 avril. Les specs, la vérification des réponses de l’IA et l’investissement dans son propre environnement de travail reviennent tous dans la conversation. Il ne les regroupe jamais
L’essentiel de la méthode résiste à une vérification faite à partir de l’enregistrement, et les parties que Karpathy n’a pas dites méritent quand même d’être utilisées. La version populaire laisse aussi de côté son meilleur exemple, et elle ne fait qu’effleurer l’idée qui explique pourquoi la couche du
Chaque couche, retracée jusqu’à sa source
| Couche | Ce que Karpathy a dit à AI Ascent | Ce que la vidéo de Marchese ajoute |
|---|---|---|
| Spec | Ce sont les humains qui restent responsables de la spec et du plan. Élaborer avec l’IA une spec très détaillée, qui va au-delà de ce que produit le mode plan. | Faire en sorte que l’IA vous interviewe sur l’objectif. Garder les specs de petite portée, avec des points de contrôle. Obliger l’IA à vous faire confirmer les décisions clés. |
| Vérificateur | L’IA automatise ce qui peut être vérifié, ce qui la rend inégale. Crier après un modèle ne change rien. Rester méfiant et rester dans la boucle. | Écrire d’abord les critères de réussite. Utiliser un deuxième modèle comme critique. Confronter le travail à des signaux réels, comme un déploiement en direct. |
| Environnement | Investir dans son propre environnement de travail. Tenir un wiki entretenu par l’IA à partir de ses lectures. | Un fichier d’instructions permanentes, des instructions enregistrées pour les tâches récurrentes, des limites appliquées par l’outil, et une répartition entre « toujours faire », « demander la permission d’abord » et « ne jamais faire ». |
La spec transporte le contexte que l’IA ne peut pas voir
Karpathy a abordé les specs quand Zhan lui a demandé quelles compétences humaines prennent de la valeur à mesure que l’IA accomplit une plus grande partie du travail. Sa réponse a commencé par les agents, ces outils d’IA qui exécutent seuls des tâches en plusieurs étapes, comme écrire et tester du logiciel. Il a dit que les agents ressemblent pour l’instant à des stagiaires, et que « ce sont les humains qui doivent être responsables de cette spec, de ce plan ». Puis il
« En fait, je n’aime même pas le mode plan… c’est évidemment très utile, mais je pense qu’il y a quelque chose de plus général ici : vous devez travailler avec votre agent pour concevoir une spec qui est
très détaillée. »
Le mode plan est un réglage de Claude Code et d’outils de programmation semblables, où l’IA rédige un plan que vous approuvez avant qu’elle ne modifie quoi que ce soit. Karpathy veut plus de détail qu’un plan n’en contient. Il a suggéré que la spec pourrait être « essentiellement la documentation », la personne étant responsable de la supervision et des grandes catégories, tandis que les agents remplissent
Son meilleur exemple vient de MenuGen, une petite application qu’il a construite et qui transforme la photo d’un menu de restaurant en images des plats. Les utilisateurs se connectent avec Google et achètent des crédits par Stripe, le service de paiement. Son agent associait chaque achat à un compte en comparant les deux adresses courriel. Or les clients peuvent payer avec une adresse différente de celle utilisée pour se connecter, et quiconque le faisait payait des crédits sans jamais les recevoir. Karpathy a dû insister pour que tout soit rattaché à un identifiant
La mise en œuvre a ignoré la possibilité qu’un même client utilise deux adresses courriel. C’est dans la spec que cette exigence doit figurer, et c’est un test avec une adresse de connexion différente de l’adresse de paiement qui permet de vérifier que le système en
Les étapes de Marchese pour rédiger une spec sont pratiques, et aucune ne vient
- Demandez à l’IA de vous interviewer sur l’objectif avant qu’elle rédige quoi que ce soit. « Produire le rapport de fin de mois » est une tâche. L’objectif, c’est la décision que ce rapport doit éclairer.
- Limitez la portée de chaque spec, avec un point de contrôle où vous révisez le résultat avant d’enchaîner avec le segment de travail suivant. Confier tout le travail d’un coup et attendre un produit fini, c’est ce que Marchese appelle travailler en cascade.
- Lisez ligne par ligne la spec que l’IA rédige, et dites-lui de vous faire confirmer chaque décision clé.
Le vérificateur : l’IA est la plus forte là où le travail peut être vérifié
C’est la couche qui a les racines les plus profondes dans les écrits de Karpathy lui-même. Dans un billet de blogue de novembre 2025 intitulé Verifiability, il soutenait que le logiciel traditionnel automatise ce que l’on peut spécifier, alors que l’IA automatise ce que l’on peut vérifier. Une tâche est vérifiable quand un modèle peut s’y essayer de nombreuses fois et que chaque tentative peut être notée automatiquement. C’est pourquoi l’IA a progressé le plus vite en mathématiques et en programmation, où les réponses peuvent être vérifiées, et traîne dans le travail qui dépend du contexte et du gros
À AI Ascent, il a donné son plus récent exemple de cette inégalité, ce qu’il appelle le caractère
« Je veux aller au lave-auto pour laver mon auto, et il est à 50 mètres. Est-ce que je devrais conduire ou marcher ? Et les modèles les plus avancés aujourd’hui vous diront de marcher, parce que c’est
tout près. »
L’auto, évidemment, doit se rendre au lave-auto. « Comment est-il possible qu’un modèle de pointe puisse refactoriser une base de code de 100 000 lignes ou trouver des vulnérabilités zero-day, et qu’il me dise pourtant de marcher jusqu’au lave-auto ? », a-t-il demandé. Sa réponse : les humains doivent rester dans la boucle et traiter ces systèmes comme
La même conférence explique pourquoi supplier un modèle ne sert à rien. Karpathy décrit ces modèles comme des fantômes plutôt que comme des animaux : des simulations statistiques dépourvues des pulsions qui poussent une personne à redoubler d’efforts sous pression. « Si vous leur criez après, ils ne travailleront ni mieux ni moins bien », a-t-il dit. « C’est plutôt une question de s’en méfier et de comprendre avec le temps. » Marchese remplace le fantôme par un bibliothécaire robot qui répond à partir des livres qu’il possède et invente avec assurance quand le bon livre manque. C’est une bonne image pour expliquer l’idée à une équipe, et elle est de
Les trois vérifications de Marchese transforment cette méfiance
- Écrivez les critères de réussite avant que le travail commence. Pour un rapport, nommez la décision qu’il doit éclairer et les preuves qu’exige chaque recommandation. Imposer un nombre de sections peut aider la présentation, mais un rapport peut respecter cette consigne tout en se trompant sur la décision.
- Envisagez un deuxième modèle d’IA comme critique s’il aide à repérer une faiblesse précise. Karpathy a proposé cette idée pour la rédaction, où il n’y a pas de réponse unique : « on peut imaginer avoir un conseil de juges LLM ». L’accord entre modèles ne prouve pas qu’une affirmation est vraie. Vérifiez les faits dans les sources et testez directement les résultats qui peuvent l’être. Un deuxième modèle reste facultatif : il apporte de la valeur seulement s’il découvre des erreurs importantes que les vérifications existantes ont manquées.
- Branchez l’IA sur un signal du monde réel. Pour un site web, vérifiez à la fois la disponibilité et la tâche du client : chargez la page, complétez une réservation et vérifiez son accusé de réception. Pour un rapport, rapprochez ses chiffres des données sources avant de comparer des périodes.
Boris Cherny, le créateur de Claude Code, donne un conseil pratique qui va dans le même sens. Dans un fil de discussion de janvier 2026, son conseil était de « donner à Claude un moyen de vérifier son travail », ce qu’il a qualifié de « probablement la chose la plus importante pour obtenir d’excellents résultats de Claude Code ». Il a ajouté que « si Claude a cette boucle de rétroaction, elle multipliera par 2 ou 3 la qualité du résultat final ». Ce chiffre est sa propre estimation et ne provient d’aucune étude publiée. Pour choisir un système d’IA, testez des cas représentatifs de votre travail, tenus à l’écart du développement. Indiquez le nombre de cas, les erreurs qui comptent et l’incertitude du résultat. Un petit échantillon choisi par commodité ne suffit pas à établir la fiabilité, comme nous l’expliquons dans ce que mesure réellement une évaluation d’IA.
L’environnement transporte votre configuration dans chaque conversation
Interrogé sur ce qui distingue un programmeur médiocre utilisant ces outils d’un programmeur pleinement natif de l’IA, Karpathy a répondu qu’il s’agit de « tirer le maximum des outils disponibles, d’utiliser leurs fonctionnalités et d’investir dans son propre environnement de travail ». Il a comparé cela à la façon dont les programmeurs ont toujours ajusté leurs éditeurs de code. Marchese en fait un atelier que vous montez une fois et que vous améliorez continuellement, de sorte que chaque nouvelle conversation commence avec vos règles et votre matériel de référence déjà
La partie de cette couche dont Karpathy a parlé en détail, c’est sa base de connaissances personnelle. « Quand je lis un article, mon wiki se construit à partir de ces articles », a-t-il dit à AI Ascent. « J’aime beaucoup lui poser des questions. » Il a publié l’idée sous forme de note le 4 avril 2026, rédigée pour être collée directement dans un outil d’IA. Dans ce montage, une IA lit les documents que vous rassemblez et en construit des pages de résumé liées entre elles. Il appelle ce patron un LLM Wiki. Un grand modèle de langage (LLM) est la technologie derrière ChatGPT
Le patron a ses propres trois couches. Les sources brutes y entrent intactes : l’IA les lit, mais ne les modifie jamais. À partir de celles-ci, l’IA rédige et entretient le wiki, un ensemble de pages liées. La troisième couche, le schéma, est un fichier d’instructions qui indique à l’IA comment le wiki est organisé. Au sujet du wiki, Karpathy écrit : « Vous le lisez; le LLM l’écrit. » Si vous avez vu « les trois couches de Karpathy » décrites comme sources, wiki et schéma, l’auteur décrivait
Ce schéma est le même genre de fichier qui ancre la version de cette couche chez Marchese, laquelle compte
- Un fichier d’instructions permanentes. Claude Code lit un fichier nommé
CLAUDE.mdau début de chaque conversation, et Codex, l’outil de programmation d’OpenAI, en lit un nomméAGENTS.md. Mettez-y les consignes par défaut que vous répéteriez autrement, par exemple : « Avant de construire quoi que ce soit en plusieurs étapes, inclure un plan de vérification. » - Un dossier de référence organisé pour que l’IA trouve ce dont elle a besoin : sa version de la base de connaissances de Karpathy.
- Des instructions enregistrées pour les tâches récurrentes, que Claude appelle des compétences (skills). Sa règle générale : en écrire une pour tout ce que vous prévoyez faire de façon répétée, et la corriger chaque fois qu’elle déçoit.
- Des limites strictes pour tout ce qui coûte cher à rater.
Les limites exigent plus qu’une phrase dans ce fichier. Une ligne demandant à l’IA de ne pas toucher à un dossier est une requête, et le modèle peut l’ignorer. Claude Code prend aussi en charge les hooks, de petites vérifications que l’outil exécute avant que l’IA modifie un fichier, et un hook peut bloquer carrément la modification. Marchese répartit le travail en trois cases : ce que l’IA fait toujours seule, ce pour quoi elle doit demander la permission avant d’agir, et ce qu’elle ne
La compréhension, elle, vous reste
La plupart des comptes rendus se terminent sur « Vous pouvez externaliser votre réflexion, mais vous ne pouvez pas externaliser votre compréhension », et la conférence de Karpathy aussi. Il a présenté la phrase comme un tweet qui l’a « épaté », donc les mots sont de quelqu’un d’autre. Il a expliqué pourquoi elle l’a marqué : « Je deviens le goulot d’étranglement, ne serait-ce que pour savoir ce que nous essayons de construire, pourquoi ça vaut la peine de le faire, et comment diriger
Chaque couche dépend de cette compréhension. Vous ne pouvez pas rédiger la spec sans connaître le véritable objectif, juger le résultat sans savoir à quoi ressemble un bon résultat, ni fixer des limites sans savoir quelles erreurs votre entreprise ne peut
Le compte rendu de la conférence sur le blogue de Karpathy montre la méthode appliquée à une petite tâche. Il a donné à un modèle d’IA ses billets de blogue et ses tweets récents, puis lui a fait transformer la transcription en un résumé et en une version nettoyée. Il a lu les deux avant de publier et a rapporté que le résultat « se lit correctement, sans erreurs flagrantes ». Ses propres écrits constituaient l’environnement, les deux sorties qu’il a demandées étaient la spec, et sa relecture,
Appliquez les trois couches à un même rapport
Voici une configuration à titre d’illustration, pour un rapport de ventes hebdomadaire. Sa fonction est d’aider un directeur des ventes à décider quelles occasions d’affaires demandent de l’attention, plutôt que de simplement
| Couche | Ce qui entre dans la configuration |
|---|---|
| Spec | Utilisez l’exportation CRM de cette semaine pour repérer les occasions d’affaires dont la prochaine étape est en retard. Pour chacune, indiquez le responsable, le dernier engagement consigné et l’action requise. Traitez l’absence d’engagement comme une information manquante. |
| Vérificateur | Confrontez chaque action recommandée à la fiche de l’occasion d’affaires correspondante. Confirmez que le rapport respecte la date de fin de période annoncée et exclut les dossiers conclus. Rejetez toute recommandation qui invente un engagement du client ou qui repose sur une date de prochaine étape périmée. |
| Environnement | Gardez ensemble les définitions des étapes, le fuseau horaire de référence, un exemple de rapport accepté et les limites d’accès aux données. Donnez à la tâche de production du rapport un accès en lecture seule : elle prépare des recommandations, tandis que le gestionnaire décide de la suite. |
Testez maintenant un cas délicat : le CRM indique que la prochaine étape est en retard, mais la note la plus récente précise que le client a reporté la rencontre à la semaine suivante. Un rapport qui réclame une relance urgente a suivi le champ de date et manqué le contexte. La correction consiste à rapprocher les données contradictoires et à signaler le champ périmé, pas à polir la formulation de
Conservez ce cas avec la configuration et vérifiez-le à la prochaine exécution. Vous avez alors un objectif concret, une défaillance que vous savez reconnaître et une amélioration durable des instructions. C’est une application utile de la méthode, peu importe le nom associé
Sources
- Andrej Karpathy, résumé de Sequoia Ascent 2026, avec une transcription révisée, 30 avril 2026
- Andrej Karpathy : du vibe coding à l’ingénierie agentique, avec Stephanie Zhan, enregistrement de la conversation informelle d’AI Ascent 2026
- Andrej Karpathy, Verifiability, 17 novembre 2025
- Andrej Karpathy, llm-wiki, 4 avril 2026
- Austin Marchese, Arrêtez de formuler des requêtes à Claude. Utilisez plutôt la méthode de Karpathy., 9 juin 2026
- Boris Cherny, fil de discussion sur l’obtention d’excellents résultats avec Claude Code, janvier 2026