Pourquoi les outils de traçage des LLM construisent désormais des passerelles d’IA

En 2026, LangSmith, Langfuse, Opik et Braintrust ont tous ajouté une passerelle en amont des fournisseurs de modèles. La principale raison est le contrôle : un outil de traçage peut uniquement enregistrer un appel de modèle, tandis qu’une passerelle peut l’interrompre.

Deux outils aux fonctions distinctes

Au cours des deux dernières années, de nombreuses équipes ont utilisé deux outils distincts pour faire fonctionner des applications reposant sur des grands modèles de langage (LLM). Une passerelle se trouvait entre l’application et les fournisseurs de modèles. Elle détenait les clés API des fournisseurs, assurait la traduction entre leurs API et relançait les appels qui échouaient. LiteLLM, un proxy open source, est devenu un choix courant pour cette tâche. À côté de l’application se trouvait un outil de traçage, tel que LangSmith ou Langfuse, qui enregistrait chaque appel de modèle, chaque appel d’outil et chaque étape de récupération afin que les ingénieurs puissent voir ce qu’un agent avait fait.

Cette séparation était logique : une passerelle doit être rapide et prendre en charge l’API de chaque fournisseur, tandis qu’un outil de traçage a besoin d’une bonne interface, d’un espace de stockage pour les charges utiles volumineuses et d’un SDK qui encapsule le code de l’application. Langfuse décrit toujours cette configuration à deux outils, avec une intégration de LiteLLM Proxy qui fait transiter chaque appel par le proxy avant de l’envoyer à Langfuse. En 2026, les fournisseurs d’outils de traçage ont commencé à construire eux-mêmes la passerelle.

Quatre lancements en six mois

LangChain a annoncé le LangSmith LLM Gateway en bêta privée en mai 2026, puis l’a ouvert en bêta publique le 30 juillet. Depuis, il l’a également intégré aux déploiements LangSmith dans le cloud du client. Braintrust a abandonné son ancien proxy d’IA et orienté ses utilisateurs vers une nouvelle passerelle, actuellement en préversion et gratuite jusqu’à sa disponibilité générale. Comet a lancé le Opik LLM Gateway sous la forme d’un point de terminaison bêta qui accepte les requêtes au format OpenAI. Le 4 novembre, Langfuse a ouvert sa passerelle d’IA en bêta publique, à la fois sur Langfuse Cloud et pour les déploiements autohébergés. La passerelle est sous licence MIT et écrite en Rust.

MLflow, qui était à l’origine un outil de gestion du cycle de vie de l’apprentissage automatique plutôt qu’un outil de traçage, propose depuis plus longtemps une passerelle d’IA, avec des alertes et des plafonds budgétaires.

Les passerelles existent depuis des années, et les risques liés à leur exploitation sont bien documentés. Les nouvelles passerelles sont proposées par des entreprises dont l’activité consistait à enregistrer les appels de modèles, et qui souhaitent désormais que chaque appel passe d’abord par elles.

Pourquoi un budget doit s’appliquer au chemin des requêtes

Un outil de traçage enregistre un appel de modèle une fois que le fournisseur a répondu et que les jetons ont été payés. Cet enregistrement suffit pour établir un graphique des dépenses, mais l’outil de traçage ne peut pas empêcher ces dépenses. Pour faire respecter le budget d’une équipe, bloquer un modèle ou supprimer un secret d’un prompt, il faut vérifier la requête avant qu’elle n’atteigne le fournisseur. Seul le composant qui se trouve sur le chemin de la requête peut le faire.

LangChain développe cet argument dans son article de lancement. L’entreprise décrit des équipes qui combinent une passerelle distincte, un produit de protection et un outil d’observabilité, et affirme que la prévention des problèmes passe par l’application de règles au niveau des requêtes. Sa passerelle répond avec le code d’état HTTP 402 à tout appel qui dépasserait un budget, au lieu de le transmettre au fournisseur.

Un point d’entrée unique enregistre chaque appel

La deuxième raison est l’étendue de la couverture. Un SDK n’enregistre que les chemins d’exécution que quelqu’un a instrumentés. C’est en dehors de ces chemins que les défaillances des agents passent souvent inaperçues. Un script sur un ordinateur portable, un bloc-notes ou un agent de programmation utilisant une clé API copiée ne laisse aucune trace. Une passerelle qui détient les clés des fournisseurs voit chaque appel, car il n’existe aucun autre chemin vers le fournisseur.

