Les prompts Claude Code d'Anthropic : lesquels valent le coup ?

On ouvre Claude Code dans un projet, le curseur clignote, et on tape « peux-tu regarder ce bug ». Claude regarde. Il propose quelque chose. Il s'arrête. On relance, on précise, on relance encore. Le problème n'est pas le modèle, c'est la phrase.

Anthropic a publié une bibliothèque de prompts pour Claude Code : une cinquantaine de phrases à copier-coller, classées par étape du cycle de développement, de la découverte d'un dépôt jusqu'à l'incident de production. Elles viennent de la documentation officielle, du guide des bonnes pratiques et de la façon dont les équipes d'Anthropic utilisent l'outil en interne. Chaque carte a un volet « Pourquoi cela fonctionne » qui explique le principe derrière la phrase.

Ce qui frappe, c'est leur longueur. Une ligne, deux au maximum. Pas de « tu es un développeur senior », pas de liste de quinze règles. J'ai tout lu, gardé ce qui sert vraiment quand on code, et laissé le reste.

Six principes, et un seul qui compte vraiment

Anthropic résume ce qui rend ses prompts efficaces en six idées, tirées de son guide des bonnes pratiques Claude Code. Une fois qu'on les a en tête, la bibliothèque devient presque inutile : on écrit les siens.

Le deuxième écrase les autres. Un prompt sans vérification s'arrête après une tentative. Un prompt avec vérification lance une boucle : Claude écrit, exécute, lit l'erreur, corrige, recommence. C'est la différence entre un assistant qui propose et un agent qui livre.

Dans la bibliothèque, les prompts ont des trous entre accolades, comme {path} ou {feature}. Ci-dessous, je les ai remplis avec les valeurs d'exemple d'Anthropic. Remplacez-les par les vôtres.

Avant d'écrire une ligne

Le premier prompt que je tape dans un dépôt inconnu :

donnez-moi un aperçu de cette base de code : architecture, répertoires clés et façon dont les éléments sont reliés

Aucun chemin de fichier, et c'est voulu. Claude explore seul. Lancez /init juste après pour que cette compréhension atterrisse dans un CLAUDE.md au lieu de mourir avec la session.

Mon préféré de toute la liste tient en une question :

qu'est-ce qui casserait si je supprimais le helper retryWithBackoff ?

La réponse liste les appelants et les effets en aval. En trente secondes, on sait si c'est un nettoyage d'une ligne ou un chantier à coordonner.

Quand une implémentation paraît absurde, la réponse est souvent dans l'historique :

parcourez l'historique des commits de internal/auth/session.go et résumez comment il a évolué et pourquoi

Le code dit « quoi », les commits disent « pourquoi ». C'est le git log et le git blame que personne n'a le courage de lire en entier. Pour fouiller l'historique soi-même, les commandes sont dans le guide Git avancé : rebase, cherry-pick et bisect.

Planifier sans toucher au code

planifiez comment refactoriser le module de paiement pour prendre en charge plusieurs devises. listez les fichiers que vous modifieriez, mais ne modifiez rien pour l'instant

Tout tient dans « ne modifiez rien pour l'instant ». La phrase sépare l'exploration de l'exécution : on voit l'approche, on la corrige, puis on lance. Si vous le faites souvent, Shift+Tab active le mode plan et rend ce comportement automatique.

Pour une fonctionnalité qui dépasse une après-midi, j'inverse les rôles :

je veux développer des limites de débit par espace de travail. interrogez-moi sur l'implémentation, l'UX, les cas limites et les compromis jusqu'à ce que nous ayons tout couvert, puis écrivez la spécification dans SPEC.md

C'est Claude qui pose les questions. Et ce sont exactement celles que j'aurais découvertes en plein milieu de l'implémentation, au pire moment.

Implémenter et tester

examinez comment le gestionnaire de webhook existant est implémenté pour comprendre le modèle, puis développez un gestionnaire de webhook de paiements de la même manière

Sans référence, Claude applique les bonnes pratiques génériques d'Internet. Avec une référence, il applique les vôtres. C'est ce qui sépare un code qui marche d'un code qui ressemble au reste du projet.

Côté front, celui-ci ferme la boucle tout seul :

implémentez ce design, puis faites une capture d'écran du résultat, comparez-la à l'original et corrigez toutes les différences

On colle la maquette, on envoie. Il faut que Claude puisse faire des captures, via l'extension Chrome ou Playwright branché en serveur MCP. Sans ça, la boucle ne se referme pas.

Pour les tests, la bibliothèque a deux variantes que j'utilise toutes les deux :

écrivez des tests pour app/parsers/feed.py, exécutez-les et corrigez les éventuels échecs

écrivez d'abord des tests pour le flux de réinitialisation du mot de passe, puis implémentez-le jusqu'à ce qu'ils réussissent

