Donner un vrai budget IA à ses équipes avec LiteLLM

L'article précédent défendait l'idée que la gouvernance IA par la politique échoue faute de point de passage où une règle pourrait s'appliquer, et que la voie d'entrée consiste à construire d'abord la couche comptable : mesurer, puis restituer, puis gouverner. Cet article construit cette couche. À la fin, chaque appel émis par une personne ou par un script de votre organisation est attribué à une identité nommée et à une équipe, chaque équipe dispose d'un plafond de dépense qui se réinitialise selon un cycle, une borne journalière se place sous la borne mensuelle pour qu'un seul processus emballé ne consomme pas le mois, des alertes se déclenchent avant tout blocage, et la direction financière peut recevoir une ventilation par équipe qui se réconcilie avec une facture fournisseur.

L'outil est LiteLLM, déployé en proxy. Tout ce qui suit est ordonné pour être suivi dans l'ordre sur une seule machine et aboutir à quelque chose que vous pourriez réellement mettre devant une équipe.

Ce que nous construisons

La forme est celle d'un reverse proxy pour l'inférence. Vos applications, vos outils de développement et vos scripts internes cessent de détenir des identifiants fournisseurs et pointent vers un unique point d'entrée interne. Ce point d'entrée parle l'API OpenAI, ce qui compte plus qu'il n'y paraît : presque tous les SDK, frameworks d'agents et intégrations d'éditeur la parlent déjà, donc l'adoption coûte une URL de base et une clé, pas une réécriture.

Derrière ce point d'entrée, le proxy détient les véritables identifiants fournisseurs, décide vers quel amont part une requête, applique les limites attachées à l'appelant, écrit un enregistrement de dépense dans Postgres, et transmet les journaux là où vous les conservez. Le chemin d'une requête est le suivant : l'appelant présente une clé virtuelle, le proxy résout cette clé vers un utilisateur et une équipe, vérifie que le modèle est autorisé et que le budget n'est pas épuisé, transmet au fournisseur, calcule le coût de la réponse à partir de sa table de prix, écrit une ligne de dépense, retourne la réponse.

Postgres n'est pas optionnel pour ce que nous faisons. Sans base de données, le proxy est une commodité de routage ; avec une base, il devient le grand livre, et le grand livre est tout l'enjeu.

Pourquoi LiteLLM

Plusieurs produits existent dans cette catégorie et le résumé honnête est qu'ils diffèrent surtout par le modèle d'hébergement et par les primitives qui sont gratuites.

Les routeurs hébergés comme OpenRouter constituent le chemin le plus rapide vers un accès multi-fournisseurs, mais ils placent un tiers entre vous et vos prompts et ne vous laissent aucun mot à dire sur l'endroit où réside le grand livre, ce qui est rédhibitoire pour quiconque a une obligation de résidence des données. Les outils centrés observabilité comme Langfuse ou Helicone excellent à montrer ce qui s'est passé et ne sont pas, principalement, des points d'application. Les passerelles d'API généralistes peuvent être configurées pour faire ce travail, mais vous modéliserez vous-même les budgets et la tarification par modèle.

LiteLLM est retenu ici parce qu'il est auto-hébergeable, open source, expose une surface compatible OpenAI donc rien en amont ne change, et embarque déjà les primitives dont ce problème a besoin : clés virtuelles, équipes, budgets avec fenêtres de réinitialisation, limites de débit, listes blanches de modèles, marquage des requêtes et grand livre de dépense. Une réserve à vérifier avant de bâtir dessus : une partie des fonctionnalités, dont des pans de la surface SSO et d'administration entreprise, relève d'une licence commerciale. Vérifiez les conditions de licence en vigueur pour les fonctions précises dont vous comptez dépendre, plutôt que de le découvrir pendant le déploiement.

Déployer le proxy

Partez du fichier compose officiel, qui démarre le proxy et sa base ensemble. L'image litellm-database embarque l'outillage Prisma et exécute la migration de schéma au démarrage, ce qui convient à un déploiement mono-nœud.

