Cette note est un contexte ; le travail actuel, ce sont les packs Web & eCommerce et l’entrée US → EMEA.
Il y a un schéma que nous voyons se répéter chez les équipes qui ont adopté l’outillage IA avec enthousiasme en 2025 et qui, en 2026, regardent la facture en silence : la facture n’a pas grossi parce que les modèles sont devenus plus chers. Elle a grossi parce que personne n’a regardé ce qu’on leur envoyait.
L’arithmétique inconfortable est la suivante. Le prix au million de tokens d’un modèle est un chiffre fixe et publié. Ce qui n’est pas fixe, c’est le nombre de tokens que produisent vos habitudes de travail — et pour la plupart des opérateurs qui utilisent Cursor et Claude au quotidien, la dépense dominante n’est pas la sortie brillante du modèle. C’est le même contexte, payé encore et encore : les fichiers du dépôt rattachés à chaque message, le system prompt renvoyé à chaque appel, la boucle d’agent qui relit la moitié du projet à chaque nouvelle tentative.
Le contexte, c’est la facture. Une fois cette idée intégrée, réduire la consommation de tokens cesse d’être une chasse au modèle moins cher et devient : envoyer moins, l’envoyer une seule fois, et arrêter les boucles avant qu’elles ne s’égarent. Rien de tout cela ne dégrade le travail. Presque tout l’améliore, parce que la discipline qui économise des tokens — contexte cadré, briefs clairs, changements planifiés — est celle qui rend la sortie du modèle plus juste dès le départ.
Ceci est un guide de terrain, pas un essai tarifaire. Pour la version stratégique de la question du coût — quelles classes de modèles doivent porter quelles charges — lisez notre calcul de coût open vs frontier. Cet article traite des habitudes qui se trouvent en dessous.
Ce qui brûle vraiment des tokens
Avant les tactiques, un inventaire honnête. Cinq postes dominent la dépense du développement assisté au quotidien, à peu près dans cet ordre :
| Poste de dépense | Pourquoi ça brûle | Le remède en une ligne |
|---|---|---|
| Contexte de conversation renvoyé | Chaque message d’un long fil renvoie l’historique accumulé | Nouveau chat par tâche ; fils courts |
| Pièces jointes de contexte surdimensionnées | Joindre des dossiers ou le dépôt entier quand trois fichiers suffisaient | Cadrer les mentions @ sur ce que touche la tâche |
| Boucles d’agent non cadrées | Chaque tentative relit des fichiers, relance des recherches, se réexplique | Planifier d’abord ; donner un brief, pas un souhait |
| System prompts et règles répétés | Les mêmes instructions renvoyées, sans cache, à chaque appel | Préfixes de prompt stables + prompt caching |
| Modes de raisonnement toujours actifs | Le raisonnement étendu multiplie les tokens de sortie sur des tâches qui n’en ont pas besoin | Ajuster l’effort de raisonnement à la difficulté |
Remarquez ce qui n’est pas dans la liste : le tarif du modèle. Une équipe au contexte discipliné sur un modèle premium dépense souvent moins qu’une équipe au contexte négligé sur un modèle bon marché — parce que la seconde envoie dix fois plus de tokens par unité de travail utile, puis les renvoie quand la première tentative échoue.
Cursor : cadrer, planifier, et savoir quand ne pas utiliser l’agent
Cursor est là où se produit l’essentiel de la dépense des équipes de développement, parce que c’est là que vit le contexte.
Joignez ce que la tâche touche, rien de plus
La recommandation de Cursor lui-même est plus étroite que les habitudes de la plupart des gens : utilisez les mentions @ quand vous savez quels fichiers sont pertinents, et passez-vous-en sinon — l’agent trouve les fichiers par sa propre recherche, généralement moins chère qu’un déversement spéculatif de dossiers (documentation Cursor). Joindre @src/ parce que la réponse est « quelque part là-dedans » fait payer chaque fichier du dossier à chaque message suivant.
La règle de travail : mentionnez les deux ou trois fichiers que le changement touche. Si vous ignorez vraiment où vit le changement, dites-le dans le prompt et laissez l’agent chercher — une recherche ciblée coûte une fraction du déversement préventif.
Des chats courts et des tâches petites
Chaque chat partage une fenêtre de contexte fixe et, à mesure que le fil s’allonge, Cursor compresse les parties anciennes en résumé pour faire de la place. Bien avant ce point, vous payez déjà pour renvoyer un historique de plus en plus périmé à chaque message. L’habitude qui corrige cela est aussi de la bonne ingénierie : une tâche, un chat. Terminez le changement, vérifiez-le, repartez de zéro. Les petits diffs sont moins chers à produire, moins chers à relire et bien moins chers à refaire quand quelque chose cloche.
Planifiez avant de lâcher la boucle
L’objet le plus coûteux du développement assisté est le run d’agent non cadré : « répare les tests qui échouent » contre une base de code que le modèle n’a pas cartographiée, relancé trois fois, chaque tentative relisant des fichiers et relançant des recherches. Le coût en tokens est mauvais ; le coût de relecture d’un diff tentaculaire et à moitié juste est pire.
L’alternative coûte un message : demandez d’abord un plan. Que le modèle dise ce qu’il pense être cassé, quels fichiers il va toucher et à quoi ressemble le changement — puis approuvez ou corrigez avant que rien ne tourne. Un plan, c’est quelques centaines de tokens de sortie. Une boucle à la dérive, ce sont des dizaines de milliers, plus votre après-midi.
Écrivez la stack une fois, dans les règles
Si vous vous surprenez à taper « nous utilisons Astro, du CSS maison, pas de Tailwind, les chaînes vivent dans les fichiers i18n » pour la troisième fois cette semaine, cette phrase appartient à un fichier de règles du projet, pas à vos prompts. Les règles de Cursor attachent automatiquement les conventions du projet — vous cessez de payer de l’attention (et des tokens) à réexpliquer votre propre stack, et le modèle cesse de commettre la classe d’erreurs qui vient de ne pas la connaître.
Savoir quand le mode Agent est le mauvais outil
Le mode Agent mérite son coût quand le modèle doit réellement chercher, lire plusieurs fichiers, faire des modifications coordonnées et vérifier. Pour un renommage, un changement dans une fonction ou une retouche de texte, l’édition inline ou un chat court et cadré font le même travail en une passe, pour une fraction des tokens. Prendre l’agent par défaut, c’est prendre la camionnette pour poster une lettre — ça fonctionne, et vous avez payé la camionnette.
Claude : mettre en cache le stable, raccourcir le system prompt, discipliner les outils
Pour les équipes qui appellent directement l’API Claude — outils internes, agents, pipelines — les leviers sont structurels.
Le prompt caching est le plus gros levier côté API
Si vos appels partagent un préfixe stable — system prompt, définitions d’outils, documents de référence —, le prompt caching change l’économie en profondeur. Sur l’API Claude, les lectures de cache sont facturées à 0,1× le prix d’entrée de base ; les écritures à 1,25× (documentation du prompt caching d’Anthropic). Pour un pipeline qui envoie le même préambule de 5 000 tokens quelques centaines de fois par jour, c’est la différence entre payer plein tarif des centaines de fois et le payer, en pratique, une seule.
La discipline exigée est architecturale : gardez stable la partie stable. Placez les instructions fixes, les définitions d’outils et le matériel de référence en tête du prompt, dans un ordre constant, et gardez pour la fin tout ce qui varie par requête. Une phrase reformulée à la légère en haut du system prompt invalide tout le cache qui suit.
Les system prompts courts font mieux que les longs
Les system prompts prennent du poids tout seuls. Quelqu’un ajoute un paragraphe pour un cas limite, quelqu’un d’autre trois exemples, et un an plus tard chaque appel traîne 4 000 tokens d’instructions — dont la moitié couvre des comportements que le modèle aurait de toute façon. Auditez-le : supprimez les instructions qui couvrent ce que le modèle réussit déjà, fusionnez les exemples redondants, déplacez la référence rarement utile vers de la récupération à la demande, pour la payer quand elle sert au lieu de toujours.
La discipline des outils réduit les allers-retours cachés
Les charges d’agent brûlent des tokens en allers-retours : chaque appel d’outil et son résultat refont passer le contexte accumulé par le modèle. Trois habitudes réduisent la note :
- Des contrats d’outils étroits. Un outil qui renvoie exactement ce dont l’agent a besoin bat un outil qui renvoie l’enregistrement complet que le modèle devra trier — le tri, vous le payez à chaque tour suivant.
- Moins d’outils, de meilleurs outils. Chaque définition d’outil voyage dans le prompt, utilisée ou non. Élaguez celles que rien n’appelle.
- Des boucles avec budget. Donnez aux agents un budget explicite d’étapes et un comportement défini quand il est atteint. « Essaie jusqu’à ce que ça marche » n’est pas une instruction ; c’est un robinet ouvert.
Ajustez la classe de modèle à la tâche
Anthropic publie des modèles à paliers nets de capacité et de prix — à la date de cet article, classe Haiku pour le travail courant rapide, classe Sonnet pour l’équilibre quotidien, classe Opus pour le raisonnement le plus exigeant (vérifiez les noms et tarifs en vigueur sur la page des modèles d’Anthropic, car ils évoluent). Le schéma qui tient de génération en génération : routez par tâche, pas par habitude. Classification, extraction, mise en forme et premiers jets n’ont pas besoin du palier supérieur ; le raisonnement architectural profond, parfois si. La même logique vaut dans le sélecteur de modèles de Cursor — et les modes de raisonnement étendu méritent le même examen, car les tokens de raisonnement sont des tokens de sortie que vous payez, que la tâche en ait eu besoin ou non.
Règles d’équipe : là où l’économie se compose
Les habitudes individuelles font économiser de l’argent réel. Les habitudes d’équipe le multiplient — parce que les modes de défaillance coûteux sont organisationnels, pas personnels.
Une seule source de vérité pour la connaissance de la stack. Si chaque développeur réexplique l’architecture au modèle avec ses propres mots, vous payez cette explication des dizaines de fois par jour — et chaque version diffère légèrement. Un fichier de règles de projet entretenu (ou un CLAUDE.md, ou les deux) s’écrit une fois, se versionne dans git et s’attache tout seul.
Ticket → brief → build. Le travail qui arrive à un agent devrait arriver sous forme de brief : quoi changer, où, à quoi ressemble le « terminé », ce qu’il ne faut pas toucher. Les briefs rendent les runs d’agent plus courts et plus justes. Le ticket vague — « améliore le parcours de commande » — devient une fouille archéologique hors de prix avant la première modification.
Une porte humaine avant les boucles « répare tout ». Les instructions larges et quasi destructrices — répare tous les tests, mets à jour toutes les dépendances, corrige chaque alerte du linter — exigent qu’une personne approuve le plan d’abord. C’est la même discipline de points de contrôle que nous appliquons aux flux d’agents en production, appliquée à votre propre outillage.
Regardez la facture chaque semaine, brièvement. Pas un projet de tableau de bord — dix minutes sur la page d’utilisation du fournisseur. Les pics de dépense remontent à un flux, à un schéma de chat ou à une boucle emballée, et chacun se corrige dès que quelqu’un le remarque. La dépense que personne ne regarde ne bouge que dans un sens.
Qui devrait faire quoi
Fondateur ou opérateur solo. Adoptez d’abord les habitudes gratuites : pièces jointes cadrées, nouveau chat par tâche, plan avant boucle, un fichier de règles. Sautez l’infrastructure — ni passerelle ni tableau de bord. Votre levier est entièrement dans les habitudes de travail, et il couvre à lui seul la plupart des scénarios de facture emballée.
Équipe ops ou produit de cinq personnes. Tout ce qui précède, plus la couche partagée : un fichier de règles versionné dont tout le monde hérite, le brief comme norme pour le travail d’agent, une personne nommée qui jette un œil à l’utilisation chaque semaine. Si vous avez des charges API, structurez les prompts pour le cache avant d’optimiser quoi que ce soit d’autre — c’est le plus gros levier isolé, et il coûte un refactoring, pas une plateforme.
Agence ou pod de delivery. La dépense en tokens, c’est de la marge. Routez par classe de tâche comme politique, pas comme préférence ; faites de la structure de prompt compatible cache un standard de build ; mettez en place l’attribution par client pour que le coût s’assoie à côté du revenu. À ce stade, la question cesse d’être de l’hygiène d’outillage et devient de l’architecture — quel modèle porte quel flux, journalisé et révisable — et c’est le territoire de la Couche Opérationnelle — nous expliquons ce qu’est une Couche Opérationnelle IA à part, avec la logique de décision détaillée dans le choix de modèle comme décision de gouvernance.
La facture est un miroir
La dépense en tokens est une télémétrie étonnamment honnête : elle reflète, ligne à ligne, la façon dont votre équipe travaille réellement avec ces outils. Le contexte gonflé, les briefs vagues et les boucles sans surveillance apparaissent sur la facture avant d’apparaître ailleurs. Corrigez les habitudes et la facture suit — et, discrètement, la qualité de ce que les modèles vous rendent aussi.
Si vous préférez un second regard — quels flux brûlent quoi, où le routage ou le cache paieraient, à quoi ressemble un montage gouverné pour une équipe de votre taille —, commencez par un devis Web & eCommerce ou US → EMEA.
Questions fréquentes
Qu'est-ce qui brûle le plus de tokens dans l'usage quotidien de Cursor et Claude ?
Le contexte répété : les mêmes fichiers, règles et historiques de conversation renvoyés à chaque message. Les longues boucles d'agent qui réessaient et relisent les fichiers multiplient le tout. Le prix au token du modèle compte moins que le nombre de tokens que vous lui envoyez — et la plupart sont envoyés plus d'une fois.
Le prompt caching réduit-il vraiment le coût ?
Oui, de façon substantielle, dès que vos prompts partagent un préfixe stable. Sur l'API Claude, les lectures de cache sont facturées à 0,1× le prix d'entrée de base et les écritures à 1,25×, selon la tarification publiée par Anthropic. La discipline est structurelle : gardez stable la partie stable du prompt pour que le cache fasse son travail.
Quand ne faut-il PAS utiliser le mode Agent de Cursor ?
Pour les petites modifications bien comprises — renommages, changement d'une seule fonction, retouches de texte. L'édition inline ou un chat cadré font le travail en une passe. Le mode Agent mérite son coût sur les changements multi-fichiers où le modèle doit réellement chercher, lire et vérifier — pas sur une modification que vous pouvez décrire en une phrase.
Ces habitudes exigent-elles une plateforme ou une passerelle coûteuse ?
Non. Tout ce qui est décrit ici fonctionne avec une licence Cursor standard et une clé API Claude. Une passerelle avec journalisation devient utile plus tard, quand plusieurs personnes ou agents partagent une facture et qu'il faut une attribution par flux — c'est un sujet de Couche Opérationnelle, pas un prérequis.