Architecting AI Gateways: Proxying Agentic Workflows and MCP Traffic

Traditional API gateways se dégradent lorsque des agents autonomes initient 50 appels d’outils en cascade simultanément. Voici comment déployer des reverse proxies natifs à l’IA pour mettre en cache les chaînes de raisonnement, router le trafic MCP, et limiter les agents indésirables — et pourquoi la sécurité est devenue bien plus complexe que ce que le pitch initial de la gateway laissait prévoir.

---

D’ici 2026, le paysage de l’IA a définitivement évolué, passant des chatbots statiques prompt-réponse à des workflows agentiques autonomes et multi-étapes. Les grands modèles de langage (LLMs) agissent désormais comme des moteurs de raisonnement, interrogeant indépendamment des bases de données, déclenchant des API externes, et exécutant du code complexe. Cette avancée architecturale a mis en lumière une faille critique dans l’infrastructure réseau d’entreprise traditionnelle : les API gateways legacy ont été conçues pour un trafic REST linéaire, prévisible, en demande-réponse 1:1. Elles sont totalement inadaptées pour gérer le trafic erratique, à volume élevé, et lourd en tokens généré par des agents IA autonomes.

Lorsqu’un seul prompt utilisateur peut déclencher des dizaines d’appels de modèles et d’invocations d’outils en cascade, le périmètre réseau nécessite un intermédiaire spécialisé. Voici l’AI gateway proxy : un reverse proxy natif à l’IA positionné à la périphérie du réseau pour gérer le cache sémantique, router intelligemment le trafic LLM, et contrôler le volume croissant de trafic Model Context Protocol (MCP) — tout en bloquant une nouvelle classe d’attaques supply-chain que les gateways legacy ne comprenaient pas.

---

Le catalyseur du changement : le Model Context Protocol

Pour comprendre pourquoi les gateways IA sont devenues indispensables, il faut saisir comment circule le trafic agentique en 2026. La clé est MCP.

Anthropic a introduit MCP le 25 novembre 2024, en open source, avec la spécification (version 2024-11-05) accompagnée de SDKs Python et TypeScript. Le protocole répond à un problème fondamental de scalabilité : avant MCP, les développeurs devaient créer des connecteurs spécifiques à chaque outil accessible par un LLM. MCP a résolu cela en proposant une interface universelle, ouverte, pour l’intégration des systèmes IA avec des sources de données externes — décrite dans la presse comme un “USB-C pour l’IA”.

La courbe d’adoption a été rapide. En trois mois, plus de 1 000 serveurs MCP communautaires ont été déployés. En avril 2025, les téléchargements ont dépassé 8 millions par mois, contre environ 100 000 au lancement. Fin 2025, plus de 5 800 serveurs MCP et 300+ clients MCP étaient disponibles, avec un support majeur par SAP, Oracle, Docker, aux côtés des pionniers Google, OpenAI, et Microsoft.

La gouvernance a suivi l’adoption. En décembre 2025, Anthropic a donné MCP à la Agentic AI Foundation (AAIF), un fonds dirigé sous la Linux Foundation, cofondé par Anthropic, Block, et OpenAI. Ce mouvement a officialisé MCP comme infrastructure neutre, plutôt que protocole propriétaire. La spécification a été mise à jour lors de son anniversaire, avec l’introduction de workflows asynchrones, d’un mode URL pour OAuth sécurisé, et de l’échantillonnage côté serveur avec outils — permettant aux serveurs MCP de faire tourner leurs propres boucles agentiques sous le budget de tokens de l’utilisateur, sans exposer de credentials.

La couche de transport du protocole utilise JSON-RPC 2.0 sur deux canaux : stdin/stdout pour l’exécution locale, et Server-Sent Events (SSE) ou HTTP Stream pour les connexions distantes. L’architecture est explicitement découplée en trois rôles :

• MCP Host — l’application exécutant le LLM (IDE, interface conversationnelle, ou backend automatisé).
• MCP Client — un routeur dans l’hôte qui traduit les requêtes LLM au format MCP.
• MCP Server — le service externe exposant capacités (outils, ressources, prompts) au LLM.

Grâce à MCP, un agent autonome peut découvrir et se connecter dynamiquement aux systèmes d’entreprise. Cette facilité de connectivité est une arme à double tranchant : elle facilite des opérations multi-systèmes complexes, mais un seul prompt peut aussi s’étendre en un arbre massif d’appels API interdépendants — augmentant la surface d’attaque.

---

