Comment utiliser Claude Code avec des prompts : un guide pratique pour de meilleurs résultats

Claude Code n'est pas un chatbot, alors arrêtez de l'utiliser comme tel

La plupart des gens arrivent à Claude Code depuis une fenêtre de chat et l'utilisent de la même façon : une demande vague, un mur d'échanges, beaucoup de « non, pas comme ça. » Ça fonctionne la plupart du temps, et c'est aussi la façon la plus lente d'utiliser l'outil.

Le modèle mental est différent. Comme Anthropic le souligne dans son guide des meilleures pratiques, Claude Code « explore, planifie et implémente » par lui-même : il lit les fichiers, exécute des commandes et travaille sur un problème pendant que vous regardez, redirigez ou partez. Donc votre travail cesse d'être « taper la réponse » pour devenir « préparer le travail ». Sean Tierney, qui a passé un an à construire de vraies applications avec l'outil, le décrit comme apprendre « à agir comme le meneur de jeu, pas le quarterback. »

Ce recadrage est tout l'article. Tout ce qui suit est une façon concrète de préparer le travail pour que Claude le fasse bien du premier coup plutôt que du quatrième.

Soyez précis : décrivez le résultat, pas les étapes

« Plus vos instructions sont précises, moins vous aurez besoin de corrections », note Anthropic. « Claude peut inférer l'intention, mais il ne peut pas lire dans vos pensées. » C'est le seul changement de plus fort levier que vous puissiez faire, et il ne coûte rien.

L'avant-après dans le propre guide d'Anthropic le rend évident. Ne dites pas « ajouter des tests pour foo.py. » Dites : « écrire un test pour foo.py couvrant le cas limite où l'utilisateur est déconnecté. sans mocks. » Ne dites pas « corriger le bug de connexion. » Dites « les utilisateurs signalent que la connexion échoue après l'expiration de la session, vérifiez le flux d'authentification dans src/auth/, notamment le renouvellement du token, écrivez un test échouant qui reproduit le problème, puis corrigez-le. »

L'astuce est de déclarer le résultat et les contraintes, puis de laisser Claude trouver le où. Le centre d'aide d'Anthropic l'appelle « Déclarez le résultat, pas les étapes » : pas « ouvrez userService.ts, trouvez la fonction validate, ajoutez un null check à la ligne 42 », mais « les utilisateurs sans e-mail font planter la validation, faites-la gérer ça gracieusement et ajoutez un test. » Vous ne microgérez pas le diff, vous décrivez le monde que vous voulez qui soit vrai.

Une mise en garde qui vaut la peine d'être conservée : vague c'est bien quand vous explorez. « Que amélioreriez-vous dans ce fichier ? » est un excellent prompt précisément parce qu'il révèle des choses auxquelles vous n'auriez pas pensé à demander. La précision est pour quand vous savez ce que vous voulez, pas pour explorer.

Donnez-lui la matière brute : fichiers, captures d'écran, URLs, logs redirigés

Un prompt précis a encore besoin de matière brute. Claude Code a plusieurs façons de tirer le contexte directement dans la conversation, et les utiliser surpasse la description de mémoire :

• Référencez les fichiers avec @. Taper @src/auth/login.ts fait lire le fichier par Claude avant de répondre. Quand vous connaissez déjà le chemin, c'est plus rapide et moins coûteux que de le laisser chercher. C'est aussi pourquoi une structure de dépôt propre est payante, et pourquoi des articles comme naviguer dans une base de code avec Claude Code sont importants.
• Collez des images. Faites glisser ou collez une capture d'écran d'un design ou d'une erreur, puis dites « implémentez ce design, prenez une capture d'écran du résultat et listez les différences. » Claude peut voir l'interface utilisateur.
• Donnez-lui des URLs. Pointez-le vers une page de documentation ou une référence d'API. Vous pouvez mettre en liste blanche les domaines que vous utilisez souvent avec /permissions.
• Redirigez des données. cat error.log | claude envoie le fichier directement. C'est la passerelle pour utiliser Claude Code dans le terminal comme un outil Unix composable.

Le centre d'aide a une règle directe attachée à ceci : donnez-lui l'erreur, mot pour mot. Collez la trace de pile complète plutôt que de la résumer. Le nom exact du fichier, le numéro de ligne et le message sont ce qui permet à Claude de sauter au bon code plutôt que de deviner. Pour des sessions plus délicates, notre guide de débogage avec Claude Code va plus loin.

Faites-le planifier avant d'écrire une ligne de code

C'est ce qui sépare les gens qui aiment Claude Code de ceux qui l'adorent. « Laisser Claude sauter directement au codage peut produire du code qui résout le mauvais problème », avertit Anthropic. La solution est une boucle en quatre phases : explorer, planifier, implémenter, valider.

Les deux premières phases se déroulent en mode plan, où Claude lit les fichiers et propose une approche mais ne fait zéro modification. Vous y entrez avec Shift+Tab (appuyez deux fois pour atteindre le mode plan), ou démarrez une session avec claude --permission-mode plan. Dans VS Code, le plan s'ouvre comme un document markdown que vous pouvez commenter en ligne ; dans le terminal, Ctrl+G ouvre le plan dans votre éditeur pour que vous puissiez le modifier directement avant que Claude continue. Vous pouvez lire la configuration complète dans notre guide du mode interactif.

