Un coût d'inférence qui augmente n'est presque jamais une surprise technique. C'est le résultat d'un usage qui a grandi sans que personne ne relise la facture par cas d'usage. Pour la maîtriser, il faut décomposer la dépense, la suivre par requête et par agent chaque mois, et n'arbitrer un changement de modèle qu'avec une mesure de qualité en face du coût.
Le coût récurrent que personne ne pilote après la mise en production
Un projet IA se pilote de près pendant la phase de construction, et c'est au moment de l'industrialisation de l'IA que le pilotage du coût doit être posé. Il y a un budget, un chef de projet, des points hebdomadaires. Le jour où l'agent ou l'assistant passe en production, cette attention retombe. La facture d'API arrive sur la carte d'un développeur ou sur un compte cloud partagé, elle est réglée avec le reste, et personne ne la relie à un usage précis.
Le scénario est classique. Une ETI industrielle met en service un assistant de réponse aux appels d'offres. Trois mois plus tard, deux autres services l'ont adopté pour d'autres usages, la facture a triplé, et la direction financière demande à quoi sert cette ligne. Personne ne peut répondre avec précision, parce que le seul indicateur disponible est le montant total du mois.
Il manque un propriétaire du coût récurrent, une facture décomposée par usage et un rendez-vous mensuel pour la relire. Sans eux, la dérive est invisible jusqu'au jour où elle devient un sujet de comité de direction.
Décomposer la facture : hébergement, API, licences, inférence par cas d'usage
La première étape consiste à séparer ce qui est mélangé. Une facture IA en production contient en général quatre familles de coûts qui n'évoluent pas de la même manière.
L'hébergement couvre les serveurs, les bases de données et la base vectorielle si le système en utilise une. Ce poste est relativement stable et suit le nombre d'utilisateurs plus que le nombre de requêtes. Les appels d'API vers les fournisseurs de modèles constituent le poste le plus variable, facturé au jeton en entrée et en sortie, et parfois différemment selon le modèle appelé. Les licences regroupent les outils annexes : plateforme d'observabilité, outil de gestion des invites, service de reconnaissance de documents. Enfin, l'inférence proprement dite, c'est-à-dire le coût des appels aux modèles, doit être rattachée à chaque cas d'usage plutôt qu'au compte global.
C'est le point décisif. Si l'assistant de réponse aux appels d'offres, le classement automatique des courriels et le résumé des comptes rendus passent par la même clé d'API, la facture ne dit rien. Une clé ou une étiquette de suivi par cas d'usage, mise en place dès le premier jour ou ajoutée après coup, permet de savoir lequel des trois consomme et lequel apporte de la valeur. C'est souvent à ce moment qu'on découvre le cas d'usage oublié : activé pour un test, jamais désactivé, et qui tourne en silence.
Suivre le coût par requête et par agent, mois après mois
Une fois la facture décomposée, le suivi repose sur deux indicateurs simples que tout dirigeant peut lire.
Le coût par requête, calculé pour chaque cas d'usage, indique ce que coûte en moyenne une interaction. Il permet de comparer un mois à l'autre à périmètre égal. S'il augmente alors que le modèle n'a pas changé, c'est que les requêtes sont devenues plus longues, que le contexte injecté a grossi ou qu'un enchaînement d'appels s'est allongé.
Le coût par agent, ou par cas d'usage, indique le total mensuel de chaque système. Il permet de mettre la dépense en face du bénéfice : combien coûte l'assistant appels d'offres, et combien de dossiers a-t-il aidé à traiter ce mois-ci. Nous avons détaillé la composition de cette ligne dans un article consacré à la facture mensuelle d'un agent IA en production, le présent article s'attache plutôt à sa lecture dans le temps.
Le tableau de suivi tient sur une page : pour chaque cas d'usage, le nombre de requêtes, le nombre de jetons en entrée et en sortie, le coût total, le coût par requête, et une colonne de commentaire. Ce tableau est produit chaque mois, à date fixe, à partir des journaux d'appels. Un tableur suffit. Il faut surtout de la constance, et une personne dont c'est la responsabilité écrite.
Repérer une dérive de consommation et en trouver la cause
Une dérive se lit dans l'écart entre le coût par requête et le volume de requêtes. Si les deux montent ensemble, l'usage se développe et c'est plutôt une bonne nouvelle, à condition qu'il soit voulu. Si le coût par requête monte seul, quelque chose a changé dans le système.
Quatre causes reviennent le plus souvent. La première est un contexte qui grossit : la base documentaire a été enrichie, le système envoie désormais davantage de passages au modèle pour chaque question, et chaque requête coûte plus cher sans que personne n'ait décidé de ce surcoût. Une boucle d'agent qui s'allonge : un agent autonome qui devait faire trois appels en fait sept parce qu'un outil renvoie des erreurs intermittentes et qu'il réessaie. Un changement de modèle par défaut côté fournisseur, avec une nouvelle grille tarifaire. Ou plus simplement un usage détourné : des utilisateurs qui collent des documents entiers dans un assistant conçu pour des questions courtes.
Le contexte trop gros est la cause la plus fréquente et la plus rentable à corriger. Chez SuperHote, éditeur d'un logiciel de location courte durée pour lequel nous avons construit un copilote conversationnel, les réponses brutes des API de la plateforme étaient transmises telles quelles au modèle. Les filtrer côté serveur, pour ne garder que les champs utiles à la question, a ramené l'entrée d'environ 30 000 à 1 500 jetons par requête. Le modèle n'avait pas changé ; c'est ce qu'on lui envoyait qui était surdimensionné.
Pour trouver la cause, l'ordre est toujours le même : comparer les jetons moyens en entrée et en sortie d'un mois sur l'autre, isoler les requêtes les plus coûteuses et en relire une dizaine, puis vérifier les changements de configuration et de modèle sur la période.
Changer de modèle : mesurer la qualité et le coût côte à côte avant de décider
Face à une facture qui monte, la tentation est de basculer vers un modèle moins cher. C'est parfois la bonne décision, mais elle ne doit jamais être prise sur le seul critère du prix. Un modèle moins coûteux qui produit des réponses moins fiables déplace le coût vers les utilisateurs, qui corrigent, vérifient ou abandonnent l'outil.
La bonne pratique consiste à constituer un jeu de test représentatif, une centaine de requêtes réelles avec la réponse attendue, et à faire tourner les deux modèles dessus. On obtient alors deux colonnes : le taux de réponses correctes et le coût pour traiter le jeu complet. La décision se prend en regardant les deux. Un modèle qui divise le coût par trois et perd deux points de qualité est un bon candidat pour un cas d'usage interne à faible enjeu. Il ne l'est pas pour un assistant qui répond à des clients ou qui prépare des documents contractuels.
Ce jeu de test a une autre vertu : il sert aussi quand le fournisseur annonce la dépréciation d'un modèle et impose une migration. Une entreprise qui l'a déjà constitué migre avec une mesure objective. Celle qui ne l'a pas fait migre à l'aveugle, et découvre les régressions par les remontées des utilisateurs.
Un exemple construit pour illustrer la logique : une PME juridique teste trois modèles pour son outil de synthèse de dossiers. Le moins cher produit des synthèses acceptables mais oublie régulièrement les dates de procédure ; l'intermédiaire coûte davantage sans cette faiblesse. La bonne réponse n'est pas un modèle unique : l'intermédiaire pour les synthèses, le moins cher pour le classement des pièces, qui ne demande pas la même précision. Router chaque tâche vers le modèle qui suffit est souvent le levier le plus simple.
Plafonds, alertes et arbitrages écrits
Le suivi mensuel détecte les dérives. Les plafonds et les alertes les contiennent avant qu'elles ne pèsent sur la trésorerie.
Un plafond de dépense par cas d'usage, configuré chez le fournisseur ou dans la couche applicative, coupe ou ralentit le service au-delà d'un montant convenu. Il faut le fixer avec une marge raisonnable par rapport à l'usage normal, sinon il coupe un service utile en fin de mois. Une alerte à un seuil intermédiaire prévient le responsable avant que le plafond ne soit atteint, ce qui laisse le temps de comprendre et de décider.
Les arbitrages doivent être écrits. Quand une équipe décide d'accepter une hausse de coût parce que l'usage s'est développé, ou de basculer un cas d'usage sur un modèle moins cher, la décision est consignée avec la date, la mesure qui l'a motivée et la personne qui l'a prise. Ce registre évite de refaire les mêmes débats six mois plus tard, et il constitue la trace dont une direction financière a besoin pour comprendre l'évolution de la ligne IA dans le budget.
Ces règles s'appliquent quel que soit le prestataire qui opère le système. Quand la supervision est confiée à un tiers, le contrat précise qui fixe les seuils, qui reçoit les alertes et comment le client est informé, sous forme d'engagements écrits définis après l'audit initial. Un suivi des coûts d'inférence en production fait partie des livrables attendus d'une maintenance supervisée de modèles IA, au même titre que la surveillance de la dérive et la préparation des migrations.
Ce qui relève de l'optimisation technique, et où la lire
Tout ce qui précède concerne le suivi et la décision. Il existe un autre niveau, celui des techniques qui réduisent le coût d'une requête sans changer de modèle : mise en cache, regroupement des appels par lots, réduction du contexte envoyé, choix du format de sortie.
Deux d'entre elles ont un effet chiffré par les fournisseurs eux-mêmes. Chez Anthropic, la facturation par lots coûte 50 % du prix standard, en échange d'un traitement différé (la plupart des lots se terminent en moins d'une heure, la limite est de 24 heures) : c'est le bon choix pour tout ce qui n'attend pas de réponse immédiate, comme un classement nocturne de documents. La mise en cache des invites facture la relecture d'un contexte déjà envoyé à une fraction du prix d'entrée (0,1 fois sur la plupart des modèles), avec une durée de vie de cinq minutes par défaut. Pour un assistant qui renvoie les mêmes consignes et la même documentation à chaque question, l'économie sur l'entrée est massive. Les deux réductions se cumulent.
Ces techniques sont utiles, mais elles viennent après le suivi. Optimiser un cas d'usage dont on ne connaît pas le coût par requête revient à régler un moteur sans compteur. L'ordre raisonnable est d'installer la mesure, d'identifier les cas d'usage qui pèsent le plus, puis d'appliquer ces techniques là où elles rapportent. Nous les avons détaillées dans un article dédié à l'optimisation du coût des modèles de langage par la tokenisation et le traitement par lots.
Pour un dirigeant, ces optimisations sont des interventions ponctuelles à gain durable, donc un investissement à comparer au coût mensuel qu'elles font baisser. Elles sont prioritaires sur le cas d'usage qui pèse la moitié de la facture, pas sur celui qui en représente une part marginale.
Ce que le rapport d'activité IA doit dire du coût
Le suivi des coûts n'a d'effet que s'il est lu par les personnes qui décident. Le rapport d'activité mensuel ou trimestriel d'un système IA, qu'il soit produit en interne ou par le prestataire qui assure la maintenance des systèmes IA, doit consacrer une section au coût, avec un contenu constant d'une édition à l'autre.
Cette section indique le coût total du mois et son évolution, la répartition par cas d'usage, le coût par requête de chaque cas d'usage et son évolution, les dérives détectées avec leur cause et leur correction, les arbitrages pris sur la période, et les migrations de modèle à venir avec leur impact estimé. Elle tient sur une page. Elle s'adresse au dirigeant et à la DSI, pas à l'équipe technique, qui dispose de ses propres tableaux.
Un rapport qui se contente d'un montant total et d'un commentaire du type « conforme aux attentes » ne remplit pas cette fonction. Le dirigeant doit pouvoir répondre en une minute à la question : combien nous coûte chaque cas d'usage IA, est-ce que cela augmente, et pourquoi. Si le rapport ne le permet pas, le suivi n'existe pas, quel que soit le volume de données collecté par ailleurs. Le coût n'est d'ailleurs qu'un des indicateurs à relire après la mise en ligne : notre guide sur ce qu'il faut surveiller après la mise en production d'une IA et notre article sur les coûts cachés de la maintenance d'un RAG complètent cette lecture.
