Qu'est-ce qu'une passerelle LLM ?

Le point d'entrée unique que chaque application, agent et IDE appelle — et le seul endroit où le trafic modèle est routé, mesuré, sécurisé et audité.

Passerelle LLM · Passerelle IA / Proxy LLM / Routeur LLM

Le terme est employé à la légère : les fournisseurs appellent la même couche passerelle IA, proxy LLM ou routeur LLM. Cette page la définit précisément, la distingue des notions voisines et dit explicitement quand ne pas en déployer.

Qu'est-ce qu'une passerelle LLM ?

Une passerelle LLM est un service placé entre vos applications et les fournisseurs de modèles. Les applications appellent un point d'entrée ; la passerelle transmet chaque requête au modèle configuré, traduit les protocoles, garde les clés des fournisseurs et enregistre l'usage. Elle n'entraîne rien sur votre trafic, ne réécrit pas vos prompts et ne remplace pas le modèle.

  • •C'est une infrastructure, pas un modèle — les modèles restent chez les fournisseurs que vous choisissez.
  • •Un seul point d'entrée sert les applications de chat, les agents de code, les traitements par lots, la voix en temps réel et les appels d'outils MCP.
  • •La bonne ligne de partage : la passerelle possède le chemin de la requête, l'application possède le prompt.

Que fait réellement une passerelle LLM ?

Quatre choses : router chaque requête vers le bon modèle, normaliser les protocoles pour que tout client parle à tout fournisseur, centraliser les clés et le contrôle d'accès, et journaliser chaque appel pour le coût et l'audit. Le cache, les budgets et les contrôles de contenu se construisent par-dessus ces quatre fonctions.

  • •Routage et repli : un modèle par rôle d'agent, une autre voie en cas de 5xx ou de délai dépassé, mise en commun des clés amont.
  • •Traduction de protocoles : quatre familles de protocoles de chat, dans les deux sens, pour que le client garde son SDK.
  • •Gouvernance : groupes de clés, admission par en-tête, quotas par locataire, SSO et SCIM, journaux d'audit au niveau de la requête.
  • •Observabilité : séries de tokens et de coûts par clé, équipe et modèle, à la minute.

Pourquoi les entreprises placent-elles une passerelle devant leurs modèles ?

Parce que l'accès aux modèles cesse d'être l'affaire d'une seule équipe. Dès que plusieurs équipes, fournisseurs et agents appellent des modèles, les questions deviennent des questions d'achat : qui peut utiliser quel modèle, combien cela coûte par service, les données sont-elles sorties du réseau, et combien de temps d'ingénierie coûte un changement de fournisseur. Une passerelle y répond par la configuration, pas par une modification de code.

  • •Imputation des coûts : chaque appel porte une clé et une étiquette, la dépense se répartit par équipe.
  • •Chemin des données : la passerelle tourne dans votre réseau ; les requêtes ne vont qu'aux points d'entrée configurés.
  • •Continuité : les pannes de fournisseur et les changements de modèle sont traités dans la couche de routage.
  • •Achat : l'auto-hébergement avec BYOK garde les clés et le trafic sous vos contrats fournisseurs.

Quand avez-vous réellement besoin d'une passerelle LLM ?

Quand deux de ces conditions sont vraies : plus d'un fournisseur de modèles, plus d'une équipe consommatrice, une exigence de conformité ou de résidence des données, ou une dépense que personne ne sait expliquer. En dessous de cette ligne, appeler directement les API des fournisseurs est plus simple et moins cher — une passerelle est un service de plus à exploiter.

  • •Deux fournisseurs ou plus, pour la capacité, le coût ou la continuité.
  • •Des rapports de coûts par équipe ou par client sont demandés régulièrement.
  • •Les données ne peuvent pas quitter un réseau, une région ou un locataire donné.
  • •Plusieurs agents et IDE partagent aujourd'hui une ou deux clés d'API.

Quand une passerelle est-elle le mauvais choix ?

