Factures d’IA en entreprise : réduire les coûts sans brider les usages

Les entreprises adoptent l’intelligence artificielle beaucoup plus vite qu’elles n’apprennent à en piloter les coûts. Les premiers prototypes paraissent peu chers, les abonnements individuels sont faciles à acheter et quelques appels API ne pèsent presque rien. Puis les usages se généralisent, les agents deviennent plus autonomes, les contextes s’allongent et les licences s’accumulent. La facture augmente sans que personne puisse dire précisément quelle valeur elle finance.

J’observe alors deux réactions opposées, et rarement satisfaisantes. Certaines entreprises laissent faire parce que l’IA est considérée comme un investissement stratégique. D’autres imposent brutalement des plafonds, suppriment des accès ou choisissent systématiquement le modèle le moins cher. Dans le premier cas, le gaspillage s’installe. Dans le second, on dégrade parfois les usages qui créaient réellement de la valeur.

Le problème n’est pas seulement le prix des modèles. Il vient surtout de la façon dont on conçoit les processus, attribue les abonnements et mesure les résultats.

Une facture d’IA contient en réalité deux factures très différentes :

la consommation variable des processus automatisés, facturée à l’appel, au token, à l’image, à la seconde ou à l’outil utilisé ;
les abonnements des salariés, facturés par siège ou par compte, avec des quotas et des niveaux de service propres à chaque fournisseur.

Ces deux catégories ne s’optimisent pas avec les mêmes leviers. Pour les automatisations, il faut travailler l’architecture, le choix des modèles, le contexte, les boucles de retry et la qualité. Pour les abonnements, il faut travailler l’attribution des licences, l’adoption, la formation, les profils d’usage et, lorsque les contrats l’autorisent, la mutualisation de la capacité.

La bonne question n’est pas « combien de tokens avons-nous consommés ? », mais « combien nous coûte un résultat métier accepté ? »

Cet article propose une méthode complète pour passer d’une dépense opaque à un système pilotable, sans transformer l’optimisation en politique de surveillance des salariés.

1. Commencer par mesurer le coût complet, pas seulement la facture du fournisseur

Le tableau de bord d’un fournisseur montre généralement des appels, des tokens et un montant. C’est utile, mais insuffisant. Il ne montre ni le temps humain consacré aux corrections, ni les traitements échoués, ni les doublons, ni les conséquences d’une mauvaise réponse.

Pour un processus automatisé, l’unité économique pertinente est :

coût par résultat utile = (inférence + infrastructure + supervision humaine + coût des échecs) / résultats acceptés

Pour un assistant de support, le résultat utile peut être une réponse envoyée sans réécriture importante. Pour un système d’extraction de documents, ce sera un document correctement structuré et validé. Pour un agent de développement, cela peut être une tâche fusionnée après revue, et non une simple quantité de code générée.

Le coût complet doit donc inclure au minimum :

le coût des appels aux modèles, y compris les entrées, sorties, données mises en cache et éventuels tokens de raisonnement ;
les appels supplémentaires déclenchés par les outils et les sous-agents ;
les retries, fallbacks et timeouts ;
l’OCR, la recherche, les bases vectorielles et l’infrastructure du gateway ;
le temps de contrôle ou de correction humaine ;
le coût des erreurs qui atteignent la production ;
le taux de résultats réellement utilisables.

Cette dernière ligne change toute l’analyse. Un modèle deux fois moins cher qui produit davantage d’erreurs peut augmenter le coût final. À l’inverse, un modèle premium utilisé uniquement sur les cas ambigus peut réduire le coût global s’il évite des reprises manuelles.

2. Pourquoi les automatisations deviennent inutilement coûteuses

Les dérives les plus importantes ne viennent généralement pas d’un prix unitaire qui aurait soudainement explosé. Elles viennent d’un processus qui multiplie un petit gaspillage par des milliers ou des millions d’exécutions.

Le modèle le plus puissant est utilisé partout

Un prototype est souvent construit avec le meilleur modèle disponible parce que cela accélère la validation. Le problème apparaît quand ce choix temporaire devient la configuration de production.

Toutes les étapes n’ont pas besoin du même niveau de raisonnement. Détecter une langue, classer une demande, extraire trois champs simples ou vérifier un format peut souvent être confié à un modèle plus petit, voire à du code déterministe. Le grand modèle doit être réservé aux cas où sa qualité supplémentaire change réellement le résultat.

La stratégie la plus robuste est un routage par difficulté :

