Templates de prompts qui livrent du code

Un prompt jetable te donne du code jetable. Un prompt précis te donne quelque chose que tu peux vraiment merger. L'écart entre les deux, c'est presque toujours la spécificité. Les instructions floues produisent des résultats flous.

Les dix recettes ci-dessous intègrent les détails dont Claude Code a besoin pour produire du travail que tu pourrais passer en review. Chacune est livrée avec le prompt, la raison pour laquelle il tient, quelques substitutions pour d'autres stacks, et les modes d'échec qui touchent les gens qui utilisent quelque chose de similaire sans structure.

Scaffolding de projet

App Web Full-Stack

claude "Create a React app with TypeScript and Tailwind CSS. It's a todo app with localStorage persistence. Include: add, edit, delete, mark complete, and filter by status (all/active/completed). Use a single TodoContext for state management. Make it mobile-responsive with min-width 320px support."

Pourquoi ça marche : La stack tech, le choix de stockage, chaque verbe CRUD, le modèle d'état et la taille d'écran minimale supportée sont tous écrits. Claude arrête de deviner, donc rien ne revient que tu devras arracher plus tard.

Substitutions :

• Next.js : remplace "React app" par "Next.js 15 app using App Router and Server Components where possible"
• Vue : remplace la stack React/TypeScript par "Vue 3 with Composition API and TypeScript"
• Starter plus riche : ajoute "Include dark mode toggle, keyboard shortcuts (Ctrl+N for new, Delete to remove), and export/import as JSON"

Où ça rate : Un simple "create a todo app" pousse Claude à choisir ce qui lui semble juste, ce qui correspond rarement à ton repo. "Make it look good" est pire que de nommer Tailwind, parce que le goût n'est pas une spec.

Ce que tu récupères : trois à cinq fichiers. Une arborescence de composants React, un context provider, des interfaces TypeScript pour le modèle todo, et un layout Tailwind qui s'adapte. npm run dev le lance du premier coup.

Backend API avec Auth

claude "Build an Express.js REST API with JWT authentication. Include: user registration (POST /auth/register), login (POST /auth/login), and a protected endpoint (GET /auth/me). Hash passwords with bcrypt (12 rounds). Use middleware for token verification. Add Zod validation for request bodies. Return consistent JSON error responses with status codes. Include a health check endpoint at GET /health."

Pourquoi ça marche : Écrire les routes empêche Claude d'en inventer. Nommer le nombre de rounds bcrypt, la bibliothèque de validation et la forme des erreurs signifie que la sortie ressemble déjà à du code de ton projet. Pas de passe de nettoyage.

Substitutions :

• Fastify : remplace "Express.js" par "Fastify with @fastify/jwt plugin"
• Prisma : ajoute "Use Prisma with PostgreSQL. Include a User model with id, email, passwordHash, createdAt fields"
• Sessions : échange "JWT authentication" contre "express-session with Redis store for session management"

Où ça rate : Saute la ligne de gestion d'erreurs et Claude n'écrit que le happy path. L'inscription et la connexion fonctionnent avec des inputs propres, et explosent sur tout ce qui est malformé.

Base de données et couche de données

Génération de schéma

claude "Create a PostgreSQL schema for a multi-tenant SaaS app. Tables needed: organizations, users (belongs to organization), projects (belongs to organization), and tasks (belongs to project, assigned to user). Include: UUID primary keys, created_at/updated_at timestamps on all tables, proper foreign keys with ON DELETE CASCADE, a unique constraint on user email per organization, and indexes on all foreign key columns. Add 5 sample INSERT statements per table for testing."

Pourquoi ça marche : Le mot "multi-tenant" porte le pattern d'isolation. Mentionner les clés UUID, les timestamps, les règles cascade et la portée de la contrainte d'email unique élimine les commentaires de review les plus courants. Demander des lignes d'exemple force le schéma à se charger sans erreurs.

Substitutions :

• MySQL : remplace "PostgreSQL" par "MySQL 8.0 using InnoDB engine"
• Migrations Prisma : ajoute "Format as Prisma schema instead of raw SQL, and generate the initial migration"
• Log d'audit : ajoute "Include an events table with a JSONB payload column, indexed with GIN, for audit logging"