Le consensus des praticiens est encore plus fort que celui d'Anthropic. Voici Sean Tierney, qui construit avec l'outil quotidiennement :

« Commencez toujours en Mode Plan. Résistez à la tentation de plonger directement dans l'implémentation. Vous pouvez donner à CC exactement le même prompt, mais en commençant d'abord en mode plan et en lui faisant réfléchir à l'avance, vous obtiendrez un résultat bien meilleur à chaque fois en ayant à proposer et défendre un plan à l'avance. Cette satisfaction légèrement retardée par rapport à se précipiter dans l'implémentation vaut bien les 2 minutes d'attente. » - Sean Tierney, Vibecode Lisboa

Quand ne pas planifier ? La règle générale d'Anthropic est celle que j'utilise : si vous pouvez décrire le diff en une phrase, ignorez le plan. Une faute de frappe, une ligne de log, un renommage de variable, demandez-le simplement. La planification vaut la peine quand vous n'êtes pas sûr de l'approche, que le changement s'étend sur plusieurs fichiers, ou que vous ne connaissez pas encore bien le code.

Donnez à Claude un moyen de vérifier son propre travail

Voici le mode d'échec dont personne ne vous avertit : Claude s'arrête quand le travail semble terminé. Sans vérification exécutable, « semble terminé » est le seul signal qu'il a, ce qui signifie que vous devenez la boucle de vérification, relisant chaque diff à la main.

La solution est de lui remettre quelque chose qui retourne succès ou échec : une suite de tests, un build, un linter, un script qui compare la sortie à un fixture, ou une capture d'écran à comparer à un design. « Donnez à Claude une vérification qu'il peut exécuter », dit Anthropic. « C'est la différence entre une session que vous regardez et une dont vous pouvez vous éloigner. » Donc la vérification appartient au prompt : « écrire une fonction validateEmail, exemples de cas de test : user@example.com est vrai, invalid est faux, user@.com est faux, exécuter les tests après implémentation. »

C'est pourquoi le prompting orienté test fonctionne si bien. Demandez à Claude d'écrire les tests en premier, confirmez qu'ils échouent, puis implémentez jusqu'à ce qu'ils passent. Et demandez-lui de montrer les preuves plutôt que d'affirmer le succès : la sortie du test, la commande exécutée, la capture d'écran. Examiner les preuves est plus rapide que de relancer vous-même la vérification. Si vous voulez que cela soit plus strict, vous pouvez l'escalader en un hook déterministe qui se déclenche quand Claude essaie de terminer, ce que notre référence des hooks explique.

Traitez votre fenêtre de contexte comme un budget

Presque tous les problèmes de prompting dans Claude Code remontent à une chose : la fenêtre de contexte contient toute la session (chaque message, chaque lecture de fichier, chaque sortie de commande) et les performances du modèle se dégradent à mesure que cette fenêtre se remplit. Une seule session de débogage peut brûler des dizaines de milliers de tokens, et une fois qu'elle est encombrée, Claude commence à « oublier » vos instructions précédentes.

Gérez-la donc délibérément :

• /clear entre les tâches non liées. C'est le grand levier. Tierney l'appelle « l'option nucléaire, utilisez-la libéralement entre les fonctionnalités. » Une fenêtre fraîche avec un prompt précis surpasse une longue pleine d'impasses.
• /compact <instructions> quand vous voulez continuer mais réduire le gras, par exemple /compact concentrez-vous sur les changements d'API.
• Déléguez à des sous-agents. Investiguer une grande base de code remplit votre fenêtre de lectures de fichiers. Un sous-agent fait cette lecture dans sa propre fenêtre et ne rapporte que le résumé. « Puisque le contexte est votre contrainte fondamentale, les sous-agents sont l'un des outils les plus puissants disponibles », dit Anthropic. Dites simplement « utiliser un sous-agent pour enquêter sur la façon dont nous gérons le renouvellement de token. » Notre guide sur les sous-agents Claude Code que vous pouvez construire contient plus de modèles.

Si vous voulez voir exactement ce qui consomme votre fenêtre, /context visualise ce qui est chargé, y compris quels outils connectés sont les grands consommateurs de tokens.

Corrigez rapidement et sachez quand recommencer

Anthropic est clair que « les meilleurs résultats viennent de boucles de rétroaction serrées. » Vous n'attendez pas que Claude finisse un mauvais virage pour tout expliquer à nouveau. Les outils de correction :

• Esc arrête Claude en pleine action. Le contexte est préservé, donc vous pouvez rediriger sur le moment.
• Esc Esc (ou /rewind) ouvre le menu de retour en arrière pour restaurer un état de conversation ou de code précédent.
• « Annule ça » fait révertir à Claude ses propres changements.

