Ce chapitre t'apprend l'art du prompt, comment formuler tes demandes pour obtenir exactement ce que tu veux du premier coup. C'est 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 comment 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 : "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 quand tu cliques ? Rien du tout ? Une erreur ? Le mauvais comportement ?
Précis : "Sur la page /app/strategie, quand je clique sur le bouton 'Générer ma stratégie', rien ne se passe. Je m'attends à 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 si tu étais 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 mais j'aimerais ajouter une validation en temps réel sur le champ email - qu'il vérifie le format pendant la saisie, pas seulement à la soumission. Et désactive 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 très puissants de Claude :
| Formulation | Ce que ça déclenche |
|---|---|
| "Brainstorme..." | Claude explore 3-4 approches avec avantages/inconvénients avant de coder quoi que ce soit |
| "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 complexes |
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. C'est 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 affiche 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". C'est 10x plus rapide que de décrire le problème en texte.
L'astuce qui change tout : le contexte business
Claude est drastiquement meilleur quand il comprend le pourquoi métier, pas juste le quoi technique. C'est ta valeur ajoutée unique, toi tu connais tes utilisateurs.
Avec contexte business :
"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 émoji 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 adopter ? 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 :
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 : affiche "12 / illimité" pour les Pro, "2 / 2" pour les Free avec la barre en rouge quand c'est plein. Quand un utilisateur Free atteint sa limite, affiche 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.