La phrase qui casse tout

Ce que c'est et pourquoi ça compte

La phrase qui casse tout, c'est celle qu'on lance en passant : « répare la connexion », « rends la page plus rapide », « ajoute les paiements ». Claude Code la prend au sérieux et fait quelque chose. Le problème, c'est qu'il décide seul ce que veut dire « réparé », ce qu'il a le droit de toucher et quand il a fini.

Ce n'est pas un défaut de l'IA. Elle ne lit tout simplement pas dans vos pensées. Le guide d'Anthropic sur les prompts le dit sans détour : traitez Claude comme un collègue brillant mais tout juste arrivé, qui ne connaît ni vos règles ni votre projet. Plus vous êtes précis sur ce que vous voulez, meilleur est le résultat.

C'est pour ça qu'avant chaque demande je remplis un modèle en trois lignes : ce qui doit se passer, ce qui ne doit pas changer, comment on le vérifie. Ça me prend peu de temps. Ça m'évite le pire : découvrir à la fin qu'il a réécrit quelque chose qui marchait. La même IA, avec une demande claire, vous donne un résultat différent. Ce n'est pas de la magie : c'est être clair avec quelqu'un qui ne lit pas dans vos pensées.

Le modèle en trois lignes

Le voici. Copiez-le et remplissez les crochets. Une ligne par partie suffit.

Ce qui doit se passer : [le résultat à obtenir, avec vos propres mots]
Ce qui ne doit pas changer : [fichiers, pages ou fonctions à ne pas toucher]
Comment on le vérifie : [comment savoir que ça marche : un test, un clic, une donnée qui doit apparaître]

Ce qui doit se passer

Le résultat que vous voulez voir, pas la façon d'y arriver. Écrivez-le avec vos mots, comme vous le diriez à voix haute. « Quand j'appuie sur Enregistrer, la note apparaît dans la liste » marche mieux que « corrige le bug de l'enregistrement », parce que ça dit ce que doit voir la personne qui utilise l'app. Si vous savez où ça se passe, quelle page, quel bouton, écrivez-le : comme ça, Claude n'a pas à deviner.

Ce qui ne doit pas changer

Les limites : fichiers, pages ou fonctions qui doivent rester comme ils sont. Pour réparer une chose, Claude « améliore » parfois d'autres choses à côté que personne ne lui a demandées. Si vous lui dites où ne pas mettre les mains, il a une limite claire. C'est la ligne que presque tout le monde saute, et j'y reviens plus bas.

Comment on le vérifie

Comment savoir que ça marche : un test, un clic, une donnée qui doit apparaître. Cette ligne sert à vous et à Claude. S'il a une vérification qu'il peut lancer tout seul, comme un test qui passe ou qui échoue, il peut essayer, lire le résultat et se corriger avant de vous dire qu'il a fini. Sans ça, le seul signal, c'est que le travail « a l'air fini », et la vérification vous revient.

Deux exemples à copier

Exemple 1 : un bouton qui n'enregistre pas

Ce qui doit se passer : quand j'appuie sur le bouton Enregistrer dans la page Notes, ça doit créer une ligne dans la table des notes de la base de données.
Ce qui ne doit pas changer : ne touche pas à la connexion et ne change pas le design de la page.
Comment on le vérifie : dis-moi exactement comment je le teste, étape par étape, et si tu peux, écris un test qui le vérifie.

Regardez la troisième ligne. Pas besoin de savoir écrire un test : je demande à Claude de me dire comment l'essayer et, s'il peut, de l'écrire lui-même. Vous n'avez pas à savoir comment on vérifie. Vous devez juste exiger qu'il y ait un moyen.

Exemple 2 : une page lente

Ce qui doit se passer : la page des tarifs doit s'ouvrir en moins de deux secondes, même sur téléphone.
Ce qui ne doit pas changer : les prix, les textes et le paiement restent identiques.
Comment on le vérifie : mesure le temps de chargement avant et après, et montre-moi les deux chiffres.

