# LiteLLM vs agentgateway vs skilder : trois couches, pas trois rivaux

> LiteLLM se place devant les modèles, agentgateway devant les outils et les agents, skilder définit les rôles qu'un agent exerce. Ce que chacun gouverne, où il se situe dans la requête, et lequel déployer en premier.

Language: fr · Category: engineering · Author: Nicolas Corod (Fondateur & CEO) · Published: 2026-09-30

## En bref

**LiteLLM, agentgateway et skilder apparaissent dans les mêmes revues d'architecture, et ils sont rarement des alternatives l'un à l'autre.** LiteLLM est une passerelle de modèles : un point d'entrée compatible OpenAI devant plus de 100 fournisseurs de LLM, qui mesure chaque appel. agentgateway est une passerelle d'agents et d'outils : elle relaie le trafic MCP, A2A et LLM et applique une politique à chaque requête. skilder est la couche des rôles : elle définit ce qu'un agent peut faire pour un poste de l'organigramme, sous forme de skills, d'outils au périmètre défini et de permissions, et le sert à la demande. La bonne question n'est pas « lequel » mais « lequel en premier, et que laisse-t-il ouvert ».

## La question derrière la comparaison

Une équipe plateforme qui évalue des agents en 2026 rencontre trois catégories de produits au vocabulaire commun. Les trois parlent de gouvernance, d'observabilité et de MCP. Les trois publient un schéma avec un agent à gauche et les systèmes de l'entreprise à droite. Une seule chose les sépare nettement : l'unité que chacun contrôle. Un appel de modèle, un appel d'outil, ou un travail.

Cet article prend les trois noms le plus souvent écrits sur le même tableau blanc et les trie selon cette unité. Les faits sur LiteLLM et agentgateway viennent de leur propre documentation et de leurs dépôts, liés au fil du texte.

## Couche 1 : la passerelle de modèles (LiteLLM)