services:
  litellm:
    image: docker.litellm.ai/berriai/litellm-database:v1.81.9-stable
    ports:
      - "4000:4000"
    environment:
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
      LITELLM_SALT_KEY: ${LITELLM_SALT_KEY}
      DATABASE_URL: postgresql://litellm:${POSTGRES_PASSWORD}@db:5432/litellm
      STORE_MODEL_IN_DB: "True"
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
      GEMINI_API_KEY: ${GEMINI_API_KEY}
    volumes:
      - ./config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml"]
    depends_on:
      db:
        condition: service_healthy
        
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: litellm
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Deux de ces variables méritent plus d'attention qu'elles n'en reçoivent d'ordinaire. LITELLM_MASTER_KEY est l'identifiant d'administration de tout le proxy : elle crée les clés, lit la dépense de tout le monde, et modifie chacune des limites décrites dans cet article. Ce n'est pas une clé applicative et elle ne doit jamais être remise à une équipe. LITELLM_SALT_KEY chiffre les identifiants fournisseurs stockés en base, et elle ne peut plus être changée une fois des modèles ajoutés sans rendre ces identifiants illisibles. Générez les deux depuis une véritable source aléatoire, placez-les dans votre gestionnaire de secrets dès le premier jour, et figez l'image sur un tag de version plutôt que sur latest, pour qu'un redémarrage ne soit jamais une montée de version surprise.

Le fichier de configuration déclare quels modèles existent et sous quels noms internes.

model_list:
  - model_name: chat-default
    litellm_params:
      model: anthropic/claude-haiku-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: chat-frontier
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: chat-cheap
    litellm_params:
      model: gemini/gemini-2.5-flash
      api_key: os.environ/GEMINI_API_KEY

  - model_name: embeddings
    litellm_params:
      model: openai/text-embedding-3-small
      api_key: os.environ/OPENAI_API_KEY

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

Nommez les modèles par rôle, pas par fournisseur. chat-default et chat-frontier sont des contrats internes que vous pourrez repointer vers un autre fournisseur plus tard sans toucher un seul appelant, pour la même raison qu'on place un nom d'hôte devant une base de données. Si vous exposez claude-sonnet-5 comme nom public, vous avez fait fuiter une décision fournisseur dans toutes les applications de l'entreprise, et vous le paierez le jour où vous voudrez en changer.

Démarrez et vérifiez que le service répond :

docker compose up -d
curl http://localhost:4000/health/liveliness

L'identité avant les budgets

La manière la plus courante de rater ce déploiement est de passer directement à la génération des clés. Créez les équipes d'abord, parce que l'équipe est l'endroit où vit l'argent et qu'une clé sans équipe est une dépense que vous ne pourrez consolider vers personne.

curl -X POST 'http://localhost:4000/team/new' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "team_alias": "support",
    "max_budget": 400,
    "budget_duration": "30d",
    "models": ["chat-default", "chat-cheap"]
  }'

Cela retourne un team_id, que portera chaque clé émise pour ce département. L'équipe porte aussi son propre plafond et sa propre liste blanche de modèles, et les deux s'héritent comme une borne extérieure : une clé dans l'équipe peut être plus restreinte, jamais moins. C'est cette structure qui rend la conversation financière possible, parce qu'un responsable de département peut se voir présenter un chiffre qui correspond exactement à un centre de coût qu'il porte déjà.

Émettez maintenant une clé pour une personne.

curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "key_alias": "aminata.support",
    "user_id": "aminata@example.com",
    "team_id": "<team_id obtenu ci-dessus>",
    "models": ["chat-default", "chat-cheap"],
    "max_budget": 40,
    "budget_duration": "30d",
    "rpm_limit": 60
  }'

Une clé par personne. La tentation d'émettre une seule clé par application et de la faire partager par cinq ingénieurs détruira l'attribution que vous construisez, et elle le fera silencieusement : les chiffres continuent d'arriver, ils ne parlent simplement plus de personne. Si plusieurs services ont besoin d'un accès, donnez à chacun sa propre clé avec une identité de compte de service, pour que « le job d'enrichissement nocturne » soit aussi attribuable qu'un humain.

À effectif réel, provisionner les clés à la main cesse de passer à l'échelle et vous voulez que l'identité vienne de votre fournisseur d'identité. LiteLLM prend en charge le SSO et sait projeter des revendications JWT sur des utilisateurs et des équipes, de sorte que l'appartenance à un groupe dans l'IdP devienne l'appartenance à une équipe sur le proxy, et qu'un départ traité dans l'IdP soit une révocation sur le proxy. Les valeurs par défaut pour toute personne arrivant par SSO se posent en configuration :

litellm_settings:
  default_internal_user_params:
    user_role: "internal_user"
    models: ["chat-default", "chat-cheap"]
  default_team_params:
    max_budget: 100
    budget_duration: 30d
    team_member_permissions:
      - "/team/daily/activity"

Cette dernière permission est modeste et mérite d'être posée tôt : elle permet aux membres ordinaires d'une équipe de consulter la consommation de leur propre équipe sans passer par un administrateur. La visibilité est le mécanisme du premier article, et elle ne fonctionne pas si la seule personne qui peut voir les chiffres est l'ingénieur plateforme.

