Guides

FinOps de l'IA : suivre le coût de Claude par équipe

Le FinOps a mis de l'ordre dans la dépense cloud en rattachant chaque euro à une équipe et en arbitrant sur des chiffres plutôt que sur l'intuition (FinOps Foundation, FinOps Framework). Sur l'IA, ces réflexes ne marchent plus. Un abonnement Claude se paie au siège, l'API se facture au token sur une ligne séparée. Aucune des deux lignes ne dit qui a consommé quoi. Faute de maille, beaucoup d'équipes reconstituent le coût depuis la facture, une approche qui surestime l'empreinte d'inférence de 10 à 40 fois (arXiv 2606.10660, juin 2026). Pour suivre Claude par équipe, il faut changer d'unité : le token, décliné par personne et par modèle.

Pourquoi les règles FinOps du cloud ne tiennent pas

Le cloud se pilote parce que chaque ressource porte une étiquette : tag de centre de coût, projet, environnement. Un token n'en a pas. Il part d'un poste de développeur, revient en facture agrégée, et rien dans la ligne comptable ne le rattache à une équipe. Deux dépenses différentes se retrouvent sur ce relevé : le siège, forfait mensuel dû qu'on l'utilise ou non, et l'API, comptée au token réel sur un autre compteur. Les additionner sans les distinguer gonfle le total. L'usage individuel, lui, reste invisible : un montant global, jamais le détail par personne pour savoir où part l'argent.

Compter en tokens, puis convertir en euros

Pour relier la dépense à un usage réel, il faut compter en tokens plutôt qu'en euros facturés. On exporte les volumes par modèle depuis la console d'administration, puis on les convertit en euros aux tarifs publics. Le calculateur fait ce calcul, et les trois méthodes de mesure disent d'où sort la donnée. Le chemin inverse, partir du montant facturé pour remonter à l'empreinte, injecte l'erreur de 10 à 40 fois mesurée sur l'inférence (arXiv 2606.10660, juin 2026) : le prix d'un million de tokens change d'un ordre de grandeur selon le modèle, et des remises comme le cache pèsent sur la facture sans lien avec l'énergie. Cette dépense aux tarifs publics sort du Bilan et du calculateur, sans dire encore qui l'a générée.

La maille utile : équipe, personne, modèle

Trois entrées suffisent pour agir sur le coût. L'équipe d'abord, pour rattacher la dépense à un budget et la refacturer en interne comme sur le cloud, puis la personne, pour vérifier qu'un siège payé sert autant qu'il coûte. Le modèle, lui, concentre les plus gros écarts : à volume égal, un usage sur un modèle premium revient à plusieurs fois le même sur un modèle léger. Sans ces axes, on a un total et rien d'autre. Avec, une facture qui déborde se ramène à des questions précises : quelle équipe, qui à l'intérieur, sur quel modèle.

Trois verdicts qui déclenchent une décision

Le tableau de bord examine chaque personne et affiche l'un de trois verdicts. Quand le siège coûte moins que l'usage à l'API, c'est « Forfait rentable » et l'abonnement se justifie. Un forfait qui revient plus cher que l'usage réel bascule en « Siège sous-utilisé », signal d'un abonnement à revoir. Sans forfait, la personne apparaît en « Facturation à l'usage » et son coût se suit au token. Ces verdicts comparent le coût employeur réel, sièges plus API, à l'API-équivalent : le même usage entièrement facturé au compteur. Au lieu d'une intuition, « on paie trop d'abonnements », vous avez des chiffres par personne pour trancher. Le détail des tarifs siège par siège est dans combien coûte Claude en entreprise, et les leviers pour agir sur ces verdicts dans réduire la facture Claude Code.

Un compteur, deux lectures

Le même token s'affiche de deux façons : en euros pour le FinOps, en grammes de CO₂e pour la RSE et les appels d'offres. Exemple avec la recommandation la plus visible du tableau de bord : dès que la part d'Opus pèse assez chez une personne, il chiffre le gain d'un basculement vers Sonnet, en euros et en gCO₂e sur le même écran. Le chiffre est cadré en « jusqu'à », car il suppose que la totalité des tokens Opus passe sur Sonnet, un plafond que vous n'atteindrez pas en pratique : une part d'Opus reste nécessaire. Sur ce point, les outils FinOps classiques s'arrêtent : ils savent sortir l'euro, aucun ne produit un CO₂e par modèle, sourcé et daté, qu'on peut coller dans un mémoire d'appel d'offres. La méthodologie documente comment ce chiffre est construit.

FAQ

Peut-on tagger l'usage de Claude par équipe ?

Pas nativement : un token ne porte pas de tag de centre de coût comme une ressource cloud. La maille se reconstruit en croisant l'outil, la personne et le modèle sur les données d'usage exportées, puis en rattachant chacun à son équipe. Cette reconstruction rend la refacturation interne possible.

« Siège sous-utilisé » veut-il dire qu'il faut couper l'abonnement ?

Pas mécaniquement. Le verdict indique que le forfait revient plus cher que le même usage facturé au token sur la période, selon le tableau de bord. Couper le siège renvoie cette personne à la facturation au token, qui peut coûter davantage certains mois. Le verdict signale le cas à arbitrer, la décision reste chez vous.

D'où viennent les tarifs utilisés pour convertir les tokens ?

Des tarifs publics affichés par Anthropic, relevés par siège (Claude Pro 20 $, Team 25 $ par siège, Max 5x 100 $, Max 20x 200 $ par mois, prix catalogue US) et au token pour l'API. Cette conversion est celle du Bilan et du calculateur ; elle chiffre la dépense, à part des verdicts d'usage.

Sources

Tous les guides →Méthodologie →