des règles déterministes éliminent les cas triviaux ou invalides ;
un petit modèle traite les cas courants ;
un modèle plus puissant reçoit uniquement les cas complexes ou à faible confiance ;
un humain arbitre les exceptions à fort risque.

Ce routage doit être évalué sur des exemples réels. Une confiance déclarée par le modèle ne suffit pas : il faut la calibrer contre des résultats annotés.

Le contexte est envoyé en bloc

Les équipes confondent parfois « donner plus d’information » avec « donner toute l’information ». Elles envoient un historique complet, une documentation entière ou un document de plusieurs centaines de pages à chaque appel.

Cette approche augmente le coût d’entrée, la latence et le bruit. Elle peut aussi dégrader la réponse : l’information utile est noyée dans des éléments sans rapport avec la tâche.

Un meilleur pipeline sélectionne le contexte avant l’appel : recherche lexicale ou vectorielle, filtrage par métadonnées, résumé d’état, fenêtre glissante et suppression des informations déjà connues. Il mesure ensuite deux ratios simples : la part du contexte effectivement citée ou utilisée, et le nombre de tokens d’entrée par résultat accepté.

Les réponses sont inutilement longues

Une consigne vague comme « analyse ce dossier en détail » produit souvent une sortie verbeuse, coûteuse et difficile à exploiter. Un contrat de sortie précis réduit à la fois le volume et les erreurs d’intégration.

Il vaut mieux demander un schéma structuré, limiter les champs, fixer une longueur maximale et interdire la répétition du raisonnement dans la réponse finale. Le programme peut ensuite valider ce schéma avant de poursuivre le workflow.

Les retries masquent les défauts de conception

Un retry est parfois nécessaire face à une erreur transitoire. Mais relancer exactement le même appel après une réponse invalide n’est pas une stratégie de qualité.

Il faut distinguer :

les erreurs techniques temporaires, qui justifient un retry avec backoff ;
les limites de quota, qui justifient un autre déploiement ou un fallback autorisé ;
les sorties invalides, qui exigent une consigne corrigée ou une validation plus stricte ;
les tâches trop difficiles, qui doivent être escaladées vers un meilleur modèle ou un humain.

Le taux de retry par workflow est l’un des meilleurs détecteurs de gaspillage. Il doit apparaître à côté du coût, pas uniquement dans les logs techniques.

Les boucles agentiques n’ont pas de budget

Un agent peut planifier, chercher, appeler plusieurs outils, relire son travail et recommencer. Cette autonomie est utile, mais son coût est non borné si aucune limite n’est définie.

Chaque exécution devrait avoir un budget explicite : nombre maximal d’étapes, nombre d’appels externes, volume de contexte, durée et coût estimé. À l’approche de la limite, l’agent doit produire un état exploitable, demander une validation ou s’arrêter. Une boucle infinie qui « réfléchit encore » est un incident de production, même si elle ne lève aucune exception.

Le cache n’est pas exploité

Les préfixes stables, documents de référence et requêtes identiques sont parfois refacturés à chaque passage. Plusieurs fournisseurs proposent une tarification spécifique pour les entrées mises en cache, et des gateways permettent aussi un cache exact ou sémantique.

Le cache ne doit toutefois pas être activé aveuglément. Sa clé doit inclure la version du prompt, du modèle, des outils et des données pertinentes. Il faut définir une durée de vie et interdire la réutilisation lorsque la fraîcheur, la confidentialité ou l’identité de l’utilisateur l’exigent.

La qualité n’est pas évaluée en continu

Sans jeu d’évaluation, une optimisation de coût est un pari. On remplace un modèle, on raccourcit un prompt ou on réduit le contexte, puis on attend les plaintes.

Un petit jeu de cas représentatifs, versionné avec les prompts, permet de mesurer la précision, le taux de refus, la conformité au schéma et le besoin de correction humaine. Les changements peuvent alors être déployés progressivement et comparés au comportement précédent.

3. Exemple : repenser une extraction documentaire

Prenons un processus qui reçoit des documents et doit produire des données structurées. La première version envoie le texte complet à un grand modèle, demande une analyse libre, tente de parser la réponse et recommence si le JSON est invalide.

Une version mieux conçue peut suivre ce chemin :

calculer l’empreinte du fichier pour éliminer les doublons ;
vérifier le type, la taille et la qualité du document avec du code classique ;
utiliser l’OCR uniquement si le texte n’est pas déjà disponible ;
sélectionner les pages ou passages pertinents ;
faire classer le document par un petit modèle ;
extraire les champs dans un schéma strict ;
calculer des contrôles déterministes sur les dates, montants et totaux ;
envoyer au grand modèle uniquement les champs ambigus ;
demander une validation humaine si le risque ou l’incertitude dépasse un seuil ;
conserver la décision, la version du prompt et les métriques pour l’évaluation.

