2026-11-06 · 5 min de lecture

Un budget IA que votre équipe tient vraiment

Pourquoi les plafonds par siège cassent sur les charges d'agents, comment budgéter par charge de travail et la revue hebdomadaire de quinze minutes qui garde le chiffre honnête.

Toute équipe qui adopte Claude Code écrit la même ligne dans son budget : « X $ par développeur et par mois. » Trois mois plus tard, cette ligne est ignorée ou disputée — parce que la dépense d'agent ne se comporte pas comme un coût par siège. Elle se comporte comme un coût par charge de travail. Ce post est le budget qui survit au contact de la façon dont les agents facturent réellement.

Transparence d'emblée : j'opère Teapot Router, une passerelle d'équipe pour GPT et Claude Code avec quotas par clé et consolidation des dépenses au niveau organisation. La méthode ci-dessous vaut pour tout endpoint qui mesure par requête — rien ici ne dépend d'utiliser le nôtre.

Les plafonds par siège cassent en premier

Un plafond uniforme par développeur est le premier budget que tout le monde essaie et le premier qui échoue, pour une raison structurelle : la dépense d'agent varie avec l'affectation, pas avec la personne. Le même développeur peut consommer 5x sa normale pendant une semaine uniquement parce que la tâche a changé — un gros refactor de centaines de tours, ou une base au cache défaillant. Le plafond punit la charge, pas la personne, et les trois modes d'échec standard suivent :

  1. Le plafond étrangle les affectations lourdes — précisément le travail qui justifiait l'achat des outils.
  2. Le plafond ne mord jamais sur les utilisateurs légers — la moyenne ne veut plus rien dire et la finance cesse de croire la ligne entière.
  3. L'exécution atterrit dans des tableurs, avec des semaines de retard, quand l'argent est dépensé et la dispute déjà périmée.

Budgétez la charge, pas le siège

Prenez les trois variables qui décident réellement la dépense d'agent — tours, contexte renvoyé, taux de réussite de cache — et allouez contre elles à l'échelle de l'équipe :

  1. Modélisez le coût mensuel par dev à partir de la forme réelle, pas de moyennes : tours quotidiens × taille de contexte × comportement de cache. Deux semaines de données observées battent tout benchmark.
  2. Allouez par projet ou par classe de tâche, pas par effectif : maintenance routinière et travail d'architecture difficile méritent des voies distinctes — et ce routage est la plus grande économie honnête.
  3. Fixez les plafonds au 80e percentile de la forme observée, pas à la moyenne — un plafond que la charge atteint une semaine normale, personne ne le respecte.

Faites respecter là où la mesure se fait

Un budget imposé par tableur est un vœu. Les requêtes sont déjà mesurées quelque part — modèle, tokens, réussites de cache, coût, par requête — donc le budget devrait habiter au même endroit : quotas par clé qui limitent au lieu de déborder en silence, alertes sur anomalie plutôt que sur chaque ligne, et un consolidé par organisation que la finance rapproche de la facture. Quand ce qui vous facture est aussi ce qui fait respecter le budget, le budget cesse d'être une dispute.

La revue hebdomadaire de quinze minutes

Trois questions, une fois par semaine, gardent le budget vivant : la tendance de taux de réussite de cache est-elle plate ou glissante ? Quelle clé ou projet a le plus bougé, et la charge a-t-elle réellement changé ? Faut-il rééquilibrer le plafond avant que quelqu'un le touche pour une raison légitime ? Ce n'est pas une réunion — c'est un coup d'œil à un registre à trois colonnes, et cela remplace intégralement l'exercice d'incendie trimestriel.

Les budgets échouent quand ce sont des paris imposés par tableur. Ils tiennent quand ils modélisent la charge réelle, s'imposent là où la mesure se fait déjà, et se corrigent chaque semaine en quinze minutes au lieu de chaque trimestre en pompier.

FAQ

Combien budgéter par développeur ?

Il n'y a pas de chiffre universel — modélisez votre forme (tours quotidiens, taille de contexte, taux de réussite ; la calculatrice sur teapotrouter.com/en/claude-code-cost-calculator fait le calcul), observez deux semaines et fixez le plafond au 80e percentile de l'observé.

Que se passe-t-il quand quelqu'un dépasse ?

La clé se limite et une alerte se déclenche — pas de drame, pas de pilori. Un dépassement est une information sur la forme de la charge : l'affectation a changé, le cache s'est dégradé, ou le plafond était un pari. Les trois se corrigent à la revue hebdomadaire.

Nous sommes en abonnements — cela s'applique-t-il quand même ?

Les forfaits sont le bon choix pour certaines formes (le point d'équilibre mérite son propre post), mais ils cachent la donnée par requête — aucune piste d'audit. Si votre finance veut le détail, seul l'usage mesuré se rapproche.

Tous les articles