Nous avons récemment regardé Andrej Karpathy expliquer comment il utilise l'IA aujourd'hui, et une affirmation nous est restée : presque tout le monde prompt mal l'IA. Non pas parce que les prompts seraient mal formulés, mais parce que le modèle est traité comme un distributeur automatique au lieu de construire un système autour de lui.
Qui est Andrej Karpathy ? Membre fondateur d'OpenAI et ancien Director of AI chez Tesla, où il dirigeait l'équipe vision d'Autopilot. C'est aussi l'un des enseignants les plus suivis du domaine, ses cours et projets open source sur les réseaux neuronaux ont façonné la manière dont toute une génération d'ingénieurs pense le deep learning. Quand il parle de la manière de réellement travailler avec ces modèles, cela mérite qu'on l'écoute.
En creusant sa méthode, elle se décompose en trois couches simples qui s'empilent : la spec, le verifier et l'environment. Si vous réussissez les trois, vous ne faites pas que rédiger de meilleurs prompts, vous construisez un workflow qui se renforce avec le temps. Dans cet article, nous allons parcourir chaque couche et voir comment l'appliquer en pratique.
Pourquoi l'IA a besoin de plus qu'un bon prompt
Karpathy utilise un exemple trompeusement simple pour montrer l'écart :
"I want to go to a car wash to wash my car, and it's 50 m away. Should I drive or should I walk? And state-of-the-art models today will tell you to walk because it's so close."
Nous l'avons essayé nous-mêmes sur plusieurs modèles de pointe, et ils ont tous donné la même réponse : marcher. Ils ratent l'évidence, il faut la voiture au car wash. L'IA est brillante pour ce qui peut être mesuré, mais lorsqu'il s'agit de jugement contextuel, elle n'a aucun signal sur lequel agir.
L'objectif des trois couches est précisément de combler cet écart : transformer votre compréhension et votre contexte en une forme que l'IA peut réellement utiliser, puis la maintenir honnête pendant qu'elle travaille. Voici comment elles s'articulent avant d'entrer dans le détail :
Couche 1 : la spec
Une spec est la manière de transmettre votre compréhension à l'IA dans un format qu'elle peut exploiter. Beaucoup de gens utilisent le "plan mode" ici, mais Karpathy considère que cela reste trop haut niveau :
"I actually don't even like the plan mode. [...] I think there's something more general here where you have to work with your agent to design a spec that is very detailed."
Il ne dit pas que le plan mode est mauvais, mais qu'il faut aller plus loin et collaborer sur la spec. Trois principes rendent une spec exploitable :
1. Mettre au jour le vrai objectif
Il existe une différence entre une tâche et un objectif. "Créer un rapport de fin de mois" est une tâche. Le vrai objectif est la conclusion que vous voulez tirer, la décision que le rapport doit permettre, et cela, l'IA ne peut jamais le décider à votre place. Une astuce pratique consiste à inverser l'interaction :
"Interview me to identify the goal of this project."
Cela fait sortir la connaissance de votre tête pour l'amener dans la spec.
2. Être agile, pas waterfall
Les gens sont dangereusement enclins à utiliser les agents IA en mode waterfall : leur donner tout le travail d'un coup et attendre un produit terminé. La meilleure approche est l'agile specking : un périmètre serré, un checkpoint clair, review, ajustement, répétition. Inscrivez-le dans votre instruction :
"Bias towards smaller, more compartmentalized specs."
3. Être précis et utiliser son cerveau
Plus vous êtes précis, moins l'IA doit supposer, et chaque hypothèse est une chance supplémentaire pour elle de dériver. Quand l'IA rédige une spec pour vous, relisez-la de manière critique. Forcez les checkpoints :
"Make me verify key decisions explicitly to ensure nothing is missed."
Ensemble, ces trois points vous donnent une spec cadrée et réellement alignée avec votre objectif. C'est ce que Karpathy appelle la modern engineering, et c'est une compétence, pas un raccourci.
Couche 2 : le verifier
La deuxième couche se place au-dessus de la spec : une fois que l'IA a produit quelque chose, comment savez-vous que c'est bon ? Pour bien faire, Karpathy propose un modèle mental : nous ne construisons pas des animaux, nous invoquons des fantômes :
"If you yell at them, they're not going to work better or worse [...] it's all just kind of like these statistical simulation circuits. It's more just being suspicious of it and figuring it out over time."
Nous trouvons plus simple d'imaginer un robot bibliothécaire. Posez-lui une question et il répond à partir des livres présents dans sa bibliothèque. Si le bon livre n'y est pas, il ne le sait pas, et peut donc inventer quelque chose avec assurance. C'est exactement pourquoi l'IA brille en mathématiques et échoue sur le contexte : quand la bibliothèque contient une réponse claire, elle excelle ; sinon, elle se trompe avec confiance.
L'implication est libératrice : supplier, crier ou dire "fais-le mieux" ne fonctionne pas, car cela revient à traiter un fantôme comme un animal. Le seul levier qui fonctionne vraiment est la vérification. Trois endroits pour l'appliquer :
1. Définir les critères d'évaluation dès le départ
Avant que l'IA ne touche à quoi que ce soit, définissez précisément ce à quoi ressemble un résultat "bon". "Rends ce rapport joli" est vague. "Le rapport doit comporter trois sections, chacune se terminant par une recommandation" est quelque chose que le modèle peut réellement vérifier. Ajoutez-le à votre prompt de vérification :
"Outline the evaluation criteria you will use to ensure a high-quality final product. Be precise."
2. Utiliser un second modèle comme critique
Imaginez un second robot bibliothécaire issu d'une autre bibliothèque, avec un autre jeu de livres, et donc une autre perspective sur la qualité de la première réponse. Dans Claude Code, par exemple, vous pouvez brancher un autre modèle et lui demander de noter le résultat :
"If this turns into a complex build, run the final output by a second model to ensure both systems agree."
3. Introduire un signal externe
Dès que c'est possible, apportez une source de vérité. Vous déployez une application ? Connectez l'IA au système cible afin qu'elle puisse confirmer que le déploiement a vraiment réussi au lieu de simplement le supposer. Vous rédigez un rapport mensuel ? Donnez-lui les rapports du trimestre précédent comme référence sur le format attendu. Vous faites entrer de vraies données dans la boucle de vérification pour qu'un "succès" soit vérifiable, et non simplement affirmé.
Ensemble, ces trois éléments transforment la vérification en boucle plutôt qu'en contrôle ponctuel :
Comme l'a dit Boris Cherney, créateur de Claude Code : si l'IA dispose d'une boucle de feedback, la qualité du résultat final est multipliée par 2 ou 3. C'est toute la raison d'être de cette couche.
Couche 3 : l'environment
La spec et le verifier ont besoin d'un endroit pour vivre, et cet endroit, c'est l'environnement que vous construisez. Imaginez un atelier : la spec est le plan épinglé au mur, le verifier est le poste de contrôle qualité près de la porte, et l'environment est l'atelier lui-même. Le problème, c'est que la plupart des gens reconstruisent cet atelier à partir de zéro à chaque fois. Un long historique de chat n'est pas un atelier. Voici comment en construire un qui s'améliore avec le temps.
1. Mettre en place un vrai AGENTS.md
Un fichier d'instructions projet est injecté à chaque prompt, c'est la première chose que l'agent lit pour comprendre comment opérer. Nous gardons le nôtre dans un AGENTS.md à la racine du dépôt : c'est un standard neutre vis-à-vis des fournisseurs, lu automatiquement par de plus en plus d'outils de codage IA, de sorte qu'un seul fichier pilote tous les assistants de l'équipe au lieu d'un fichier par outil. Utilisez-le pour encoder des comportements par défaut que vous devriez autrement répéter :
"Before building anything multi-step, include a verification plan."
Ainsi, la vérification devient obligatoire dans chaque construction au lieu d'être un sujet auquel il faut penser à la main. Un bon fichier d'instructions décrit le fonctionnement du dépôt, quelles compétences personnalisées existent et quand les utiliser, où réside la connaissance, et quelles règles de travail sont non négociables. Faites en sorte que l'environnement soit le vôtre : l'IA doit vivre dans votre monde, pas l'inverse.
2. Construire une base de connaissances LLM
Karpathy est devenu viral sur ce point : une structure de dossiers délibérée sur votre machine qui contient vos propres "données d'entraînement" d'une manière facile à parcourir pour l'IA. Vos données sont votre moat. C'est ainsi que vous commencez à capitaliser sur votre propre propriété intellectuelle au lieu de repartir de zéro à chaque session.
3. Développer votre jeu de compétences
Une bonne règle empirique : si vous prévoyez de faire quelque chose à plusieurs reprises, transformez-le en skill personnalisée, un guide réutilisable pour une tâche donnée. Et les skills s'améliorent avec l'usage. Nous avons une formule dans l'équipe : la meilleure manière de trouver une fuite dans un tuyau, c'est d'y faire passer de l'eau. Continuez à faire passer de l'eau dans vos skills, et les angles morts apparaîtront ; votre système se renforcera avec le temps.
4. Créer des règles dures, pas seulement des demandes
Selon le coût d'une erreur, il faut différents niveaux de garde-fous. Une ligne dans AGENTS.md comme "ne touche pas au dossier /important" est une demande, l'IA peut encore l'ignorer. Pour ce qui ne doit absolument pas être raté, il faut imposer cela au niveau de l'outil. Un pre-tool-use hook qui inspecte le fichier avant toute écriture ou édition rend l'action littéralement impossible, pas seulement déconseillée : une ligne AGENTS.md est un guide que l'agent peut ignorer, un hook est un mur qu'il ne peut pas franchir.
Une manière utile de classer votre travail :
- Toujours faire : suffisamment sûr pour tourner en pilote automatique.
- Demander avant : tout ce que vous voulez revérifier avant que cela n'arrive.
- Ne jamais faire : lignes absolues à ne pas franchir, imposées par des règles et non par des demandes.
La seule chose qui vaut vraiment la peine d'être apprise en profondeur
Lorsqu'on lui demande ce qui compte encore quand l'intelligence devient bon marché, Karpathy donne une réponse qui relie les trois couches :
"You can outsource your thinking, but you can't outsource your understanding."
Chaque couche gravite autour de votre compréhension de la vue d'ensemble. La spec ne fonctionne que si vous connaissez le vrai objectif. Le verifier ne fonctionne que si vous savez à quoi ressemble quelque chose de "bon". L'environment ne fonctionne que si vous savez quelles règles ne doivent jamais être franchies. L'IA fournit la puissance de calcul ; vous fournissez la compréhension, et c'est cette partie que vous ne pouvez pas déléguer.
Comment nous appliquons cela chez vensas
Rien de tout cela n'est théorique pour nous. Nous traitons la collaboration spec-first, les boucles de vérification explicites et des environnements projet bien entretenus comme une partie normale de notre manière de construire du logiciel avec l'IA au quotidien. C'est pourquoi nos conventions AGENTS.md, nos skills personnalisées et nos guardrails au niveau des outils comptent autant que le code lui-même. Le résultat : livrer plus vite sans perdre le contrôle sur la qualité.
Conclusion
Mieux prompter n'est pas une question de mots magiques. C'est une question de construction de trois couches autour du modèle :
- La spec : transformer votre compréhension et votre vrai objectif en un plan précis, agile et relu de façon critique.
- Le verifier : définir le "bon" en amont, obtenir un second avis et intégrer un signal externe pour que la qualité soit vérifiée, pas supposée.
- L'environment : un atelier qui s'améliore avec le temps grâce aux fichiers d'instructions, à une base de connaissances, à des skills réutilisables et à des guardrails durs.
Si vous faites fonctionner les trois ensemble, vous cessez de lutter contre le modèle et commencez à capitaliser avec lui.
Besoin d'aide ?
Vous voulez introduire dans votre équipe des workflows IA pilotés par la spec et réellement vérifiables, mais vous ne savez pas par où commencer ? Nous pouvons vous aider. Contactez-nous via notre page de contact et nous l'examinerons ensemble.
Comment structurez-vous vos propres workflows IA ? Chez vensas, nous serions ravis d'échanger à ce sujet et de partager les meilleures pratiques.