L’anatomie d’un meltdown agentique : étude de cas IIoT

Pour visualiser la pression que les workflows agentiques exercent sur l’infrastructure réseau, prenons un déploiement d’entreprise basé sur la duplication industrielle et le tunneling de capteurs locaux vers des jumeaux numériques dans le cloud.

Un agent IA autonome spécialisé surveille un réseau de capteurs IIoT. Il écoute un flux télémétrique continu, tunnelé directement depuis l’usine. Lorsqu’une anomalie est détectée dans les données vibratoires, le LLM de l’agent en déduit qu’il lui faut plus de contexte — et, sans intervention humaine, exécute la cascade suivante via MCP :

1. Interroge une base de données de séries temporelles pour 72 heures de données historiques.
2. Invokes un LLM léger pour analyser les logs de maintenance.
3. Déclenche un outil de simulation physique via un serveur MCP.
4. Appelle un pipeline de rendu NVIDIA Omniverse pour mettre à jour et visualiser le jumeau numérique de la machine concernée en temps réel.
5. Rédige et envoie une alerte dans un canal Slack d’entreprise.

En une fraction de seconde, un seul déclencheur d’anomalie a généré plus de 50 appels API, plusieurs invocations de LLM consommant des centaines de milliers de tokens, et une tâche de rendu intensif.

Si ce trafic passe par une API gateway classique, le système devient aveugle. Une gateway legacy voit du HTTP, mais ne comprend pas tokens. Elle ne peut pas différencier une simple lecture de base de données d’une étape de raisonnement LLM coûteuse. Résultat : épuisement des limites de débit, pics de facturation dus à des appels d’outils redondants, et échec du pipeline, l’agent étant bloqué par les fournisseurs LLM pour surcharge.

---

Entrée dans le AI Gateway Proxy

Un AI gateway proxy est une couche middleware conçue pour réguler le trafic IA. Positionné comme reverse proxy entre le MCP Host et les différents LLM et serveurs MCP, il intercepte, analyse, et gère chaque étape du workflow agentique.

Les gateways natifs à l’IA actuels — dont Bifrost (Maxim AI, Apache 2.0, Go, ~11 µs de surcharge à 5k RPS), LiteLLM (MIT, Python, 33 000+ stars GitHub), Portkey (version open source complète en mars 2026), Kong AI Gateway (version 3.14), et le projet agentgateway de la Linux Foundation — sont tous experts en IA. Ils suivent la consommation en tokens plutôt qu’en octets, inspectent les payloads prompts, et appliquent des politiques basées sur l’intention sémantique plutôt que sur le simple chemin URL.

Le choix architectural entre ces gateways a un impact réel sur la performance. Les gateways Python comme LiteLLM ajoutent environ 8–50 ms de surcharge par requête, ce qui est acceptable pour un débit modéré, mais devient problématique au-delà de ~250–300 RPS par instance. Les gateways Go comme Bifrost affichent une surcharge d’environ 11 µs à 5 000 RPS — une différence de plusieurs ordres de grandeur cruciale dans des pipelines sensibles à la latence comme l’IIoT.

En déployant un AI gateway à la périphérie du réseau, les entreprises retrouvent le contrôle via trois piliers : Cache sémantique, Routing intelligent, et Limitation des agents indésirables. Un quatrième — sécurité contre les classes d’attaques spécifiques à MCP — devient tout aussi vital, et est détaillé ci-dessous.

---

Pilier 1 : Cache sémantique à la périphérie

Dans les workflows agentiques, les LLM entrent souvent dans des boucles cognitives où ils posent en boucle les mêmes questions ou interrogent les mêmes données pour résoudre un problème multi-étapes. Payer un fournisseur LLM pour des requêtes identiques ou quasi-identiques est coûteux en calcul et en argent — et introduit une latence inacceptable dans des systèmes en temps réel. Une étude de cas a montré qu’un cache sémantique réduit les coûts LLM de 69% dans un système de support client.

Le cache sémantique résout cela en servant directement depuis le cache du gateway des requêtes identiques ou logiquement similaires. Contrairement au cache traditionnel — qui exige une correspondance byte-à-byte parfaite — le cache sémantique comprend le sens d’un prompt.

Les gateways IA modernes déploient une architecture de cache à double couche :

Couche 1 — Correspondance par hash exact. Le gateway hache le prompt entrant. Si l’agent demande, “Quelle est la température actuelle de la turbine 4 ?”, le gateway renvoie instantanément la réponse en cache, sans surcharge.

