Comment fonctionne une passerelle LLM ? Guide pratique pour les équipes d’ingénierie

Une passerelle LLM se place entre vos applications et les fournisseurs de modèles que vous y connectez, ce qui vous offre un point unique pour gérer les identifiants et suivre l’utilisation.

« En ce moment, c’est le b****l total », écrivait un ingénieur sur Reddit, dans r/LLMDevs, en septembre 2026.

« Chacun a son propre jeu de clés pour Claude, OpenAI, AWS Bedrock et tous les autres fournisseurs d’inférence que nous utilisons. »

L’article de BigGo consacré à llm-proxy-tk, une passerelle FastAPI légère, compare ce dispositif à la transformation des LLM en « eau du robinet d’entreprise », la passerelle jouant le rôle de vanne principale de l’immeuble.

Mais avant d’accorder autant de confiance à la tuyauterie, voyons ce que vous installez.

Qu’est-ce qu’une passerelle LLM ?

Une passerelle LLM est un proxy inverse pour les appels de modèles. Vos applications envoient leurs requêtes à la passerelle plutôt que directement à OpenAI, Anthropic, Google ou à tout autre fournisseur de LLM que vous utilisez. La passerelle transmet ces requêtes en appliquant vos règles au passage.

Chaque fournisseur de LLM possède sa propre API, avec son propre format de requête, sa propre authentification et sa propre façon de renvoyer les erreurs. Chacun a aussi ses propres limites de débit et modes de défaillance. Or, sans couche commune devant eux, chaque application qui appelle un fournisseur fait tout elle-même, et le fait un peu différemment.

L’analogie de l’eau du robinet a ses limites, mais elle permet d’aller jusque-là : les fournisseurs ne sont raccordés qu’une seule fois, au niveau de la passerelle. Ensuite, chaque application dispose de son propre branchement avec compteur, ce qui vous permet de voir qui consomme quoi et de couper n’importe quelle conduite sans toucher aux autres.

Passerelles LLM, IA, MCP et API : quelle différence ?

Comment fonctionne une passerelle LLM ?

Suivons le trajet aller-retour d’une requête entre votre application et le modèle.

1. La requête arrive à la passerelle : Votre application envoie une requête de chat d’apparence normale, souvent dans un format compatible OpenAI, au point de terminaison de la passerelle. Du point de vue de l’application, c’est l’adresse qu’elle appelle pour joindre le modèle.
2. La passerelle vérifie qui fait la demande et ce qu’il est autorisé à faire : Avant de transmettre la requête, elle valide les identifiants. Il s’agit souvent d’une clé virtuelle attribuée à une équipe ou à un produit. Si vous avez mis en place des garde-fous en entrée, les prompts peuvent aussi être analysés afin de détecter des données sensibles ou des tentatives de contournement des instructions du modèle.
3. La passerelle vérifie si elle dispose déjà de la réponse : Si la mise en cache est activée, une requête correspondante éligible peut recevoir une réponse enregistrée, sans nouvel appel au fournisseur. Certaines passerelles proposent aussi une mise en cache sémantique, qui recherche des requêtes jugées suffisamment similaires plutôt qu’identiques. Cela peut convenir à un trafic de type FAQ.
4. La passerelle choisit la destination de la requête : La requête peut désigner un modèle précis ou un alias. La passerelle recherche la route correspondante dans votre configuration. Vous pouvez aussi configurer une route de secours. Si le fournisseur A ne répond pas à temps, la passerelle peut essayer le fournisseur B.
5. La passerelle prépare l’appel et renvoie la réponse : La passerelle convertit votre requête au format du fournisseur choisi et authentifie l’appel sortant. Dès réception de la réponse, celle-ci est convertie au format requis par votre application.
6. La passerelle enregistre ce qui s’est passé : Lorsque la journalisation est activée, la passerelle enregistre des informations telles que l’auteur de l’appel, le modèle qui l’a traité, le nombre de tokens, la latence et le coût. C’est précisément le journal dont l’ingénieur de Reddit cité en introduction ne disposait pas.