Il y a une note de ton ici qui compte plus qu'il n'y paraît : corrigez-le comme un collègue, pas comme un moteur de recherche. Vous ne retapez pas toute la requête, vous dites juste ce qui ne va pas, comme « ça change l'API publique, gardez la même signature », et Claude n'ajuste que ça. Et l'heuristique sur laquelle je me fie le plus : si vous avez corrigé Claude plus de deux fois sur le même problème, le contexte est pollué par des approches échouées. Lancez /clear et recommencez avec un meilleur prompt qui intègre ce que vous venez d'apprendre. Une session propre surpasse presque toujours une longue qui porte des corrections accumulées.

Écrivez un CLAUDE.md : le prompt que vous n'écrivez qu'une seule fois

Tout ce qui précède est par session. Un fichier CLAUDE.md est la partie de votre prompt qui persiste. Claude le lit au début de chaque conversation, donc c'est là que vit le contexte permanent de votre projet : les commandes de build qu'il ne peut pas deviner, vos règles de style de code, l'étiquette du dépôt, les particularités de l'environnement de développement, les pièges. Le centre d'aide l'appelle « le briefing que vous donneriez à un nouveau coéquipier capable lors de son premier matin. »

Lancez /init pour générer un point de départ depuis votre projet, puis gardez-le léger. L'avertissement d'Anthropic est catégorique : « Les fichiers CLAUDE.md gonflés font que Claude ignore vos instructions réelles. » Pour chaque ligne, demandez « supprimer ceci ferait-il commettre une erreur à Claude ? » Si non, supprimez-la. Ajoutez une règle quand Claude se trompe deux fois, élaguez trimestriellement et committez le fichier pour que toute l'équipe contribue. L'histoire complète de la configuration, y compris où vit le fichier et comment il se fusionne entre répertoires, se trouve dans notre guide de configuration Claude Code et la référence settings.json. Pour les workflows répétables, la même logique s'étend aux commandes slash.

Les habitudes de prompting qui gaspillent silencieusement vos tokens

La plupart des sessions gaspillées viennent d'une poignée d'erreurs répétables. Anthropic en nomme cinq, et la solution pour chacune est une habitude de prompting :

Le méta-point sur lequel Anthropic conclut mérite d'être retenu : ce sont des points de départ, pas des lois. Parfois vous devriez laisser le contexte s'accumuler (quand vous êtes profondément dans un problème difficile), ignorer le plan (travail exploratoire), ou lancer un prompt vague (pour voir comment il interprète avant de contraindre). Observez ce qui se passe quand la sortie est excellente, et demandez pourquoi quand ça coince. C'est ainsi que vous construisez l'intuition qu'aucune liste de contrôle ne peut remplacer. Si vous cherchez un ensemble sélectionné, notre récapitulatif des meilleures pratiques Claude Code rassemble celles qui ont survécu au contact avec de vrais projets.

Ce que cela a à voir avec l'IA qui répond aux tickets de support

Voici ce que je n'attendais pas quand j'ai commencé à utiliser Claude Code : la discipline de prompting est la même discipline que nous utilisons pour mettre l'IA sur une file d'attente de support en direct. Donnez à l'agent le bon contexte. Délimitez ce qu'il est autorisé à toucher. Faites-le vérifier avant d'agir. Corrigez rapidement et capturez la leçon.

J'ai appris cet ordre à la dure. Au début, nous avons vu des bots qui semblaient confiants donner silencieusement de mauvaises réponses aux clients, c'est pourquoi nous simulons maintenant chaque déploiement contre les tickets historiques d'une entreprise avant qu'une seule réponse en direct ne parte. C'est le mode plan pour le support : lire le monde, proposer comment vous allez le gérer, obtenir l'approbation, puis agir. Quand Gridwise l'a mis en place, l'agent a résolu 73% de leurs demandes de niveau 1 le premier mois, et les résultats sont apparus lors d'un essai de 7 jours. Le chiffre venait de la configuration, pas d'un modèle plus intelligent.

Si vous écrivez du contenu de la même façon, le parallèle s'applique aussi à la rédaction IA : le rédacteur de blog eesel AI est, sous le capot, un agent que vous briefez et vérifiez plutôt qu'une boîte de chat avec laquelle vous vous battez.

Essayez eesel

eesel AI met cette même discipline agentique au travail sur votre helpdesk. Vous connectez vos outils existants (Zendesk, Freshdesk, HubSpot, Gorgias, Slack et 100+ autres), et l'agent apprend de vos tickets passés et de vos documents d'aide dès le premier jour. La partie qui correspond directement à tout ce qui précède : vous le configurez en langage simple et l'exécutez en simulation contre des milliers de vos vrais tickets passés avant qu'il ne réponde à un client, pour que vous voyez exactement ce qu'il aurait dit et où il aurait escaladé.

C'est la même leçon que l'utilisation de prompts avec Claude Code, pointée vers votre file d'attente de support : l'agent est aussi bon que le contexte et les garde-fous que vous lui donnez. Vous pouvez Essayer eesel gratuitement, sans carte de crédit, et le voir s'exécuter contre votre propre historique avant de lui confier un client.