Les articles sur les passerelles LLM racontent tous la même moitié de l'histoire : un point d'entrée unique, plus de cent fournisseurs, des clés virtuelles, du suivi de coût. Tout est vrai. Ce qu'on lit rarement, c'est ce qu'il y a de l'autre côté — parce que le jour où vous déployez une passerelle, vous n'ajoutez pas une fonctionnalité, vous ajoutez un service critique à exploiter.
Ce n'est pas un argument contre. Sur des parcs hétérogènes, une passerelle est souvent la bonne réponse, et c'est ce que je déploie chez des clients qui ne sont pas sur AWS. C'est un argument pour poser le calcul avant, parce qu'il existe un seuil sous lequel l'opération est perdante — et ce seuil est plus haut qu'on ne l'imagine.
Cet article prend LiteLLM comme référence, puisque c'est l'implémentation open source la plus déployée. Le raisonnement vaut pour n'importe quelle passerelle.
Ce qu'une passerelle apporte réellement
Commençons par le côté pile, honnêtement. Une passerelle s'intercale entre vos applications et les fournisseurs de modèles, et résout cinq problèmes que la plupart des équipes traitent mal.
- La clé du fournisseur ne circule plus. Elle reste sur la passerelle. Les applications, les agents et les développeurs reçoivent une clé virtuelle, révocable individuellement. Un départ dans l'équipe, c'est une clé désactivée, pas une rotation générale.
- La dépense est attribuée. Chaque clé virtuelle porte son budget, ses limites de débit, sa liste de modèles autorisés et ses métadonnées. Vous savez enfin quelle équipe et quel service consomment quoi.
- Les plafonds sont appliqués avant l'appel, pas constatés sur la facture du mois suivant. Budget par équipe, limites en requêtes et en tokens par minute.
- Tout est journalisé au même endroit, quel que soit le fournisseur en aval. C'est ce qui rend un audit possible sur un parc hétérogène.
- Changer de fournisseur ne touche pas les machines. C'est la propriété que les intégrations natives n'ont pas : la bascule se fait dans la configuration de la passerelle, pas dans les déploiements.
Côté client, l'intégration est triviale. LiteLLM expose notamment un point d'entrée /v1/messages au format Anthropic, ce qui permet de router un agent existant sans rien réécrire — voir l'article sur les agents autonomes en production.
Le côté face : l'inventaire de ce que vous exploitez
Une passerelle n'est pas un binaire qu'on lance et qu'on oublie. La documentation de mise en production de LiteLLM est explicite, et c'est tout à son honneur. Voici ce qu'elle demande.
Une base PostgreSQL, non négociable
Les clés virtuelles, les budgets et les journaux de dépense vivent dans Postgres — c'est-à-dire exactement les fonctionnalités pour lesquelles vous déployez la passerelle. SQLite tient pour une démo sur un portable et pas au-delà : sous requêtes simultanées, les décrémentations de budget entrent en concurrence et vos plafonds deviennent approximatifs. Il faut aussi définir une clé de salage avant d'enregistrer le moindre modèle, faute de quoi les identifiants des fournisseurs ne sont pas chiffrés en base.
Un Redis dès la deuxième instance
Et c'est le piège le plus coûteux de tous. Sans Redis partagé, chaque instance applique les limites dans son coin : deux instances, et une équipe plafonnée à 100 requêtes par minute en obtient 200. Vous croyez avoir des budgets, vous avez des budgets multipliés par votre nombre de répliques. Or la haute disponibilité impose au moins deux instances. Autrement dit, dès que la passerelle devient fiable, Redis cesse d'être optionnel.
Un worker par pod, et de la mémoire
La recommandation est un seul processus par pod, avec une montée en charge horizontale — plusieurs workers dans un même pod rendent la latence imprévisible et faussent l'autoscaling. Comptez de l'ordre d'un cœur et 4 Go de mémoire par worker. Ce n'est pas un sidecar : c'est un service applicatif à part entière, avec ses ressources et ses sondes.
Des redémarrages périodiques
La documentation recommande de fixer un nombre maximal de requêtes avant redémarrage du processus, pour absorber les fuites mémoire sous charge soutenue. C'est un aveu honnête de la part du projet, et une contrainte d'exploitation réelle : votre passerelle doit être conçue pour être redémarrée souvent et sans coupure.
Le réglage qui mord en premier : le délai d'expiration des requêtes est très élevé par défaut. Laissé tel quel, une requête bloquée en amont immobilise une connexion pendant des heures. C'est le genre de valeur par défaut qui ne se voit pas en recette et qui sature la passerelle en production.
Dans le même esprit : les écritures de dépense se font par requête tant qu'on ne les regroupe pas, et au-delà d'environ mille requêtes par seconde elles deviennent le goulot d'étranglement de toute la passerelle. Il existe un tampon de transactions pour éviter les interblocages à ce niveau de charge — ce sont des réglages à connaître avant, pas après.
Le calcul que personne ne pose
Voilà le cœur du sujet, et il tient en une phrase : le coût d'une passerelle est fixe, alors que le poste qu'elle optimise est variable.
Reprenez l'inventaire ci-dessus et traduisez-le en lignes de facture. En haute disponibilité, une passerelle, c'est au minimum :
- deux instances de calcul, environ un cœur et 4 Go chacune ;
- une base PostgreSQL managée, sauvegardée ;
- un Redis managé ;
- un répartiteur de charge, de la supervision, des alertes ;
- et le temps humain de maintenir tout ça à jour.
Chiffrons-le pour de vrai. Voici une passerelle correctement redondée sur AWS en région Paris, aux tarifs à la demande relevés le 22 juillet 2026 dans l'API de tarification d'AWS.
| Composant | Configuration | USD / mois |
|---|---|---|
| Calcul (Fargate) | 2 tâches, 1 vCPU + 4 Go chacune | 101,91 |
| PostgreSQL (RDS) | db.t4g.small, Multi-AZ | 52,56 |
| Redis (ElastiCache) | cache.t4g.micro | 21,17 |
| Répartiteur de charge | ALB + 1 LCU moyenne | 25,45 |
| Total | ≈ 201 | |
Environ 200 USD par mois, soit de l'ordre de 185 € au taux du moment, avant le premier appel à un modèle. Et c'est un plancher : ce total exclut le trafic sortant, le stockage et les sauvegardes de la base, la supervision, et surtout le temps d'ingénierie, qui ne s'arrête pas au déploiement.
En version frugale — base en zone unique, et Valkey plutôt que Redis — on descend autour de 151 USD. À noter au passage, c'est typiquement le genre d'arbitrage qu'un audit de coûts fait remonter : sur la même classe d'instance, Valkey est facturé environ moitié moins cher que Redis chez ElastiCache, pour un protocole compatible.
Le seuil, exprimé en tokens. À 3 USD le million en entrée et 15 USD en sortie, 200 USD de passerelle équivalent à environ 11 millions de tokens par mois (à volumes d'entrée et de sortie égaux). Si votre consommation est loin sous ce seuil, votre dispositif de maîtrise des coûts coûte plus cher que le poste qu'il maîtrise.
C'est exactement le raisonnement d'un audit FinOps : on ne déploie pas un dispositif de pilotage plus cher que le poste piloté. Refaites le calcul avec vos propres tarifs, votre région et votre niveau de disponibilité — l'ordre de grandeur, lui, bouge peu.
La règle de décision
N'en mettez pas si
- • vous n'avez qu'un seul fournisseur de modèles ;
- • une seule équipe consomme, et personne ne refacture ;
- • votre dépense mensuelle est du même ordre que le coût d'exploitation ;
- • vous n'avez pas d'astreinte pour un service critique de plus.
Mettez-en une si
- • plusieurs équipes consomment et il faut refacturer ;
- • vous êtes sur plusieurs fournisseurs ou plusieurs clouds ;
- • vous devez prouver qui a appelé quoi, de façon uniforme ;
- • l'indépendance vis-à-vis d'un fournisseur est un objectif assumé.
Notez que trois des quatre bonnes raisons ne sont pas financières. C'est normal, et c'est même le point important : une passerelle est un outil d'organisation avant d'être un outil d'économie. Vendue comme un moyen de réduire la facture, elle déçoit presque toujours.
Si vous n'êtes pas au-dessus du seuil
La bonne nouvelle, c'est que les propriétés recherchées existent souvent déjà sans service supplémentaire, quand vous n'avez qu'un fournisseur.
Sur AWS, Amazon Bedrock donne l'authentification par rôle IAM plutôt que par clé statique, la traçabilité de chaque appel dans CloudTrail, le suivi de coût par tag dans Cost Explorer et des plafonds via AWS Budgets. Ce sont quatre des cinq propriétés de la section 1, sans aucun composant à exploiter. Il manque la cinquième — changer de fournisseur sans toucher aux machines — et c'est précisément celle qu'on paye avec une passerelle.
Les autres fournisseurs ont leurs équivalents. Le raisonnement est le même : si un seul d'entre eux couvre votre parc, sa gouvernance native est presque toujours le meilleur rapport résultat/exploitation.
Étape intermédiaire souvent suffisante : avant de déployer une passerelle pour obtenir de l'attribution de coût, essayez une clé (ou un rôle) distinct par service et par environnement, avec une convention de nommage et des tags. C'est gratuit, ça se met en place en une journée, et ça résout la question « qui consomme quoi » dans une grande partie des cas. Vous saurez ensuite si le reste justifie une passerelle.
Si vous y allez : les points à ne pas découvrir en production
Une liste courte, tirée des réglages qui ne sont pas ceux par défaut et des erreurs qu'on voit le plus souvent.
- Redis avant la deuxième instance, pas après. Sinon vos limites et vos budgets sont faux d'un facteur égal au nombre de répliques, silencieusement.
- Abaissez le délai d'expiration des requêtes dès le premier déploiement. La valeur par défaut se compte en heures.
- Regroupez les écritures de dépense plutôt que d'écrire à chaque requête, et bornez le nombre de connexions à la base en fonction du nombre d'instances multiplié par le nombre de workers.
- Traitez la passerelle comme un point de panne unique, parce que c'en est un. Si elle tombe, ce n'est pas une application qui perd l'accès aux modèles, c'est toutes. Redondance, sondes, et un plan de contournement écrit.
- Prévoyez le coût de la mise à jour. Les clients évoluent vite ; une passerelle qui ne relaie pas une nouvelle capacité casse la fonctionnalité correspondante côté application, souvent sans message d'erreur clair.
- Chiffrez les identifiants en base avec une clé de salage définie avant d'enregistrer le premier modèle, et sauvegardez cette clé comme le secret critique qu'elle est.
Questions fréquentes
Une passerelle LLM ajoute-t-elle de la latence ?
Oui, mécaniquement : un saut réseau de plus, et le temps de traitement du proxy. En pratique c'est négligeable devant la durée de l'inférence elle-même. Le vrai risque n'est pas la latence moyenne, c'est la disponibilité : sans redondance, la passerelle coupe l'accès aux modèles pour toutes vos applications à la fois.
Peut-on faire tourner LiteLLM sans base de données ?
Pour du simple routage, oui. Dès que vous voulez les clés virtuelles, les budgets ou les journaux de dépense — c'est-à-dire les fonctions qui justifient la passerelle — PostgreSQL devient nécessaire. SQLite convient à une démo locale, pas à la production.
Passerelle ou Bedrock : faut-il choisir ?
Non, ce ne sont pas des concurrents. Bedrock sert les modèles, la passerelle gouverne les accès. Le montage courant en entreprise place la passerelle devant Bedrock, pour uniformiser la gouvernance sur un parc qui comprend aussi d'autres fournisseurs. La vraie question n'est pas « lequel » mais « ai-je besoin de la couche supplémentaire ».
Faut-il l'héberger soi-même ou prendre une offre managée ?
Si le calcul de rentabilité est serré, une offre managée le rend souvent négatif, mais elle supprime la ligne la plus sous-estimée : votre temps. Auto-héberger n'a de sens que si vous avez déjà une plateforme Kubernetes, une astreinte et des habitudes d'exploitation. Sinon, vous ajoutez un service critique à une équipe qui n'en demandait pas.
Comment migrer sans tout casser ?
Par service, pas d'un bloc. Vous basculez une application, vous vérifiez que la journalisation et les plafonds se comportent comme prévu, puis vous passez à la suivante. Côté client, la bascule est en général une variable d'environnement de point d'entrée, donc réversible immédiatement — gardez ce chemin de retour ouvert le temps de la migration.
Est-ce que ça remplace l'observabilité ?
Non. Une passerelle vous donne le coût, le volume et le débit — du comptage. Elle ne vous dit pas si les réponses sont bonnes, si les prompts dérivent, ni pourquoi un agent boucle. Ce sont deux chantiers distincts, et confondre les deux est une déception classique après la mise en place.
Lire aussi
Passerelle LLM : utile chez vous, ou pas ?
Je pose le calcul avec vous : dépense actuelle, nombre d'équipes et de fournisseurs, contraintes de conformité. Puis on déploie la passerelle, ou on utilise la gouvernance native de votre cloud — selon ce que dit le chiffre.
Discutons de votre projetRéponse sous 24h - Premier échange gratuit et sans engagement