On ne cherche plus à rendre un appel moins cher. On supprime les appels inutiles, on réduit leur contexte et on réserve la capacité coûteuse aux cas où elle crée de la valeur.

Avant de déployer cette nouvelle version, je la ferais tourner en parallèle sur un échantillon de production. La comparaison doit porter sur le coût par document accepté, le taux de correction, la latence et les erreurs métier. Une économie affichée par le fournisseur n’est pas une économie si le service comptable doit corriger davantage de résultats.

4. Rendre chaque euro traçable avec un gateway comme LiteLLM

Il est difficile de piloter les coûts quand chaque application appelle directement plusieurs fournisseurs avec sa propre clé et son propre format de logs. Un gateway LLM crée un point de contrôle commun.

LiteLLM est l’un des outils adaptés à ce rôle. Il expose une interface homogène vers de nombreux modèles et peut centraliser l’authentification, le routage, les retries, les fallbacks, le cache et l’observabilité. Ses clés virtuelles permettent d’associer des usages à un utilisateur ou une équipe, d’appliquer des limites de débit et des budgets. Sa documentation décrit également le suivi des dépenses par clé, utilisateur et équipe.

LiteLLM ne résout pas magiquement les problèmes de coût. Il rend les décisions applicables et mesurables. Si tous les workflows portent encore le même identifiant, si les prompts ne sont pas versionnés ou si personne ne définit le résultat métier, le dashboard restera peu utile.

Ce que chaque trace devrait contenir

Pour relier technique et finance, j’enregistre au minimum :

un identifiant de trace et l’environnement ;
le produit, le projet, le workflow et l’étape ;
la version du prompt, du modèle et du routeur ;
le fournisseur et le modèle réellement utilisés, pas seulement ceux demandés ;
les tokens d’entrée, de sortie, mis en cache et, quand ils sont exposés, de raisonnement ;
le prix appliqué au moment de l’appel ;
la latence, les erreurs, retries et fallbacks ;
les outils appelés et leur durée ;
le statut du résultat : accepté, corrigé, rejeté ou abandonné ;
un score qualité issu d’une évaluation automatique ou humaine.

Les conventions sémantiques OpenTelemetry pour l’IA générative peuvent servir de socle pour éviter un format propriétaire différent dans chaque service.

Quatre vues suffisent pour commencer

Un premier tableau de bord utile n’a pas besoin de cinquante graphiques. Il doit répondre à quatre questions :

Où part l’argent ? Dépense par produit, workflow, équipe, modèle et environnement.
Pourquoi varie-t-elle ? Volume, taille du contexte, sorties, retries, cache et routage.
Qu’obtient-on en échange ? Résultats acceptés, taux de correction, temps gagné ou revenu protégé.
Où agir en premier ? Coût par résultat, dérives par rapport à la référence et principaux échecs.

Une alerte devrait porter sur une anomalie exploitable : coût par résultat qui double, retry anormal, chute du cache ou apparition d’un modèle premium dans un workflow qui ne l’utilisait pas. Une alerte sur le seul total mensuel arrive souvent trop tard.

Ne pas transformer l’observabilité en fuite de données

Tracer ne signifie pas stocker tous les prompts et toutes les réponses. Ces contenus peuvent contenir des données personnelles, du code privé, des secrets ou des documents clients.

Par défaut, je privilégie les métadonnées, les compteurs et des identifiants pseudonymisés. Les contenus complets ne sont activés que pour un échantillon contrôlé, avec caviardage, chiffrement, durée de rétention courte et contrôle d’accès. LiteLLM prévoit des callbacks d’observabilité et des mécanismes de nettoyage des données journalisées, mais leur configuration reste une responsabilité de l’entreprise.

5. Les abonnements salariés : optimiser l’allocation, pas surveiller les personnes

La seconde facture est celle des licences : assistants de développement, outils de rédaction, recherche, image, réunion ou analyse. Elle semble simple parce que le prix par siège est fixe. Pourtant, elle cache souvent des comptes inactifs, des abonnements redondants et des utilisateurs avancés bloqués par des quotas trop faibles.

La mauvaise réponse consiste à classer les salariés selon leur nombre de prompts ou de tokens. La consommation brute ne mesure pas la productivité. Une personne peut lancer beaucoup de requêtes inutiles ; une autre peut utiliser l’outil deux fois par semaine pour des décisions à forte valeur. Un classement individuel crée en outre de mauvais comportements et un climat de surveillance.

