Stack IA — Écrire des prompts qui marchent

1 · Anatomie

Les cinq briques d’un prompt solide

Tu n’as pas besoin des cinq à chaque fois. Mais quand un résultat déçoit, il manque presque toujours l’une d’elles — et c’est un bon réflexe de diagnostic.

1

Le rôle et le cadre

« Tu es un auditeur sécurité défensif », « tu agis comme un lead dev exigeant ». Ça oriente le vocabulaire, le niveau de détail et les priorités. Utile surtout quand tu veux un regard particulier, inutile pour une tâche mécanique.

2

Le contexte réel

Le fichier concerné, la stack, la contrainte métier, ce que tu as déjà essayé. C’est la brique la plus rentable : la plupart des mauvaises réponses viennent d’un contexte manquant, pas d’un modèle faible.

3

L’objectif précis

Ce que tu veux obtenir, formulé en résultat et pas en action vague. « Corrige l’auth » est une intention ; « le login échoue quand l’email contient un +, il doit passer » est un objectif.

4

Les contraintes et interdits

Ce qu’il ne doit pas faire : ne pas toucher aux autres fichiers, ne pas ajouter de dépendance, ne pas reformater. Sans ça, un agent élargit spontanément le périmètre — c’est le fameux refacto non demandé.

5

Le critère de succès

Comment on saura que c’est fini : un test qui passe, une commande qui sort sans erreur, une capture d’écran. Sans critère, l’agent s’arrête quand lui estime avoir terminé.

✗ Le prompt qui produit du flou

Trois mots, aucun cadre. L’agent invente le périmètre et tu passes la soirée à corriger.

Améliore la page de login

✓ Le prompt qui produit du code utilisable

Contexte, objectif, contrainte, critère. L’agent sait quoi faire et quand s’arrêter.

Dans src/auth/LoginForm.tsx : les erreurs de
validation ne s'affichent pas sous les champs.
Objectif : chaque champ invalide montre son
message sous l'input, en rouge.
Contraintes :
- ne touche à aucun autre fichier
- pas de nouvelle dépendance
- garde les classes Tailwind existantes
Fini quand : tu me montres une capture du
formulaire avec deux champs en erreur.

2 · Techniques

Ce qui marche vraiment

Quatre techniques valent le détour. Elles ont un point commun : elles réduisent la part de devinette laissée au modèle.

La plus rentable

Montrer un exemple

Un exemple de sortie attendue vaut trois paragraphes de description. Colle un morceau de code existant qui a le bon style, ou écris à la main le format que tu veux. Le modèle imite bien mieux qu’il n’interprète.

Pour les tâches longues

Décomposer

Demander un plan d’abord, puis l’exécution. Ou découper en trois messages plutôt qu’un seul énorme. Chaque étape devient vérifiable, et une erreur ne contamine pas tout le reste.

Contre la complaisance

Demander l’auto-critique

« Avant de coder, dis-moi ce qui pourrait mal tourner dans cette approche » ou « relis ta réponse et trouve deux faiblesses ». Ça déclenche une passe de vérification que le modèle ne fait pas spontanément.

Contre les hypothèses

Autoriser la question

« Si quelque chose est ambigu, pose-moi la question au lieu de choisir ». Par défaut un agent tranche en silence. Cette phrase seule évite énormément de malentendus coûteux.

Format

Imposer la structure

Demander explicitement un tableau, une liste numérotée, du JSON avec des clés précises. Un format contraint réduit le bavardage et rend la réponse exploitable directement.

Économie

Corriger plutôt que recommencer

Un prompt parfait du premier coup est un mythe coûteux. Vise une première réponse correcte à 70 %, puis corrige précisément : « garde tout, change seulement la gestion d’erreur ».

3 · Débuggage

Quand le prompt rate, quoi corriger

Plutôt que de reformuler au hasard, diagnostique le symptôme. Chaque type d’échec a une cause probable et un remède précis.

Symptôme	Cause probable	Remède
Réponse générique, « scolaire »	Pas assez de contexte spécifique à ton projet	Colle le code réel, nomme les fichiers, décris la contrainte métier
Il en fait trop, touche à tout	Aucun périmètre posé	Ajoute les interdits : quels fichiers, quelles limites
Il s’arrête trop tôt	Pas de critère de succès	Termine par « fini quand… » avec une preuve observable
Il invente une API ou une option	Il répond de mémoire au lieu de lire	« Ouvre la doc ou le code source avant de répondre »
Il approuve une mauvaise idée	Aucune permission de contredire	« Si tu penses que c’est une mauvaise approche, dis-le avant de coder »
Ça se dégrade après plusieurs échanges	Contexte saturé, consignes du début diluées	Repartir d’une session propre avec un prompt qui résume l’état

Le test de l’ambiguïté : relis ton prompt et demande-toi si un développeur qui ne connaît pas le projet pourrait l’interpréter de deux façons différentes. Si oui, l’agent choisira la mauvaise — pas par malice, par probabilité.

4 · Modèles de prompts

Trois patrons réutilisables

Ces trois formes couvrent la majorité des situations de dev. Adapte-les, garde la structure.

Parce que la structure porte la moitié de la qualité. Réécrire le cadre à chaque fois fait oublier une brique sur deux — surtout le critère de succès, qui est celle qu’on oublie le plus.

Corriger un bug

Bug : [ce qui se passe] alors que [ce qui devrait se passer].
Reproduction : [étapes précises].
Zone concernée : [fichier ou dossier].
Avant de corriger :
1. Lis le code concerné et explique-moi la cause réelle.
2. Écris un test qui reproduit le bug, montre-moi qu'il échoue.
Ensuite seulement, corrige — sans toucher au reste.
Fini quand le test passe et que tu me montres la sortie.

Ajouter une fonctionnalité

Objectif : [le résultat attendu, côté utilisateur].
Contexte : [stack, fichiers concernés, contraintes existantes].
Commence en lecture seule : propose-moi un plan
(fichiers touchés, étapes, cas limites, ce qui peut casser).
Ne code rien avant que je valide le plan.
Contraintes : pas de nouvelle dépendance sans me demander,
respecte les conventions du projet.
Si un point est ambigu, pose la question.

Faire relire du code

Relis [ces fichiers ou ce diff] comme un reviewer senior.
Cherche en priorité :
- failles de sécurité et entrées non validées
- cas limites non gérés (null, vide, erreur réseau)
- écarts avec les conventions du projet
- complexité inutile
Ne modifie rien. Rends un rapport priorisé :
critique / important / cosmétique, avec le fichier
et la ligne pour chaque point.

Vérifie que c’est acquis

Ton agent corrige bien le bug demandé, mais reformate aussi douze fichiers au passage. Quelle brique manquait à ton prompt ?

À retenir

Le prompt est un cahier des charges, pas une incantation

Contexte réel, objectif formulé en résultat, interdits explicites, critère de succès observable. Si une réponse déçoit, cherche la brique manquante avant de changer de modèle : neuf fois sur dix, c’est le contexte ou le critère qui manquait.