La demande qui marche : le but, le contexte, les contraintes, la preuve

Quatre questions à régler d'avance

Une bonne demande répond à quatre questions avant qu'on les pose :

1. Le but : qu'est-ce que je veux obtenir, et pourquoi ça compte ?
2. Le contexte : où ça se passe, qu'est-ce qui existe déjà ?
3. Les contraintes : qu'est-ce qui ne doit pas bouger ?
4. La preuve : comment saura-t-on que c'est fini ?

Tu n'as pas à écrire ces quatre titres à chaque fois. Mais si une des quatre réponses manque, c'est elle que Claude va inventer.

Un vrai cas : des hashtags qui n'existaient pas

Mes vidéos partent sur TikTok, Instagram et YouTube avec des hashtags, les mots-clés précédés d'un #. Un jour, je trouve sur YouTube des hashtags qui n'existent pas : #debug au lieu de #debugging, #short au lieu de #shorts. Ils étaient déjà programmés sur deux semaines.

Ma demande à Claude, telle quelle : « la prochaine fois, tu vérifies tous les tags, s'ils existent ».

L'intention est bonne. Mais tout reste ouvert : vérifier où et comment, combien de hashtags garder, et que faire des vidéos déjà envoyées ?

La même demande, en quatre parties

But : ne plus jamais publier un hashtag qui n'existe pas.
Un hashtag faux ne ramène personne, et ça se voit.

Contexte : chaque vidéo a un jeu de hashtags par réseau
(TikTok, Instagram, YouTube). Aujourd'hui ils sont écrits
à la main dans chaque fiche.

Contraintes :
- une seule source pour tous les hashtags, par série
  et par réseau ;
- au plus 5 sur TikTok, 5 sur Instagram, 3 sur YouTube,
  avec #shorts en dernier sur YouTube ;
- ne touche pas aux vidéos déjà envoyées.

Preuve : un script vérifie que chaque hashtag existe sur
son réseau, et la fabrication d'une vidéo refuse une fiche
hors normes. Après chaque production, l'audit doit
afficher 0 bloquant.

C'est la règle qui tourne aujourd'hui sur ma chaîne. Elle a été appliquée à 281 fiches, et plus aucun hashtag n'y est écrit à la main.

Regarde ce qui a changé : l'intention est la même, mais chaque question que Claude aurait dû trancher seul a maintenant sa réponse.

Partie par partie

Le but : dis pourquoi

Le « pourquoi » sert à tous les cas que tu n'as pas prévus. Si Claude sait qu'un hashtag faux ne ramène personne, il sait aussi quoi faire d'un hashtag douteux : il l'écarte.

Le guide d'Anthropic donne un exemple parlant. « N'utilise jamais de points de suspension » marche moins bien que : « Ta réponse sera lue par une synthèse vocale : n'utilise jamais de points de suspension, elle ne saura pas les prononcer. » Avec la raison, Claude généralise tout seul.

Le contexte : montre au lieu de raconter

Plutôt que décrire où se trouve le code, désigne-le. Dans Claude Code, tape @ puis le début d'un chemin : un menu te propose les fichiers, et Claude lit celui que tu choisis avant de répondre.

La documentation de Claude Code donne deux exemples que je traduis :

• Au lieu de « ajoute un widget calendrier », écris : « regarde comment sont faits les widgets de la page d'accueil, HotDogWidget.php est un bon exemple, et suis ce modèle pour un widget calendrier ».
• Au lieu de « pourquoi cette API est si bizarre ? », écris : « parcours l'historique git de ExecutionFactory et résume comment son API en est arrivée là ».

Dans les deux cas, tu montres à Claude où trouver la réponse.

Les contraintes : ce qui ne doit pas bouger

Une contrainte, c'est une limite que Claude ne peut pas deviner : garder la même signature de fonction, ne pas ajouter de dépendance, ne toucher qu'à un dossier.

Exemple officiel : « écris un test pour foo.py qui couvre le cas où l'utilisateur est déconnecté. Évite les mocks. » Un mock est une fausse version d'un module, utilisée dans les tests. Sans cette dernière phrase, c'est Claude qui décide s'il en utilise.

Le verbe compte aussi. Selon le guide d'Anthropic, « tu peux me suggérer des changements ? » amène parfois de simples suggestions, sans modification. « Modifie cette fonction pour qu'elle soit plus rapide » amène des modifications.

La preuve : comment on sait que c'est fini

La preuve, c'est ce que Claude peut lancer lui-même pour savoir s'il a réussi. Exemple de la documentation : « écris une fonction validateEmail. Cas de test : user@example.com est vrai, invalid est faux, user@.com est faux. Lance les tests après l'avoir écrite. »

Sans preuve, Claude s'arrête quand le travail a l'air fini. Avec une preuve, il s'arrête quand le test passe. Le chapitre 3 y revient en détail.

Quand faire plus court

Cette structure n'est pas une obligation. La documentation de Claude Code le rappelle : une demande vague peut être utile quand tu explores. « Qu'est-ce que tu améliorerais dans ce fichier ? » fait remonter des idées auxquelles tu n'aurais pas pensé.

Et si tu peux décrire le changement en une phrase, fais-le en une phrase. Les quatre parties servent quand « à peu près » ne suffit pas : plusieurs fichiers, un comportement précis, une erreur qui coûterait cher.

Ce que la suite t'apporte

Tu as la structure. La suite t'apprend à la remplir sans effort, et à t'assurer que le résultat est juste.

• Le mode plan : Claude lit le code et rédige lui-même le contexte et le plan. Tu corriges ce plan avant qu'une seule ligne change.
• Les images : une capture d'erreur ou une maquette remplace un long paragraphe. Tu verras comment la donner à Claude Code sous Windows, Mac et Linux, et le piège de l'image trop petite, où &$v se lit &&$v.
• La dictée : comment je dicte mes demandes à la voix, en phrases longues, sans perdre en précision.
• Les preuves : pourquoi mes images de contrôle étaient parfaites alors que la vidéo finale n'avait aucune animation, et comment l'éviter.
• Corriger le tir et une bibliothèque de demandes prêtes à copier.

Sources : les bonnes pratiques de Claude Code, les recettes courantes et le guide d'écriture des demandes d'Anthropic, vérifiés le 19 octobre 2026.