Les indicateurs réellement utiles

Je suivrais plutôt, avec une granularité adaptée et autant que possible au niveau agrégé :

le nombre de licences attribuées, activées et réellement utilisées ;
le coût par utilisateur actif, avec une définition stable de l’activité ;
le nombre de jours d’usage utile par mois ;
la part des utilisateurs qui atteignent régulièrement leur quota ;
la fréquence des changements manuels de fournisseur ou de compte ;
les cas d’usage déclarés et leur niveau de criticité ;
le temps économisé, estimé avec prudence puis vérifié sur des échantillons ;
des métriques métier existantes : délai de traitement, temps de cycle, taux de correction ou satisfaction ;
le nombre de licences redondantes couvrant le même besoin.

Il faut distinguer l’adoption de la valeur. « A ouvert l’outil ce mois-ci » mesure l’activation. « A réduit le temps de préparation d’un dossier sans dégrader sa qualité » commence à mesurer un résultat.

Une politique de licences par profil

Une politique simple peut prévoir trois profils :

occasionnel : accès à un service partagé ou à la demande ;
régulier : licence standard individuelle ;
intensif : capacité supérieure, outils spécialisés ou plusieurs modèles justifiés par le métier.

L’attribution doit pouvoir évoluer. Une licence inactive peut être réaffectée après une période annoncée, avec un mécanisme de réactivation rapide. Un utilisateur qui atteint régulièrement ses limites ne doit pas perdre du temps à contourner son outil : son profil doit être réévalué.

La formation est un levier financier à part entière. Savoir choisir un modèle, limiter le contexte, réutiliser un prompt validé et vérifier une sortie réduit la dépense tout en augmentant la qualité. Une heure de formation ciblée peut avoir plus d’impact qu’une négociation de quelques pourcents sur le prix des sièges.

6. Mutualiser une capacité d’abonnement avec MultiVibe

Certains usages ne correspondent pas bien au modèle « une licence, un salarié, un outil ». Des agents de développement, des runners ou des applications internes ont une demande irrégulière : un compte reste inutilisé pendant qu’un autre atteint son quota.

C’est pour cette situation que j’ai développé MultiVibe, publié dans le dépôt multicodex-proxy. Le projet expose une API compatible OpenAI et route les requêtes entre plusieurs comptes et fournisseurs. Au moment où j’écris ces lignes, il propose notamment :

un routage multi-comptes sensible aux quotas, avec failover sur les erreurs de limite ;
des alias de modèles et des fallbacks ordonnés entre modèles ou fournisseurs ;
l’onboarding OAuth ou manuel selon les fournisseurs ;
des clés distinctes par application partageant le même pool ;
des traces avec modèle, tokens, erreurs et latence ;
des statistiques par compte, route, application et période ;
une attribution des sessions Codex par projet ;
la prise en compte de l’en-tête X-LiteLLM-Key-Alias pour conserver l’attribution projet quand LiteLLM est placé en amont.

L’objectif est de lisser l’utilisation d’une capacité autorisée et de présenter une interface unique aux outils internes. Les clients n’ont pas à connaître le compte disponible ni à être reconfigurés lorsqu’un quota est atteint.

LiteLLM et MultiVibe ne répondent pas exactement au même besoin

LiteLLM est particulièrement utile comme couche de gouvernance : clés virtuelles, budgets, équipes, politique de modèles et consolidation de la dépense API. MultiVibe apporte un routage orienté comptes d’abonnement et quotas disponibles. Selon le contexte, on peut utiliser l’un, l’autre ou les combiner :

Applications, agents et IDE
            ↓
LiteLLM : identité, budgets, politiques et reporting
            ↓
MultiVibe : routage comptes, quotas, alias et continuité
            ↓
Fournisseurs et comptes autorisés

Dans cette architecture, un alias de clé LiteLLM peut suivre le projet, tandis que MultiVibe choisit le compte capable de servir la requête. L’entreprise conserve ainsi la vue financière et l’attribution sans exposer les identifiants fournisseurs aux applications.

Une limite essentielle : la technique ne remplace pas le contrat

Mutualiser techniquement des comptes ne signifie pas que tous les abonnements peuvent être partagés. Les conditions d’utilisation, règles de licences, politiques OAuth et limites organisationnelles varient selon les fournisseurs et les offres.