Les 4 points à connaître avant de mettre une passerelle en production

Tout ce qui est décrit dans la section précédente est possible parce que la passerelle voit chaque requête qui transite par elle. C’est l’argument de vente. Mais c’est aussi une description de la surface d’attaque et de la dépendance vis-à-vis de l’éditeur que vous devez anticiper.

La passerelle est désormais l’élément le plus précieux de votre stack IA

La passerelle centralise les accès. Elle place donc aussi de nombreux identifiants à la portée d’un seul service. L’équipe de sécurité de Microsoft répertorie ce qu’un déploiement LiteLLM peut détenir ou récupérer : les clés d’API des fournisseurs, sa propre clé principale, les enregistrements de clés virtuelles, les chaînes de connexion aux bases de données, les paramètres de routage et les politiques des locataires.

En octobre 2026, Check Point Research a divulgué deux vulnérabilités à haut risque dans LiteLLM :

• La CVE-2026-35029 permettait à des utilisateurs authentifiés, y compris ceux disposant d’un accès en lecture seule, d’accéder à des fonctions d’administration et de prendre le contrôle de l’instance.
• La CVE-2026-59823 permettait à des utilisateurs de rediriger des requêtes vers un serveur qu’ils contrôlaient et d’intercepter les clés des fournisseurs.

Toutes deux ont été corrigées dans la version 1.83.9. Une application qui utilise la passerelle ne devrait pas pouvoir en modifier les paramètres.

Vos garde-fous ont besoin d’une politique en cas de défaillance

Une étude publiée le 4 octobre 2026 par Pillar Security recense les intégrations de garde-fous tiers dans les principales passerelles, notamment LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management et Apigee. (Pillar vend des garde-fous ; gardez-le à l’esprit en lisant ses recommandations.)

Un hook est un point du parcours de la requête, généralement avant que le prompt ne parte vers le modèle ou après le retour de la réponse, où la passerelle peut transmettre le contenu à un scanner externe pour obtenir un verdict. Une vérification bloquante attend ce verdict avant de laisser passer le trafic. La documentation de Portkey les appelle before_request_hooks et after_request_hooks ; TrueFoundry en utilise quatre, en ajoutant des vérifications avant et après les appels d’outils MCP.

Deux points sont alors à vérifier :

• Que se passe-t-il si le scanner lui-même tombe en panne ? Si vous bloquez la requête, vous arrêtez le trafic non vérifié, mais vous risquez d’interrompre votre application. Si vous la laissez passer, votre application peut continuer sans cette vérification. Le journal des défaillances vous indique après coup que la vérification n’a pas eu lieu, ce qui est utile, mais ne revient pas à l’avoir effectuée.
• Pouvez-vous remplacer le scanner ? Si un autre fournisseur n’est pas pris en charge, vous devrez peut-être modifier votre application ou passer par un autre proxy pour vous connecter.

Les hooks MCP de TrueFoundry étendent la portée de la passerelle des requêtes de modèle aux appels d’outils. Mais elle ne peut inspecter que le trafic qui transite par elle. Un agent de codage qui exécute une commande sur la machine d’un développeur peut échapper à son champ de vision.

Numbat, l’outil open source de Perplexity, intervient de ce côté-là. Numbat se connecte aux agents pris en charge via des hooks locaux et peut inspecter les actions prévues, comme des commandes shell ou des écritures de fichiers, avant leur exécution. La fonction de blocage est facultative et désactivée par défaut. La passerelle voit le trafic de modèle qui transite par elle. Numbat apporte de la visibilité sur ce que l’agent fait de la réponse.

Vous devez savoir où s’arrête le contrôle de la passerelle

Forkast News distingue trois familles de solutions qui abordent la passerelle sous des angles différents :

