Claude Code comprend mal la tâche : trois prompts utiles
MarkdownClaude écrit la mauvaise chose parce qu’il se précipite dans le code sans comprendre votre intention. J’explique pourquoi et vous propose 3 prompts prêts à l’emploi pour qu’il pose d’abord des questions.
Lire l’article complet
À retenir
Claude écrit la mauvaise chose parce qu’il se précipite dans le code et imagine ce que vous vouliez. Souvent, il se trompe. Le problème vient presque jamais du modèle : même le meilleur passera à côté si la tâche est vague. Je règle ça en une étape : je demande à Claude de m’interviewer d’abord, de faire émerger mon intention, puis seulement d’écrire. Vous trouverez ci-dessous trois prompts prêts à copier-coller.
Pour en savoir plus sur l’utilisation du service, consultez la documentation Ailoot.
Pourquoi Claude fait-il la mauvaise chose ?
À retenir
Claude reçoit une demande courte, comble immédiatement les éléments manquants et se met à écrire du code en fonction de sa propre interprétation de la tâche. Cette interprétation diffère de la vôtre. C’est ainsi qu’on se retrouve avec un diff touchant 14 fichiers alors qu’on s’attendait à une seule ligne modifiée. La cause, c’est l’écart entre ce que vous avez dit et ce que vous aviez en tête. Le modèle n’y est presque pour rien.
Vous écrivez : « Ajoute des filtres à la page des produits. » Dans votre tête, cela signifie quelques cases à cocher et une liste mise à jour. Claude entend la même chose et décide de créer un moteur de filtrage complet : son propre magasin d’état, une logique distincte de délai de saisie, une synchronisation de l’URL et une douzaine de fonctions auxiliaires. Des centaines de lignes alors que quelques paramètres d’URL auraient suffi.
Dans un cas comme celui-ci, la conclusion est claire : l’agent n’a pas commis d’erreur ; il a simplement résolu un problème bien plus vaste que nécessaire. Le problème était de ne pas avoir décrit le résultat souhaité assez brièvement et précisément.
Le mot clé, c’est « intention ». Vous l’avez en tête ; Claude ne l’a pas. Il voit le texte de votre demande et tout ce qui se trouve dans son contexte jusqu’à cette demande. Puis il comble les lacunes par des suppositions. Plus la demande est courte, plus il en fait — et plus le résultat s’éloigne de ce que vous vouliez.
Anthropic le dit clairement dans la documentation Claude Code :
Si vous laissez Claude se lancer directement dans le code, il risque de résoudre le mauvais problème.
J’ai rencontré ce problème dans mon propre projet. J’ai demandé une correction sur un écran d’autorisation et obtenu un diff touchant la moitié d’un module voisin. Claude n’était pas en cause : je lui ai donné une ligne et il a complété le reste tout seul. Depuis, je commence chaque tâche qui dépasse la correction d’une faute de frappe par des questions — celles que Claude me pose.
Est-ce vraiment le modèle ? Pourquoi même les meilleurs passent-ils à côté ?
À retenir
Le modèle compte moins qu’on ne le pense. Face à une tâche vague, même le meilleur passera à côté : il reçoit les mêmes instructions incomplètes et comble les lacunes avec ses propres suppositions. Les développeurs qui gardent leur agent sous contrôle obtiennent les mêmes résultats avec un modèle haut de gamme ou un modèle de milieu de gamme. Tout dépend de la clarté avec laquelle vous décrivez ce que vous voulez. Ici, la puissance du modèle passe au second plan.
Chaque semaine voit arriver un modèle « plus intelligent » que le précédent, et à chaque fois on se dit que ça y est, l’IA va enfin nous comprendre en quelques mots. Ce n’est pas le cas. Un modèle plus puissant écrit du code plus vite et gère mieux la logique complexe, mais il ne peut toujours pas lire dans vos pensées. Si la tâche est mal formulée, vous obtiendrez quelque chose de très bien écrit, mais toujours incorrect.
La conclusion pour vous est simple. Courir après le dernier modèle pour qu’il devine mieux est une impasse. Il est moins coûteux et plus fiable d’apprendre à lui confier des tâches sans le laisser deviner. C’est ce que nous allons voir.
Qu’est-ce que le grilling, et comment corrige-t-il le décalage avec l’IA ?
À retenir
Le grilling consiste à faire passer un entretien par l’IA avant qu’elle ne commence à travailler : elle pose des questions détaillées sur la tâche jusqu’à ce que vous parveniez à une compréhension commune. Le but est de combler le fossé de communication avant la première ligne de code.
Cela semble contre-intuitif. Nous nous tournons vers l’IA pour aller plus vite, et voilà qu’on nous dit de la ralentir et de lui faire poser des questions d’abord. Pourtant, cinq minutes de questions avant de coder peuvent vous épargner une heure de corrections par la suite.
Le problème ne vient pas seulement du fait que vous avez mal expliqué les choses à Claude. Souvent, vous n’avez pas vous-même réfléchi à la tâche : aux cas à prendre en compte, aux limites, à ce qui compte le plus. Le grilling fait émerger tout cela en vous posant des questions. À la fin de la conversation, vous avez non seulement une tâche que l’IA comprend, mais aussi votre propre tâche, enfin décrite en détail.
C’est ainsi que fonctionne l’ingénierie du contexte : le travail principal se fait avant le prompt, pas pendant. Vous ne cherchez pas une formulation magique pour le prompt ; vous exposez à l’avance vos besoins à Claude, jusqu’à ce qu’il comprenne sans explication supplémentaire.
Comment faire en sorte que Claude vous pose d’abord des questions ?
À retenir
Donnez à Claude une brève description de la tâche et demandez-lui explicitement de vous interviewer avant de commencer : faites-lui poser des questions sur les détails, les cas limites et les contraintes, puis rassembler le tout dans un fichier de spécification. C’est la recommandation officielle d’Anthropic : la documentation Claude Code propose un modèle de prompt prêt à l’emploi. Copiez-le, modifiez la description et collez-le au début d’une session.
Anthropic ne se contente pas d’autoriser cette approche : l’entreprise la recommande. Sa documentation comporte une section intitulée « Laissez Claude vous interviewer », avec un prompt prêt à l’emploi. En voici une version pratique :
Prompt
Prompt de grilling — demander à Claude de vous interviewer
Je veux créer [brève description de la tâche].
Fais-moi passer un entretien détaillé avant d’écrire du code. Pose des questions sur l’implémentation, l’interface, les cas limites, les risques et les compromis. Ne pose pas de questions évidentes : approfondis les aspects délicats auxquels je n’ai peut-être pas pensé.
Pose une question à la fois et attends ma réponse. Pour chaque question, propose immédiatement la réponse que tu recommandes.
Continue jusqu’à ce que nous ayons tout abordé. Rédige ensuite une spécification complète dans un fichier nommé SPEC.md.
Trois détails rendent ce prompt utile plutôt que décoratif. D’abord, « une question à la fois ». Si l’IA vous pose dix questions d’un coup, vous êtes submergé et répondez superficiellement. Ensuite, « propose ta réponse » : vous n’avez pas à tout inventer de zéro ; vous pouvez accepter ou corriger la proposition. Enfin, « rédige une spécification dans un fichier » : l’intention qui a émergé devient un document qui ne se perdra pas.
Anthropic décrit le bénéfice en termes d’effort :
Le temps consacré à bien définir la spécification a plus de valeur que celui passé à observer l’implémentation.
Après l’entretien, ouvrez une nouvelle session et fournissez-lui la spécification finalisée. Un contexte vierge et une intention clairement formulée : Claude vise juste dès le premier essai.
La technique « prouve-moi que c’est le meilleur plan »
À retenir
Ne demandez pas seulement à l’IA de poser des questions : demandez-lui aussi de défendre ses décisions. J’ajoute une exigence à la tâche : prouver que le plan proposé est le meilleur, et pas simplement le premier qui vient à l’esprit, et qu’il a été pensé plusieurs étapes à l’avance. Claude sort ainsi du mode « je vais faire quelque chose de similaire » pour passer en mode critique, où il vérifie son propre travail avant que vous investissiez du temps dans l’implémentation.
Le grilling fait émerger votre intention. Mais l’IA a une autre habitude : choisir la première solution qui semble plausible. Anthropic appelle cela le décalage entre confiance et vérification : Claude produit une implémentation plausible qui ne résiste pas aux cas limites. La solution consiste à demander des preuves avant le code.
Si vous ne pouvez pas vérifier le résultat, ne le soumettez pas.
J’ajoute presque toujours une section « prouve-le » à mon prompt. Voici la formulation exacte :
Prompt
Prompt — demander à l’IA de défendre son plan
Avant d’écrire du code, analyse la tâche comme un critique.
Trouve 2-3 façons de la résoudre. Pour chacune, prouve-moi qu’elle répond vraiment à ma demande au lieu d’ajouter de la complexité pour le plaisir. N’écris pas de code juste pour écrire du code.
Choisis-en ensuite une et prouve que c’est la meilleure solution, pensée plusieurs étapes à l’avance. Qu’est-ce qui risque de casser à mesure que le projet grandit ? Qu’est-ce qui nous échappe pour le moment ?
Propose seulement ensuite une implémentation.
Sans cette section, Claude vous donne la première option viable. Avec elle, Claude élimine lui-même les impasses, explique son choix et vous permet de voir son raisonnement avant qu’un seul fichier soit touché. Vous lisez un court texte qui prend deux minutes au lieu de passer une heure à comprendre pourquoi le code terminé ne fonctionne pas comme prévu.
Pré-mortem : demandez à l’IA de trouver 10 raisons d’échec avant de commencer
À retenir
Un pré-mortem est une technique qui consiste à demander à l’IA d’imaginer que le projet a déjà échoué et d’en nommer les raisons. Claude passe du mode optimiste « je vais m’en occuper » à la recherche des faiblesses qui, autrement, n’apparaîtraient qu’après une semaine de travail. Vous obtenez une liste de risques avant d’avoir investi du temps dans le projet et pouvez les traiter à l’avance.
C’est ma technique préférée, et elle joue sur la psychologie. Quand vous demandez à l’IA de « faire du bon travail », elle se concentre sur la réussite et passe à côté des failles. Demandez-lui d’imaginer un échec et elle commence à voir ce qu’elle avait ignoré. Le prompt est court :
Prompt de pré-mortem — repérer les lacunes avant de commencer
Imagine que nous sommes dans un an. Le projet que nous préparons a échoué.
Écris 10 raisons pour lesquelles c’est arrivé. De quoi n’avons-nous pas tenu compte au départ, qu’avons-nous sous-estimé, où avons-nous bâclé le travail et quelles hypothèses se sont révélées fausses ?
Pour chaque raison, dis-moi ensuite ce que nous pouvons corriger dès maintenant pour y remédier.
J’utilise ce prompt avant d’approuver le plan. La moitié des raisons sont absurdes, mais l’autre moitié correspond à de vrais pièges dans lesquels je serais tombé une semaine plus tard. Les traiter dès la phase de planification prend dix minutes. Les découvrir dans un projet terminé demande plusieurs jours d’enquête.
La combinaison est simple : le grilling fait émerger l’intention, « prouve-le » défend la décision et le pré-mortem repère les lacunes. Trois courts textes à coller avant d’écrire du code. Ils transforment Claude, exécutant pressé, en collaborateur qui réfléchit d’abord.
Pourquoi un contexte surchargé rend-il Claude idiot ?
À retenir
Claude dispose d’une fenêtre de contexte limitée, c’est-à-dire la quantité d’informations qu’il peut garder à l’esprit en même temps. Quand elle est remplie à plus de moitié, il commence à perdre des détails importants, à confondre les accords antérieurs et à combler les lacunes au lieu de se souvenir. Une longue session qui part dans tous les sens est une raison fréquente pour laquelle l’IA fait, en fin de journée, quelque chose de complètement différent de ce dont vous étiez convenus le matin.
Même une tâche parfaitement formulée échoue si vous la traitez dans un contexte encombré. Voici comment cela fonctionne : chaque nouvelle demande que vous faites ajoute tout l’historique de la conversation au contexte de travail de Claude. Plus la session est longue, plus la fenêtre se remplit vite. Ne la laissez pas se remplir au-delà de la moitié ; ensuite, l’IA commence à agir bêtement et à perdre des éléments importants discutés au début.
Voici la règle qui m’épargne le plus de frustration : une tâche, une discussion. Vous avez terminé une fonction ? Fermez la discussion et ouvrez-en une nouvelle pour la tâche suivante. Oui, tout faire dans une seule fenêtre est parfois plus pratique, mais vous le paierez par un contexte perdu et des réponses hors sujet.
Anthropic appelle ce mode d’échec une « session tiroir à bazar ». La solution est simple : utilisez /clear entre des tâches sans rapport afin de vider la fenêtre et d’éviter d’emporter le fouillis de la tâche précédente dans la nouvelle.
Si vous faites de longues sessions sans comprendre où partent l’argent et l’attention de l’IA, j’aborde séparément ce sujet dans le guide sur la consommation de tokens de Claude Code. J’ai aussi rassemblé les bases du contexte persistant, que Claude lit à chaque démarrage, dans le guide sur la configuration de CLAUDE.md.
Grilling ou Plan Mode : quelle est la différence, et comment les combiner ?
À retenir
Le grilling et Plan Mode règlent deux aspects différents du même problème. Le grilling fait émerger votre intention par des questions avant qu’il y ait un plan. Plan Mode prend une tâche déjà comprise et vous présente un plan de modifications sans rien toucher jusqu’à votre approbation. Ils fonctionnent mieux ensemble : le grilling clarifie d’abord ce que nous construisons, puis Plan Mode montre exactement comment.
On confond souvent ces deux techniques ou on suppose qu’une seule suffit. En pratique, elles interviennent à des étapes différentes du processus.
| Fonction | Grilling | Plan Mode |
|---|---|---|
| Quand | Avant le plan : clarifie l’intention | Après : crée un plan de modifications |
| Qui pose les questions à qui | L’IA vous interviewe | Vous lisez le plan et l’approuvez |
| Résultat | Une spécification de la tâche | Un plan de modifications fichier par fichier |
| Principal avantage | Évite « ce n’est pas ce que je voulais » | Évite « ne touche à rien d’autre » |
Anthropic décrit un flux de travail de référence en quatre phases : d’abord Explore (Claude examine et pose des questions), puis Plan (élabore un plan sans rien modifier), ensuite Implement (écrit le code conformément au plan) et enfin Commit (enregistre le résultat). Le grilling intervient dans la première phase ; Plan Mode, dans la deuxième. Pour une explication détaillée de cette deuxième phase, consultez le guide sur Plan Mode dans Claude Code.
Anthropic elle-même émet une réserve importante : ne compliquez pas les petites tâches avec cette méthode.
Si vous pouvez décrire une modification en une phrase, passez le plan.
Pour une faute de frappe, un renommage ou une modification d’une ligne, indiquez simplement ce qu’il faut faire, sans entretien ni plan. Le grilling est utile pour les tâches ambiguës et coûteuses en cas d’erreur. Pour les tâches triviales, il ne fait que vous ralentir.
5 erreurs de formulation qui poussent l’IA à faire la mauvaise chose
À retenir
Presque toutes les erreurs de l’IA viennent de cinq problèmes de formulation : une phrase vague, aucune contrainte, « écris du code » sans étape préalable de compréhension, aucune définition de « terminé » et une session interminable pour tout faire. Chacun pousse Claude à compléter la tâche par des suppositions. Voici à quoi ressemble chaque erreur et comment la remplacer.
J’ai résumé les pièges courants dans un tableau. À gauche, ce que les gens font généralement et ratent ; à droite, ce qu’il vaut mieux faire.
| Erreur | Exemple | À faire à la place |
|---|---|---|
| Phrase vague | « Améliore le tableau de bord » | Décrivez la tâche et lancez une séance de grilling : laissez l’IA faire émerger les détails en posant des questions |
| Aucune contrainte | « Ajoute l’autorisation » | Précisez ce qui ne doit pas être cassé, quelles bibliothèques ne doivent pas être ajoutées et ce qui est hors périmètre |
| « Écris du code » tout de suite | Prompt, puis on commence à coder | D’abord « comprendre et poser des questions », puis écrire le code |
| Aucune définition de « terminé » | Vous vous attendez à ce que l’IA devine le résultat | Donnez un exemple, une capture d’écran de référence ou un test qui montre ce que signifie « fonctionner » |
| Une seule session pour tout | Passer toute la journée dans une conversation | Une tâche, une nouvelle discussion, pour éviter d’encombrer le contexte |
Relisez le dernier prompt auquel l’IA a répondu de travers. Il y a presque sûrement l’une de ces cinq erreurs. Le plus souvent, c’est la première : vous lui avez donné une courte formule et vous vous attendiez à ce que Claude complète correctement le reste. Il l’a complété, mais pas comme vous l’aviez imaginé.
Et maintenant : créez un système pour que l’IA vous comprenne en quelques mots
À retenir
Des prompts ponctuels règlent des tâches ponctuelles. Pour que l’IA vous comprenne sans longues explications à chaque fois, il vous faut un système : le grilling fait émerger l’intention pour chaque tâche, un Second Brain stocke les connaissances du projet et l’ingénierie du contexte relie tout ce que Claude lit avant le prompt. La raison pour laquelle il fait la mauvaise chose disparaît alors : il dispose toujours d’assez de contexte pour ne pas avoir à deviner.
Les trois prompts de ce guide — le grilling, « prouve-le » et le pré-mortem — traitent la tâche du moment. C’est déjà beaucoup : vous ne vous retrouvez plus avec un diff touchant 14 fichiers alors que vous ne vouliez modifier qu’une ligne.
Mais le grilling a ses limites. Faire émerger votre intention de zéro à chaque fois prend beaucoup de temps. Le véritable changement vient de la présence permanente d’une partie du contexte : dans un dossier contenant les connaissances sur votre projet, dans un fichier CLAUDE.md que Claude lit à chaque démarrage et dans votre méthodologie encodée dans des skills. L’IA aborde alors la tâche en connaissant déjà votre activité, vos objectifs et votre style. Elle vous comprend en quelques mots parce que vous avez préparé la moitié du contexte à l’avance.
Une analyse récente d’Anthropic montre l’ampleur du travail : les développeurs utilisent l’IA dans environ 60% de leur travail, mais ne peuvent lui faire entièrement confiance que pour 0-20% des tâches. Pour le reste, il faut votre compréhension, votre supervision et votre capacité à expliquer ce qu’il faut construire. Voilà la compétence qui vaut la peine d’être développée, plutôt que de courir après le modèle le plus intelligent.
Sources
Découvrez Ailoot.
Plus de détails
Questions fréquentes : Claude Code comprend mal la tâche : trois prompts utiles
Quand utiliser le prompt d’entretien avant de coder ?
Lorsque résultat, cas limites ou contraintes sont flous et qu’une erreur coûterait cher. Posez une question à la fois et enregistrez l’accord dans SPEC.md. Une faute ou une modification d’une ligne clairement définie peut être demandée directement.
Que vérifier avant d’accepter le plan proposé ?
Demandez deux ou trois approches et comparez leur respect de la spécification et des contraintes. Lancez ensuite le prompt de pré-mortem, examinez les causes d’échec et traitez les risques pertinents avant d’implémenter.