Ce que coûte réellement une fonctionnalité LLM sur un an

En janvier, j’ai fait un exercice que je recommande à toute équipe qui s’apprête à livrer une fonctionnalité LLM : j’ai pris la facture réelle de six mois d’une fonctionnalité de résumé, pas la projection d’avant-lancement, la facture réelle, et je l’ai comparée à ce qu’on avait budgété. Le ratio était de 4,2×.

Ce n’est pas un échec de planification. C’est un échec de modèle mental. Quand on budgète une fonctionnalité LLM, on prend le coût d’un appel, on le multiplie par le nombre d’utilisateurs, et on obtient un chiffre. Ce chiffre est faux, systématiquement, parce qu’il oublie tout ce qui se passe après le jour du lancement.

L’anatomie d’une facture LLM

La partie visible : les tokens de production

C’est le chiffre que tout le monde calcule. Nombre de requêtes × tokens moyens × prix par token. Pour un assistant de résumé servant 10 000 utilisateurs/jour avec des requêtes de ~2 000 tokens (entrée + sortie), ça donne quelque chose comme :

10 000 req/jour × 2 000 tokens × $3/M tokens = ~$60/jour = ~$1 800/mois

Ce chiffre est correct. Il représente environ 25 % de la facture réelle.

Les retries (×1.3)

Avec un taux d’erreur typique de 2-5 % et 2-3 retries par échec, vous consommez 15-30 % de tokens en plus. Ce n’est pas visible dans vos logs « requêtes réussies », c’est visible uniquement dans la facture.

Les évals (×1.2)

Si vous faites des évaluations continues (et vous devriez), chaque suite d’évals consomme des tokens. Un jeu de 50 cas de test, lancé à chaque déploiement, avec un pipeline de 3 déploiements par semaine : ça s’additionne. Ajoutez les évals de régression hebdomadaires et les tests adversariaux mensuels.

Le contexte gonflé (×1.5-2.0)

C’est le poste le plus sous-estimé. Au lancement, votre prompt système fait 500 tokens. Trois mois plus tard, après les corrections de cas limites, les instructions supplémentaires et les exemples few-shot ajoutés pour gérer les plaintes : 1 500 tokens. Ce prompt voyage avec chaque requête. Votre coût par appel a triplé sans que personne ne s’en rende compte.

Les abus et le bruit (×1.1-1.5)

Les utilisateurs explorent les limites. Certains collent des documents de 50 pages dans un champ prévu pour un paragraphe. D’autres lancent des boucles de requêtes par curiosité. Un seul utilisateur avec un script mal écrit peut générer plus de trafic que cent utilisateurs normaux.

Le budget réaliste

En pratique, la formule corrigée ressemble à :

Coût réel ≈ Coût projeté × 3 à 5

Pour notre exemple :

• Projection naïve : $1 800/mois
• Réalité après 6 mois : $7 500/mois

La bonne nouvelle : la plupart de ces facteurs sont compressibles une fois identifiés.

Les leviers de réduction

1. Le cache sémantique

Si deux utilisateurs posent la même question (ou une question suffisamment similaire), servez la même réponse. Un cache basé sur l’embedding de la requête avec un seuil de similarité de 0.95 peut réduire les appels de 20-40 % selon le cas d’usage. Le résumé d’un même article sera identique quel que soit l’utilisateur, pourquoi le re-générer ?

2. Le prompt diet

Auditez votre prompt tous les mois. Chaque instruction ajoutée pour un cas limite coûte des tokens sur toutes les requêtes. Est-ce que ce cas limite à 0.1 % justifie 200 tokens supplémentaires sur 100 % des appels ? Souvent non. Déplacez la logique dans le code.

3. Le routage de modèle

Toutes les requêtes n’ont pas besoin du modèle le plus puissant. Un classifieur léger en amont (ou même un switch sur la longueur de l’entrée) peut router 60 % des requêtes simples vers un modèle 10× moins cher, et réserver le modèle premium pour les cas complexes.

4. Les limites utilisateur

Un rate limit par utilisateur, non pas en requêtes/seconde (ça c’est de l’infra), mais en tokens/jour, empêche les abus sans pénaliser l’usage normal. « Vous avez utilisé votre quota de résumés pour aujourd’hui » est un message acceptable quand l’alternative est une facture incontrôlable.

Le tableau de bord que je construis maintenant

Cinq métriques, vérifiées chaque lundi matin :

1. Coût par requête réussie (pas par requête envoyée, inclut les retries)
2. Taille moyenne du prompt (dérive = coût caché)
3. Taux de cache hit (doit monter, pas descendre)
4. Top 10 utilisateurs par consommation (les outliers sont toujours instructifs)
5. Coût des évals en % du coût de production (si ça dépasse 15 %, optimisez les évals)

La conversation à avoir avant le lancement

Avant de livrer une fonctionnalité LLM, répondez à trois questions que personne ne pose :

1. Quel est le coût marginal d’un utilisateur supplémentaire ? Si c’est $0 (SaaS classique) vs $0.30/jour (LLM), votre modèle de pricing doit le refléter.
2. Que se passe-t-il quand le coût dépasse 2× le budget ? Alertes ? Kill switch ? Rate limiting automatique ?
3. Qui regarde la facture chaque semaine ? Si la réponse est « personne avant la fin du mois », vous découvrirez les problèmes trois semaines trop tard.

Une fonctionnalité LLM n’est pas un déploiement, c’est un engagement financier récurrent. Traitez-la comme tel. La question qui vient juste avant, est-ce que cette fonctionnalité répond à une demande qui existe déjà ?, mérite la même rigueur ; trouver des idées d’entreprise avec un agent IA propose la méthode qu’on peut adopter en amont pour ne pas budgétiser une feature dont personne ne voulait.

---

Si cela vous a parlé, vous aimerez Votre logique de retry vous ment et Fallbacks, timeouts et l’art de se dégrader gracieusement. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.