La méthode Karpathy : utiliser l’IA 10× plus efficacement

Andrej Karpathy – cofondateur d’OpenAI et ancien responsable de l’IA chez Tesla – explique depuis un moment, dans des conférences et des interviews, pourquoi la plupart des gens utilisent l’IA de travers. Non pas parce qu’ils s’exercent trop peu, mais parce qu’ils se méprennent sur l’outil. Sa méthode pour travailler nettement plus vite avec l’IA se ramène à trois couches : Spec, vérification et environnement. Voici ce qu’il y a vraiment derrière – sans hype, mais avec de quoi s’y mettre.

Pourquoi l’IA échoue sur des questions simples

Karpathy donne un exemple tout simple : « Je veux aller au lavage auto, il est à 50 mètres. Dois-je y aller en voiture ou à pied ? » Les modèles de pointe actuels – Claude, Gemini, Grok, ChatGPT – répondent tous : à pied, c’est tout près. Faux. Car pour laver la voiture, il faut que la voiture soit sur place.

C’est tout le noyau : l’IA est brillante sur tout ce qui se mesure – et aveugle sur tout ce qui demande du contexte. Votre objectif, vos contraintes, votre intuition : l’IA n’en a aucun signal. La tâche ne consiste donc pas à « mieux prompter », mais à combler cet écart entre votre compréhension et la puissance de calcul de l’IA. C’est exactement ce que font les trois couches.

Couche 1 : le Spec – votre compréhension sous une forme exploitable

Un Spec est la manière dont vous transmettez votre compréhension à l’IA – dans un format qu’elle peut exploiter. Le fameux « mode plan » de Claude va dans la bonne direction, mais reste trop superficiel aux yeux de Karpathy. Son conseil : concevoir avec l’outil d’IA un Spec vraiment détaillé. Voici comment y parvenir en trois étapes.

1. Mettez au jour l’objectif réel

« Établis un rapport mensuel » est une tâche. L’objectif est la conclusion que vous en tirez, la décision que le rapport déclenche. Ce qu’est l’objectif, l’IA ne pourra jamais le définir à votre place. Faites-vous plutôt interroger :

« Interroge-moi pour identifier l’objectif de ce projet avant de commencer. »

2. Travaillez en agile, pas en cascade

La plupart des gens balancent tout d’un coup à l’IA (cascade) et espèrent le résultat fini. Mieux vaut le speccing agile : cadre étroit, checkpoint clair, vérifier le résultat, réajuster, recommencer. Vous voyez ainsi tôt si la direction n’est pas la bonne.

« Privilégie des Specs plus petits et mieux délimités, avec des résultats intermédiaires clairs. »

3. Soyez précis – et gardez la tête sur les épaules

Plus vous êtes précis, moins l’IA doit supposer. Et chaque supposition est une occasion de dériver du résultat souhaité. Si l’IA rédige un Spec pour vous, lisez-le d’un œil critique – avec votre propre tête.

« Fais-moi confirmer explicitement les décisions centrales, pour que rien ne soit oublié. »

Trois éléments, un résultat : un Spec étroitement cadré et réfléchi, qui correspond à votre objectif réel. Karpathy appelle cela le modern engineering – une posture dont aura besoin quiconque travaille sérieusement avec l’IA.

Couche 2 : le vérificateur – faire contrôler à l’IA son propre travail

Le plus frustrant avec l’IA, c’est la vérification du résultat. Pour comprendre pourquoi, le modèle mental de Karpathy aide. Il parle d’« animaux » par opposition à des « esprits » : les humains sont comme des animaux – avec des motivations et des émotions. Si vous dites à quelqu’un « deviens pro du SEO en 14 jours ou tu es viré », la personne trouve un moyen. L’IA fonctionne autrement.

Une image plus parlante : représentez-vous l’IA comme un bibliothécaire robot. Elle ne répond aux questions qu’à partir des livres de sa bibliothèque. S’il manque un livre, elle ne peut pas aider – et souvent ne s’en aperçoit pas. C’est pourquoi elle brille en mathématiques et trébuche sur le contexte : là où la bibliothèque contient des réponses claires, elle est brillante ; là où ce n’est pas le cas, elle se trompe avec assurance. Crier, supplier ou dire « fais mieux » n’aide pas. Le seul vrai levier est la vérification. Trois points d’appui :

