Tu as demandé une page de login et Claude a choisi la moitié des règles à ta place ? Voici comment écrire la demande pour l'avoir du premier coup, et quand monter l'effort de réflexion.
La règle d'or
Sois précis sur le quoi et le pourquoi. Laisse Claude gérer le comment.
Tu peux briefer Claude sans savoir coder, à condition de savoir ce que tu veux et pourquoi. La traduction technique, c'est son boulot.
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."
Claude n'a plus rien à deviner.
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 ?
Mieux :
"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.
4. Itérer sur un résultat
Le premier jet tombe rarement juste. Compte 2 ou 3 retours pour arriver où tu veux.
"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 utiles
Quelques formulations déclenchent un comportement précis :
| 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) |
Régler l'effort de réflexion
Pour que Claude réfléchisse plus (ou moins), le réglage officiel s'appelle l'effort.
La quantité de raisonnement que le modèle s'autorise avant de répondre et à
chaque étape. Cinq niveaux : low, medium, high, xhigh, max. Plus
c'est haut, plus Claude teste de cas limites et vérifie son travail, et plus
il produit de tokens de réflexion, facturés comme du texte écrit.
/effort high
Tapé comme ça, le niveau devient ton défaut pour ce modèle, y compris dans les sessions suivantes. Sans argument, /effort ouvre un curseur : Entrée enregistre le niveau, s ne l'applique qu'à la session en cours. Tu peux aussi le fixer au lancement avec claude --effort high. Sans réglage, Opus 5.5, Sonnet 5.5 et Haiku 5.5 tournent en medium, Fable 5.1 en high.
| Niveau | Quand l'utiliser |
|---|---|
low | Renommer, corriger une faute, question rapide sur le code |
medium | Le défaut des modèles 5.5. La majorité du travail courant |
high, xhigh | Bug coriace, refacto qui touche beaucoup de fichiers, choix d'architecture |
max | Problème très dur. Vaut pour la session en cours seulement |
Moi je tourne en high sur Opus 5.5 pour le travail de fond, et je baisse quand je fais de petites retouches.
Le choix de l'effort va avec celui du modèle. La doc coûts de Claude Code donne cette grille :
L'effort coûte de l'argent. Le raisonnement est facturé comme du texte produit (l'output, le plus cher), et sur Opus 5.5, Sonnet 5.5, Haiku 5.5 et Fable tu ne peux pas le couper. Pour payer moins de réflexion, tu baisses l'effort. Bonne nouvelle : sur ces modèles (abonnement ou clé API), changer d'effort en pleine session ne casse pas le cache. Détail au chapitre 19.
Et le fameux "ultrathink" des vieux tutos ? Il marche encore, mais pour un seul message : Claude Code ajoute une consigne de réflexion plus poussée à ce tour, sans toucher à ton niveau d'effort. Les variantes comme "think hard" ou "réfléchis bien" ne déclenchent rien de spécial, Claude les lit comme du texte normal. Pour une session entière, c'est /effort.
Ne confonds pas non plus avec ultracode : lui lance un workflow, c'est-à-dire un script qui fait travailler des dizaines de sub-agents en parallèle. Rien à voir avec la profondeur de réflexion, et ça consomme beaucoup plus. C'est au chapitre 18.
Deux techniques qui font gagner du temps
Les diagrammes ASCII
Claude lit sans problème 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, pour ce qui se voit
Quand tu es bloqué sur un problème visuel (mise en page cassée, élément qui déborde, mauvaise couleur), prends un screenshot et partage-le avec Claude. Claude Code lit les images : une capture montre en une seconde le rendu et le contexte de la page.
Pour une erreur en texte (console, terminal, log de build), c'est l'inverse : copie-colle le texte. Une image coûte plus de tokens que le même message en texte, et Claude peut mal lire un bout de stack trace sur une capture. Autre effet : au-delà d'un certain volume d'images, Claude Code retire les plus anciennes de la conversation, ce qui fait recalculer sans cache tout ce qui suit.
Habitude à prendre : bug visuel → screenshot avec "Voici ce que je vois, voici ce que j'attends". Message d'erreur → copier-coller du texte complet, pas une capture.
Donne le contexte business
Claude fait de meilleurs choix quand il sait à quoi sert la feature. Là, ta connaissance métier fait la différence : tu connais tes utilisateurs, lui ne les a jamais vus.
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 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 ?
Avec le contexte métier, un essai suffit souvent. Sans, compte 3 ou 4 allers-retours.
La structure que j'utilise
Pour les demandes complexes, je découpe en quatre blocs :
- Contexte : pourquoi cette feature existe (quel problème utilisateur elle résout)
- Quoi : ce que tu veux construire (description fonctionnelle)
- Critères : ce qui doit se passer quand ça marche, et quand ça ne marche pas
- 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 : 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, Claude ne sait pas quoi changer | "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 |
Question
Tu es sur Opus 5.5 avec ton abonnement, en medium. En plein milieu d'une grosse session, tu passes en high avec /effort high. Que devient le cache ?
Choisis une réponse pour voir l'explication.
À retenir
- Donne le pourquoi métier et les critères d'acceptation : ce qui se passe quand ça marche, et quand ça casse.
/effort highpour un bug coriace ou un choix d'architecture.ultrathinkne vaut que pour un message.- Bug visuel : screenshot. Message d'erreur : copier-coller du texte.