Quand vous avez une équipe, un fournisseur et une application. Une passerelle ajoute un saut, un déploiement et une astreinte. Si la dépense mensuelle est prévisible et votre conformité simple, appelez directement le fournisseur et réexaminez la question quand le deuxième fournisseur, la deuxième équipe ou la première demande d'audit arrivera.

  • •Un prototype ou un outil interne unique sur un fournisseur n'en a pas besoin.
  • •La gestion des prompts et l'évaluation des modèles sont d'autres produits — une passerelle ne les remplace pas.
  • •Aucune passerelle ne dispense de lire vos contrats fournisseurs.

En quoi une passerelle diffère-t-elle d'un service relais ou des SDK fournisseurs ?

Un relais transmet le trafic à un fournisseur pour vous, garde souvent votre clé et prélève des frais. Une passerelle que vous exploitez garde les clés et le trafic dans votre réseau et ajoute routage, mesure et politiques. Appeler directement les SDK évite cet intermédiaire mais laisse la logique de reprise, de protocole et de mesure dans chaque application.

  • •Un relais peut suffire pour un prototype ; le prix est que prompts et clés quittent votre réseau.
  • •Le SDK seul est le moins cher jusqu'au deuxième fournisseur — chaque application a alors besoin du même code de collage.
  • •Sur les trois, seule la passerelle peut dire qui a dépensé quoi.
CritèrePasserelle auto-hébergéeRelais / agrégateurSDK fournisseurs seuls
Lieu d'exécutionVotre VPC ou votre centre de donnéesLe cloud du fournisseurDans chaque application
Qui garde les clésVotre coffre de secrets ; mémoire de la passerelle à l'exécutionLe fournisseur du relaisChaque application
Couverture des modèlesTout fournisseur configuréLe catalogue du fournisseurUn fournisseur par SDK
Routage et repliPar rôle, par clé, entre fournisseursLimité au catalogueÉcrit par vous
Rapports de coûtsPar clé, groupe et modèle, depuis votre registreTableau de bord du fournisseurCe que vous construisez
Surface d'auditJournaux par requête que vous possédezJournaux du fournisseurDispersés entre applications

La passerelle doit-elle être auto-hébergée ou en SaaS ?

Auto-hébergée quand les clés, les prompts ou les journaux ne peuvent pas quitter votre réseau, ou quand les achats refusent un sous-traitant de plus. Le SaaS gagne quand vous n'avez pas d'équipe plateforme et voulez zéro exploitation. La question décisive n'est pas la mode : c'est qui peut lire votre trafic.

  • •L'auto-hébergement coûte des conteneurs, des mises à jour et un runbook ; le SaaS coûte un abonnement et une revue de sous-traitance.
  • •L'hybride existe : plan de données auto-hébergé et plan de contrôle chez le fournisseur — les prompts restent dedans, les métadonnées peut-être pas.
  • •Demandez le schéma de flux de données, pas la page marketing.
CritèreAuto-hébergéSaaS
Chemin des donnéesReste dans votre réseauTraverse le fournisseur
Garde des clésBYOK, seulement en mémoire de la passerelleGérées ou relayées par le fournisseur
Coût d'exploitationVous gérez conteneurs et mises à jourLe fournisseur l'exploite
Première requêteUn fichier ComposeUne inscription
Surface de conformitéVotre DPA, vos sous-traitantsDPA et sous-traitants du fournisseur
Domaine de panneVotre infrastructureLa page de statut du fournisseur

Comment la choisir ?

Notez la présélection sur cinq points : où elle tourne, sur quoi la facture est ancrée, quels protocoles et SDK elle parle nativement, à quel point elle gouverne clés et locataires, et si le fournisseur possédera encore le produit l'an prochain. Vérifiez ensuite ce qu'aucune matrice ne montre : pouvez-vous reproduire aujourd'hui un rapport de coûts vieux d'un mois ?

  • •Déploiement : auto-hébergé, SaaS ou hybride — et si le plan de contrôle appelle l'extérieur.
  • •Ancrage de la facturation : par instance, par siège, par token ou en pourcentage de la dépense.
  • •Protocoles : OpenAI, Anthropic, Gemini et DashScope dans les deux sens, avec un vrai streaming et une parité des appels d'outils.
  • •Gouvernance : groupes de clés, ACL par en-tête, budgets, SSO et SCIM, export d'audit.
  • •Reproductibilité : mêmes entrées, mêmes chiffres, des mois plus tard.

FAQ passerelle LLM

Pour aller plus loin