Des budgets qui se réinitialisent, et la borne journalière

Voici la partie qui répond à l'objection que soulève chaque directeur financier : la facturation au token rendrait tout engagement fixe impossible.

Un budget assorti d'une durée est un plafond récurrent. Ce n'est ni un prépaiement ni une prévision, c'est une perte maximale par période, et il se réinitialise tout seul :

curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{ "key_alias": "marketing.batch", "max_budget": 50, "budget_duration": "30d" }'

Cela laisse un trou, et c'est celui qui mord vraiment : rien n'empêche l'allocation mensuelle entière d'être consommée en vingt minutes par une boucle mal configurée un mardi matin. Le mois est protégé. Le mois est aussi terminé. Les fenêtres de budget empilées referment ce trou :

curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "key_alias": "eng.agent-runner",
    "budget_limits": [
      {"budget_duration": "24h", "max_budget": 20},
      {"budget_duration": "30d", "max_budget": 200}
    ]
  }'

Les deux fenêtres sont appliquées. Le travail normal n'approche jamais la borne journalière, donc personne ne remarque son existence ; un agent emballé l'atteint dans l'heure et s'arrête, vous ayant coûté vingt dollars et un après-midi au lieu du trimestre du département. C'est la réponse concrète à « nous ne pouvons pas engager un montant fixe » : vous engagez un maximum, par jour et par mois, et vous le dimensionnez à partir de la mesure plutôt que de l'inquiétude.

Posez ensuite le budget souple, qui est la partie qui garde les humains dans la boucle :

curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{ "key_alias": "eng.agent-runner", "soft_budget": 150, "max_budget": 200, "budget_duration": "30d" }'

Un budget souple déclenche une alerte plutôt qu'un rejet. Branchez-la sur le canal que le responsable d'équipe lit réellement, et mettez une vraie distance entre le souple et le dur pour que l'alerte arrive tant qu'il reste du temps pour décider quelque chose. Une alerte qui se déclenche à quatre-vingt-dix-huit pour cent du plafond n'est pas un avertissement, c'est la notification d'une panne déjà commencée.

Limites de débit, et pourquoi les agents ont besoin de celle en tokens

Les budgets bornent l'argent sur une période. Les limites de débit bornent le rythme, et les deux modes de défaillance sont assez différents pour justifier les deux.

curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{ "key_alias": "eng.agent-runner", "rpm_limit": 120, "tpm_limit": 400000 }'

Pour le trafic conversationnel, une limite de requêtes par minute est le garde-fou naturel : un humain génère peu de requêtes et chacune est petite. Pour le trafic agentique elle est presque inutile, car le cas pathologique n'est pas un nombre élevé de requêtes, c'est un nombre modeste de requêtes traînant chacune un contexte accumulé énorme. Un agent à sa quarantième étape peut envoyer cent mille tokens par appel en ne faisant qu'un appel toutes les quelques secondes, ce qui passe largement sous n'importe quelle limite rpm raisonnable tout en brûlant de l'argent à un rythme qu'aucun chiffre de rpm ne sait exprimer. Plafonnez les tokens par minute pour tout ce qui est automatisé. Plafonnez les requêtes par minute pour tout ce qui a une personne au bout.

Hiérarchiser les modèles

Le plus gros levier de coût unitaire est le choix du modèle qui sert la requête, et l'écart entre le modèle le moins cher qui fait le travail et le modèle frontier se compte en multiples et non en marge. La hiérarchisation est la façon d'exploiter cet écart sans tenir une réunion à ce sujet.

Placez tout le monde par défaut sur un modèle rapide et peu coûteux qui traite correctement la grande majorité des demandes. Accordez le niveau frontier au niveau de l'équipe, aux rôles qui en ont démontrablement besoin. Comme les clés héritent de la liste blanche de l'équipe comme borne extérieure, faire monter quelqu'un d'un niveau est une modification de son appartenance ou de sa clé, pas une négociation :

curl -X POST 'http://localhost:4000/key/update' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{ "key": "sk-...", "models": ["chat-default", "chat-cheap", "chat-frontier"] }'

Faites-en une appartenance de groupe qu'un responsable peut accorder, pas un ticket. Dès l'instant où la montée en niveau passe par une file d'attente, les gens repartent sur leurs comptes personnels et vous perdez le trafic, qui est la seule chose que vous protégiez réellement.

