Un bon prompt, c’est d’abord une bonne spec

On parle beaucoup de « l’art du prompt », comme s’il existait une tournure qui débloque le bon code. Après un an à travailler avec un assistant dans l’éditeur, je crois que c’est une mauvaise piste. Ce qui change le résultat, ce n’est pas la formule. C’est le contexte : ce que l’outil sait du projet avant même que je lui demande quoi que ce soit.

Autrement dit, un bon prompt commence bien avant le prompt.

Le fichier que l’assistant lit en premier

À la racine de chaque projet, j’ai un fichier de conventions, lu automatiquement au début de chaque session. Il tient sur une page et il répond aux questions qu’un nouveau développeur poserait le premier jour :

# Conventions du projet

- Code en anglais (noms, commentaires), textes visibles en français.
- Vue 3 en `<script setup>` avec TypeScript, jamais l'Options API.
- Un composant par fichier, nommé en PascalCase, dans `app/components/<domaine>/`.
- Les couleurs passent par les variables du thème (`var(--accent)`), jamais en dur.
- Chaque composant qui affiche une liste gère quatre états : chargement, vide, erreur, succès.
- Tests Cypress dans `tests/e2e/`, un fichier par parcours utilisateur.
- Commits en anglais, préfixés [ADD], [CHANGE] ou [DELETE].

Ce fichier a changé ma façon de travailler plus que n’importe quelle astuce de formulation. Avant, chaque génération partait dans une direction différente : un jour l’Options API, le lendemain des couleurs en dur, des commentaires en anglais puis en français. Depuis, le code généré ressemble au code existant, et la relecture va deux fois plus vite.

Décrire le résultat, pas la méthode

Une demande efficace dit ce qu’on veut obtenir et comment on saura que c’est bon. Elle ne dicte pas les étapes.

La seconde version tient en trois lignes et contient tout ce qu’il faut : le périmètre (un champ), les règles (facultatif, format), le comportement visible (le message d’erreur), et la preuve (le test). L’assistant n’a rien à deviner, et moi, j’ai une liste pour vérifier.

Donner les contraintes avant les envies

Les contraintes coûtent cher quand elles arrivent après. Un composant écrit sans savoir qu’il doit marcher sans JavaScript, ou qu’il sera rendu côté serveur, ou qu’il doit rester lisible à 320 pixels, est souvent à refaire plutôt qu’à corriger.

Je mets donc les contraintes en premier, dans la demande ou dans le fichier de conventions selon qu’elles sont ponctuelles ou permanentes :

• La cible : navigateurs, tailles d’écran, rendu serveur ou non.
• Ce qui existe déjà et qu’il faut réutiliser : « il y a un composant MdsButton, utilise-le ».
• Ce qu’il ne faut pas faire : « pas de nouvelle dépendance », « ne touche pas à l’API ».
• Le niveau d’accessibilité attendu : clavier, lecteur d’écran, contrastes.

Montrer un exemple

Quand un motif existe déjà dans le projet, je pointe le fichier : « fais comme ProjectCard.vue ». Un exemple vaut mieux qu’une description, parce qu’il porte toutes les conventions implicites : l’indentation, la façon de nommer les props, l’ordre des blocs, le style des commentaires.

C’est aussi le meilleur moyen de garder un projet cohérent dans le temps. Le dixième composant ressemble au premier, parce que le premier a servi de modèle à tous les autres.

Demander petit, souvent

Une demande qui touche cinq fichiers produit un diff que je mets vingt minutes à relire, et dans lequel une erreur se cache facilement. Cinq demandes qui touchent un fichier chacune produisent cinq diffs lisibles en deux minutes, avec les tests qui tournent entre chaque.

Ça semble plus lent. En pratique, c’est plus rapide, parce que je ne reviens jamais en arrière.

Ce que je ne fais plus

• Chercher la tournure parfaite. Le contexte compte plus que les mots.
• Demander « le meilleur » ou « le plus propre ». Ça ne veut rien dire pour la machine, et rarement pour moi.
• Accepter une génération sans test quand un test est possible.
• Laisser une convention dans ma tête au lieu de l’écrire dans le fichier.

Le résultat, c’est un projet où n’importe qui, humain ou assistant, peut arriver et produire du code qui a l’air d’avoir été écrit par la même personne. C’était déjà la définition d’une bonne spec avant l’IA. Ça l’est toujours.