• Définir les critères d’évaluation à l’avance. Au lieu de « fais un bon rapport » : « Le rapport comporte trois sections, chacune se termine par une recommandation. » Plus c’est précis en amont, moins il y a de place pour l’erreur.
• Un second modèle comme critique. Un deuxième bibliothécaire, issu d’une autre bibliothèque, évalue le résultat du premier. Dans Claude Code, on peut par exemple utiliser le plugin Codex : « Si cela devient un build complexe, fais contre-vérifier le résultat final par Codex. »
• Intégrer des signaux externes. Reliez l’IA au système qui connaît la vérité – par exemple l’environnement de déploiement, pour confirmer que la livraison a bien eu lieu. Ou fournissez d’anciens rapports comme format de référence.

Boris Cherney, l’inventeur de Claude Code, le résume ainsi : si Claude dispose d’une boucle de retour, cela double voire triple la qualité du résultat final.

« Esquisse les critères d’évaluation avec lesquels tu garantis un résultat final de qualité. Sois précis. Là où c’est pertinent, fais appel à un second modèle ou à des données externes pour la vérification. »

Couche 3 : l’environnement – le sol d’atelier sur lequel tout repose

Le Spec et la vérification ont besoin d’un lieu où vivre : l’environnement dans lequel vous construisez. Pensez à un atelier – le Spec est le plan accroché au mur, le vérificateur le contrôle qualité à la porte, et l’environnement, c’est l’atelier lui-même. Le problème : la plupart repartent de zéro à chaque fois. Voici comment installer à la place un poste de travail qui s’améliore avec le temps :

• Un fichier CLAUDE.md propre. Il est chargé automatiquement à chaque prompt – la première chose que Claude lit. Exemple : « Avant de construire quelque chose en plusieurs étapes, ajoute un plan de vérification. » La vérification devient ainsi imposée, non optionnelle.
• Une base de connaissances propre (LLM knowledge base). Un système de dossiers avec vos propres données, que l’IA parcourt facilement. Vos données sont votre douve – c’est là que commence votre propriété intellectuelle.
• Des skills réutilisables. Règle empirique : ce que vous faites de façon répétée devient un skill – un manuel pour une tâche concrète. « Le meilleur moyen de trouver une fuite dans un tuyau, c’est d’y faire couler de l’eau. » Plus vous utilisez les skills, meilleurs ils deviennent.
• De vraies règles plutôt que des prières. Une phrase dans CLAUDE.md (« ne rien inventer ») est une prière que l’IA peut ignorer. Ce qui est critique doit être imposé au niveau de l’outil – p. ex. un hook Pre-Tool-Use qui protège durement certains fichiers.

Rangez vos actions dans trois paniers : Toujours autorisé (tourne en pilote automatique), Demander avant (contre-vérifier) et Jamais (des limites à ne pas franchir). Faites de l’environnement votre monde – l’IA y vit, pas l’inverse.

La seule chose qui compte

« Vous pouvez externaliser votre réflexion – mais pas votre compréhension. »
– Andrej Karpathy

Les trois couches tournent exactement autour de cela : votre compréhension de l’ensemble. Vous devez connaître vos objectifs et savoir ce qu’il faut pour orienter l’IA dans la bonne direction. Les outils deviennent moins chers – la compréhension, elle, reste rare.

Conclusion

« Mieux prompter » est la mauvaise question. Qui veut vraiment devenir plus rapide et meilleur avec l’IA construit un système : un Spec précis qui part de l’objectif ; une vérification qui impose la qualité ; et un environnement qui grandit à chaque usage. Ce n’est ni de la magie ni du hype – c’est du travail propre, où vous gardez la tête. C’est exactement ainsi que je conseille : honnêtement, de façon mesurable, sans hype de l’IA. Si vous voulez mettre cela en place dans votre entreprise, parlons-en.

À emporter

La méthode complète sous forme de documents compacts – idéaux à enregistrer et à partager dans l’équipe :

Source : « Stop Prompting Claude. Use Karpathy’s Method Instead. » d’Austin Marchese (YouTube). Librement résumé et adapté en français.