Les fallbacks appartiennent à la même conversation, car ils rendent honnêtes les noms de modèles internes. Si chat-default est indisponible, le proxy peut router vers un équivalent au lieu de retourner une erreur à un utilisateur qui n'a aucune idée de ce qu'est une panne fournisseur :

router_settings:
  fallbacks:
    - chat-default: ["chat-cheap"]
    - chat-frontier: ["chat-default"]

C'est aussi le mécanisme qui transforme une migration de fournisseur en changement de configuration plutôt qu'en projet, ce qui compte beaucoup dans le scénario de souveraineté que reprend l'article suivant.

L'attribution au-delà de la clé

Les clés disent qui a dépensé. Elles ne disent pas pour quoi, et dès qu'on vous demande de facturer un client ou de justifier le coût d'un projet, cette distinction devient toute la question. Les tags portent la seconde dimension.

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $VIRTUAL_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "chat-default",
    "messages": [{"role": "user", "content": "résume ce ticket"}],
    "metadata": {
      "tags": ["project:helpdesk-triage", "customer:acme"]
    }
  }'

Les applications que vous contrôlez peuvent poser les tags directement. Pour tout le reste, promouvez un en-tête en tag de dépense afin que des appelants que vous ne pouvez pas modifier produisent quand même du trafic attribuable :

litellm_settings:
  extra_spend_tag_headers:
    - "x-project-id"
    - "x-customer-id"

La même dépense se découpe désormais par personne, par équipe, par projet et par client final, depuis un seul grand livre. C'est ce qui fait passer la plateforme du statut de contrôle de coût à celui de service que le métier réclame, parce que le coût par client est l'entrée de décisions de tarification qui se prenaient jusque-là au feeling.

Lire l'argent

Le grand livre est interrogeable. La vue agrégée est celle que vous envoyez à un responsable de département :

curl -G "http://localhost:4000/spend/logs" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  --data-urlencode "start_date=2026-08-01" \
  --data-urlencode "end_date=2026-08-31"

Passer summarize=false retourne les transactions individuelles, chacune portant la clé, l'utilisateur, l'équipe et les tags éventuels. Cette vue ligne à ligne est celle dont vous avez besoin pour une question d'audit, pour réconcilier une anomalie, et pour le premier mois du déploiement, où la sortie intéressante n'est pas un total mais une distribution.

Pour le reporting continu, envoyez les événements vers un endroit qui fait correctement des tableaux de bord plutôt que de les construire sur le proxy. LiteLLM émet vers les destinations habituelles via son système de callbacks, dont OpenTelemetry, si bien que la dépense LLM peut atterrir dans le même Grafana que le reste de votre plateforme. C'est l'intégration la moins coûteuse pour la plupart des équipes, parce que le pipeline existe déjà et que le coût devient simplement un signal de plus à côté de la latence et du taux d'erreur.

Les endpoints d'activité journalière sont ceux à exposer aux équipes elles-mêmes. La visibilité en libre-service est ce qui fait advenir la phase d'optimisation sans vous.

Garde-fous, et que journaliser

Dès lors que chaque prompt transite par un même endroit, cet endroit peut les inspecter, et vous devez décider délibérément de ce qu'il fait de ce pouvoir.

Les garde-fous fondés sur Presidio détectent et traitent les données personnelles avant que la requête ne quitte votre infrastructure :

guardrails:
  - guardrail_name: "pii-mask"
    litellm_params:
      guardrail: presidio
      mode: "pre_call"
      presidio_filter_scope: both
      presidio_score_thresholds:
        ALL: 0.7
        CREDIT_CARD: 0.8
      pii_entities_config:
        CREDIT_CARD: "MASK"
        EMAIL_ADDRESS: "MASK"
        IBAN_CODE: "BLOCK"

Le masquage remplace l'entité détectée avant que l'appel ne parte vers l'amont ; le blocage rejette la requête. Utilisez le blocage avec parcimonie et seulement pour les catégories dont la bonne réponse est réellement « jamais », car un garde-fou qui bloque du travail légitime apprend aux gens à contourner le proxy, et la détection est statistique et non exacte. Traitez-la comme une réduction de risque, pas comme une garantie de conformité, et soyez prudent dans la façon de la présenter en interne, parce que « nous masquons les données personnelles » est entendu comme « nous ne pouvons pas fuiter de données personnelles » par tous ceux qui ne sont pas dans la pièce.

La décision de journalisation est la plus lourde de conséquences. Par défaut, les intégrations de logs peuvent enregistrer le contenu des messages, ce qui signifie que votre pile d'observabilité devient une seconde copie de tous les prompts de l'entreprise, y compris ceux contenant des identifiants collés par mégarde. Pour la plupart des organisations, le bon défaut est de journaliser les métadonnées et de laisser le contenu dehors :