Tests

Setup de tests complet

claude "Set up Vitest with React Testing Library for this TypeScript React project. Create: a test for the Button component that checks rendering, click handling, disabled state, and loading state. An integration test for the LoginForm that mocks the auth API call, fills the form, submits, and verifies redirect on success and error message on failure. Add a test utility file with a renderWithProviders function that wraps components in the app's context providers. Add test and test:coverage scripts to package.json."

Pourquoi ça marche : Les prompts de tests s'effondrent quand ils ressemblent à "write tests for this component." Ici, tu obtiens quatre cas nommés pour le test unitaire et deux flows end-to-end pour le test d'intégration. Le fichier helper partagé est la pièce que la plupart des gens sautent, et c'est la pièce qui garde les futurs tests cohérents.

Substitutions :

• Playwright E2E : remplace le framework par "Set up Playwright for end-to-end testing. Include a test that navigates to the login page, fills credentials, submits, and verifies the dashboard loads"
• Tests API : "Set up Supertest with Vitest for the Express API. Test the /auth/register endpoint with valid data, duplicate email, and missing required fields"

Ce que tu récupères : un fichier de config, deux ou trois fichiers de tests qui passent, un fichier d'utilitaires partagés, et de nouveaux scripts package.json. npm test passe au vert tout de suite.

Refactoring

Décomposition de composant

claude "This UserDashboard component is 400 lines long. Refactor it by: extracting the stats cards into a StatsGrid component, the activity feed into an ActivityFeed component, and the sidebar navigation into a DashboardNav component. Keep the data fetching in UserDashboard and pass data down as props. Create TypeScript interfaces for all props. Preserve all existing functionality and don't change any CSS class names."

Pourquoi ça marche : Les prompts de refactor ont besoin de garde-fous. "Refactor this component" laisse Claude déplacer ce qu'il veut, et le comportement change silencieusement. Préciser quels enfants extraire, où le fetching reste, et quelles classes CSS restent fixes signifie que le nouveau code s'insère dans ton app sans casser l'UI ni les tests.

Substitutions :

• Custom hook : "Extract the data fetching logic into a useUserDashboard custom hook. Return the loading state, error state, and all data objects. Keep the component purely presentational"
• Migration Zustand : "Move the local useState calls into a Zustand store. Export typed selectors for each piece of state. Keep the component renders identical"

Debugging

Chasse aux bugs structurée

claude "Users report that the checkout form submits twice on slow connections. Investigate: check the form's onSubmit handler for missing event.preventDefault() or missing disabled state during submission. Check if the submit button lacks a loading/disabled state. Check for React StrictMode double-render issues. Check if the API call has retry logic that could cause duplicates. Propose a fix and add an idempotency safeguard."

Pourquoi ça marche : La plupart des prompts de debugging lisent "fix this bug." Ça demande à Claude de deviner, fouiller et patcher en une fois, et généralement il se fixe sur la première histoire plausible. Cette version donne les quatre causes profondes les plus probables d'un double submit et demande à Claude de les parcourir dans l'ordre.

Substitutions :

• Page lente : "The dashboard takes 8 seconds to load. Investigate: check for N+1 queries in the API, unnecessary re-renders in React components, unoptimized images, and missing database indexes. Measure the time each fix saves"
• Déconnexion auth : "Users are getting logged out randomly. Check: JWT expiration handling, refresh token rotation, cookie settings (SameSite, Secure, HttpOnly), and whether concurrent requests race on token refresh"

Code Review et qualité

Review pre-PR

claude "Review the changes in this branch for a PR. Check for: security issues (SQL injection, XSS, exposed secrets), missing error handling on async operations, TypeScript type safety (no 'any' types, proper null checks), accessibility on any new UI components (ARIA labels, keyboard navigation), and performance concerns (unnecessary re-renders, missing useMemo/useCallback). Format findings as a list with severity (critical/warning/info) and file location."

Pourquoi ça marche : "Review this code" donne des notes superficielles. Préciser les cinq axes de review et la forme de sortie produit un rapport que tu peux parcourir et actionner tout de suite.

