Perplexity détaille les mécanismes des passerelles LLM et les risques en production

Perplexity a publié le 27 octobre 2026 un guide pratique sur les passerelles LLM, qui explique aux équipes d’ingénierie comment cette couche intermédiaire achemine, authentifie et met en cache les appels aux modèles, ainsi que la façon dont elle les consigne, et recense les risques de sécurité et de fiabilité liés à la concentration des identifiants des fournisseurs dans un même service.

Définition et typologie des passerelles

Le guide définit une passerelle LLM comme un proxy inverse pour les appels aux modèles : les applications envoient leurs requêtes à la passerelle plutôt que directement à des fournisseurs tels qu’OpenAI, Anthropic ou Google, et la passerelle les transmet en appliquant les règles de l’opérateur. Il présente cette catégorie comme une réponse à la prolifération des solutions, en s’appuyant d’abord sur une publication de septembre 2026 sur le subreddit r/LLMDevs de Reddit, où un ingénieur décrivait un lieu de travail où chacun possédait ses propres clés pour Claude, OpenAI, AWS Bedrock et d’autres fournisseurs d’inférence.

Le tableau comparatif du guide distingue quatre types de passerelles. Une passerelle d’API se place devant les services d’arrière-plan et vérifie si un client est authentifié et respecte sa limite de débit. Une passerelle LLM se place devant les fournisseurs de modèles et détermine quel modèle reçoit une requête, qui en assume le coût et si la réponse est bien revenue. Une passerelle MCP détermine si un agent peut appeler un outil donné avec des arguments donnés. Le guide emploie l’expression « passerelle d’IA » pour désigner les produits de fournisseurs qui regroupent certaines de ces fonctions.

Le cycle de vie d’une requête en six étapes

Le guide explique le fonctionnement en suivant une requête de l’application au modèle, puis en sens inverse. Tout d’abord, l’application envoie une requête de conversation au point de terminaison de la passerelle, souvent dans un format compatible avec OpenAI. La passerelle valide les identifiants, souvent une clé virtuelle attribuée à une équipe ou à un produit, et, si des garde-fous d’entrée sont configurés, peut analyser les invites pour y détecter des données sensibles ou des tentatives de contournement des instructions du modèle. Si la mise en cache est activée, une requête admissible correspondant à une réponse enregistrée peut recevoir cette réponse, et certaines passerelles proposent une mise en cache sémantique qui associe les requêtes jugées similaires plutôt qu’identiques. La passerelle recherche ensuite dans sa configuration la route correspondante et peut basculer vers un fournisseur de secours si le premier ne répond pas dans les délais. Elle convertit la requête au format du fournisseur choisi, authentifie l’appel sortant, puis convertit la réponse pour l’application. Lorsque la journalisation est activée, elle consigne l’auteur de l’appel, le modèle utilisé, le nombre de jetons, la latence et le coût.

Risques liés à la sécurité et à la fiabilité

Le principal avertissement du guide est que la passerelle concentre les identifiants. L’équipe de sécurité de Microsoft a énuméré les éléments qu’un déploiement de LiteLLM peut détenir ou récupérer : les clés d’API des fournisseurs, la clé principale de LiteLLM, les enregistrements de clés virtuelles, les chaînes de connexion à la base de données, la configuration du routage et les données de politique des locataires. Dans cette publication du 26 août 2026, Microsoft a décrit une compromission observée d’une passerelle LiteLLM, au cours de laquelle des attaquants ont dérobé des identifiants dans l’environnement d’exécution de la passerelle.

Le 13 octobre 2026, Check Point Research a révélé deux vulnérabilités à haut risque dans LiteLLM : CVE-2026-35029, une faille de contrôle d’accès qui 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 la passerelle ; et CVE-2026-59823, une faille de falsification de requête côté serveur qui permettait aux utilisateurs de rediriger les requêtes de la passerelle vers un serveur contrôlé par un attaquant et d’intercepter les clés d’API des fournisseurs d’IA. Les deux failles sont corrigées dans la version 1.83.9 de LiteLLM. Check Point a indiqué que LiteLLM enregistrait 97 millions de téléchargements par mois et plus de 59 000 étoiles sur GitHub, et a précisé que sa divulgation coordonnée auprès de LiteLLM avait débuté en octobre 2025.

Le guide recommande également aux équipes de définir une politique de gestion des défaillances pour les garde-fous. Il décrit les hooks comme des points du parcours d’une requête où la passerelle transmet le contenu à un analyseur externe afin d’obtenir un verdict. Il précise que la documentation de Portkey mentionne before_request_hooks et after_request_hooks, et que TrueFoundry exécute quatre hooks en ajoutant des contrôles avant et après les appels aux outils MCP.

Concernant la fiabilité, le guide cite des pannes documentées. Le récit de Cloudflare sur sa panne du 12 juin 2025 indique que le taux d’erreur d’AI Gateway a atteint un pic de 97 % des requêtes, car AI Gateway dépend de Workers KV pour les configurations client et internes ; la panne générale a duré 2 heures et 28 minutes. Le rapport d’analyse après incident d’OpenRouter sur ses pannes des 17 et 19 février 2026 indique que les incidents ont duré respectivement 38 et 35 minutes après la défaillance d’une dépendance tierce de mise en cache, qu’ils ont entraîné des erreurs 401 « Utilisateur introuvable » et qu’ils ont donné lieu à des mesures correctives, notamment l’ajout de coupe-circuits et le renvoi d’erreurs 503 au lieu d’erreurs 401 lorsque des problèmes d’infrastructure empêchent les vérifications d’autorisation.

Options de déploiement, tarifs et spécificités des fournisseurs

Le guide présente quatre options de déploiement. Les équipes peuvent développer une passerelle minimale en interne — qui accepte les requêtes, vérifie la clé de l’appelant, ajoute l’identifiant du fournisseur, transmet l’appel et consigne le résultat — ou auto-héberger une passerelle open source, avec LiteLLM, Bifrost et Helicone parmi les solutions citées. Les passerelles gérées mentionnées sont Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter et la passerelle hébergée de Portkey. Une quatrième option consiste à étendre une passerelle d’API déjà utilisée par l’entreprise ; le guide cite Kong AI Gateway, les politiques de passerelle d’IA d’Apigee et la passerelle d’IA d’Azure API Management.

Concernant les coûts, le guide indique que les passerelles LLM vont des logiciels libres gratuits aux offres payantes à partir d’environ 50 $ par mois, avec une tarification entreprise personnalisée. Certaines facturent plutôt un pourcentage : l’offre Standard d’OpenRouter ajoute 5,5 % aux achats de crédits.

Le guide se termine par des réponses propres à chaque fournisseur. Il indique qu’Amazon Bedrock AgentCore Gateway prend en charge les appels aux modèles via ce qu’AWS appelle des « cibles d’inférence », permettant aux applications d’utiliser un seul point de terminaison pour accéder à des fournisseurs comme Amazon Bedrock, OpenAI et Anthropic. Il précise que 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, et que l’Agent API permet aux utilisateurs de répertorier jusqu’à cinq modèles, y compris des modèles de différents fournisseurs, dans l’ordre de leur choix. Le guide mentionne également Numbat, l’outil libre de Perplexity, qui se connecte aux agents pris en charge par l’intermédiaire de hooks locaux et peut examiner les actions prévues, telles que les commandes shell ou les écritures de fichiers, avant leur exécution. Le blocage est facultatif et désactivé par défaut.