Diriger Claude : l’art du prompt
Écrire des consignes claires qui produisent du bon code, du premier coup.
Ce que vous allez apprendre
- Structurer un prompt : objectif, contexte, contraintes, critère de réussite
- Demander une fonctionnalité, une correction, une revue, une optimisation
- Empêcher l’IA de tout réécrire et éviter les régressions
Votre projet est cadré et documenté (Module 3). Il est temps d’apprendre à parler à Claude. Un bon prompt n’est pas une formule magique : c’est une consigne claire. La qualité de ce que produit l’IA est directement proportionnelle à la précision de ce que vous demandez. Ce module est un mode d’emploi concret, situation par situation.
Anatomie d’un bon prompt
Un prompt efficace contient quatre éléments, explicitement ou implicitement :
- L’objectif.
- Ce que vous voulez obtenir, précisément.
- Le contexte.
- Où cela s’insère, quels éléments existants sont concernés.
- Les contraintes.
- Ce qu’il faut respecter — et surtout ce qu’il ne faut pas toucher.
- Le critère de réussite.
- Comment vous saurez que c’est réussi.
La différence se voit immédiatement à l’usage :
| Prompt vague | Prompt précis |
|---|---|
| « Fais un formulaire de contact. » | « Crée un composant ContactForm avec les champs nom, e-mail et message. Utilise le composant Button existant et le style des autres formulaires. Valide l’e-mail côté client. N’implémente pas encore l’envoi : laisse une fonction onSubmit vide que je remplirai. » |
| « Le site est lent, optimise. » | « La page d’accueil met du temps à afficher les images. Identifie les images non optimisées et propose une solution, sans changer le design. Explique-moi ton plan avant de modifier. » |
Le prompt vague force l’IA à deviner — et elle devine souvent à côté. Le prompt précis lui donne un cadre où réussir. Principe transversal, valable partout : demandez à l’IA d’expliquer son plan avant d’agir sur les tâches importantes. Un simple « explique-moi ta démarche avant de coder » vous évite de découvrir trop tard une mauvaise direction.
Demander une nouvelle fonctionnalité
Décrivez la fonctionnalité, son point d’insertion et les éléments à réutiliser. Surtout, délimitez le périmètre : « Ajoute une section "Avis clients" après la section "Services". Réutilise le style de carte existant (Card). Crée des données d’exemple dans lib/constants.ts. Ne modifie aucune autre section. » Ce « ne modifie aucune autre section » n’est pas un détail : c’est ce qui empêche l’IA de « profiter » du passage pour réécrire ce qui fonctionnait déjà.
Demander une correction de bug
Un bon rapport de bug à l’IA contient trois choses : le comportement observé, le comportement attendu, et le contexte (message d’erreur exact, étapes pour reproduire). Le pire prompt de correction est « ça marche pas, corrige » : sans symptôme précis, l’IA modifie au hasard et introduit souvent de nouveaux bugs.
Le message d’erreur exact est l’information la plus précieuse que vous puissiez donner à l’IA. Copiez-le intégralement, ne le résumez pas.
Demander une revue de code
Claude est aussi bon relecteur que rédacteur, à condition de le lui demander explicitement : « Relis le composant AppointmentForm. Y a-t-il des problèmes de sécurité, de performance ou de lisibilité ? Signale-moi les points faibles sans encore les corriger : je veux d’abord comprendre. » Séparer la revue de la correction est une excellente habitude : vous apprenez en voyant ce que l’IA repère, et vous gardez le contrôle de ce qui est effectivement modifié.
Demander une optimisation
Précisez quoi optimiser et à quel prix, car une optimisation a presque toujours un coût (lisibilité, complexité) : « Cette page charge 40 images d’un coup. Propose une optimisation (lazy loading, format d’image) qui améliore le temps de chargement sans dégrader la qualité visuelle. Explique le compromis de chaque option. » Méfiez-vous des optimisations prématurées : n’optimisez que ce qui pose un problème réel et mesuré (Module 8).
Éviter les régressions
Une régression, c’est quand une modification casse quelque chose qui fonctionnait. C’est le fléau du vibe coding. Trois réflexes la préviennent : délimiter le périmètre dans le prompt, vérifier le diff avant d’accepter (Module 5), et tester après chaque modification, y compris ce qui n’était pas censé changer (Module 6).
Modifie uniquement la couleur du bouton principal en bleu. Ne change rien d’autre : ni la taille, ni le comportement, ni les autres boutons. Montre-moi précisément les lignes modifiées.
Empêcher Claude de tout réécrire
Frustration classique : vous demandez un petit changement, et l’IA vous rend un fichier entièrement réécrit, où vous ne reconnaissez plus rien — avec le risque qu’elle ait modifié au passage des parties qui allaient bien. Pour l’éviter :
- Formulez des demandes chirurgicales : « change seulement cette ligne », « ajoute sans réorganiser le reste ».
- Travaillez par petits pas : une modification à la fois, validée, avant la suivante.
- Inscrivez la règle dans votre CLAUDE.md : « Ne pas réécrire un fichier entier pour une petite modification ».
- Refusez et reformulez si l’IA en fait trop : « C’est trop de changements. Reprends la version précédente et ne modifie que X. »
À retenir
- Un bon prompt délimite toujours le périmètre.
- Le message d’erreur exact est l’information la plus précieuse.
- Demandez à l’IA d’expliquer son plan avant d’agir.
À vous de jouer
Réécrivez un prompt vague
- Partez d’une demande vague (« fais un formulaire de contact »).
- Réécrivez-la avec objectif, contexte, contraintes et critère de réussite.
- Ajoutez la consigne « ne modifie rien d’autre » et « montre-moi les lignes changées ».
Un projet à enjeux, ou un doute sur vos fondations ?
Cette formation vous rend autonome. Pour un audit, un cadrage ou un accompagnement sur mesure, l’équipe DJEZYS Digital peut prendre le relais.