Prompt engineering pour développeurs : tirer le maximum de Claude Code
Claude Code peut générer du code impressionnant, mais aussi te faire perdre des heures si tu ne sais pas le briefer. Voici comment structurer tes prompts pour obtenir du code propre, documenté et prêt à déployer.
Le problème que tu connais trop bien
Tu demandes à Claude de générer une fonction. Il te pond 200 lignes de code. Ça a l'air propre, bien indenté, avec des commentaires. Tu testes. Ça plante. Tu redemandes une correction. Nouvelle version. Nouveau bug. Après 45 minutes d'aller-retour, tu aurais codé la fonction toi-même en 20 minutes.
Le souci n'est pas Claude. C'est ton prompt.
Claude Code (via Claude 3.5 Sonnet ou Opus) est l'un des meilleurs modèles pour la génération de code. Mais comme tout outil puissant, il a besoin d'instructions précises. Un prompt flou = du code générique qui rate à côté.
Voici comment briefer Claude comme un senior dev brief un junior.
La structure de prompt qui change tout
Les meilleurs prompts de code suivent cette structure en 5 parties :
1. Contexte technique
Ne fais pas deviner à Claude ton stack. Sois explicite :
Projet : API REST Node.js avec Express et TypeScript
Version Node : 18.x
Base de données : PostgreSQL avec Prisma ORM
Authentification : JWT via middleware custom
2. Objectif fonctionnel clair
Pas "crée une fonction de paiement". Plutôt :
Crée un endpoint POST /api/payments qui :
- Accepte un montant et un payment_method_id Stripe
- Valide que l'utilisateur est authentifié
- Crée une PaymentIntent Stripe
- Enregistre la transaction en BDD avec statut "pending"
- Retourne l'objet payment avec client_secret
3. Contraintes et standards
C'est là que 90% des devs oublient de préciser :
Contraintes :
- Utiliser async/await (pas de .then())
- Gestion d'erreur avec try/catch et codes HTTP appropriés
- Validation des inputs avec Zod
- Logging avec Winston sur toutes les erreurs
- Tests unitaires avec Jest
4. Format de sortie attendu
Sois précis :
Fournis :
1. Le code du controller
2. Le schéma Zod de validation
3. Les types TypeScript
4. 3 tests unitaires (succès, montant invalide, utilisateur non auth)
5. Un exemple de requête curl
5. Exemple concret (optionnel mais puissant)
Montre un exemple de ce que tu veux :
Exemple de réponse attendue :
{
"success": true,
"payment": {
"id": "pay_123",
"amount": 2999,
"status": "pending",
"client_secret": "pi_xxx_secret_yyy"
}
}
Exemple de prompt complet
Voici un vrai prompt qui génère du code utilisable directement :
Contexte :
- API Express + TypeScript
- Auth JWT via middleware requireAuth
- Stripe SDK v12
- Prisma ORM
Tâche :
Crée un endpoint POST /api/subscriptions/cancel qui permet à un utilisateur authentifié d'annuler son abonnement Stripe.
Logique métier :
1. Récupérer le subscription_id depuis req.user (injecté par le middleware)
2. Annuler l'abonnement via Stripe API (cancel_at_period_end: true)
3. Mettre à jour le statut en BDD (table subscriptions, champ status = 'canceling')
4. Retourner la date de fin d'accès
Contraintes :
- Validation : vérifier que l'abonnement appartient bien à l'utilisateur
- Gestion d'erreur : gérer le cas où Stripe est down
- Logger toutes les erreurs avec Winston
- Code testé avec Jest (au moins 2 tests)
Format de sortie :
1. Controller TypeScript
2. Types nécessaires
3. Tests Jest
4. Exemple de réponse JSON
Ne génère pas les fichiers de config (Stripe, Prisma), suppose qu'ils existent.
Les patterns qui font gagner du temps
Pattern 1 : Demande des morceaux, pas tout d'un coup
Plutôt que "crée une app complète", décompose :
Étape 1 : Crée juste le schéma Prisma pour User et Subscription
Étape 2 : Crée le service d'auth (login/register)
Étape 3 : Crée les endpoints CRUD pour subscriptions
Claude est meilleur sur des tâches ciblées.
Pattern 2 : Demande d'expliquer avant de coder
Pour de la logique complexe :
Avant de coder, explique-moi en 5 étapes comment tu implémenterais un système de rate limiting avec Redis pour cette API. Une fois validé, tu coderas.
Ça évite de partir dans la mauvaise direction.
Pattern 3 : Spécifie le niveau de commentaires
Commentaires :
- Aucun commentaire évident (type "// Boucle sur les items")
- Commente uniquement la logique métier non-évidente
- Docstring JSDoc sur les fonctions publiques uniquement
Par défaut, Claude sur-commente. Guide-le.
Les erreurs qui te font perdre du temps
Erreur 1 : Prompt trop vague
❌ "Crée une fonction de recherche" ✅ "Crée une fonction searchUsers qui prend un string query, cherche dans les champs name et email via Prisma, retourne max 20 résultats, avec pagination"
Erreur 2 : Oublier les dépendances
❌ "Utilise Redis" ✅ "Utilise ioredis v5, connection déjà configurée dans lib/redis.ts, utilise les méthodes async/await"
Erreur 3 : Ne pas demander de tests
Si tu ne demandes pas explicitement, Claude ne les génère pas. Résultat : tu dois les écrire toi-même après.
Erreur 4 : Accepter du code sans gestion d'erreur
Force toujours :
Toute fonction async doit avoir un try/catch
Toute erreur doit être loggée
Retourner des codes HTTP appropriés (400, 401, 404, 500)
Comment KayaPrompt t'aide à industrialiser ça
Si tu te retrouves à copier-coller le même contexte technique dans chaque prompt (ton stack, tes contraintes, tes standards de code), c'est exactement le problème que KayaPrompt résout.
Tu crées un template de prompt avec tes variables :
Contexte : {{stack_technique}}
Tâche : {{description_fonctionnalite}}
Contraintes : {{standards_code}}
Tests : {{type_tests}}
Ensuite, tu ne remplis que les variables spécifiques à chaque nouvelle feature. Le reste (ton stack, tes conventions, tes exigences de qualité) est déjà là.
C'est comme avoir un senior dev qui connaît déjà ta codebase et tes standards.
Ta checklist avant d'envoyer un prompt de code
Avant de presser Entrée :
- J'ai précisé le langage ET la version
- J'ai listé les librairies utilisées
- J'ai décrit le comportement attendu en 3-5 points
- J'ai spécifié la gestion d'erreur attendue
- J'ai demandé des tests (ou pas, selon le cas)
- J'ai indiqué le format de sortie exact
- J'ai donné un exemple de résultat si c'est complexe
Si tu coches ces 7 cases, ton prompt va générer du code 10x plus utilisable.
Pour aller plus loin
Claude Code n'est pas magique. C'est un collaborateur très compétent mais qui a besoin d'instructions claires. Traite-le comme tu brieferais un dev qui rejoint ton équipe : contexte, objectif, contraintes, exemples.
La différence entre un dev qui perd son temps avec l'IA et un dev qui 10x sa productivité ? La qualité des prompts.
Si tu veux tester tes prompts de code et les améliorer avec des templates réutilisables, jette un œil à KayaPrompt. C'est fait exactement pour ça : structurer, tester et réutiliser tes meilleurs prompts.
Maintenant, va coder. Mais cette fois, avec des prompts qui marchent.