Il existe une croyance tenace dans le développement agentique : « dans le doute, donne tout le contexte à l'agent ». Tout le dépôt, tout l'historique, toute la doc. L'intuition est rassurante - et c'est une erreur coûteuse. Un contexte gonflé, c'est une facture de tokens qui gonfle à chaque exécution, et souvent une réponse moins bonne, l'agent se noyant dans le bruit.
Chez Survol, on part d'un principe simple, presque comptable : les tokens, c'est l'argent du client. On ne revend pas de tokens, l'abonnement reste le vôtre. Notre travail n'est donc pas de vous en faire consommer, mais de vous en faire consommer le moins possible à qualité égale. Voici comment.
Le bon contexte n'est pas le plus gros. C'est le plus petit qui suffit.
1. Composer le contexte, pas le déverser
Quand vous validez une fonctionnalité, Survol ne balance pas le dépôt entier à l'agent. Il assemble un contexte ciblé à partir de trois ingrédients, et trois seulement :
- la spec validée de la fonctionnalité - ce qu'on veut, formulé une fois proprement ;
- les décisions déjà tranchées qui s'y rapportent - pour ne pas refaire les débats ;
- les fichiers réellement concernés - pas tout le code, ceux qui comptent.
Ce trio change tout. Là où un prompt naïf envoie 80 000 tokens de contexte « pour être sûr », un contexte composé en envoie une fraction - et l'agent vise plus juste parce qu'il n'a pas à deviner ce qui est pertinent.
# Contexte composé par Survol 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"
2. Le bon modèle pour la bonne tâche
Tout ne mérite pas le modèle le plus puissant. Renommer une variable, ajuster un libellé, écrire un test unitaire simple : un modèle léger fait le travail pour une fraction du prix. Un refactoring multi-fichiers ou un débogage tordu : là, on sort l'artillerie. Survol choisit le modèle automatiquement selon la nature de la tâche, au lieu de vous laisser payer le tarif premium pour tout, tout le temps.
Ordre de grandeur : entre un contexte composé au plus juste et un modèle adapté à chaque tâche, on vise environ un tiers de tokens en moins sur un cycle de développement typique - sans dégradation perceptible de la qualité. (C'est une cible interne, pas une garantie contractuelle : tout dépend de votre code.)
3. Mesurer pour pouvoir décider
On n'optimise que ce qu'on mesure. Survol suit la consommation par session, par version et par fonctionnalité - pas seulement par personne. Vous voyez quelle fonctionnalité a coûté quoi, et vous reliez enfin la dépense à ce qui est livré. Une fonctionnalité qui brûle des tokens sans avancer se repère du premier coup d'œil, et déclenche la bonne question : contexte mal taillé ? spec ambiguë ? tâche mal découpée ?
Ce que ça donne au quotidien
- Vous validez une spec ; Survol compose le contexte minimal correspondant.
- Le modèle est choisi selon la tâche, sans que vous ayez à y penser.
- La consommation s'affiche, rattachée à la fonctionnalité et à la version.
- Vous arbitrez sur des chiffres, pas sur une intuition de fin de mois.
Optimiser les tokens n'est pas une affaire de radinerie : c'est du respect. Votre abonnement est une ressource finie, votre temps aussi. Un contexte taillé sur mesure rend les deux à leur juste valeur - et, accessoirement, rend l'agent meilleur. Le plus petit contexte qui suffit gagne presque toujours contre le plus gros.
