Piloter l'agent
Un bon prompt n'est pas une question, c'est une commande : objectif, contexte, contraintes, critère de réussite.
Un prompt n'est pas une question, c'est une commande
Vous ne demandez pas une opinion à l'agent : vous lui confiez un travail. Et comme pour tout travail confié, ce qui manque se paie plus tard. Une question vague produit une réponse vague ; une commande précise produit quelque chose qu'on peut vérifier.
Parlez-lui comme à un développeur junior très rapide : il ne connaît pas votre projet, il ne devine pas vos intentions, mais il exécute très bien des consignes claires. Ce qui compte n'est pas la politesse, c'est la précision.
Un bon prompt contient un objectif, du contexte, des contrainteset un critère de réussite. S'il en manque un, l'agent le remplacera par une supposition.
L'anatomie d'un prompt qui marche
Objectif
Ajoute une section « horaires » sous la présentation de la page d'accueil.
Une seule intention, formulée comme une commande. Deux objectifs dans un message, c'est deux fois plus de chances de tout casser.
Contexte
Projet Astro. La page concernée est src/pages/index.astro ; les styles sont dans src/styles. Les autres sections sont déjà en place.
L'agent ne connaît que ce qu'il a lu. Nommer les fichiers évite les allers-retours et les modifications au mauvais endroit.
Contraintes
Ne modifie que src/pages/index.astro. Réutilise les classes existantes, n'ajoute aucune dépendance.
Les contraintes protègent le reste du projet. Un agent obéissant fera exactement ce qu'on ne lui a pas interdit.
Critère de réussite
La section s'affiche sous la présentation, avec un tableau à deux colonnes ; le reste de la page est identique.
Sans critère vérifiable, personne ne peut dire si c'est fini. Avec, on teste, et on sait.
Remarquez ce que ce prompt ne contient pas : ni politesse inutile, ni explication de ce qu'est Astro, ni liste de toutes les fonctionnalités du site. Un prompt utile est court parce qu'il est précis.
Construisez le vôtre
Remplissez les quatre blocs, choisissez la procédure, copiez. Le constructeur ne devine rien pour vous : il met simplement de l'ordre dans ce que vous écrivez.
Ajoute une section « horaires » sous la présentation de la page d'accueil.
Contexte : Projet Astro. La page concernée est src/pages/index.astro ; les styles sont dans src/styles. Les autres sections sont déjà en place.
Contraintes : Ne modifie que src/pages/index.astro. Réutilise les classes existantes, n'ajoute aucune dépendance et ne touche pas au pied de page.
C'est réussi quand : La section s'affiche sous la présentation, avec un tableau à deux colonnes ; le reste de la page est identique.
Avant d'agir, décris ton plan sans modifier aucun fichier. J'attends ma validation.Utilisez le constructeur pour votre prochaine demande réelle, même minuscule : « change le titre de la page ». C'est en comparant le résultat avec un prompt bâclé qu'on mesure la différence.
Le niveau de détail : deux exemples
Vague
Améliore la page d'accueil.
L'agent va changer ce qu'il veut, dans l'ordre qu'il veut. Le résultat sera peut-être joli, sûrement pas ce que vous imaginiez, et impossible à discuter.
Précis
Sur la page d'accueil, mets le titre principal en 2 lignes maximum et ajoute sous le bouton une phrase qui dit à qui le site s'adresse. Ne touche pas aux couleurs.
Un périmètre, un effet attendu, une interdiction. Si le résultat déçoit, vous savez exactement quelle phrase corriger.
Sept anti-patterns à reconnaître
Ces sept prompts reviennent sans arrêt. Les reconnaître, c'est déjà les éviter — et savoir quoi dire à la place.
À éviter Fais-moi un site.
Ce qui cloche : Aucun objet, aucun contexte, aucun critère : l'agent va inventer à votre place.
À la place : « Crée une page d'accueil avec un titre, un paragraphe et un bouton. Le titre parle de X. Je veux une seule colonne, lisible sur téléphone. »
À éviter Ça ne marche pas.
Ce qui cloche : Le message ne dit ni ce qui était attendu, ni ce qui se passe, ni où.
À la place : « J'attendais le menu à droite ; il s'affiche à gauche et passe sous le titre sur téléphone. Voici le message d'erreur complet : […] »
À éviter Ajoute un menu, change les couleurs et refais le texte de la page.
Ce qui cloche : Trois intentions dans un message : si le résultat déçoit, impossible de savoir laquelle a échoué.
À la place : Un message par intention. Le menu d'abord, on teste, puis les couleurs, puis le texte.
À éviter Répare tout.
Ce qui cloche : Aucun périmètre : l'agent peut réécrire des fichiers qui fonctionnaient.
À la place : « Le build échoue avec cette erreur : […]. Corrige uniquement la cause de cette erreur, sans refactoriser le reste. »
À éviter Choisis un beau design et un sujet sympa.
Ce qui cloche : Ce sont des décisions humaines. L'agent n'a ni goût, ni responsabilité, ni connaissance de votre public.
À la place : Vous choisissez le sujet et les grandes lignes ; l'agent propose des variantes, vous tranchez.
À éviter Voici ma clé d'API pour tester : sk-…
Ce qui cloche : Le secret part dans un service tiers et reste dans l'historique de la conversation.
À la place : On ne colle jamais de secret dans un prompt. La clé vit dans .env (voir la section Sécurité).
À éviter Non, refais pareil.
Ce qui cloche : Relancer la même demande donne souvent la même réponse : ce n'est pas une loterie, c'est un texte prédit.
À la place : Reformulez, ajoutez un exemple, réduisez le périmètre, ou changez de mode (plan) — mais changez quelque chose.
Les phrases qui pilotent
Huit situations, huit phrases à réutiliser telles quelles. Elles ne sont pas magiques : elles imposent un cadre à la conversation.
| Situation | Ce que vous pouvez écrire |
|---|---|
| Comprendre avant d'agir | Explique-moi ta démarche et les risques avant de modifier le moindre fichier. |
| Limiter le périmètre | Ne touche qu'à ce fichier. Si tu penses devoir en modifier un autre, demande-moi d'abord. |
| Vérifier ce qui a changé | Montre-moi la liste des fichiers modifiés et résume chaque changement en une phrase. |
| Revenir en arrière | Cette modification a cassé […]. Indique-moi comment revenir au dernier état qui fonctionnait. |
| Faire expliquer le code | Explique-moi ce fichier ligne par ligne, comme à un débutant, sans rien modifier. |
| Contester une réponse | Es-tu sûr que cette fonction existe dans cette version ? Cite la source ou vérifie dans le projet. |
| Demander des alternatives | Propose trois approches différentes avec leurs avantages et inconvénients, puis attends mon choix. |
| Terminer proprement | Le résultat est bon. Résume ce qu'on a fait, ce qu'il reste à faire, et propose un message de commit. |
Quand ça bloque : l'escalade
Un agent qui tourne en rond, ce n'est pas une fatalité : c'est une procédure. Essayez ces étapes dans l'ordre, en vous arrêtant dès que ça débloque.
- Vérifier le contexte. L'agent a-t-il lu le bon fichier ? Sinon, joignez-le avec @ et reformulez.
- Donner un exemple. Un exemple vaut mieux qu'une description : montrez une section qui fonctionne comme modèle.
- Réduire le périmètre. Découpez la demande en deux. Ce qui est trop gros échoue presque toujours.
- Passer en mode plan. Demandez le plan, corrigez-le, puis basculez en build pour exécuter ce plan-là.
- Repartir propre. Nouvelle session (/new) ou contexte compacté : une conversation trop longue brouille tout.
- Changer d'outil ou de modèle. Si le blocage persiste, un autre modèle ou une recherche dans la documentation débloque souvent.
Réessayer la même demande en espérant un autre résultat. Le modèle ne tire pas au sort : il produit du texte probable. Si l'entrée ne change pas, la sortie ne change pas non plus.
Pour aller plus loin
La promptothèque
Des prompts testés, classés par intention, expliqués phrase par phrase.
Espace de travailOpenCode
Où écrire le prompt, comment joindre un fichier avec @, où lire le coût.
MéthodeLe workflow
La boucle complète : décrire, générer, tester, corriger, livrer.
À ne pas raterSécurité
Ce qu'on ne met jamais dans un prompt : clés, données personnelles, secrets.