Couche 2 — Recherche par similarité vectorielle. Si l’agent reformule légèrement la même requête — “Donne-moi la lecture de température pour la quatrième turbine” — le gateway génère une embedding du nouveau prompt et la compare à celles des requêtes précédemment en cache dans une base vectorielle haute vitesse (Redis, Qdrant, ou Milvus). Si le score de similarité sémantique dépasse un seuil configuré (typiquement 0.85 ou plus), le gateway évite l’appel LLM et sert la réponse en cache.

LiteLLM supporte les modes de cache redis-semantic et qdrant-semantic. Portkey propose une des implémentations de cache sémantique les plus matures dans la catégorie managed-gateway. Cloudflare AI Gateway couvre actuellement le cache exact à l’échelle mondiale, avec TTL configurable via headers HTTP ; le cache sémantique complet (similarité vectorielle) reste une lacune dans l’offre managée à mi-2026.

Pour un trafic MCP élevé, le cache sémantique fait la différence entre une application en temps réel fonctionnelle et un prototype inabordable.

---

Pilier 2 : Routage du trafic LLM et stratégies de fallback

Les agents autonomes ne sont pas liés à un seul modèle. Une architecture agentique mature utilise un ensemble de LLM, chacun adapté à une sous-tâche spécifique. Programmer cette logique de routage dans l’agent lui-même crée un système fragile : si un fournisseur tombe en panne, l’agent échoue.

Un AI gateway abstrait cette complexité. L’agent envoie toutes ses requêtes à un point d’accès unique (souvent une API compatible OpenAI), et le gateway décide dynamiquement du routage en quelques millisecondes.

Routage dynamique par modèle. Le gateway inspecte la charge utile et la dirige vers la destination optimale. Les tâches simples — comme classer la gravité d’une alerte capteur — sont routées vers des modèles rapides et peu coûteux. Les tâches complexes de raisonnement ou de génération de code sont envoyées à des modèles plus puissants. Kong AI Gateway 3.10 et ultérieur implémente le routage sémantique via le plugin AI Proxy Advanced, qui distribue les requêtes selon la similarité sémantique entre le prompt et une description du domaine de spécialité de chaque modèle. Portkey supporte le routage vers plus de 200 fournisseurs de LLM depuis une seule console de contrôle.

Résilience et chaînes de fallback. Les pannes d’API LLM ou les limites de débit sont une réalité en production — OpenAI a connu trois grandes pannes en 2025 ; Anthropic a subi des périodes de rate-limiting durant les heures de pointe. Les gateways IA surveillent en continu la santé des fournisseurs et automatisent les chaînes de fallback. Lorsqu’un fournisseur principal renvoie un timeout ou un 429 Too Many Requests, le gateway redirige de façon transparente vers un fournisseur secondaire. L’agent ne voit pas la panne ; il reçoit les données demandées et poursuit son workflow.

Trafic agent-à-agent (A2A). En avril 2026, le problème de routage s’est étendu au-delà des appels LLM. Kong 3.14 a introduit Kong Agent Gateway, premier gateway de production à gérer nativement ces trois types de trafic dans un contrôle unifié : appels LLM, outils MCP, et communication A2A via le protocole A2A (initialement lancé par Google en avril 2024). Le Emerging Tech Adoption Radar de Gartner 2026 note que “avec la montée des interactions agent-à-agent, les AI gateways deviennent la colonne vertébrale d’une adoption IA sûre et scalable.” Le projet agentgateway de la Linux Foundation — soutenu par Microsoft, AWS, Cisco, Adobe, Huawei, et Apple — poursuit cet objectif avec une conception open-source, basée sur OPA pour une gestion fine des politiques.

---

Pilier 3 : Limiter les agents indésirables et appliquer des garde-fous

Le risque le plus grave dans les workflows agentiques est la boucle autonome hors contrôle. Un agent indésirable survient lorsqu’un LLM mal interprète un message d’erreur, hallucine une solution, et déclenche en boucle des outils MCP. En environnement non contrôlé, un agent indésirable peut générer des milliers d’appels API coûteux en quelques minutes, ou effectuer des opérations destructrices sur des bases de données d’entreprise.

Les gateways IA jouent le rôle de garde-fou, avec une gouvernance granulaire, basée sur les tokens.

