Le prix affiché d'un appel à un modèle est si bas qu'il désactive toute vigilance. Quelques centimes pour mille appels, c'est du bruit dans un budget. Puis arrive une facture qui ne ressemble pas du tout à l'estimation mentale du départ, et on cherche l'erreur. Il n'y en a généralement pas : le calcul de tête était juste, il portait juste sur la mauvaise unité.
D'où vient réellement la facture
Quatre multiplicateurs, qui se composent entre eux.
La taille du contexte. Tu ne paies pas la question, tu paies tout ce que tu envoies au modèle. Les instructions système, les exemples, les documents injectés, l'historique de conversation. Une question de vingt mots accompagnée de six pages de contexte, c'est six pages que tu paies, à chaque appel. Et dans une conversation, l'historique s'accumule : le dixième message coûte bien plus cher que le premier, parce qu'il transporte les neuf précédents.
Le nombre d'appels par tâche. Une chaîne qui classe, puis extrait, puis rédige, puis vérifie, c'est quatre appels pour un résultat. On raisonne en « traitements » et on facture en « appels ». Le facteur quatre passe inaperçu jusqu'à la facture.
Les boucles d'agent. C'est le poste le plus explosif, et le plus difficile à anticiper. Un agent qui utilise des outils décide lui-même du nombre d'itérations. Sur un cas simple, deux tours. Sur un cas ambigu, il cherche, se corrige, réessaie — quinze tours, chacun transportant tout l'historique de la conversation. Le coût d'un cas difficile n'est pas le double d'un cas simple : il est facilement dix ou vingt fois supérieur.
Les relances. Timeout, format de sortie invalide, erreur transitoire. La plupart des bibliothèques réessaient automatiquement, souvent trois fois. Un appel raté à la fin d'une longue génération se paie quand même, puis se repaie à chaque tentative.
La formule à garder en tête : taille du contexte × appels par tâche × itérations × relances × volume. Aucun de ces facteurs n'est grand tout seul. Leur produit, si.
Estimer avant de déployer
L'exercice prend une demi-heure et évite beaucoup de mauvaises surprises. Je le fais systématiquement avant toute mise en ligne.
- Prends dix cas réels, choisis pour couvrir le facile et le difficile. Pas dix cas de démonstration.
- Fais-les passer dans la chaîne complète, en mesurant pour chacun le nombre d'appels et le total de jetons consommés en entrée et en sortie.
- Calcule le coût du cas médian et celui du pire cas. L'écart entre les deux est l'information la plus utile de l'exercice.
- Multiplie le pire cas par ton volume mensuel. C'est ton plafond réaliste, celui à présenter en interne. Pas la médiane : c'est le pire cas qui arrive quand l'usage augmente, parce que les nouveaux usages sont toujours plus tordus que ceux prévus.
- Compare au gain attendu. Si le pire cas mange le bénéfice, revois la conception avant de déployer, pas après.
Les leviers, du plus rentable au moins
Mettre en cache ce qui se répète. Deux caches différents, souvent confondus. Le cache de prompt, proposé par la plupart des fournisseurs, évite de repayer plein tarif la partie fixe de ton contexte — instructions, exemples, documents de référence — quand elle est identique d'un appel à l'autre. Il suppose de structurer tes prompts avec la partie stable en tête. Et le cache applicatif, plus bête et souvent plus efficace : si la même question arrive deux fois, ressers la réponse sans rappeler le modèle. Sur des cas où les demandes se répètent beaucoup, c'est le levier qui donne le plus.
Utiliser un petit modèle pour les étapes simples. Classer une demande en cinq catégories, détecter une langue, extraire une date : ces tâches ne demandent pas le modèle le plus capable. Découper la chaîne pour n'appeler le gros modèle qu'à l'étape qui l'exige change l'ordre de grandeur de la facture. C'est de l'ingénierie de conception, pas de l'optimisation tardive.
Couper le contexte inutile. Beaucoup de systèmes injectent dix documents « au cas où » quand trois suffisent. Réduire le nombre de morceaux retrouvés et raccourcir l'historique conservé fait souvent baisser le coût sans dégrader la qualité. Il faut mesurer les deux, évidemment.
Plafonner les boucles. Un nombre maximum d'itérations par tâche, en dur. Au-delà, l'agent s'arrête et escalade. Un cas qui a besoin de trente tours ne va pas trouver au trente-et-unième : il est perdu, et il te coûte le plus cher de la journée.
Sortir des données courtes. Tu paies aussi ce que le modèle écrit, plus cher que ce que tu envoies. Demander un JSON compact plutôt qu'une explication rédigée, quand la sortie est consommée par une machine, coupe une part réelle du coût.
Les garde-fous à poser
Aucune optimisation ne remplace deux dispositifs simples.
Un plafond dur au niveau du compte. La plupart des fournisseurs permettent de fixer une limite de dépense mensuelle qui coupe l'accès. Mets-la, à un niveau que tu acceptes de perdre. C'est la seule protection contre la boucle infinie découverte un lundi matin.
Une alerte à mi-parcours. Une notification quand la moitié du budget mensuel est consommée avant la moitié du mois. Ça ne coûte rien à mettre en place et ça transforme un incident de facturation en simple information.
Ajoute, si ton volume le justifie, un suivi du coût par exécution dans le temps. Sa dérive est un signal précoce : un contexte qui grossit ou des boucles qui s'allongent apparaissent là avant d'apparaître sur la facture.
Ce que je regarde en premier
Devant un système dont le coût dérape, je pose deux questions avant toute autre. Combien d'appels pour une tâche ? Et quelle est la taille de ce qu'on envoie à chaque fois ? Neuf fois sur dix, la réponse est dans une de ces deux lignes — un historique jamais tronqué, ou une chaîne qui appelle le gros modèle pour trier du courrier.