Ce chapitre t'apprend l'art du prompt, comment formuler tes demandes pour obtenir ce que tu veux du premier coup. La compétence qui fait toute la différence. Temps de lecture : 10 minutes.
La règle d'or
Sois précis sur le QUOI et le POURQUOI. Laisse Claude gérer le COMMENT.
Tu n'as pas besoin de savoir coder pour donner une bonne instruction. Tu as besoin de savoir ce que tu veux et pourquoi tu le veux. Claude s'occupe de la traduction technique.
Les 5 types de prompts
1. Créer quelque chose de nouveau
Tu veux une nouvelle page, un composant, une fonctionnalité.
Vague : "Fais-moi une page de login."
Claude va faire des choix aléatoires : quel design, quels champs, quelle redirection après connexion, quel message d'erreur ?
Précis, copiable tel quel :
"Crée une page de connexion avec email et mot de passe. Utilise Supabase Auth. Après connexion réussie, redirige vers /app. Si l'email n'existe pas, affiche 'Aucun compte trouvé avec cet email' en rouge sous le champ. Si le mot de passe est incorrect, affiche 'Mot de passe incorrect'. Respecte la palette du projet."
Résultat exact au premier essai.
Ce qui fait la différence : les critères d'acceptation. Plutôt que "fais une page", décris ce qui doit se passer quand ça marche ET quand ça ne marche pas.
2. Corriger un problème
Quelque chose ne fonctionne pas. Décris ce que tu observes vs ce que tu attendais.
Vague : "Le bouton ne marche pas."
Quel bouton ? Sur quelle page ? Qu'est-ce qui se passe au clic ? Rien ? Une erreur ? Un mauvais comportement ?
Précis, copiable tel quel :
"Sur la page /app/strategie, quand je clique sur le bouton 'Générer ma stratégie', rien ne se passe. J'attends de voir un chargement puis la stratégie générée s'afficher en dessous. Le bouton reste cliquable, pas de spinner, pas d'erreur dans la console."
3. Comprendre le code existant
Tu veux comprendre comment quelque chose fonctionne avant de le modifier.
"Explique-moi comment fonctionne le système de scoring de marque. Montre-moi les fichiers impliqués et le flux de données depuis le calcul jusqu'à l'affichage."
"Détaille le parcours d'un utilisateur de l'inscription à sa première génération de contenu. Quels fichiers sont traversés ?"
Claude va naviguer dans le code et t'expliquer comme à un collègue curieux, pas à un développeur.
4. Itérer sur un résultat
Le premier jet est rarement parfait. 2-3 itérations = résultat excellent.
"Le formulaire marche bien. J'aimerais ajouter une validation en temps réel sur le champ email, qu'il vérifie le format pendant la saisie et pas seulement à la soumission. Désactive aussi le bouton tant que le formulaire n'est pas valide."
"La page est fonctionnelle mais le design est trop basique. Ajoute des ombres légères sur les cards, un espacement plus aéré entre les sections, et une animation subtile quand les données se chargent."
5. Explorer des options
Avant de construire, explore les possibilités.
"Quelles sont mes options pour ajouter un système de notifications dans l'app ? Compare email, push, in-app, et webhook. Donne les avantages et inconvénients de chacun pour un SaaS B2B avec 100-500 utilisateurs."
Claude va comparer les approches avec des critères concrets : coût, complexité, UX, maintenance.
Les formulations magiques
Certaines formulations débloquent des comportements puissants :
| Formulation | Ce que ça déclenche |
|---|---|
| "Brainstorme..." | Claude explore 3-4 approches avec avantages et inconvénients avant d'écrire du code |
| "Planifie l'implémentation de..." | Claude produit un plan numéroté tâche par tâche avec les fichiers concernés |
| "Exécute le plan dans..." | Claude lit le plan et l'exécute séquentiellement avec vérifications entre chaque étape |
| "Vérifie que tout compile et passe les tests" | Claude lance typecheck + lint + tests et corrige les erreurs en boucle |
| "Mets à jour la mémoire projet" | Claude sauvegarde les décisions prises pour les prochaines sessions |
| "Fais-le en parallèle" | Claude lance plusieurs tâches indépendantes en simultané (plus rapide) |
| "ultrathink" | Force un raisonnement approfondi. Claude prend plus de temps mais produit une réflexion plus profonde. Idéal pour les problèmes d'architecture. |
Deux techniques avancées qui changent la donne
Les diagrammes ASCII
Claude comprend très bien les diagrammes en texte. Quand tu veux expliquer une architecture, un flux de données ou une relation entre modules, dessine-le en ASCII au lieu de l'écrire en phrases :
Utilisateur → Page login → Supabase Auth
↓
Cookie session
↓
Middleware vérifie auth
↓
Page /app (Server Component)
↓
Server Action + RLS auto
Claude intègre ce diagramme et produit du code cohérent avec l'architecture décrite. Souvent plus clair que 3 paragraphes d'explications.
Les screenshots
Quand tu es bloqué sur un problème visuel (bug d'affichage, erreur dans le navigateur, console qui crache une erreur), prends un screenshot et partage-le avec Claude.
Claude Code est multimodal, il peut lire les images. Un screenshot montre instantanément :
- L'erreur exacte dans la console
- Le rendu visuel du problème
- Le contexte de la page
Habitude à prendre : dès que tu vois un bug visuel, fais un screenshot et envoie-le avec "Voici ce que je vois, voici ce que j'attends". 10x plus rapide que de décrire le problème en texte.
Le contexte business, ton multiplicateur
Claude est bien meilleur quand il comprend le pourquoi métier, pas juste le quoi technique. Ta valeur ajoutée unique, toi tu connais tes utilisateurs.
Avec contexte business (prompt copiable) :
"Les freelances qui utilisent notre app oublient souvent de publier leur contenu planifié. Crée un système de rappels qui envoie un email la veille de chaque publication prévue dans le calendrier. Ton : encourageant, pas culpabilisant. Objet de l'email : prévoir un emoji et le titre du contenu."
Sans contexte :
"Ajoute des notifications de rappel."
Claude ne sait pas : quand déclencher ? Quel canal (email, push, in-app) ? Quel ton ? Quelles données inclure ?
Plus tu donnes de contexte métier, moins tu feras d'itérations. Un bon prompt avec contexte = 1 essai. Un prompt vague = 3-4 aller-retours.
La structure d'un prompt parfait
Voici le template que j'utilise pour les demandes complexes :
- Contexte : pourquoi cette feature existe (quel problème utilisateur elle résout) 2. Quoi : ce que tu veux construire (description fonctionnelle) 3. Critères : ce qui doit se passer quand ça marche ET quand ça ne marche pas 4. Contraintes : limites techniques, design, ou business à respecter
Exemple complet, copiable tel quel :
Contexte : nos utilisateurs pro paient 29€/mois et veulent savoir combien de contenus ils ont générés ce mois-ci par rapport à leur forfait.
Quoi : un composant de barre de progression dans le dashboard qui montre l'usage IA du mois en cours (nombre de générations utilisées / limite du plan).
Critères : afficher "12 / illimité" pour les Pro, "2 / 2" pour les Free avec la barre en rouge quand c'est plein. Quand un Free atteint sa limite, afficher un bouton "Passer en Pro".
Contraintes : utiliser les données de la table
ai_usageen base. Respecter la palette du projet. Composant réutilisable.
Les erreurs de communication les plus fréquentes
| Erreur | Pourquoi c'est un problème | Comment corriger |
|---|---|---|
| "Améliore la page" | Trop vague, améliorer quoi ? Le design ? La perf ? L'UX ? | "Ajoute une animation de chargement et un meilleur espacement entre les sections" |
| "Fais comme l'autre page" | Claude ne sait pas quelle page tu veux copier | "Utilise le même layout que la page /app/strategie : sidebar + contenu principal" |
| "C'est pas beau" | Subjectif et non actionnable | "Les cards sont trop tassées, ajoute 16px de gap. Le titre est trop petit, passe-le en 2xl." |
| Envoyer un screenshot sans contexte | Claude voit l'image mais ne sait pas quoi chercher ni quoi corriger | Ajoute toujours "Voici ce que je vois, voici ce que j'attends" avec le screenshot |
À retenir : un prompt précis avec contexte métier = résultat au premier essai. Un prompt vague = 3-4 aller-retours. Investis 30 secondes de plus dans ta formulation, économise 10 minutes de corrections.