• Passerelles centrées sur les LLM : LiteLLM et Portkey ont commencé par les appels de modèles : traduction entre fournisseurs, routage des requêtes et suivi des tokens. Elles ajoutent désormais des contrôles pour les appels d’outils.
• Plateformes de gestion d’API : Kong, Apigee de Google et Azure API Management ont commencé par l’authentification, les autorisations et la gestion du trafic, puis ont ajouté la prise en charge des modèles et de règles propres à l’IA.
• Infrastructure native pour les agents : agentgateway, par exemple, a été conçu autour de la communication des agents avec les modèles, les outils et d’autres agents, notamment via MCP et A2A.

La question qui permet de trancher, c’est ce que vous routez :

• Uniquement des appels de modèles ? Une passerelle centrée sur les LLM est un bon point de départ.
• Des appels de modèles au sein d’une entreprise qui regorge déjà de règles d’API ? Commencez par la plateforme dont vous disposez.
• Des agents qui appellent des outils qui appellent des modèles ? Vérifiez que ces connexions sont également couvertes.

Vous introduisez un point de défaillance commun

Imaginons que votre chatbot d’assistance utilise OpenAI et votre outil de recherche Anthropic, et que tous deux se connectent via la même passerelle. Si cette passerelle cesse de fonctionner, les deux outils perdent l’accès à leurs modèles, même si OpenAI et Anthropic fonctionnent normalement.

Ce n’est pas une hypothèse d’école. Chez Cloudflare, le taux d’erreur de l’AI Gateway a culminé à 97 % lors de la panne du 12 juin 2025. La passerelle dépendait du service de stockage Workers KV de Cloudflare pour ses paramètres, et ce service était défaillant.

Si vous exploitez vous-même la passerelle, gardez une autre instance en service, capable de prendre le relais en cas de défaillance. Si votre passerelle est hébergée par un tiers, demandez-lui comment il assure sa disponibilité en cas de panne et ce qu’il advient de vos requêtes pendant le rétablissement.

Les fonctionnalités clés à rechercher dans une passerelle LLM

Vous allez confier à la passerelle les identifiants de tout le monde : soyez donc exigeant sur ce qu’elle vous apporte en retour.

• Une seule API devant plusieurs fournisseurs : Votre code utilise un seul format, souvent compatible OpenAI, et la passerelle se charge de la traduction. Les fournisseurs de LLM font aussi un pas dans cette direction. Par exemple, l’Agent API de Perplexity prend en charge l’interface Responses API d’OpenAI, ce qui permet aux équipes de réutiliser leurs bibliothèques clientes OpenAI existantes.
• Des clés virtuelles assorties de règles : Chaque équipe ou produit reçoit sa propre clé, avec des règles qui encadrent les modèles autorisés, les limites de requêtes et les dépenses.
• Routage et repli : La passerelle envoie les requêtes aux modèles en fonction de vos paramètres, qui peuvent privilégier le coût, la vitesse ou un fournisseur particulier. Si un appel échoue, elle peut en essayer un autre. L’Agent API de Perplexity vous permet d’indiquer jusqu’à cinq modèles, y compris de fournisseurs différents, dans l’ordre de votre choix.
• Mise en cache : Une réponse enregistrée peut vous épargner un nouvel appel au fournisseur. Certaines passerelles reconnaissent les requêtes identiques ; d’autres peuvent aussi reconnaître des requêtes de sens similaire. Vérifiez si les réponses en cache peuvent être cloisonnées par utilisateur ou par équipe, et si vous pouvez désactiver la mise en cache pour les réponses personnalisées ou dont la validité dépend du moment.
• Streaming et erreurs cohérentes : Les réponses arrivent au fur et à mesure de leur génération, et les erreurs des fournisseurs sont converties dans un format que votre application peut gérer. Vérifiez ce qui se passe lorsque vous ajoutez des garde-fous d’IA.
• Journalisation et attribution des coûts : La passerelle enregistre l’auteur de l’appel, le modèle qui l’a traité, le nombre de tokens utilisés, la durée de traitement et le coût estimé. Vérifiez si les journaux incluent les prompts et les réponses, et combien de temps ils sont conservés.
• Hooks de garde-fous : Il s’agit de points du parcours de la requête où la passerelle peut envoyer le contenu à un scanner externe pour obtenir un verdict. Ils se situent généralement avant une requête au modèle ou après sa réponse. Vérifiez si les requêtes sont bloquées ou poursuivies en cas de défaillance du scanner, et si vous pouvez brancher un autre scanner.
• Une interface d’administration que vous pouvez verrouiller : La passerelle gère l’accès aux identifiants des fournisseurs et les règles que tout le monde utilise. Vérifiez que vous pouvez restreindre l’accès administrateur indépendamment du trafic applicatif et que les utilisateurs en lecture seule ne peuvent pas modifier les paramètres. La vanne principale a besoin d’un cadenas.