Avant tout déploiement, il faut vérifier que le contrat autorise l’usage prévu, l’automatisation et le routage entre comptes. MultiVibe ne doit pas servir à usurper l’identité d’utilisateurs, contourner une limitation contractuelle ou masquer un abus de quota. Pour certains besoins, une offre API ou entreprise restera la seule option conforme.

Il faut également sécuriser le proxy comme un composant critique : authentification obligatoire, séparation des droits d’administration, stockage protégé des tokens, rotation, journalisation, restrictions réseau et procédure de révocation. Le dépôt fournit les primitives techniques ; l’organisation reste responsable de son architecture de sécurité et de sa conformité.

7. Une feuille de route en trente jours

La reprise de contrôle ne nécessite pas de refondre toute la plateforme avant d’obtenir un résultat. Je commencerais par un cycle court.

Semaine 1 : établir la référence

inventorier fournisseurs, clés, abonnements, propriétaires et centres de coût ;
choisir les trois workflows qui dépensent le plus ;
définir pour chacun un résultat métier accepté ;
instrumenter modèle, tokens, latence, retry, erreur et résultat ;
calculer un premier coût complet, même imparfait.

Semaine 2 : corriger les multiplicateurs

supprimer doublons et appels sans résultat ;
réduire les contextes les plus volumineux ;
imposer des sorties structurées ;
limiter boucles et retries ;
tester un petit modèle sur les étapes simples ;
activer le cache lorsque la sémantique et la confidentialité le permettent.

Semaine 3 : rationaliser les licences

identifier les comptes non activés, inactifs ou redondants ;
interroger les équipes sur leurs cas d’usage, pas uniquement sur leur fréquence ;
définir les profils occasionnel, régulier et intensif ;
réaffecter les licences avec une règle transparente ;
former les utilisateurs sur les deux ou trois gestes qui coûtent le plus.

Semaine 4 : installer les garde-fous

créer des budgets et limites par projet ;
ajouter des alertes sur le coût par résultat et les anomalies ;
versionner prompts, évaluations et règles de routage ;
documenter une procédure pour changer de modèle ou de fournisseur ;
décider si un gateway, MultiVibe ou une combinaison des deux est justifiée.

À la fin du mois, l’objectif n’est pas seulement une facture plus basse. L’entreprise doit pouvoir expliquer ses principaux postes, détecter une dérive en quelques heures et décider où un euro supplémentaire produira le plus de valeur.

8. Les indicateurs à conserver dans la durée

Pour les automatisations :

coût complet par résultat accepté ;
taux de succès au premier passage ;
taux de retry et de fallback ;
tokens d’entrée et de sortie par résultat ;
taux de cache ;
part des demandes traitées par modèle léger ;
taux de correction humaine ;
latence jusqu’au résultat utile ;
dérive de qualité par version de prompt ou de modèle.

Pour les abonnements :

licences achetées, attribuées, activées et actives ;
coût par utilisateur actif et par cas d’usage ;
part des licences inactives ou redondantes ;
utilisateurs régulièrement limités par leur quota ;
délai de réattribution d’une licence ;
valeur perçue et résultats métier, mesurés de manière agrégée.

Au niveau financier, je complète toujours la facture visible :

coût total IA = API + abonnements + infrastructure + gouvernance + revue humaine + coût des erreurs

Et je reste prudent avec le « temps économisé ». Dix heures théoriquement gagnées ne deviennent pas automatiquement dix heures de marge. Le gain n’est réel que si ce temps est réinvesti, si un délai est réduit, si une capacité est évitée ou si un résultat supplémentaire est produit.

Conclusion : optimiser le système, pas seulement le tarif

Les coûts d’IA ne sont pas incontrôlables. Ils deviennent incontrôlés lorsque les entreprises achètent des accès sans politique, automatisent sans instrumentation et évaluent la consommation sans mesurer les résultats.

La méthode est la même que pour toute infrastructure mature : définir une unité de valeur, attribuer chaque dépense, observer les dérives, poser des limites et améliorer les composants les plus coûteux. LiteLLM peut apporter une couche de gouvernance et de traçabilité. MultiVibe peut mutualiser et router une capacité d’abonnement lorsque les contrats l’autorisent. Mais les outils ne remplacent ni une architecture sobre, ni des évaluations, ni une politique claire pour les équipes.

Une bonne stratégie FinOps pour l’IA ne cherche pas la facture minimale. Elle cherche le meilleur rapport entre coût, qualité, risque et vitesse. C’est cette discipline qui permet de développer les usages utiles sans signer un chèque en blanc aux modèles.