La première tient en trois verbes. Écrivez seulement « écrivez des tests » et Claude s'arrête après l'écriture. La seconde, c'est du TDD en une phrase : les tests deviennent la définition de « terminé », et Claude ne peut pas déclarer victoire tant qu'ils sont rouges.

Même logique pour la performance :

optimisez la requête de recherche pour faire passer la latence p95 de 2s à moins de 500ms

« Rends ça plus rapide » n'a pas de fin. « Sous 500 ms » en a une.

Relire avant le commit

relisez mes modifications non commitées et signalez tout ce qui semble risqué avant que je crée le commit

Claude lit les fichiers modifiés en entier, pas seulement les lignes du diff. Il attrape la variable renommée à moitié, le console.log oublié, l'erreur qui ne remonte plus. /code-review fait la même chose en une commande.

utilisez un sous-agent pour analyser src/api/ à la recherche de problèmes de sécurité et rapportez ce qu'il trouve

L'audit tourne dans sa propre fenêtre de contexte. La session principale reçoit un résumé au lieu de se remplir de centaines de lignes lues. Le mot « sous-agent » suffit, aucune configuration n'est nécessaire.

Quand Claude se trompe

C'est la partie qu'on oublie, et celle qui change le plus le quotidien. Claude se trompe. Ce qui compte, c'est comment on le lui dit.

ce n'est pas correct : la signature de la fonction doit rester rétrocompatible. essayez une autre approche

« C'est faux » pousse Claude à deviner autre chose. « C'est faux parce que… » lui donne une contrainte. Si la tentative ratée a pollué le code, Esc deux fois ouvre le menu de retour en arrière et restaure fichiers et conversation.

c'est trop. conservez uniquement les modifications apportées à la logique de validation dans src/forms/ et annulez vos autres changements

Pour le jour où un correctif de trois lignes est devenu un refactoring de quinze fichiers. On garde la bonne partie au lieu de tout jeter.

vous continuez à utiliser des exports par défaut alors que ce projet utilise des exports nommés. ajoutez une règle dans CLAUDE.md pour que cela cesse

Une correction dans le chat meurt avec la session. Une règle dans CLAUDE.md est relue au début de chaque session et partagée avec l'équipe dès qu'elle est commitée. Ma règle personnelle : si je corrige la même chose deux fois, ce prompt part.

Déboguer

voici une erreur de build. corrigez la cause racine et vérifiez que le build réussit

On colle l'erreur complète en dessous. « Cause racine » interdit le // @ts-ignore qui fait taire le compilateur. « Vérifiez » oblige à relancer le build. Deux mots contre les correctifs cosmétiques.

l'endpoint de paiement a commencé à renvoyer des erreurs 500 il y a une heure. vérifiez les logs, les déploiements récents et les changements de configuration, puis dites-moi quelle est la cause la plus probable

On liste les sources à croiser, pas les étapes à suivre. Claude lit ensemble logs, historique Git et configuration.

Ne pas réécrire deux fois le même prompt

Les deux derniers prompts de ma sélection servent à ne plus avoir besoin des autres.

résumez ce que nous avons fait au cours de cette session et suggérez ce qu'il faudrait ajouter à CLAUDE.md

Je le tape avant de fermer le terminal. Claude sait ce qu'il a dû comprendre péniblement pendant deux heures, ce prompt le transforme en contexte pour la prochaine fois. C'est la version manuelle de ce que Trail-code automatise avec une mémoire partagée entre agents.

créez un skill /ship pour ce projet qui exécute le linter et les tests, puis rédige un message de commit

Un prompt qui marche et qu'on tape souvent devient une commande. Pour ce qui doit se déclencher sans qu'on le demande, comme un formatage après chaque modification, ce sont les hooks de Claude Code qui prennent le relais.

Ce que j'ai laissé de côté

La bibliothèque vise aussi les PM, les designers, le marketing et le juridique : transformer une réunion en tickets, générer des variantes de publicités à partir d'un CSV, relire un post avant l'équipe juridique. Ils sont bien faits, mais pas pour moi. J'en sauve deux pour les développeurs : « transformer une maquette en prototype cliquable », utile pour montrer une idée sans lancer de projet, et « analyser un fichier de données », pratique pour un export CSV qui ne mérite pas de script.

Ces prompts sont courts parce que le travail lourd se fait ailleurs : dans le CLAUDE.md qui donne le contexte, dans les skills qui figent ce qui marche, dans les hooks qui automatisent le reste. Le meilleur usage de la bibliothèque n'est pas de la copier, c'est d'en retenir le réflexe : chaque prompt dit à Claude comment savoir qu'il a fini. Prenez-en trois, utilisez-les une semaine, et transformez celui que vous tapez le plus souvent en skill.