Limitation par tokens. Les limites classiques par minute sont inutiles quand une requête peut consommer entre 100 et 100 000 tokens. Les gateways appliquent des limites Tokens-Par-Minute (TPM) par clé virtuelle, par persona d’agent, ou par projet. Bifrost implémente une hiérarchie de budgets à quatre niveaux : Client → Équipe → Clé virtuelle → Configuration fournisseur, avec plafonds de dépenses à chaque étape. Si l’agent IIoT consomme soudainement beaucoup de tokens, le gateway limite le flux avant que le budget d’entreprise ne soit épuisé.

Contrôle d’accès aux outils MCP. Les gateways appliquent un RBAC (Role-Based Access Control) au niveau des outils MCP. Un agent peut avoir accès à la découverte de serveurs MCP, mais le gateway applique le principe du moindre privilège — autorisant les requêtes SELECT pour lire la télémétrie, tout en bloquant DROP ou UPDATE sur les bases de production. Kong 3.12 (octobre 2025) a ajouté des MCP ACLs et auto-génère des serveurs MCP à partir de définitions REST API existantes, facilitant l’exposition rapide de services internes avec OAuth centralisé.

Mode Code de Bifrost. Une optimisation notable à ce niveau : il réduit la définition des outils à leur schéma essentiel avant inclusion dans le contexte LLM, diminuant la consommation de tokens par tour agent de plus de 50%, ce qui limite l’impact d’une boucle incontrôlée.

---

Pilier 4 : Sécurité contre les classes d’attaques spécifiques à MCP

Cette section n’existait pas dans le pitch initial de la gateway. Elle est désormais essentielle, car l’exposition MCP a été cartographiée méthodiquement ces 18 derniers mois, et les risques identifiés sont sérieux.

Poisoning des outils. Les serveurs MCP peuvent intégrer des instructions malveillantes dans leurs métadonnées — champs JSON Schema, descriptions d’outils, métadonnées structurées récupérées au démarrage. Le modèle lit ces instructions comme directives, et un attaquant contrôlant un serveur MCP peut écrire des directives dans ces descripteurs, sans nettoyage, avec toute l’autorité ambiante. Cela a été catalogué comme une classe distincte de prompt injection (CVE-2025-54136, MCPoison) et de manipulation de sortie (CVE-2025-54135, CurXecute), toutes révélées en 2025. OWASP classe ces vulnérabilités sous LLM01 (injection de prompt) et LLM05 (gestion incorrecte des sorties).

Rug-pull. Les définitions d’outils MCP peuvent muter après déploiement. Un outil jugé sûr peut se reconfigurer discrètement — reroutant des clés API, changeant ses commandes, ou interceptant des appels à des outils de confiance — sans changement visible. Simon Willison a documenté ce risque en avril 2025, comme l’un des plus insidieux.

Compromission supply chain via les registres. CVE-2025-6514, une vulnérabilité critique d’injection de commandes OS dans mcp-remote (CVSS 9.6), a montré la dimension supply chain. La faille — découverte par JFrog Security Research, corrigée en version 0.1.16 — permet à un serveur MCP malveillant d’injecter une commande malicieuse dans authorization_endpoint, entraînant une exécution de code à distance. Avec plus de 437 000 téléchargements et une adoption par Cloudflare, Hugging Face, et Auth0, une version non patchée constituait une porte dérobée supply chain. CVE-2025-49596 (MCP Inspector) était une vulnérabilité CSRF permettant une RCE via une page web modifiée.

Poisoning multi-serveurs inter-outils. Une analyse empirique sur sept clients MCP majeurs a montré qu’un serveur malveillant connecté à plusieurs serveurs peut intercepter ou override des appels vers un serveur de confiance. Un agent Cursor avec accès service-role dans Supabase a traité des tickets support contenant du SQL embarqué, exposant des tokens d’intégration dans un fil de discussion public. Validation statique insuffisante et gestion invisible des paramètres en sont la cause.

Ce que fait le gateway. Un AI gateway sert de point de contrôle où une équipe peut déployer une mitigation unique à des milliers d’agents. En maintenant un registre validé et figé des définitions MCP approuvées, et en interceptant l’enregistrement dynamique d’outils — la voie la plus risquée — le gateway limite la portée même lorsqu’un client est vulnérable. Il ne remplace pas les patchs clients ni l’hygiène des fournisseurs, mais c’est la couche où scanner l’injection de prompt, valider la définition des outils, et détecter les anomalies comportementales peut se faire centralement, avant que les appels ne soient transmis. L’exécution sandboxée (dans Docker) et la moindre privilège imposée par le gateway constituent la base de défense recommandée par l’Cloud Security Alliance.

