Réduire sa facture LLM de 30 à 70%

Le scénario est presque toujours le même : vous ouvrez le tableau de bord de votre fournisseur, la courbe monte, et personne dans l'équipe ne sait dire pourquoi. Le nombre d'utilisateurs n'a pas bougé, mais la facture, si. Quand j'audite ces produits, je ne cherche ni un tarif magique ni un fournisseur moins cher. Je cherche les tokens que vous payez sans que personne ne les lise. Ils se cachent aux deux ou trois mêmes endroits, et les couper ne demande ni migration ni refonte.

Pourquoi ma facture d'IA grimpe-t-elle alors que l'usage stagne ?

Parce que le coût d'un LLM ne suit pas le nombre d'utilisateurs, il suit le nombre de tokens que vous lui faites lire et écrire à chaque appel. Et ce volume gonfle tout seul, version après version. Trois causes reviennent dans la quasi-totalité des missions : du contexte inutile renvoyé à chaque appel (un historique complet, un document entier, des consignes empilées au fil des mois), le modèle le plus cher branché partout par défaut alors qu'une partie des tâches s'en passe, et des réponses regénérées à l'identique alors qu'elles existaient déjà. Aucune de ces trois causes n'apparaît sur la facture : elle affiche un total, jamais la raison. C'est pour ça que je commence par lire la facture ligne par ligne plutôt que par couper au hasard.

Par où commencer pour reprendre le contrôle ?

Par la mesure, avant toute optimisation. Tant que vous ne savez pas où part chaque euro, chaque changement est un pari. Je décompose donc la dépense selon quelques axes simples, et le coupable saute vite aux yeux : une poignée d'appels concentre l'essentiel du budget. C'est là qu'on travaille en premier, pas sur ce qui est le plus visible.

• Par fonctionnalité : quelle partie du produit consomme, et est-ce qu'elle le mérite.
• Par modèle : combien vous coûte réellement le modèle premium, appel par appel.
• Par type d'appel : ce qui relève d'une tâche simple et répétitive, et ce qui demande vraiment de la puissance.
• Entrée contre sortie : quelle part des tokens sert au contexte que vous envoyez, plutôt qu'à ce que le modèle produit.
• Part de doublons : combien d'appels reposent la même question avec les mêmes données.

Le cache est-il vraiment le premier levier ?

Oui, et c'est le plus souvent par là que je commence, parce que le gain est immédiat et invisible pour l'utilisateur. En production, une grande partie des appels sont des quasi-doublons : la même question, les mêmes données, la même réponse, regénérée à plein tarif. Mettre en cache la réponse sur des entrées identiques supprime ce gaspillage sans rien changer pour vos utilisateurs, souvent en quelques jours.

Il y a deux caches à distinguer. Le premier stocke la réponse complète quand l'entrée est identique : parfait pour des questions récurrentes ou des écrans qui rechargent les mêmes données. Le second, proposé par les principaux fournisseurs, garde en mémoire la partie stable de votre prompt (les longues consignes, un document de référence) pour ne pas la refacturer plein tarif à chaque appel. Les deux se posent sans toucher à votre logique métier.

Faut-il vraiment le modèle le plus cher partout ?

Non, et c'est le deuxième grand levier. Router chaque requête vers le modèle le moins cher capable de la traiter suffit dans la majorité des cas. Une classification, une extraction de champs, un reformatage, une détection d'intention : ces tâches n'ont pas besoin du modèle le plus puissant, elles ont besoin d'un modèle assez bon, et il coûte une fraction du prix. Le réflexe de tout envoyer au meilleur modèle est confortable, il est rarement justifié. Pour décider quelle tâche mérite quel modèle, le choix se raisonne cas par cas, pas une fois pour toutes.

• Vers un petit modèle : classer, extraire des champs, reformuler court, détecter une intention, trier.
• Vers le gros modèle : raisonnement multi-étapes, rédaction longue, code, cas ambigus à fort enjeu.
• La règle : on garde le modèle le moins cher qui passe vos tests sur la tâche, et c'est lui qui la traite.

Que reste-t-il à couper une fois le cache et le routage en place ?

Le gras du prompt lui-même. C'est le travail le moins spectaculaire et souvent le plus rentable, parce qu'il s'attaque à ce que vous payez sur chaque appel, sans exception.

• Couper le contexte mort : tout ce que le modèle ne lit jamais coûte quand même. Un historique complet, un document entier envoyé pour trois lignes utiles, des consignes accumulées et jamais nettoyées.
• Préférer des instructions courtes et des exemples ciblés à de longues consignes : deux bons exemples valent souvent mieux qu'un pavé de règles, et coûtent moins cher à chaque appel.
• Regrouper les traitements de masse en batch quand la latence le permet : la plupart des fournisseurs facturent le traitement par lots à un tarif réduit.

Réduire la facture, est-ce risquer la qualité ?

C'est la première question qu'on me pose, et la réponse tient dans une méthode : je ne coupe rien sans le passer par les mêmes tests avant et après. Chaque changement (un cache, un modèle plus léger, un prompt raccourci) est validé sur un jeu de cas réels. Si la qualité mesurée baisse, le changement ne passe pas. Ce qui tombe, ce n'est pas la précision, c'est la dépense pour ce qui n'apportait rien. Sans cette mesure, on ne réduit pas une facture, on la déplace vers un problème de qualité qu'on découvrira plus tard. C'est exactement pour ça que je mesure la qualité en continu plutôt que de me fier à une impression.

Combien puis-je espérer économiser, et en combien de temps ?

Pris ensemble, ces leviers font tomber une facture de 30 à 70 % sur la plupart des produits que j'audite, à qualité égale. Les premiers gains tombent en général sous deux à trois semaines, parce que le cache et le routage se posent vite et rapportent tout de suite. Le reste est un travail d'hygiène qui continue de payer ensuite, appel après appel. La fourchette est large parce qu'elle dépend d'un seul facteur : la quantité de gaspillage déjà en place. Plus un produit a grossi sans être nettoyé, plus la marge de récupération est grande.

Je ne réduis jamais une facture en dégradant la qualité. Je la réduis en arrêtant de payer pour ce qui n'apporte rien.

Réduire une facture LLM n'est pas une affaire de négociation ni de migration, c'est une affaire de mesure et de discipline : voir où part l'argent, couper ce qui n'est jamais lu, réserver le modèle le plus cher aux tâches qui le méritent. C'est précisément le travail d'un audit d'optimisation. Si votre facture grimpe et que vous ne savez pas dire pourquoi, un premier échange suffit souvent à repérer les deux ou trois postes à couper d'abord, sans engagement : parlons-en.