litellm_settings:
  turn_off_message_logging: true

Vous perdez la possibilité de déboguer une mauvaise réponse en la lisant, ce qui est un coût réel. Vous évitez de constituer une archive interrogeable de tout ce que vos collaborateurs ont jamais demandé, ce qui est un risque réel et, sous certains régimes, un traitement à part entière. Si vous avez besoin de journaliser le contenu pour un workflow précis, restreignez-le délibérément à ce workflow, avec une durée de conservation et un propriétaire nommé, plutôt que de le laisser actif globalement parce que c'était le défaut.

Le jour deux

Trois choses vous surprendront une fois le dispositif en route, et il vaut mieux les prévoir que les découvrir.

Les chiffres ne correspondront pas à la facture. Le proxy calcule le coût à partir d'une table de prix maintenue dans du logiciel, et elle divergera de ce que le fournisseur facture réellement : préfixes en cache avec remise, offres batch, tarifs entreprise négociés, changement de prix livré un mardi. Les chiffres de la passerelle sont excellents pour la comparaison relative et l'allocation entre équipes, ce qui est l'usage que vous en faites. Ils ne sont pas une vérité comptable. Confiez à quelqu'un la réconciliation mensuelle avec la facture réelle et traitez un écart qui se creuse comme le signal qu'une table de prix ou une hypothèse de routage a vieilli.

Le proxy est désormais un point unique de défaillance et une cible très intéressante. Tout workflow dépendant de l'IA tombe avec lui, il lui faut donc plus d'une réplique, un health check qui veut dire quelque chose, et un budget de latence, puisque vous avez inséré un saut dans chaque appel d'inférence. Il détient aussi chaque identifiant fournisseur et voit chaque prompt, ce qui en fait une cible de plus grande valeur que la plupart des services internes. Son modèle de menace mérite le traitement que vous réserveriez à un fournisseur d'identité, pas celui d'un tableau de bord interne.

Les clés ont besoin d'un cycle de vie. Elles fuitent dans les historiques de shell, les configurations de CI et les portables. Posez une expiration à la création, faites tourner selon un cycle, révoquez au départ, et préférez les clés issues du SSO précisément parce qu'elles héritent d'un cycle de vie que vous opérez déjà. Une clé qui survit à son propriétaire est exactement la défaillance que tout cet exercice devait empêcher.

Récapitulatif

L'ordre compte plus que n'importe quel réglage pris isolément, et il reprend la séquence du premier article. Déployez le proxy avec sa base et figez la version. Créez les équipes avant les clés, et une clé par identité, humaine ou de service. Posez des limites généreuses et mesurez pendant un mois sans rien bloquer. Publiez les chiffres par équipe et laissez le gaspillage évident se corriger sans consigne. Posez ensuite les budgets à partir de ce que vous avez mesuré, avec une borne journalière empilée sous la borne mensuelle, une alerte souple suffisamment sous le plafond dur pour être actionnable, des limites en tokens par minute sur tout ce qui est automatisé, et un niveau de modèle par défaut que la plupart des gens n'ont jamais besoin de quitter.

Ce que vous détenez à ce stade est la couche d'attribution, celle des trois inconnues qui était traitable. L'article suivant s'attaque à la deuxième, l'exposition, dans un cadre où elle cesse d'être une affaire de politique interne : ce qu'une passerelle change et ne change pas quand les prompts qui sortent de vos murs sont des données personnelles et que la loi qui vous interroge est la 2019-014 togolaise.

Sources

• Documentation LiteLLM, Déploiement du proxy : images, variables d'environnement, sémantique de LITELLM_SALT_KEY et figeage de version. docs.litellm.ai/docs/proxy/deploy
• Documentation LiteLLM, Suivi des coûts et journaux de dépense : /spend/logs, métadonnées personnalisées, tags de requête et extra_spend_tag_headers. docs.litellm.ai/docs/proxy/cost_tracking
• Documentation LiteLLM, Utilisateurs, équipes et budgets : /team/new, /key/generate, budget_duration, budget_limits empilés, soft_budget, limites rpm et tpm. docs.litellm.ai/docs/proxy/users
• Documentation LiteLLM, Contrôle d'accès aux modèles et authentification JWT : accès aux modèles par équipe et valeurs par défaut SSO. docs.litellm.ai/docs/proxy/model_access
• Documentation LiteLLM, Garde-fous : masquage PII avec Presidio. docs.litellm.ai/docs/proxy/guardrails/pii_masking_v2