Mesurer le coût par fonctionnalité
CoûtObservabilitéTutorielProduction2026-03-1010 min
Une facture mensuelle ne dit rien. Étiqueter chaque appel prend une demi-journée et révèle qu'une fonctionnalité minoritaire porte la majorité de la dépense.
Pourquoi une facture globale ne sert à rien
Un total mensuel indique qu'on dépense, jamais ce qu'il faut faire. C'est pourtant la seule information dont disposent la plupart des équipes que je rencontre.
La conversation qui suit une facture élevée est toujours la même. Quelqu'un propose de réduire le contexte, quelqu'un d'autre de changer de modèle, un troisième de limiter l'usage. Chacune de ces propositions peut être bonne ou inutile, et rien ne permet de trancher.
Attribuer la dépense à chaque fonctionnalité transforme cette discussion en décision. Une fonctionnalité qui coûte les deux tiers de la facture pour trois utilisateurs par semaine se traite ; une fonctionnalité massivement utilisée qui coûte peu se laisse tranquille.
La mise en œuvre, en une demi-journée
Ajouter une étiquette à chaque appel dans la couche d'abstraction suffit à tout mesurer. C'est une modification de quelques lignes, à condition que la couche existe.
Chaque appel part avec trois informations : la fonctionnalité concernée, le type de tâche, et l'identifiant de la requête utilisateur. Au retour, on enregistre le nombre de jetons envoyés, produits, et le coût correspondant.
Le stockage n'a pas besoin d'être sophistiqué : une ligne par appel dans une table suffit largement, y compris sur des volumes importants.
Ce dispositif est le même que celui de la journalisation exigée par ailleurs, ce qui permet de traiter les deux besoins d'un coup. C'est un argument utile pour faire accepter le chantier, comme évoqué dans ce qui doit exister avant l'échéance.
Les quatre vues à produire
- Coût par fonctionnalité, trié décroissant. Les trois premières lignes expliquent en général plus de la moitié de la facture.
- Coût par utilisateur, qui révèle les usages intensifs isolés, souvent quelques personnes portant l'essentiel du volume.
- Jetons moyens par requête, suivi dans le temps : c'est l'indicateur qui détecte la reprise de poids du contexte.
- Coût au quantile 95, et non en moyenne, pour repérer les requêtes pathologiques. Voir la réflexion devient un budget.
Ce que la mesure révèle presque toujours
Une fonctionnalité minoritaire en usage porte la majorité de la dépense, et ce n'est jamais celle qu'on soupçonnait. J'ai fait cette mesure sur une dizaine de systèmes, avec le même résultat.
Les coupables habituels sont au nombre de trois. Une fonctionnalité de synthèse qui envoie l'intégralité d'un dossier à chaque appel. Une conversation qui conserve tout son historique et dont le coût croît de façon quadratique. Et un traitement de fond, invisible des utilisateurs, qui tourne plus souvent que prévu.
Ce dernier cas est le plus fréquent et le plus facile à corriger : un traitement programmé toutes les heures alors qu'une fois par jour suffit, ou qui retraite l'ensemble du corpus au lieu des seuls documents modifiés.
Aucun de ces trois problèmes n'est visible sans la mesure, et tous se corrigent en quelques heures une fois identifiés.
Ce qu'il faut faire de la mesure une fois obtenue
Traiter les trois premières lignes et ignorer le reste : c'est la règle qui évite de transformer l'optimisation en projet permanent. Le rendement décroît très vite.
Sur les systèmes que j'ai mesurés, les trois premières lignes représentent entre cinquante et soixante-dix pour cent de la facture. Les traiter demande quelques jours et produit l'essentiel du gain disponible.
Au-delà, chaque optimisation supplémentaire coûte davantage qu'elle ne rapporte, et détourne l'équipe d'un travail plus utile, sur le corpus ou sur le périmètre.
L'ordre d'intervention sur chaque ligne reste celui posé plus haut : réduire le contexte d'abord, mettre en cache ensuite, router en dernier. Il donne le meilleur résultat et il est décrit dans réduire de moitié le contexte envoyé.
L'indicateur à laisser en place après la campagne
Le nombre moyen de jetons envoyés par requête, suivi dans le temps. Sans lui, le contexte regrossit en six mois : chaque incident ajoute une consigne, et personne ne retire jamais rien.
Ce que la mesure permet de dire à une direction
Un coût par fonctionnalité transforme « l'IA coûte cher » en un arbitrage ordinaire, ce qui change complètement la conversation. C'est le bénéfice le moins technique et le plus utile.
Une direction ne peut rien faire d'un total mensuel. Elle peut en revanche décider qu'une fonctionnalité coûtant huit cents euros par mois pour quatre utilisateurs mérite d'être arrêtée, ou au contraire qu'elle en vaut trois mille parce qu'elle évite une erreur coûteuse.
Ce type d'arbitrage se prend en dix minutes quand les chiffres sont posés, et jamais quand ils ne le sont pas.
La mesure a un second effet : elle protège le système. Un service dont personne ne sait ce qu'il apporte est arbitré à la baisse au premier exercice contraint. Un service dont on connaît le coût et l'usage se défend.
Questions fréquentes
- Comment attribuer la dépense à chaque fonctionnalité ?
En étiquetant chaque appel dans la couche d'abstraction avec la fonctionnalité, le type de tâche et l'identifiant de requête, puis en enregistrant jetons envoyés, produits et coût. Une demi-journée.
- Que révèle la mesure le plus souvent ?
Qu'une fonctionnalité minoritaire en usage porte la majorité de la dépense, le plus souvent un traitement de fond programmé trop fréquemment, ou une conversation qui conserve tout son historique.
- Jusqu'où faut-il optimiser ?
Les trois premières lignes du classement, qui représentent cinquante à soixante-dix pour cent de la facture. Au-delà, chaque optimisation coûte davantage qu'elle ne rapporte.
- Quel indicateur conserver après la campagne ?
Le nombre moyen de jetons envoyés par requête, suivi dans le temps. Sans lui, le contexte regrossit en six mois car chaque incident ajoute une consigne que personne ne retire.