---

Observabilité : reconstruire la chaîne de raisonnement

Déboguer un workflow agentique échoué est difficile, car la logique est non déterministe. Les logs classiques montrent que des requêtes HTTP ont été faites, mais pas pourquoi l’agent a fait ces choix.

OpenTelemetry est devenu la norme pour l’observabilité IA. Le groupe de spécialité GenAI (GenAI SIG), créé en avril 2024, a étendu progressivement les conventions sémantiques, passant d’un simple traçage des appels LLM à une couverture complète des workflows agentiques. La version 1.39 d’OTel a introduit des attributs de span spécifiques à MCP — mcp.session.id, mcp.method.name, mcp.protocol.version, gen_ai.tool.name — qui portent le contexte que les conventions RPC générales manquaient. Cela a comblé le vide où l’agent produisait Trace A et le serveur MCP Trace B sans propagation.

Les conventions sémantiques gen_ai.* standardisent la capture des attributs du modèle, de l’utilisation des tokens, de la latence, des invocations d’outils, et des étapes de raisonnement de l’agent dans tout l’arbre d’appels. Datadog a ajouté le support natif OTel GenAI SemConv (v1.37) en décembre 2025. New Relic a lancé le monitoring MCP en 2025. Plusieurs fournisseurs d’identité — Auth0, Okta, WorkOS — proposent désormais des intégrations d’authentification d’entreprise pour MCP.

Les gateways IA exportant la télémétrie via OTel permettent aux développeurs de reconstruire précisément pourquoi un agent a choisi une séquence d’appels, ce qui a été servi en cache, quel fournisseur a été utilisé en fallback, et où le workflow a bloqué — toute la chaîne de raisonnement, plutôt qu’un amas de logs HTTP déconnectés.

---

La sélection de gateway en pratique

Aucune gateway unique ne convient à tous les profils de déploiement :

Gateway	Architecture	Meilleur usage
Bifrost (Maxim AI)	Go, Apache 2.0, ~11 µs de surcharge à 5k RPS	Latence critique, industries réglementées, VPC / air-gapped
LiteLLM	Python, MIT, 100+ fournisseurs, 33k+ stars GitHub	Couverture large des fournisseurs ; prototypage à débit modéré
Portkey	SaaS géré (open source complet mars 2026), 200+ fournisseurs	Équipes cherchant une gestion managée, PII mature + garde-fous
Kong AI Gateway 3.14	Nginx + plugins ; tarif entreprise ~$500–2 500$/mois	Entreprises déjà avec Kong ; LLM + MCP + A2A unifiés
Cloudflare AI Gateway	Entièrement géré, edge global	Zéro infra ; cache exact ; 350+ modèles
agentgateway (Linux Foundation)	Open source, OPA, multi-fournisseurs	Gouvernance, standard ouvert, A2A et MCP ; communauté

Pour les équipes traitant moins de 250 RPS par instance avec un large choix de fournisseurs, LiteLLM est un bon point de départ. Pour des charges de production à haut débit où chaque milliseconde d’overhead s’accumule, une solution Go ou en edge gérée est la meilleure architecture. Pour les organisations déjà avec Kong, la version 3.14 (avril 2026) du Kong Agent Gateway couvre tout le flux sans nouvelle infrastructure.

---

Conclusion : le nouveau périmètre

Alors que MCP dépasse 97 millions de téléchargements SDK mensuels et que les agents s’intègrent dans des environnements critiques — de la prévision financière au tunneling en temps réel de capteurs industriels — le périmètre réseau doit évoluer.

L’API gateway traditionnelle est un vestige de l’ère web 2.0. Elle manque de contrôles au niveau des tokens, de cache sémantique, et — surtout — de compréhension des nouvelles classes d’attaques introduites par MCP. Déployer des agents autonomes sans reverse proxy IA natif, c’est comme connecter un tuyau d’incendie haute pression à un système d’arrosage : ça va tout faire sauter, et en plus, cela ne sera détecté qu’après coup par la surveillance classique.

En architecturant des systèmes avec des gateways IA dédiés, les organisations obtiennent quatre avantages impossibles avec l’infrastructure legacy : un cache sémantique qui maintient la solvabilité des pipelines en temps réel ; un routage intelligent pour une haute disponibilité face à la volatilité des fournisseurs LLM ; une limitation stricte des tokens pour éviter que des systèmes autonomes ne deviennent des gouffres financiers ; et une couche d’interception centralisée pour valider les définitions d’outils et détecter les anomalies comportementales avant que les MCP ne touchent des systèmes en aval.

