Il y a un an, je pilotais tous mes projets à coups de prompts dans le terminal. Une fonctionnalité naissait d'un message, se corrigeait dans un deuxième, dérivait dans un troisième. Six semaines plus tard, impossible de répondre à trois questions pourtant simples : qu'est-ce qui est vraiment fait ? dans quelle version ? sur quelle branche ?
Ce n'est pas un problème de Claude Code - l'agent fait remarquablement bien son travail. C'est un problème d'outillage autour de l'agent. Quand on délègue le code, on a besoin, plus que jamais, de garder la vision produit. Et le prompt jetable est exactement l'inverse d'une vision produit : il est éphémère, non versionné, illisible trois jours plus tard.
On ne pilote pas un produit avec un historique de terminal.
Le prompt jetable, ce faux ami
Le prompt direct est séduisant parce qu'il est immédiat. Mais il a trois défauts rédhibitoires dès qu'une équipe - ou simplement votre vous du mois prochain - doit reprendre le fil :
- Il n'est pas versionné : on ne sait pas ce qui a été demandé, ni quand, ni pourquoi.
- Il n'est pas relu : aucune décision d'équipe avant de lancer la machine.
- Il n'est pas relié à une branche, une PR, une préview, un coût en tokens.
L'inversion : la spec d'abord
La proposition de Survol tient en une phrase : vous décrivez une fonctionnalité comme à un collègue, vous la validez en équipe, et c'est cette spec validée qui devient l'instruction envoyée à Claude. Vous ne tapez jamais le prompt - il est généré, affiné et tracé à partir de ce que vous avez déjà écrit et décidé.
Concrètement : chaque fonctionnalité a un historique de versions (v1.0, v1.1, v2.0…) avec les modifications demandées entre chaque. La version est l'unité de vérité - pas l'auteur, pas le prompt.
Ce déplacement a une conséquence inattendue mais décisive sur les coûts. Quand la spec est l'objet de travail, on peut calibrer le contexte au strict nécessaire : la spec, les décisions tranchées, les fichiers réellement concernés. Rien de plus.
# Ce que Survol envoie à l'agent, généré depuis la spec validée : contexte: fonctionnalité: "Codes promo & bons cadeaux" version: "v2.0" décisions: ["cumul interdit avec les soldes"] fichiers: ["src/Pricing/Promo.cs", "src/Checkout/Cart.cs"] modèle: "choisi automatiquement selon la tâche"
Et les humains, dans tout ça ?
Inverser le flux ne veut pas dire retirer la main aux équipes - au contraire. Les décisions produit se discutent avant de lancer une session. Vos développeurs peuvent toujours coder directement : branches, commits et PR manuels sont détectés et rattachés à la bonne fonctionnalité, sans ton délateur. Et à tout moment, une revue d'expert humaine peut transformer ses constats en tâches pour Claude.
Ce que ça change au quotidien
- Vous écrivez la fonctionnalité une fois, proprement.
- L'équipe tranche les décisions ouvertes.
- Claude développe sur sa branche, vous suivez en direct.
- Vous validez la préview - ou vos retours deviennent la version suivante.
Au bout de quelques semaines, la question « qu'est-ce qui est vraiment fait ? » a une réponse, en permanence. C'est tout ce qu'on demandait au départ - et c'est précisément ce que le prompt jetable ne donnera jamais.