[LiteLLM](https://github.com/BerriAI/litellm) se présente comme « an open source AI Gateway that gives you a single, unified interface to call 100+ LLM providers ». Il existe sous deux formes : un SDK Python pour l'intégration directe, et un serveur proxy, ce que la plupart des équipes appellent « la passerelle ». Les applications appellent le proxy au format OpenAI ; le proxy traduit vers OpenAI, Anthropic, Gemini, Bedrock, Azure et les autres.

La liste de fonctions du proxy, d'après la [documentation du proxy LiteLLM](https://docs.litellm.ai/docs/simple_proxy), est celle d'une passerelle de modèles : clés virtuelles, suivi des dépenses avec « budgets + rate limits » par clé ou par utilisateur, « load balancing, routing, fallbacks (failover) » entre déploiements, garde-fous sur les requêtes et les réponses, et « logging, alerting, metrics » via des intégrations comme Langfuse et MLflow. Le déploiement se fait par `pip`, Docker ou Helm ; la configuration est un `config.yaml` qui liste les modèles et leurs identifiants.

Licence : le dépôt est sous [licence MIT](https://github.com/BerriAI/litellm/blob/main/LICENSE), avec une exception inscrite dans le texte de la licence : le contenu du répertoire `enterprise/` relève d'une licence distincte. Le SSO et certaines fonctions d'administration se trouvent derrière cette licence commerciale, d'après le README.

L'unité de contrôle est l'**appel de modèle**. LiteLLM décide quel fournisseur répond, à quel coût, sous quelle clé, et enregistre le résultat. Il ne sait pas quel outil l'agent appellera ensuite, ni quel travail la personne était en train de faire.

## Couche 2 : la passerelle d'agents et d'outils (agentgateway)

[agentgateway](https://github.com/agentgateway/agentgateway) se décrit comme un « next generation agentic proxy for AI agents and MCP servers », offrant « drop-in security, observability, and governance for agent-to-LLM, agent-to-tool, and agent-to-agent communication ». Il est écrit en Rust, sous licence [Apache 2.0](https://github.com/agentgateway/agentgateway/blob/main/LICENSE), et hébergé par la Linux Foundation depuis que [solo.io a donné le projet](https://agentgateway.dev/).

Là où LiteLLM part du modèle, agentgateway part des protocoles que parle un agent. Le README liste une passerelle MCP avec « tool federation, stdio/HTTP/SSE/Streamable HTTP transports », une passerelle A2A pour « secure agent-to-agent communication », et une passerelle LLM avec « budget and spend controls, prompt enrichment, load balancing, and failover ». Les politiques s'appliquent par « auth (JWT, API keys, OAuth), fine-grained RBAC with CEL policy engine, rate limiting », et la télémétrie passe par OpenTelemetry (métriques, journaux, traces). Il tourne en binaire autonome piloté par YAML, dans Docker, ou sur Kubernetes avec un contrôleur intégré et le support de la Gateway API, d'après la [documentation de déploiement](https://agentgateway.dev/docs/).

L'unité de contrôle est l'**appel d'outil** (et l'appel d'agent à agent). agentgateway peut autoriser un outil sur un serveur MCP et en refuser un autre, multiplexer plusieurs serveurs derrière un seul point d'entrée, et journaliser quelle identité a appelé quel outil. C'est le point d'application dont un [registre MCP](/fr/blog/shadow-mcp/) a besoin pour que « approuvé » veuille dire quelque chose à l'exécution. Il ne décide pas quels outils un travail donné requiert, et il ne porte pas les instructions qui rendent un agent bon à ce travail.

## Couche 3 : la couche des rôles et du contexte (skilder)

Un **rôle**, dans le vocabulaire de skilder, c'est le travail que fait réellement un poste de l'organigramme, assemblé à partir de skills au [format ouvert Agent Skill](https://docs.skilder.ai) (fichiers SKILL.md), d'outils MCP au périmètre défini tirés d'un registre interne et curé de serveurs, du contexte dont ils ont besoin, et des permissions qui les bornent. Un rôle se configure depuis un blueprint sur les processus propres d'une équipe, puis il est servi via MCP à l'agent que la personne utilise déjà : Claude, ChatGPT, Copilot ou un client interne.

skilder n'est pas une passerelle. Il ne se place pas entre l'agent et le modèle à chaque token, et il ne relaie pas le trafic MCP brut. Il se situe un niveau au-dessus et répond à une question qu'aucune des deux passerelles ne pose : **qu'est-ce que cet agent a le droit et les moyens de faire, pour ce travail, maintenant ?** La réponse est le rôle. Ses skills et ses outils sont chargés à la demande, au moment où la tâche en a besoin, plutôt que déversés dans la fenêtre de contexte à l'ouverture de la session, ce qui est tout l'enjeu du problème de [context bloat](/fr/blog/du-context-bloat-au-context-load/).

La gouvernance chez skilder est celle du rôle : paquets versionnés et signés, promotion et retour arrière à l'échelle de l'organisation, accès par rôle, trace d'exécution attribuable à la personne qui a lancé la tâche, et usage qui montre quels rôles servent, à qui et à quelle fréquence. Le choix du modèle est routé par tâche parmi plus de 100 modèles, si bien que le rôle ne change pas quand le fournisseur change.

L'unité de contrôle est le **travail**. C'est aussi la limite de ce que fait skilder : il ne mesure pas les tokens par fournisseur comme LiteLLM, et il n'applique pas de politique réseau à un trafic MCP quelconque comme agentgateway.

## Côte à côte

| | LiteLLM | agentgateway | skilder |
| --- | --- | --- | --- |
| Ce qu'il gouverne | Les appels de modèles ([source](https://github.com/BerriAI/litellm)) | Les appels d'outils, d'agents et de modèles en transit ([source](https://github.com/agentgateway/agentgateway)) | Ce qu'un agent peut faire pour un travail : skills, outils au périmètre défini, permissions ([source](https://docs.skilder.ai)) |
| Unité de contrôle | La requête vers un modèle, par clé virtuelle | La requête MCP, A2A ou LLM, par identité et politique | Le rôle, par personne et par équipe |
| Surface de protocole | API compatible OpenAI en entrée, plus de 100 fournisseurs en sortie ; registre de serveurs MCP par clé et par équipe ([source](https://docs.litellm.ai/docs/mcp)) | MCP (stdio, HTTP, SSE, Streamable HTTP), A2A, routage LLM compatible OpenAI | Rôles exposés comme serveurs MCP à tout client MCP ; skills en SKILL.md |
| Qui le configure | L'équipe plateforme ou ML, via `config.yaml` et l'interface d'administration | L'équipe plateforme ou réseau, via YAML ou la Gateway API de Kubernetes | Les builders et les experts métier, depuis un blueprint dans une interface visuelle |
| Licence | MIT, avec une licence distincte pour le répertoire `enterprise/` ([source](https://github.com/BerriAI/litellm/blob/main/LICENSE)) | Apache 2.0 ([source](https://github.com/agentgateway/agentgateway/blob/main/LICENSE)) | SaaS multi-tenant, déploiement privé sur demande |
| Où il tourne | Auto-hébergé : pip, Docker, Helm | Auto-hébergé : binaire, Docker, Kubernetes | Hébergé en Suisse et dans l'UE par défaut ; on-premise sur demande |

## Là où ils se recouvrent, honnêtement

Les trois ne sont pas disjoints, et c'est sur les recouvrements qu'une revue se perd.

**LiteLLM avance vers les outils.** Sa [passerelle MCP](https://docs.litellm.ai/docs/mcp) permet à un administrateur d'enregistrer des serveurs MCP une fois, d'« use a fixed endpoint for all MCP tools and control MCP access by key, team », et d'exposer ces outils via les points d'entrée `/v1/chat/completions` et `/v1/responses` sur tous les modèles pris en charge. Si les outils dont un agent a besoin sont peu nombreux et que l'agent est une application écrite par l'équipe plateforme, cela peut suffire comme gouvernance des outils.

**agentgateway avance vers les modèles.** Sa passerelle LLM gère budgets, dépenses et bascule entre fournisseurs. Si le trafic qui compte est MCP et A2A, ajouter le routage de modèles dans le même data plane évite un second proxy.

**skilder route les modèles et délimite les outils, mais par rôle.** Un rôle ne peut atteindre que les serveurs MCP déjà présents dans le registre de son workspace, et une tâche est routée vers un modèle choisi pour le coût, la latence ou la sensibilité. C'est une politique au niveau du travail, pas du réseau. Elle complète une passerelle ; elle ne remplace pas l'application au niveau des paquets qu'une passerelle apporte.

La distinction qui tient : une passerelle décide si un appel passe. Un rôle décide si l'appel fait partie du travail, et porte le savoir-faire qui rend l'appel utile.

## Lequel vous faut-il en premier

Partez de la question que votre organisation se pose ce trimestre.

1. **« Notre dépense de modèles est répartie sur cinq fournisseurs et personne ne peut l'attribuer. »** Une passerelle de modèles. Les clés virtuelles et les budgets de LiteLLM y répondent directement, et le côté applicatif change à peine puisque l'interface reste au format OpenAI.
2. **« Des collaborateurs et des agents internes branchent des serveurs MCP que personne n'a revus. »** Une passerelle d'agents, devant un registre interne. C'est le problème du [shadow MCP](/fr/blog/shadow-mcp/), et il demande un point d'application à l'exécution, pas un tableur.
3. **« Personne ne sait dire ce qu'un agent a le droit de faire pour un travail donné, ni pourquoi il fait le travail différemment pour chaque personne. »** Une couche de rôles. C'est la question qui reste ouverte une fois les deux passerelles en place, parce qu'une passerelle applique des règles aux appels et ne dit rien de la tâche. C'est aussi là que vit le savoir-faire de l'entreprise, et là que les [skills par-dessus les outils MCP](/fr/blog/au-dela-de-mcp-vs-skills/) transforment une installation gouvernée en installation utilisable.

Deux sur trois est la réponse la plus courante. Une passerelle de modèles plus une couche de rôles couvre une entreprise dont les agents sont les clients des éditeurs (Claude, ChatGPT, Copilot) et dont les outils passent par un registre curé. Une passerelle d'agents plus une couche de rôles couvre une entreprise qui fait tourner ses propres agents sur Kubernetes avec du trafic MCP à surveiller. Les trois ensemble se justifient à grande échelle, et font double emploi avant.

## En résumé

LiteLLM mesure le modèle. agentgateway surveille le fil. skilder définit le travail. Confondre les trois coûte un trimestre d'évaluation ; les empiler dans le bon ordre coûte un fichier de configuration chacun.

Pour voir à quoi ressemble un rôle en pratique, configurez-en un premier depuis un blueprint sur [app.skilder.ai/signup](https://app.skilder.ai/signup), ou lisez comment un rôle est exposé à un client MCP dans la [documentation](https://docs.skilder.ai).