Quels outils utiliser pour créer votre passerelle LLM ?

Les listes de fonctionnalités se recoupent d’un acteur à l’autre. Dans un fil Reddit consacré à l’accès interne aux modèles, l’auteur posait la question suivante : quelle passerelle n’exigera pas un ingénieur dédié ?

C’est selon nous la bonne question, et elle appelle quatre réponses, selon la part du travail que vous êtes prêt à assumer.

La développer vous-même

Une passerelle minimale assure une courte liste de tâches : accepter les requêtes, vérifier la clé de l’appelant, ajouter l’identifiant du fournisseur, transmettre l’appel et journaliser le résultat. Mais la prise en charge des différents formats des fournisseurs demande du travail supplémentaire. Tout comme le maintien en service de l’ensemble.

Si vous utilisez déjà Envoy, son filtre de traitement externe vous permet de connecter un service qui inspecte et modifie les requêtes et les réponses. Il vous reste toutefois à développer et à exploiter ce service.

Dans un fil r/LLMDevs consacré à la question de savoir si une passerelle réduit les coûts, u/QuanTradin a expliqué que journaliser les tokens et un indicateur de succès du cache pour chaque appel lui avait permis de repérer deux tâches qui payaient le plein tarif pour des prompts identiques.

« … corriger ça nous a rapporté plus que ne l’aurait fait n’importe quelle couche de routage. »

Il s’agit d’un témoignage, et d’un bon point de départ. Identifiez d’abord ce pour quoi vous payez, avant de concevoir des moyens sophistiqués de router ce trafic.

Auto-héberger une passerelle open source

LiteLLM est un choix courant dans ce cas : compatible OpenAI, il prend en charge un large éventail de fournisseurs et bénéficie d’une vaste communauté. Bifrost est une alternative conçue pour minimiser la surcharge par requête. Helicone mérite le détour si l’observabilité arrive en tête de vos priorités.

Comme tout produit, LiteLLM a ses limites pour certaines équipes. Dans un fil r/aiagents sur les alternatives au développement en interne, u/Own_Bar_920 a indiqué que LiteLLM gérait bien le routage, mais ne répondait pas à ses besoins en matière de versionnage des prompts entre équipes et d’évaluations continues lors des changements de modèle, ce qui l’a poussé vers un outil distinct.

Ces besoins dépassent le routage de base d’une passerelle, et c’est bien là le propos : si le routage est le besoin principal, LiteLLM a tenu la route pour eux.

Vous bénéficiez d’une liste de fonctionnalités prête à l’emploi, certaines dépendant de l’édition, et vous conservez la passerelle au sein de votre réseau. Mais l’application des correctifs vous incombe aussi, comme l’ont illustré les divulgations de Check Point évoquées plus haut, tout comme la disponibilité de la passerelle, comme l’a montré la section sur le point de défaillance unique.

Mais prévoyez quelqu’un qui en assume la responsabilité. Dans un fil r/LLMDevs sur les passerelles d’accès interne, l’une des inquiétudes portait sur la maintenance. u/Informal-Writer9685 cherchait une solution qui « ne nécessite pas d’ingénieur dédié à sa maintenance » et se demandait si l’instabilité des mises à niveau signalée pour LiteLLM posait un vrai problème à son échelle ou ne concernait que la production.

Utiliser une passerelle gérée

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter et la passerelle hébergée de Portkey exploitent le service pour vous. Pour une application compatible, faire passer la première requête peut se limiter à changer une URL et à fournir une clé d’API.