En 2026, l’AI gateway n’est plus une couche d’optimisation ajoutée à une stack API existante. Elle devient le plan de contrôle fondamental pour l’entreprise agentique — et la première ligne de défense contre des classes d’attaques qui n’existaient pas il y a seulement dix-huit mois.

---

Changelog

Corrections factuelles et ajouts à la version initiale :

• Gouvernance MCP corrigée. La version initiale disait que MCP avait été donnée à “l’Agentic AI Foundation”. C’est exact, mais incomplet : l’AAIF est un fonds dirigé sous la Linux Foundation, cofondé par Anthropic, Block, et OpenAI. La donation a eu lieu en décembre 2025, pas plus tôt.
• Date de lancement MCP confirmée. 25 novembre 2024 ; spécification version 2024-11-05. Vérifié via la documentation d’Anthropic.
• Transport MCP ajouté. La version initiale omettait le transport HTTP Streamable, ajouté lors de l’anniversaire en novembre 2025 avec SSE et stdio. La mise à jour a aussi introduit workflows asynchrones, mode URL pour OAuth sécurisé, et l’échantillonnage côté serveur — tous importants pour la sécurité.
• Métriques d’adoption précisées. “Plus de 1 000 serveurs MCP communautaires” était la situation vers février 2025 ; la version initiale laissait penser que c’était la situation actuelle. La réalité : plus de 5 800 serveurs, 97 millions+ de téléchargements SDK mensuels, et 300+ clients.
• Correction du paysage des gateways. La version initiale mentionnait seulement “Bifrost, Cequence, ou Kong AI Gateway”. Cequence est une plateforme de sécurité API, pas une gateway IA — retiré. LiteLLM, Portkey, Cloudflare AI Gateway, et le projet agentgateway de la Linux Foundation ont été ajoutés.
• Chiffres de latence Python vs Go. LiteLLM : ~8–50 ms. Bifrost : ~11 µs à 5 000 RPS. Ces chiffres proviennent de benchmarks publiés (Maxim AI, mars 2026) et concernent l’usage en temps réel IIoT.
• Références de versions de modèles mises à jour. Les mentions de “Claude 3.7 Haiku” et “Claude 3.5 Sonnet” ont été remplacées par un langage neutre, car ce ne sont pas des noms produits.
• Correction de la version de Kong AI Gateway. La version 3.8 (décembre 2025, cache sémantique + MCP ACLs), 3.10 (avril 2025, RAG automatique + load balancing token), 3.12 (octobre 2025, MCP ACLs + support Code pour Claude), 3.14 (avril 2026, Kong Agent Gateway avec A2A, version GA).
• Ajout du tarif Kong. Kong Konnect : environ 500–2 500$/mois ; tarif entreprise sur demande.
• Section protocole A2A ajoutée. Lancé par Google en avril 2024, maintenant en production avec Kong 3.14 et agentgateway, c’est une avancée majeure absente du draft initial.
• Section sécurité complète (Pilier 4). Pas dans le draft initial, ajoutée : poisoning d’outils (CVE-2025-54136, CVE-2025-54135), mutation rug-pull, vulnérabilités supply chain CVE-2025-6514 (mcp-remote, CVSS 9.6, corrigé en 0.1.16), incident de prompt injection chez Cursor/MindStudio (mi-2025). Sources : Elastic Security Labs, JFrog, authzed.com, arXiv 2603.22489 (mars 2026), practical-devsecops.com, TrueFoundry.
• Section observabilité étendue. Mention d’OpenTelemetry, ajout : groupe GenAI (avril 2024), conventions sémantiques MCP dans OTel v1.39 (mcp.session.id, mcp.method.name, mcp.protocol.version, gen_ai.tool.name), support Datadog (v1.37, décembre 2025), support New Relic MCP (2025), fournisseurs d’identité (Auth0, Okta, WorkOS).
• Seuil de cache sémantique précisé. La valeur 0.85 de similarité cosinus, décrite dans le draft, est cohérente avec les configurations publiées pour LiteLLM ; conservée.
• Économies de coûts mentionnées. 69% de réduction grâce au cache sémantique, selon une étude de cas support client (MindStudio, février 2026).
• Mode Code Bifrost ajouté. Réduit la consommation de tokens de plus de 50% en simplifiant la définition des outils, limite l’impact d’une boucle incontrôlée.