Langfuse conçoit sa passerelle autour de cette idée. Selon sa documentation sur la passerelle, chaque clé de passerelle est associée à un utilisateur ou à un compte de service et peut inclure des métadonnées telles qu’une équipe ou un centre de coûts. Seule la passerelle détient les identifiants du fournisseur, et les administrateurs approuvent les modèles que chaque identifiant est autorisé à appeler. LangSmith publie des pages de configuration expliquant comment acheminer Claude Code, Codex et Gemini CLI par sa passerelle. Ces agents appellent des modèles depuis l’ordinateur du développeur, en dehors du code de traçage de toute application.

Ce qu’ajoute la passerelle d’un outil de traçage

Les fournisseurs d’outils de traçage avancent aussi l’argument inverse : une passerelle autonome ne suffit pas à elle seule. Dans son article de lancement, Langfuse affirme qu’une passerelle autonome peut uniquement compter les jetons et les coûts, tandis que sa propre passerelle intègre chaque appel à une trace complète. La passerelle de Langfuse accepte un en-tête W3C traceparent, de sorte qu’un appel qui la traverse rejoint la trace déjà démarrée par l’application. Par défaut, elle enregistre l’utilisation et le coût, mais pas le contenu des prompts et des réponses.

C’est l’argument technique le plus convaincant en faveur de l’intégration de la passerelle à l’outil de traçage. Une passerelle autonome ne voit qu’une liste à plat de réponses générées. Un outil de traçage dispose déjà, grâce à son SDK, des appels d’outils et des étapes de récupération de l’agent, et peut insérer chaque appel passant par la passerelle dans cette structure.

Il y a aussi un enjeu commercial, que les fournisseurs ne mettent pas eux-mêmes en avant. Celui qui exploite la passerelle détient les clés des fournisseurs et le rapport des dépenses, que consultent les équipes financières et les équipes plateforme. Une passerelle est donc plus difficile à remplacer qu’un outil de visualisation des traces. LangSmith et Langfuse tirent déjà parti de cette position de manière différente : LangSmith vend des Gateway Credits, qui permettent aux clients d’appeler des modèles hébergés comme Kimi sans utiliser leur propre clé fournisseur, tandis que la FAQ de Langfuse indique que l’entreprise ne revend pas de jetons.

Ce que les passerelles en bêta ne peuvent pas encore faire

Ces passerelles sont récentes, et les fournisseurs documentent eux-mêmes leurs lacunes. Aujourd’hui, la passerelle de Langfuse prend uniquement en charge OpenAI et Anthropic ; Amazon Bedrock, Google Vertex AI et Google AI Studio figurent sur sa feuille de route. Le basculement entre fournisseurs et les plafonds stricts de dépenses par équipe, utilisateur ou clé sont prévus, mais n’ont pas encore été déployés. Pour l’instant, la passerelle propose un tableau de bord des dépenses et des alertes. Sa documentation ne mentionne ni limites de débit ni mise en cache des réponses.

La passerelle de Langfuse ne convertit pas les formats d’API ; un client OpenAI ne peut donc appeler que des modèles OpenAI. La version auto-hébergée appelle uniquement les URL officielles des fournisseurs, ce qui exclut pour l’instant Azure OpenAI, Bedrock et les proxys internes. Comet indique que la passerelle Opik est conçue pour le développement et les tests. Braintrust n’a pas annoncé de tarif pour sa passerelle.

La passerelle de LangSmith offre déjà davantage que les autres. Sa documentation répertorie le basculement, les limites de dépenses, les limites de débit et les politiques relatives aux données parmi les fonctionnalités disponibles. Elle accepte également les formats OpenAI Chat Completions, OpenAI Responses et Anthropic Messages. Le basculement et les limites de débit figuraient parmi les travaux prévus en mai : ils ont donc été ajoutés pendant la bêta. Le produit dans son ensemble est toujours présenté comme étant en bêta.