La contrepartie, c’est que chaque prompt transite désormais par un tiers avant d’atteindre le fournisseur. Cela fait un sous-traitant de données de plus dans votre documentation de conformité, et une panne de la passerelle devient un incident chez un prestataire : ce n’est pas à vous de le résoudre.

Par exemple, les 17 et 19 février 2026, OpenRouter a subi des pannes de 38 et 35 minutes respectivement, à la suite de la défaillance d’une dépendance de mise en cache. Certains clients ont reçu des erreurs « User not found » et ont passé du temps à déboguer des clés d’API parfaitement valides. Le problème venait de l’infrastructure de la passerelle.

Mais il faut lui reconnaître ce mérite : OpenRouter a publié un post-mortem détaillé et ajouté des protections pour éviter qu’une défaillance du cache ne submerge sa base de données. Une passerelle gérée comme OpenRouter peut simplifier l’accès, mais comme le souligne u/QuanTradin sur r/LLMDevs, regrouper les factures ne réduit pas automatiquement les dépenses.

Étendre la passerelle API dont vous disposez déjà

Si Kong, Apigee ou Azure API Management sert déjà de frontal à vos services, chacun propose des fonctionnalités propres à l’IA : Kong AI Gateway, les politiques de passerelle IA d’Apigee et la passerelle IA d’Azure API Management. Vous pouvez vous appuyer sur l’authentification, les règles réseau et les procédures d’exploitation existantes, et ajouter des contrôles de modèles au moyen de plugins ou de politiques.

Dans une grande entreprise, cela peut être la voie qui suscite le moins de résistance organisationnelle. Les fonctionnalités d’IA y sont plus récentes que celles des passerelles autonomes. Veillez à tester la limitation de débit basée sur les tokens et le streaming avec l’ensemble des plugins ou politiques que vous prévoyez d’utiliser.

Alors, installez sans hésiter la vanne principale, cette passerelle toute-puissante. L’ingénieur cité en introduction n’a cependant pas tort : l’accès d’une entreprise aux modèles ne devrait pas dépendre de la personne qui se trouve avoir la bonne clé dans un tiroir.

Une passerelle règle ce problème en plaçant ces clés sous contrôle centralisé, ce qui rend d’autant plus risqué le fait de laisser le tiroir ouvert. Encore faut-il savoir à qui appartient le tiroir.

FAQ sur les passerelles LLM

La passerelle LLM est-elle gratuite ?

S’il s’agit de la catégorie de produits, certaines passerelles LLM proposent des versions gratuites.

Les passerelles LLM vont des logiciels open source gratuits aux forfaits payants à partir d’environ 50 $ par mois, avec une tarification sur mesure pour les déploiements en entreprise. Certaines facturent plutôt un pourcentage : par exemple, le forfait Standard d’OpenRouter ajoute 5,5 % aux achats de crédits.

Quelle est la meilleure passerelle LLM ?

Quelle part du travail êtes-vous prêt à assumer ?

• Penchez-vous sur Bifrost ou Helicone si vous souhaitez héberger vous-même la solution et maîtriser sa configuration.
• Une option gérée comme OpenRouter ou Vercel AI Gateway convient aux équipes qui préfèrent confier l’exploitation du service à quelqu’un d’autre.
• Si vous utilisez déjà Kong ou Azure API Management, examinez d’abord leurs capacités en matière d’IA.

Testez les solutions présélectionnées avec vos propres requêtes, notamment pour voir comment elles réagissent en cas de défaillance d’un fournisseur.

AWS propose-t-il une passerelle LLM ?

Oui. Amazon Bedrock AgentCore Gateway prend en charge les appels aux modèles via ce qu’AWS appelle des « cibles d’inférence ». Celles-ci permettent aux applications d’utiliser un point de terminaison unique pour accéder à des fournisseurs comme Amazon Bedrock, OpenAI et Anthropic, la passerelle se chargeant des identifiants des fournisseurs et du routage.