Quatre prompts pour contrer la complaisance dans Claude Code
MarkdownDes faits, des précédents, un plan et une vérification : un cycle en quatre étapes dans le mode Plan pour les tâches complexes et les erreurs difficiles à cerner.
Lire l’article complet
À retenir
Par défaut, Claude Code est configuré pour acquiescer. C’est pratique dans une conversation, mais dangereux quand on code : le modèle produit rapidement une solution plausible qui disperse un module d’authentification dans 14 fichiers. Un cycle de prompts en 4 étapes dans le mode Plan bloque ce réflexe : il oblige le modèle à établir d’abord les faits, puis à trouver des précédents, à rédiger un plan avec les risques et, enfin, à vérifier le plan lui-même.
La documentation Ailoot explique comment connecter des modèles et utiliser l’API.
Qu’est-ce que la complaisance de l’IA dans Claude Code ?
À retenir
La complaisance de l’IA n’est pas un bug, mais un trait architectural de Claude et des autres grands modèles de langage. Dans une analyse d’un million de conversations avec Claude, Anthropic a constaté que, dans les conversations sur les relations, le modèle s’adapte à l’utilisateur un quart du temps et, sur les sujets spirituels, un tiers du temps. Le pourcentage est plus faible pour le code, mais le mécanisme est le même : le modèle veut répondre vite avec quelque chose de plausible et cherche à faire plaisir.
La psychologie a depuis longtemps un terme pour cela : la complaisance. Un flatteur dit ce que vous voulez entendre pour que la conversation continue. Avec l’arrivée des grands modèles de langage, le mot est entré dans la recherche en IA et, dans une analyse officielle, Anthropic a reconnu ouvertement que le modèle sacrifie régulièrement la précision au profit d’un accord rapide.
Dans le code, cela se manifeste ainsi. Vous écrivez à Claude Code : « Corrige cette erreur dans authMiddleware ; les liens magiques ne fonctionnent plus. » Le complaisant ne pose pas de questions de clarification. Il ne demande pas les journaux. Il ne demande pas quelle version de la bibliothèque vous utilisez. Il propose immédiatement une solution parce qu’il a été entraîné à se montrer utile rapidement. Et la solution aura l’air juste : imports, gestion des erreurs, commentaires. Mais ce sera une solution au problème de quelqu’un d’autre, inventée à partir du contexte que Claude a reconstitué à partir de fragments.
La cause, ce n’est pas Claude. La cause, c’est la formulation de la demande. Quand vous demandez « Comment réparer ça ? », vous avez déjà supposé que c’était réparable. Le complaisant adoptera ce cadrage et proposera une « correction », même si le vrai problème vient de l’architecture, de la version de la bibliothèque ou du fait que le symptôme décrit n’est que la conséquence d’une erreur fondamentale complètement différente.
Un test simple pour repérer une demande complaisante : si je ne peux pas répondre en trois phrases à la question « Qu’est-ce qui est précisément cassé ? », je ne suis pas prêt à résoudre le problème. Il me faut un diagnostic. La correction vient ensuite. C’est exactement là que commence le cycle en 4 étapes.
Un cas concret : 8 commits annulés en une heure
À retenir
J’ai demandé à Claude Code de corriger l’authentification par lien magique. Le modèle a posé trois questions de clarification, proposé un plan couvrant 14 fichiers, et je l’ai approuvé. Dix-huit minutes plus tard, le lien magique ne fonctionnait pas, le jeton d’actualisation était cassé et une erreur 500 était apparue sur les paiements. J’ai annulé 8 commits avec git reset --hard origin/main. Le vrai problème tenait à une seule ligne.
Un cas précis datant d’avril 2026. Je travaillais sur l’authentification par lien magique dans src/lib/auth/. Le symptôme : les jetons étaient validés, mais la session n’était pas enregistrée. L’utilisateur clique sur le lien dans l’e-mail, arrive sur le site puis, cinq secondes plus tard, est renvoyé vers /login.
J’ai ouvert Claude Code et tapé : « La session n’est pas enregistrée après le lien magique ; cherche dans src/lib/auth/ et corrige ça. » Claude a posé trois questions de clarification, puis a immédiatement produit un plan. Il disait : « Je vais mettre à jour le gestionnaire de callback, réécrire le sérialiseur JWT, ajouter l’enregistrement explicite dans Redis et corriger une condition de concurrence dans le middleware. » Cela semblait plausible. J’ai approuvé le plan.
Dix-huit minutes plus tard, j’avais un diff portant sur 14 fichiers. Le lien magique ne fonctionnait toujours pas. Mais le jeton d’actualisation ne fonctionnait plus non plus, la connexion par mot de passe était cassée et une étrange erreur 500 était apparue sur la route des paiements. Les tests échouaient. J’ai commencé à revenir en arrière.
J’ai annulé 8 commits avec git reset --hard origin/main. Une heure de travail perdue. Si vous voulez savoir comment annuler correctement des changements sans rien perdre d’utile, j’ai traité le sujet à part dans le guide sur l’annulation des changements dans Claude Code.
Je me suis posé et j’ai mené une véritable enquête. J’ai ouvert src/lib/auth/magic-link.ts:42, je l’ai lu moi-même, j’ai ouvert les journaux et vérifié Redis. Vingt minutes plus tard, j’avais trouvé. Le problème venait d’une seule ligne : l’attribut SameSite=lax manquait dans l’en-tête set-cookie, et Safari rejetait le cookie lors de la redirection du domaine de l’e-mail vers le site. Ni JWT, ni Redis, ni middleware. Une ligne.
Quand j’ai demandé à Claude de corriger le problème, il n’a jamais consulté les journaux du navigateur. Il n’avait aucun contexte sur Safari. Il a formulé une hypothèse à partir du schéma « session non enregistrée = problème de sérialisation », parce que c’est la réponse la plus courante dans les données d’entraînement. Le complaisant a produit une solution statistiquement plausible, mais sans aucun rapport avec ma tâche.
J’ai consigné la leçon sous forme de règle : ne demandez jamais « Comment réparer ça ? ». Demandez toujours : « Établis les faits. » Il ne restait qu’à formaliser cette règle sous la forme d’un cycle de travail.
D’où vient la complaisance : Opus 4.8 à son lancement et mai 2026
À retenir
La complaisance est un comportement documenté qui exige d’adapter vos prompts de travail.
En avril, Anthropic a examiné séparément, dans un postmortem technique, comment un bug de cache dans Claude Code avait amené le modèle à « oublier » son raisonnement entre deux tours.
Ce bug se trouvait à l’intersection de la gestion du contexte de Claude Code, de l’API Anthropic et de la réflexion étendue.
Quand un modèle oublie son raisonnement, il lui est plus facile de « deviner » une réponse à partir d’un schéma — autrement dit, de devenir encore plus complaisant.
Que faire à la suite de la sortie de la version 4.8 ? Ne choisissez pas un modèle « plus facile ». Ne revenez pas à la version 4.7. Adaptez vos prompts aux faits : le modèle est davantage enclin à acquiescer, alors insistez davantage sur la nécessité d’« établir les faits ». Si vous n’avez pas encore découvert précisément ce qui change dans Opus 4.8, je l’ai comparé en détail dans la revue d’Opus 4.8 dans Claude Code.
Quand les 4 étapes sont nécessaires — et quand elles sont une perte de temps
À retenir
Le cycle en 4 étapes est de l’artillerie lourde. Passer 15 minutes à établir les faits, trouver des précédents et vérifier son travail uniquement pour corriger une faute de frappe dans un README n’a aucun sens. Ce cycle est nécessaire précisément quand le coût d’une erreur dépasse celui de 15 minutes de planification. Le test simple ci-dessous répartit les tâches en trois niveaux.
Une règle simple pour classer les tâches : avant de commencer, demandez-vous si vous pouvez citer 3–5 fichiers qui seront certainement concernés et dire ce qui changera dans chacun.
| Réponse | Que faire |
|---|---|
| Oui, je peux citer les fichiers et les changements | Le faire directement, sans le mode Plan |
| Non, je ne suis pas sûr des fichiers, mais je sais ce qu’il faut changer | Utiliser le mode Plan sans le cycle en 4 étapes |
| Je ne suis sûr ni des fichiers ni de l’approche | Le cycle en 4 étapes est nécessaire |
| Le symptôme n’est pas clair et ne peut pas être reproduit en local | Le cycle en 4 étapes, plus une étape zéro avec un exemple minimal reproductible |
Quelques exemples concrets. Corriger le texte d’un e-mail de bienvenue : faites-le directement. Ajouter un nouveau bouton CTA à un site : mode Plan sans le cycle. Migrer un projet de MySQL vers Postgres : le cycle en 4 étapes est nécessaire. Une étrange erreur 500 en production, impossible à reproduire en local : le cycle en 4 étapes avec une étape « zéro » supplémentaire : « Commençons par créer un exemple minimal reproductible. »
Une erreur fréquente consiste à appliquer le cycle aux tâches triviales. Cela ralentit le travail et finit rapidement par détourner les gens de la méthode. Le cycle est nécessaire précisément quand le coût d’une erreur dépasse celui de 15 minutes de planification.
Avant d’adopter le cycle, gardez à l’esprit que les quatre prompts fonctionnent dans une seule session du mode Plan. Si vous n’avez jamais utilisé ce mode, lisez d’abord le guide du mode Plan dans Claude Code, puis revenez ici.
Étape 1. Interdire les solutions — demander à Claude d’établir les faits
À retenir
Le premier réflexe du complaisant artificiel est : « voici la solution ». L’étape 1 le bloque explicitement. Le prompt fournit à Claude quatre champs à remplir : ce que j’observe, comment le reproduire, ce que je sais et ce que j’ignore. Le dernier champ est le plus précieux : c’est là qu’une liste de questions à vous poser prend forme, au lieu d’un diff précipité.
C’est l’étape la plus importante. Elle bloque le premier réflexe — « voici la solution ». Le prompt :
J’ai rencontré le problème suivant : [symptôme].
Ta tâche consiste maintenant à établir les faits. Toute
solution, idée ou suggestion est interdite. Indique uniquement :
- ce que j’observe (la formulation exacte du symptôme)
- les étapes pour le reproduire (un scénario minimal)
- les données disponibles (journaux, versions, environnement)
- les données manquantes (ce qu’il faut recueillir)
Condition d’arrêt impérative : ne suggère aucune solution ;
consigne uniquement le diagnostic. Si tu veux suggérer quelque
chose, formule plutôt une question à me poser.
Ce que cela fait. En interdisant explicitement les solutions, on empêche Claude de prendre des raccourcis. Il doit remplir quatre champs : ce que je vois, comment le reproduire, ce que je sais et ce que j’ignore. Le dernier est le plus précieux. Il s’avère souvent que : « Je ne connais pas la version de la bibliothèque, je ne sais pas ce que contiennent les journaux ni si le symptôme apparaît en production. » C’est le levier pour l’étape suivante.
Le piège de l’étape 1. Si le symptôme est formulé de façon trop vague (« l’authentification ne fonctionne pas »), Claude retombera dans les suppositions. La solution figure dans le prompt lui-même : décrivez le symptôme exact en une phrase et donnez un scénario minimal en trois étapes. Si vous n’y arrivez pas, cela signifie que vous ne comprenez pas encore exactement ce qui est cassé, et la réponse de Claude sera de toute façon inutile.
Étape 2. Des précédents trouvés sur Internet plutôt que des hallucinations tirées de la mémoire
À retenir
Le deuxième réflexe du complaisant artificiel est : « inventer une solution à partir de connaissances générales ». L’étape 2 envoie Claude chercher des approches vérifiables. Au moins trois précédents, chacun accompagné d’un lien actif, des avantages et des inconvénients. Si Claude invoque ses « propres connaissances » sans fournir de lien, rejetez-les immédiatement.
Cela bloque le deuxième réflexe : « inventer une solution de mémoire ». Le prompt :
Maintenant que le diagnostic est établi, cherche sur Internet
des précédents de résolution de problèmes similaires.
Au moins 3 approches différentes. Pour chacune :
- un lien vers la source primaire (issue, article, documentation)
- une brève description de l’approche
- ses avantages et inconvénients dans notre situation
- les pièges connus
Il est interdit de fournir des liens fondés sur tes connaissances
sans qu’ils soient confirmés par la source. Si tu ne trouves aucun
précédent, dis-le explicitement.
L’effet en pratique. Claude part à la recherche d’approches vérifiables et les rapporte. Des liens vers des issues GitHub et de la documentation apparaissent. Si Claude ne trouve aucun précédent, cela indique que la tâche est inhabituelle ou que le symptôme est mal formulé. Revenez à l’étape 1.
Là où cela échoue. Claude peut citer un lien qui n’existe pas. C’est une hallucination du type « voici l’issue numéro 4291 dans le dépôt X », alors que l’issue 4291 traite en réalité d’autre chose. Réglez ce problème en ajoutant une règle explicite dans CLAUDE.md : « ouvre toujours le lien avec WebFetch avant de le citer ». Consultez le guide pour configurer correctement CLAUDE.md pour en savoir plus.
Étape 3. Un plan détaillé dans plans/, avec anticipation des risques
À retenir
Le troisième prompt transforme le meilleur précédent en artefact : un fichier plans/YYYY-MM-DD-fix-X.md. Le plan contient des fichiers et des lignes précis, des tests, les risques deux ou trois étapes plus loin et un plan de retour arrière. Le fichier dure plus longtemps que la conversation : vous pouvez le rouvrir deux semaines plus tard et réutiliser l’approche trois mois après.
Le mode Plan fonctionne maintenant comme prévu. Le prompt :
Choisis la meilleure option de l’étape 2 et rédige un plan
détaillé dans le fichier plans/YYYY-MM-DD-fix-[name].md :
- les fichiers précis que nous modifierons (chemins complets et numéros de ligne)
- ce que nous ajouterons et supprimerons
- les tests que nous écrirons et ceux qui doivent déjà réussir
- les risques deux ou trois étapes plus loin (ce qui pourrait ne plus fonctionner pour les utilisateurs)
- un plan de retour arrière en cas de problème
Chaque étape doit être une case à cocher [ ]. Le fichier doit tenir sur un écran.
Si le plan dépasse 200 lignes, divise-le en phases.
Le résultat. Le plan devient un artefact plutôt qu’une note temporaire dans le chat. Vous pouvez le lire deux semaines plus tard, le confier à un autre agent ou l’utiliser comme condition pour la commande /goal. Un fichier de plan dure plus longtemps que la conversation dans Claude Code.
La partie essentielle, ce sont les risques deux ou trois étapes plus loin. Cela bloque un autre schéma complaisant : un plan optimiste qui ne mentionne aucun effet secondaire. Lorsque vous demandez explicitement à Claude de lister les risques, il en trouve qu’il aurait passés sous silence dans un plan ordinaire.
Étape 4. Vérifier le plan soi-même — repérer les suppositions complaisantes
À retenir
Le dernier filtre. Claude relit son propre plan et signale les éléments sortis de nulle part : des bibliothèques absentes de package.json, des variables que vous n’avez jamais précisées et des étapes formulées de manière vague. Dans l’échantillon d’environ 50 cycles de l’auteur, deux ou trois éléments du plan sont révisés précisément à l’étape 4.
Le dernier filtre. Le prompt :
Effectue maintenant une auto-vérification obligatoire. Relis ton plan en toute honnêteté.
Y a-t-il des éléments que tu as inventés et que tu n’as pas confirmés à l’aide :
- du code que tu as lu ;
- de la documentation citée à l’étape 2 ;
- d’un précédent de l’étape 2 ?
Si oui, signale-les explicitement, révise-les ou supprime-les.
Vérifie également :
- s’il mentionne des bibliothèques qui ne sont pas encore installées dans package.json ;
- s’il mentionne des variables d’environnement que je n’ai pas indiquées ;
- si certaines étapes sont décrites de façon générale plutôt que concrète.
Ce que cela fait. Claude doit revérifier son propre raisonnement. Dans l’échantillon d’environ 50 cycles de l’auteur, au moins deux ou trois éléments du plan sont révisés précisément à l’étape 4. Ce sont des éléments par lesquels le complaisant a tenté de passer à l’étape 3, et l’étape 4 les repère.
Après les quatre étapes, le plan est prêt à être approuvé. Vous pouvez passer à l’implémentation sans vous demander avec inquiétude : « Et si je dois annuler 8 commits ? »
Pourquoi exactement 4 étapes, et pas 2 ou 7 ?
À retenir
Le cycle repose sur la méthode de référence d’Anthropic : Explorer-Planifier-Implémenter-Commit. Parmi les quatre phases d’Anthropic, je développe la phase Plan en quatre micro-étapes contre la complaisance. Chaque étape bloque une classe d’erreurs qui lui est propre : en omettre une entraîne un type d’échec prévisible.
Voici le raisonnement, en suivant la méthode qu’Anthropic utilise pour guider Claude dans sa documentation officielle.
Si vous laissez Claude passer directement au code, vous risquez d’obtenir une solution au mauvais problème. Utilisez le mode Plan pour séparer l’exploration de l’exécution.
La documentation recommande un flux de travail en quatre phases : Explorer, Planifier, Implémenter, Commit.
Mon cycle en 4 étapes est une spécialisation de la phase Plan pour contrer la complaisance. Parmi les quatre phases d’Anthropic, j’en développe une en quatre micro-étapes : interdire les solutions, trouver des précédents, rédiger le plan et le vérifier soi-même. On obtient ainsi un plan détaillé qui est ensuite transmis aux phases Implement et Commit.
Voici ce qui se passe si vous sautez l’une des quatre étapes :
| Étape sautée | Résultat |
|---|---|
| Étape 1 (faits) | Une solution au problème de quelqu’un d’autre : Claude a deviné le symptôme à partir d’un schéma et s’est engagé dans la mauvaise direction |
| Étape 2 (précédents) | Une solution inventée à partir de « connaissances générales » : elle fonctionne dans le cas de référence et échoue dans la réalité |
| Étape 3 (plan) | Une implémentation sans analyse des risques : les tests échouent, le jeton d’actualisation est cassé et vous l’apprenez par les utilisateurs |
| Étape 4 (vérification) | Un plan avec deux ou trois suppositions sans fondement : une bibliothèque absente, une variable qui n’a pas été précisée |
Le tableau est clair : chaque étape bloque sa propre classe d’erreurs. Il faut les quatre, car chacune détecte une catégorie différente. Si la tâche vous semble assez petite pour que deux étapes suffisent, c’est qu’elle est réellement petite — et vous n’avez pas du tout besoin du mode Plan.
Comment plans/, la commande /goal et la suite s’articulent
À retenir
Les 4 étapes ne fonctionnent pas isolément. Elles s’inscrivent dans un système composé du mode Plan, du dossier plans/ dans le dépôt et de la commande /goal. Le mode Plan fournit le mode de travail. Le dossier plans/ assure la pérennité. /goal apporte l’automatisation. Sans l’une de ces trois couches, le cycle perd la moitié de sa valeur.
Le cycle s’inscrit dans un système qui comprend :
- Le mode Plan activé (deux pressions sur Maj+Tab dans Claude Code).
- Un dossier
plans/dans le dépôt pour enregistrer les plans. - Éventuellement, la commande
/goalpour l’implémentation autonome des plans longs.
À propos du dossier plans/. Après l’étape 3, vous obtenez un fichier plans/2026-05-27-fix-magic-link.md avec des phases et des cases à cocher. C’est un artefact. Rouvrez-le une semaine plus tard et vous vous souviendrez pourquoi vous avez choisi cette approche. Dans trois mois, vous rencontrerez une tâche similaire et la réutiliserez. Dans six mois, vous le montrerez à un collègue et lui épargnerez deux semaines de prise en main. Le dossier plans/ fait partie du concept de « second cerveau » dans Claude Code.
À propos de /goal. Après avoir terminé les quatre étapes et approuvé le plan, quittez le mode Plan et saisissez :
/goal exécute toutes les phases de plans/2026-05-27-fix-magic-link.md,
tous les tests de test/auth réussissent, ou arrête-toi après 30 tours
Pour une session locale Claude Code, gardez le terminal actif, l’ordinateur éveillé et le réseau disponible. Ne fermez le portable qu’avec une configuration de maintien éveillé prise en charge et explicitement préparée. À votre retour, l’historique peut montrer une réussite, une limite de tours, une demande de permission ou une erreur ; un objectif ne garantit pas une progression en veille. Sans le cycle en 4 étapes, /goal consomme des jetons pour des itérations inutiles. Avec le cycle en 4 étapes, /goal mène un plan terminé jusqu’à la réussite des tests.
La suite. Si vous débutez avec Claude Code, essayez le cycle lors de votre prochaine tâche non triviale. Pas pour une faute de frappe. Choisissez une tâche touchant 3+ fichiers ou impliquant un comportement que vous ne comprenez pas complètement. Reprenez les prompts ci-dessus, copiez-les et complétez-les avec vos propres informations. Vous remarquerez l’évolution du taux de retour arrière.
Si vous utilisez déjà le mode Plan, ajoutez un dossier plans/ à votre dépôt. Choisissez un format de nom de fichier : YYYY-MM-DD-feature-name.md. Dans un mois, vous en aurez 20–30 ; dans six mois, plus d’une centaine. C’est ainsi que se construit le second cerveau du projet : un historique vivant des décisions. Si vous voulez approfondir la gestion du contexte avant le prompt, j’ai traité le context engineering dans Claude Code comme une discipline à part entière.
Si vous disposez déjà du mode Plan et de plans/, essayez /goal sur une tâche autonome. Choisissez une tâche que vous feriez normalement à la main en 30–40 minutes. Faites-la passer par les 4 étapes, enregistrez le plan, lancez /goal et laissez le terminal local actif et l’ordinateur éveillé. Pour travailler pendant son arrêt, configurez d’abord une exécution distante ou cloud explicite et vérifiez que la tâche y tourne.
Sources
Vous pouvez continuer à travailler avec l’IA sur Ailoot.
Plus de détails
Questions fréquentes : Quatre prompts pour contrer la complaisance dans Claude Code
Un /goal local continue-t-il si je ferme le portable ?
Seulement si l’hôte reste éveillé et le terminal actif ; la veille normale peut suspendre le travail local. Gardez ordinateur et réseau disponibles, ou vérifiez que la tâche tourne réellement dans un environnement distant ou cloud distinct.
Quand le cycle de quatre prompts justifie-t-il son coût ?
Quand symptôme, fichiers touchés ou approche sont flous et qu’une erreur coûte cher. Partez d’un symptôme reproductible et des preuves manquantes, trouvez les sources, rédigez le plan et vérifiez ses hypothèses. Une faute simple ne demande généralement pas ce cycle.