Substitutions :

• Backend seulement : remplace accessibilité et re-renders par "N+1 queries, missing rate limiting, and improper error propagation"
• Passe sécurité : "Focus exclusively on security: check all user inputs, authentication boundaries, authorization checks, sensitive data handling, and dependency vulnerabilities"

Développement de features

Build de tranche verticale

claude "Add a comment system to blog posts. Requirements: comments stored in a PostgreSQL comments table with id, post_id, author_name, content, created_at. API endpoints: GET /posts/:id/comments and POST /posts/:id/comments with Zod validation. React component showing threaded comments with a reply form. Optimistic UI update on new comment submission. Rate limit to 5 comments per minute per IP. Include the database migration."

Pourquoi ça marche : Le prompt couvre toute la tranche. Table, API et UI en une seule requête. Nommer le rendu optimiste, la rate limit et le fichier de migration signifie que Claude écrit la feature comme une unité finie, et non trois fragments vaguement liés qui exposent des lacunes au moment des tests.

Substitutions :

• Temps réel : "Add WebSocket support so new comments appear for all viewers without refreshing"
• Modération : "Include an isApproved boolean field and an admin endpoint to approve/reject comments"

Infrastructure et DevOps

Pipeline CI/CD

claude "Create a GitHub Actions workflow for this TypeScript monorepo. On push to main: run TypeScript type checking, run Vitest tests, build the Next.js app, and deploy to Vercel. On pull request: run type checking and tests only, post a preview deployment link as a PR comment. Cache node_modules between runs using pnpm lockfile hash. Fail fast if any step errors."

Pourquoi ça marche : Les prompts de pipeline ont besoin de règles de branches écrites en amont. En séparant ce qui tourne sur main de ce qui tourne sur les PRs, en nommant la clé de cache et en précisant le comportement preview, le workflow arrive correctement au premier push. Pas trois rounds de "ah, ajoute aussi ça."

Substitutions :

• Docker : "Build and push a Docker image to GitHub Container Registry on main, tagged with the git SHA and 'latest'"
• Migrations : "Add a step that runs Prisma migrations against the staging database before deployment, with a rollback step if deployment fails"

Configuration et environnement

Audit de config

claude "Audit this project's configuration. Check: tsconfig.json has strict mode enabled and proper path aliases. ESLint config catches unused imports, consistent formatting, and React hook dependency warnings. Package.json has correct scripts for dev, build, test, and lint. Environment variables are validated at startup (not just process.env access scattered through code). Flag any configuration that could cause silent failures in production."

Pourquoi ça marche : Les bugs de config sont les pires. Ils échouent silencieusement ou seulement le mardi. Ce prompt pointe Claude vers les quatre surfaces qui comptent et demande directement les modes d'échec en production.

Principes d'utilisation

Les dix recettes tiennent pour trois raisons qui méritent d'être retenues.

Livre la forme, pas seulement l'objectif. "Create an API" est un objectif. "Create Express endpoints at these routes with Zod validation and consistent error responses" est une forme. Claude travaille à partir de la forme et construit pour correspondre.

Nomme les contraintes en amont. Toute contrainte que tu laisses sans dire devient un pile ou face. Stack, gestion d'erreurs, styling, support navigateur, moteur de base de données. Si c'est important, écris-le. Sinon, Claude choisit ce qui lui semble bien.

Note les requirements ennuyeux. Rate limiting. Idempotence. États de chargement. Error boundaries. Labels accessibles. Ce sont les lignes qui séparent une démo du vrai code, et ce sont celles que la plupart des prompts laissent de côté. Dépenser quelques mots supplémentaires dessus te fait économiser des heures de rework plus tard.

Construis ta propre bibliothèque

Les dix recettes couvrent les patterns qui apparaissent sur presque chaque projet. Ton codebase a sa propre forme et ses propres zones délicates. Le gain vient de la création d'une bibliothèque de templates à toi. Quand un run Claude Code produit quelque chose de propre, sauvegarde le prompt. Quand ce n'est pas le cas, identifie quelle partie de la spec manquait et ajoute-la.