Les tests de charge révèlent un autre type de lacune. Un banc d’essai auto-hébergé comparant la passerelle Langfuse, LiteLLM et AcruxCore a conclu que la passerelle Langfuse ajoutait moins de latence par appel que LiteLLM. Toutefois, avec les paramètres Docker par défaut, elle a échoué sur 739 des 1 000 flux simultanés, car son processus conservait la limite par défaut de Docker, fixée à 1 024 fichiers ouverts. Une ligne dans le fichier Compose de Langfuse a corrigé le problème.

Comparé à ces versions bêta, LiteLLM, une passerelle autonome depuis des années, prend en charge plus de 100 fournisseurs et intègre déjà des clés virtuelles, le suivi des dépenses, des garde-fous, l’équilibrage de charge et un tableau de bord d’administration. LiteLLM déplace également le traitement des requêtes de Python vers Rust. Sa passerelle d’IA Rust est en bêta, et l’équipe de LiteLLM prévoit que les requêtes au format /v1/messages d’Anthropic pourront être traitées de bout en bout en Rust d’ici au 1er décembre, avec une latence environ 20 fois moindre. Quelques plateformes open source, comme MLflow et AcruxCore, proposent déjà une passerelle et le traçage dans un même produit.

Pourquoi les garder séparés

Fusionner la passerelle avec l’outil de traçage a un coût, et le principal est le couplage. Avec une passerelle distincte, une équipe peut changer de fournisseur de traçage en modifiant un rappel de journalisation. Si l’outil de traçage fait aussi office de passerelle, il faut également modifier l’URL de base, les clés et les identifiants de modèle de chaque service. Langfuse, par exemple, écrit les identifiants de modèle sous la forme credential:model.

L’outil de traçage devient aussi une dépendance à l’exécution. Si le système de traçage tombe en panne, l’équipe perd ses traces. Si une passerelle tombe en panne, les appels aux modèles échouent. Un fournisseur d’outils de traçage qui exploite la passerelle doit désormais assurer la disponibilité d’une infrastructure critique.

Les fournisseurs de solutions de sécurité veulent eux aussi occuper cette place dans le chemin des requêtes. Palo Alto Networks a finalisé l’acquisition de Portkey, une passerelle autonome, en mai 2026 et en a fait la passerelle d’IA de sa plateforme Prisma AIRS. Une équipe de sécurité peut vouloir garder le contrôle de la passerelle plutôt que de l’intégrer à un outil d’observabilité. Les passerelles sont également devenues la cible d’attaquants, comme l’a montré en mars la faille de la chaîne d’approvisionnement de LiteLLM.

Comment les équipes peuvent faire leur choix

Les équipes peuvent commencer par dresser la liste de ce qui doit se passer avant un appel à un modèle. Si elles ont uniquement besoin de visibilité, un outil de traçage placé à côté du chemin des requêtes suffit et n’ajoute aucune dépendance à l’exécution. Si elles ont aussi besoin de budgets, de règles concernant les clés ou d’un processus d’approbation des modèles, il leur faut une passerelle, quelle qu’elle soit.

Il faut ensuite examiner la couverture des fournisseurs. Une équipe devrait noter tous les fournisseurs et formats d’API qu’elle utilise en production, notamment Azure OpenAI et Bedrock, puis comparer cette liste aux capacités actuellement prises en charge par chaque passerelle, plutôt qu’à celles prévues sur sa feuille de route.

Les équipes qui utilisent déjà LiteLLM ont peu de raisons de changer tant qu’une passerelle en bêta ne propose rien qui leur manque. Le principal avantage de la passerelle d’un outil de traçage est d’insérer l’appel à la passerelle dans la trace de l’agent ; cet avantage doit justifier une migration. Les équipes qui démarrent peuvent garder la passerelle comme couche distincte, même si un seul fournisseur propose les deux outils. En conservant l’URL de base et les clés dans un même module de configuration, elles pourront ensuite changer de solution en modifiant la configuration plutôt que le code.

La plupart de ces passerelles sont présentées comme des versions bêta ou préliminaires ; la liste de leurs lacunes va donc rapidement se réduire. La question reste de savoir qui contrôlera le chemin des requêtes dans une entreprise type : l’équipe d’observabilité, l’équipe plateforme qui exploite une passerelle autonome ou l’équipe de sécurité. Cette année, LangSmith et Langfuse ont créé leurs propres passerelles et Palo Alto Networks en a acheté une ; pourtant, dans de nombreuses infrastructures, les requêtes passent encore par LiteLLM.