La facture d'API IA a cette particularité désagréable : elle grossit sans prévenir, et personne dans l'équipe ne sait dire quelle fonctionnalité coûte quoi. La bonne nouvelle, c'est que les leviers sont connus, qu'ils se cumulent, et qu'aucun ne demande de changer de modèle. La mauvaise, c'est qu'on les tire presque toujours dans le désordre.
D'abord, comprendre d'où vient la facture
Deux mécanismes suffisent à expliquer l'essentiel.
La sortie coûte cinq fois l'entrée. Ce n'est pas une bizarrerie de fournisseur, c'est structurel : générer un jeton demande une passe complète du modèle, lire un jeton non. Prenons une grille réelle pour fixer les ordres de grandeur, celle d'Anthropic relevée le 24 juin 2026, en dollars par million de jetons :
| Modèle | Entrée | Sortie |
|---|---|---|
| Claude Opus 5 | 5 $ | 25 $ |
| Claude Sonnet 5 | 2 $ | 10 $ |
| Claude Haiku 4.5 | 1 $ | 5 $ |
Le rapport de un à cinq entre entrée et sortie se retrouve sur toute la gamme, et chez les autres fournisseurs à quelques variations près. Vérifiez la grille de votre fournisseur au moment où vous lisez ces lignes : ces tarifs bougent, et plutôt à la baisse ces derniers mois.
Première conséquence pratique : une consigne de concision est une mesure d'économie. Demander une réponse en cinq lignes plutôt qu'en trente ne dégrade pas la qualité de l'analyse, et divise le poste le plus cher.
Le contexte se repaie à chaque appel. Un modèle n'a pas de mémoire entre deux requêtes : l'intégralité de la conversation lui est renvoyée à chaque tour. Une discussion qui traîne 200 000 jetons d'historique facture ces 200 000 jetons à chaque message, pas une fois. C'est la mécanique détaillée dans notre article sur ce que change le contexte long, et c'est le premier poste de dérive sur les usages conversationnels.
Levier 1 : instrumenter, avant tout le reste
Cela paraît une évidence et c'est pourtant l'étape sautée neuf fois sur dix. Sans mesure par fonctionnalité, on optimise au hasard, et on optimise en général ce qu'on comprend le mieux plutôt que ce qui coûte le plus.
Le minimum utile : pour chaque appel, journaliser la fonctionnalité appelante, les jetons d'entrée, les jetons de sortie, les jetons lus depuis le cache, et le modèle employé. Cinq champs. À partir de là, un tableau hebdomadaire du coût par fonctionnalité suffit à trancher.
Ce que révèle presque toujours ce premier relevé : une fonctionnalité minoritaire en volume représente la majorité de la facture. Souvent une tâche de fond, un traitement par lot mal réglé, ou une fonctionnalité de confort utilisée par trois personnes. C'est là qu'il faut agir, pas sur la fonctionnalité principale que tout le monde a en tête.
Levier 2 : le cache de prompt, et sa condition
C'est le levier au meilleur rapport gain sur effort, et celui qu'on rate le plus souvent sans le savoir.
Le principe : le fournisseur conserve le résultat du calcul sur la partie invariable de votre requête et ne refacture au plein tarif que ce qui change. La réduction est substantielle sur toutes les grandes plateformes.
La condition est unique et sans indulgence : le cache fonctionne sur un préfixe, par correspondance exacte d'octets. Un seul caractère différent quelque part dans le préfixe invalide tout ce qui suit. L'ordre dans lequel votre requête est assemblée devient donc une décision d'architecture : d'abord la liste des outils, puis les instructions système, puis les messages. Le stable en tête, le variable en queue.
Trois précisions qui évitent de perdre du temps :
- Il existe un seuil minimal, de l'ordre du millier de jetons. En deçà, le préfixe n'est simplement pas mis en cache, sans message d'erreur.
- Le nombre de points de rupture que vous pouvez déclarer est limité, quatre par requête chez Anthropic. Ce n'est pas une contrainte gênante si votre requête est bien ordonnée ; c'en est une si vous espériez cacher sept segments épars.
- Le gain se vérifie, il ne se suppose pas. La réponse de l'API expose le nombre de jetons lus depuis le cache. S'il reste à zéro sur des requêtes répétées, votre cache ne fonctionne pas, quoi que vous croyiez avoir configuré.
Les invalidateurs silencieux, par ordre de fréquence :
- Un horodatage dans les instructions système. « Nous sommes le 25 juin 2026 à 14h03 » en tête de prompt annule le cache à chaque seconde. Si la date est nécessaire, mettez-la après le dernier point de rupture, pas avant.
- Un identifiant de session ou d'utilisateur en tête. Même effet, même remède.
- Un objet JSON sérialisé sans ordre stable. Deux exécutions produisent deux ordres de clés différents, donc deux préfixes différents. Triez les clés.
- Une liste d'outils qui varie. Les outils sont rendus en premier : ajouter conditionnellement un outil selon le contexte invalide tout le reste.
Levier 3 : le traitement par lots, pour tout ce qui n'est pas interactif
Les grands fournisseurs proposent une file asynchrone facturée la moitié du tarif normal, en échange d'un délai de traitement qui se compte en heures plutôt qu'en secondes.
C'est une remise de 50 %, sans contrepartie de qualité, sur tout ce qu'aucun humain n'attend devant son écran. Passez en revue ce qui pourrait y basculer : enrichissement nocturne d'une base, classification d'un arriéré de tickets, génération de résumés, traduction d'un catalogue, indexation documentaire, analyses de fin de mois.
L'objection habituelle est qu'il faut alors gérer l'asynchrone : soumettre, interroger l'état, récupérer les résultats. C'est vrai, et c'est une demi-journée de travail. Rapportée à une remise permanente de moitié sur un poste entier, l'arbitrage est vite fait.
Un piège à connaître : les résultats reviennent dans un ordre quelconque. Rattachez-les par l'identifiant que vous avez fourni à la soumission, jamais par leur position dans la liste.
💡 Le relevé de trente minutes
Prenez votre dernière facture, et rangez vos appels en trois colonnes : ceux qu'un humain attend en direct, ceux qui tournent en tâche de fond, et ceux qui répètent le même préfixe. La deuxième colonne bascule en traitement par lots, la troisième relève du cache. Il est fréquent que ces deux colonnes pèsent la majorité du montant. Si l'exercice révèle plutôt un problème d'architecture, c'est le genre de diagnostic que nous posons dans un audit NET&PRO.
Levier 4 : router selon la difficulté
Entre le haut et le bas d'une même gamme, le rapport est d'environ un à cinq. Envoyer toutes les tâches au modèle le plus capable revient à faire livrer le courrier interne en taxi.
La question difficile n'est pas technique, elle est méthodologique : comment décide-t-on qu'une tâche est facile ? Trois réponses, de la plus simple à la plus fine.
Par nature de tâche. La classification, l'extraction de champs, la détection de langue, le formatage et la reformulation courte passent très bien sur un petit modèle. Le raisonnement en plusieurs étapes, la rédaction longue et le code non.
Par mesure. Constituez un jeu de cinquante cas représentatifs avec leur réponse attendue, faites-le passer par le petit modèle, comparez. C'est une heure de travail qui remplace un débat d'opinion, et le résultat surprend souvent dans le bon sens.
Par escalade. Le petit modèle traite, et un contrôle déterministe décide s'il faut repasser au grand : format invalide, score de confiance bas, champ manquant. Vous payez le tarif élevé sur la minorité de cas qui le justifient. Attention toutefois à l'effet pervers : si le taux d'escalade dépasse le tiers, vous payez les deux modèles et vous perdez de l'argent.
Quand un petit modèle échoue de peu et de façon régulière, l'ajuster finement sur quelques centaines d'exemples le hisse souvent au niveau du grand pour cette tâche précise, et vous payez ensuite le tarif du petit à chaque appel. C'est l'un des rares cas où l'entraînement se rentabilise vraiment, et nous en détaillons les conditions dans fine-tuning ou RAG : comment trancher.
Levier 5 : réduire le contexte plutôt que l'empiler
Le réflexe naturel, quand une réponse déçoit, est d'ajouter du contexte. C'est souvent l'inverse qu'il faudrait faire, et pas seulement pour la facture : un modèle noyé répond moins bien.
Trois pratiques, dans l'ordre de rentabilité :
Sélectionner plutôt que tout envoyer. Si vous savez dans quel document se trouve la réponse, n'envoyez que celui-là. Une recherche documentaire en amont qui remonte trois pages pertinentes coûte une fraction d'un corpus complet expédié à chaque requête.
Résumer l'historique glissant. Sur une conversation longue, remplacez les vingt premiers tours par un résumé de deux cents jetons. Vous perdez le détail littéral, vous gardez les décisions, et vous divisez le coût par tour d'un facteur important.
Couper quand le sujet change. Une nouvelle conversation coûte moins cher et répond mieux qu'une conversation de trois semaines dans laquelle le modèle patauge. C'est gratuit et personne ne le fait.
L'ordre des travaux
Ces cinq leviers ne se valent pas, et l'ordre compte.
- Instrumenter. Une semaine de mesure. Sans elle, tout le reste est de la superstition.
- Le cache, sur le poste le plus lourd révélé par la mesure. Effort faible, effet immédiat.
- Le traitement par lots, sur tout ce qui peut attendre. Une demi-journée, une remise permanente de moitié.
- Le routage, une fois que vous savez quelles tâches sont vraiment faciles. Demande un jeu de test, donc du temps.
- La réduction de contexte, en dernier, parce qu'elle touche à la qualité et se valide au cas par cas.
Un mot pour finir sur ce qui ne marche pas. Changer de fournisseur pour économiser est presque toujours un mauvais calcul à court terme : vous perdez vos réglages, vos invites doivent être retestées, et l'écart de grille est souvent inférieur au gain qu'un cache bien placé vous aurait donné. Gardez cette option pour ce qu'elle est vraiment : un levier de négociation et une assurance contre la dépendance, sujet que traite notre article sur l'argent de l'IA.
Et si votre facture vient d'un agent plutôt que d'appels isolés, la mécanique est différente : le coût s'y multiplie par le nombre de tours, et c'est le taux de reprise humaine qui pilote la dépense. Nous détaillons ce cas dans ce qui casse entre la démo et le service.
