Le virage AI de Gravitee : API Management à l’heure des LLMs

Note personnelle : j’ai commencé ce billet après avoir remarqué une accélération nette des publications de Gravitee autour de l’AI Gateway début 2026. En quelques semaines, j’ai l’impression que le blog est passé de sujets classiques (rate limiting, auth) à une déferlante sur l’orchestration d’agents, la sécurité MCP et les risques LLM. De quoi se demander : qu’est-ce que les grands modèles de langage changent à la couche API Management ? Et qu’est-ce que ça signifie pour quelqu’un qui build et run une fabrique logicielle au quotidien ?

Le signal

Gravitee est une brique de la stack de mon équipe dans le développement de l’usine logicielle pour de la R&D.

En début d’année, en suivant le blog de l’éditeur, j’ai vu quelque chose d’inhabituel. Le rythme de publication s’est accéléré, et le contenu a changé de nature. Là où on trouvait des articles sur le rate limiting REST ou l’authentification OAuth2 classique, sont apparus des sujets comme la gestion de contexte LLM, le protocole MCP, la prévention de fuites PII dans les échanges avec des agents, ou encore le semantic caching pour embeddings.

D’avril à juin 2026, Gravitee a publié une douzaine d’articles sur ce qu’ils appellent désormais leur AI Gateway. Des titres comme The AI Gateway: One Runtime for LLM, MCP and A2A, How to Prevent PII Leaks in AI Systems, ou Semantic Caching for LLMs. C’est un signal fort, qui dépasse le simple marketing de fonctionnalité.

Ce que j’ai découvert

Pourquoi ce pivot maintenant

Les LLMs ne sont plus un service API qu’on consomme depuis une application. Ils deviennent une couche applicative à part entière, avec des besoins spécifiques que les gateway traditionnelles ne couvrent pas bien.

Ce mouvement n’a pas commencé en 2026. Les éditeurs comme Gravitee, Kong ou Cloudflare ont lancé leurs premières AI Gateways et des fonctionnalités comme le filtrage de PII ou le rate limiting par tokens dès fin 2023 et début 2024. Ce que j’observe en 2026, c’est une phase de maturation : le protocole MCP (qui n’existait pas début 2024) s’impose comme standard, et les fonctionnalités AI-native deviennent un argument de vente structurant plutôt qu’une expérimentation.

Un endpoint REST classique, tu le sécurises avec une API key, un rate limit basé sur le nombre d’appels, et un quota mensuel. Un endpoint LLM, c’est différent : le coût d’un appel varie selon le nombre de tokens, les risques de sécurité ne sont pas dans le transport mais dans le contenu échangé, et la latence peut exploser selon le modèle utilisé sans que ce soit un problème d’infrastructure.

Les éditeurs d’API Management l’ont compris. Gravitee, Kong, Apigee, tous annoncent des fonctionnalités AI-native. Mais Gravitee a mis le paquet sur la communication, au point que la question n’est plus “est-ce que l’AI va arriver dans l’API Management” mais “à quelle vitesse”.

Les nouveaux risques

Trois catégories de risques reviennent systématiquement dans la littérature :

Les injections. Un utilisateur peut manipuler un prompt pour contourner les garde-fous d’un LLM, et potentiellement accéder à des données auxquelles il n’a pas droit. Le vecteur d’attaque n’est pas technique (buffer overflow, SQLi) mais sémantique. La réponse de l’industrie, c’est des politiques de sécurité au niveau de la gateway, avant même que la requête atteigne le modèle.

Les fuites de données. Quand un LLM traite des données internes, tout le contexte envoyé dans le prompt peut fuiter via le cache, les logs, ou une réponse mal configurée. Les politiques de data redaction et de filtrage de contenu deviennent des briques essentielles au niveau de la gateway.

Le rate limiting par consommation. Le nombre d’appels ne suffit pas comme métrique. Un appel avec 10 tokens et un appel avec 10 000 tokens n’ont pas le même coût ni le même impact. Les gateways commencent à implémenter du rate limiting basé sur les tokens consommés, un pattern nouveau pour l’API Management classique.

Les patterns émergents

Le protocole MCP (Model Context Protocol). C’est sans doute ce qui m’a le plus marqué. L’idée est simple : standardiser la façon dont les LLMs interagissent avec des outils et des sources de données externes. Concrètement, au lieu d’avoir chaque agent qui implémente sa propre connexion à une base ou à une API, le MCP sert de couche d’abstraction. Et la gateway devient le point de contrôle central pour sécuriser ces échanges.

Le semantic caching. Le caching HTTP classique ne sert à rien sur des réponses LLM : deux prompts similaires mais pas identiques produisent des réponses différentes. Le semantic caching calcule la distance entre la question posée et les questions déjà répondues, et sert une réponse en cache si la similarité dépasse un seuil. C’est un gain de latence et de coût considérable, à condition de ne pas servir une mauvaise réponse.

L’agent identity. Quand un agent LLM appelle des APIs pour le compte d’un utilisateur, qui est le sujet de l’authentification ? L’utilisateur qui a initié la conversation, ou l’agent qui exécute ? Les patterns comme On-Behalf-Of (OBO) et les délégations de jetons (Token Exchange, RFC 8693) resurgissent, mais adaptés au contexte agent, où l’agent n’est pas un service backend mais une entité qui raisonne.

OWASP LLM Top 10 comme cadre de référence

L’OWASP a publié son Top 10 pour les applications LLM (mis à jour en 2025). C’est devenu la référence pour qui veut sécuriser des workloads AI. Les vulnérabilités identifiées (injection de prompt, fuite de données d’entraînement, supply chain des modèles, excessive agency) redessinent ce que doit couvrir une politique de sécurité d’API.

Ce qui m’a frappé, c’est la proximité entre ce cadre et ce que Gravitee implémente dans son AI Gateway. L’éditeur semble avoir aligné sa roadmap sur les recommandations OWASP. Chaque politique annoncée (MCP Resource Server, data redaction, rate limiting sémantique) répond à une ligne du Top 10.

Ce qui m’a marqué

Deux choses me semblent notables dans ce virage.

D’abord, le passage d’une logique de sécurisation d’appels à une logique de sécurisation de conversations. Avec les APIs REST, tu vérifies que le bon client appelle la bonne ressource. Avec les LLMs, tu vérifies que le contenu de l’échange reste dans le périmètre autorisé, que les données sensibles ne fuient pas dans le contexte, et que la réponse ne révèle rien d’indésirable. C’est un changement de paradigme pour la couche API Management.

Ensuite, la standardisation autour de MCP. Si le protocole s’impose, les gateway vont devenir le point de passage obligé de tous les échanges agent vers outil. Ça change leur positionnement : d’un proxy de sécurisation, elles deviennent un orchestrateur de confiance entre les LLMs et les systèmes existants.

Ce que je n’ai pas exploré

Je n’ai pas encore comparé concrètement les offres AI Gateway de Kong, Gravitee et Apigee, ce serait le sujet d’un prochain billet. Je n’ai pas non plus mis en pratique le semantic caching ou la gestion des tokens dans un environnement de production. Ce billet documente une veille, pas un déploiement.

Pour aller plus loin

• Blog Gravitee : série AI Gateway (gravitee.io/blog, avril-juin 2026)
• OWASP Top 10 for LLM Applications 2025 : genai.owasp.org