Ici, la vérification, c'est un chiffre avant et un après. Si Claude vous dit « c'est plus rapide maintenant » sans les deux chiffres, vous ne savez pas si c'est vrai. Et la ligne du milieu protège ce que vous ne voulez pas voir changer par erreur pendant qu'il optimise : prix, textes, paiement.

Trois conseils pour l'utiliser dans Claude Code

1. Si vous ne savez pas comment le vérifier, arrêtez-vous

Si vous ne savez pas répondre à « comment on le vérifie », vous ne savez pas encore ce que vous voulez. Ça arrive, et mieux vaut s'en rendre compte avant qu'après. Au lieu de lancer le travail, demandez de l'aide pour y voir clair :

Aide-moi à comprendre comment vérifier ça, n'écris pas de code.

Pour les travaux plus importants, j'utilise le mode plan de Claude Code (plan mode). Claude lit les fichiers et vous propose un plan, mais ne modifie rien tant que vous ne l'avez pas approuvé. Vous y entrez en appuyant sur Shift+Tab jusqu'à ce que « plan mode on » apparaisse en bas, ou en tapant /plan devant votre message. C'est là que je colle le modèle et que je demande :

Lis le modèle ci-dessous et propose-moi un plan. Dis-moi quels fichiers tu comptes toucher, confirme que tu ne touches pas ceux que j'ai exclus et explique-moi comment on fera la vérification de la dernière ligne.

[collez ici le modèle rempli]

Pour une petite modification, pas besoin de plan : si vous pouvez la décrire en une phrase, comme corriger une faute dans un texte, demandez-la directement.

2. Ne sautez pas la ligne du milieu

« Ce qui ne doit pas changer », c'est la partie que tout le monde saute, et c'est elle qui sauve votre connexion, vos paiements et vos vraies données. Ce qu'il ne doit jamais toucher, je l'écris aussi dans le CLAUDE.md, le fichier du dossier du projet que Claude Code lit au début de chaque session. Par exemple cette ligne :

Ne modifie pas la connexion, les paiements ni les données des utilisateurs sans me demander avant.

Attention quand même : le CLAUDE.md est une consigne, pas un cadenas. Claude le traite comme du contexte, pas comme un blocage. C'est pour ça que, quand une demande passe près de ces parties, je les réécris quand même dans le modèle.

3. À la fin, demandez le compte rendu

Quand il a fini, demandez toujours :

Dis-moi ce que tu as changé et ce que tu n'as pas touché.

Ensuite, comparez la réponse avec le modèle. S'il a touché quelque chose de la ligne du milieu, ou si la vérification de la troisième ligne manque, vous le voyez tout de suite. Dans ce cas, je n'avance pas et je demande :

Montre-moi la preuve pour la dernière ligne du modèle : le test avec le résultat, ou les étapes exactes pour que je l'essaie moi-même.

Les erreurs les plus courantes

• Décrire le code au lieu du résultat, du genre « change cette fonction » : écrivez ce que doit voir la personne qui utilise l'app et laissez le comment à Claude.
• Laisser vide « ce qui ne doit pas changer » parce que ça semble évident : écrivez au moins connexion, paiements et vraies données quand le travail passe à côté.
• Une vérification floue comme « vérifie que ça marche » : demandez quelque chose qui se voit ou se mesure, c'est-à-dire un test qui passe, un clic, un chiffre.
• Mettre trois demandes dans le même modèle : un modèle, une seule chose, et le reste vous le demandez après, une chose à la fois.
• Faire confiance au « c'est fait » sans compte rendu : demandez ce qu'il a changé et ce qu'il n'a pas touché, et comparez avec le modèle.

Check-list

• J'ai écrit le résultat avec mes mots
• J'ai écrit ce qu'il ne doit pas toucher
• Je sais comment je vérifierai que ça marche
• Le modèle ne demande qu'une seule chose
• Pour un gros travail, j'ai d'abord demandé un plan
• À la fin, j'ai demandé ce qu'il a changé et ce qu'il n'a pas changé

Questions fréquentes