AI Gateway 2026 : Switchyard vs LiteLLM vs Portkey

Un agent de codage fonctionne avec un fournisseur, mais échoue dès qu’un modèle devient indisponible, qu’un appel d’outil perd son format ou que les clés d’équipe ne sont plus traçables.

La solution la plus rapide consiste à évaluer Switchyard pour les agents locaux et le routage par étapes, LiteLLM pour la compatibilité multi-fournisseurs, et Portkey pour la gouvernance, la console et l’observabilité. Ce comparatif AI Gateway 2026 ne désigne donc pas un vainqueur universel : il associe chaque passerelle au problème qu’elle résout réellement.

Cet article s’adresse aux équipes qui veulent exposer une API unifiée à plusieurs modèles, aux ingénieurs plateforme qui gèrent les identifiants, les replis et les journaux d’utilisation, ainsi qu’aux développeurs qui souhaitent configurer Claude Code ou un autre agent sans réécrire toute leur intégration.

Dernière mise à jour : 14 août 2026. Les informations ont été vérifiées à partir des dépôts officiels, de la documentation d’installation, des licences et des pages de fonctionnalités de Switchyard, LiteLLM et Portkey.

Lecture rapide des trois approches

Le premier piège consiste à comparer uniquement le nombre de fournisseurs annoncés. Une passerelle peut accepter une requête de discussion simple tout en perdant les appels d’outils, le flux progressif, les sorties structurées ou les champs propres à un fournisseur.

Solution	Positionnement principal	API et intégration	Routage distinctif	Niveau de maturité à vérifier
Switchyard	Proxy et bibliothèque Rust pour agents de codage et modèles locaux	OpenAI Chat, OpenAI Responses et Anthropic Messages	Routage par classifieur, par étapes, escalade et répartition aléatoire	Le dépôt officiel le décrit comme pré-alpha et déconseille l’usage en production
LiteLLM	Proxy et SDK généralistes pour centraliser de nombreux modèles	Formats d’entrée et de sortie unifiés, proxy HTTP et SDK Python	Reprises, équilibrage, stratégies entre déploiements et suivi des dépenses	La séparation entre édition communautaire, fonctions Enterprise et services associés doit être vérifiée
Portkey	AI Gateway orienté plateforme, gouvernance et observabilité	API universelle, SDK, intégrations d’agents et fournisseurs	Repli, réessai, routage conditionnel, équilibrage, disjoncteur et tests canary	Les fonctions hébergées, open source et Enterprise ne sont pas équivalentes

Switchyard accepte les formats OpenAI Chat, OpenAI Responses et Anthropic Messages, et son dépôt indique une traduction vers des cibles comme vLLM, NVIDIA NIM, Ollama ou des points de terminaison compatibles OpenAI. Il expose également des métriques Prometheus concernant les requêtes, les erreurs, la latence, les jetons et le surcoût du routage. Documentation officielle de Switchyard

LiteLLM documente une interface unifiée pour plus de 100 modèles, avec des chemins tels que /chat/completions, /responses, /embeddings, /images, /audio et /batches. Cette largeur d’interface est utile lorsque l’application doit changer de fournisseur sans modifier chaque client, mais elle ne garantit pas que toutes les fonctions avancées se comporteront exactement de la même manière derrière chaque modèle. Documentation officielle de LiteLLM

Portkey documente une API universelle, les replis entre fournisseurs et modèles, le routage conditionnel, les limites de budget, les limites de débit, la gestion des délais, les tests canary et les points d’accès personnalisés pour des modèles privés ou locaux. Sa documentation signale aussi des fonctions distinctes pour les agents, MCP, la console et les déploiements hybrides. Fonctionnalités officielles d’AI Gateway

Vérification des protocoles et des clients

Pour Claude Code, le critère n’est pas simplement « l’API est-elle compatible avec Anthropic ? ». Il faut vérifier que la passerelle conserve les éléments utilisés par l’agent : appels d’outils, identifiants de conversation, résultats d’outils, réponses en flux, blocs de contenu et éventuels champs propres au fournisseur.

Switchyard se distingue ici par son objectif explicite : conserver le format natif d’un agent de codage tout en envoyant la requête vers un autre backend. Son serveur accepte les formats OpenAI Chat Completions, OpenAI Responses et Anthropic Messages, tandis que les modules de protocole et de traduction prennent en charge les types de flux. Cela le rend particulièrement intéressant pour un environnement où Claude Code reste le client, mais où le backend doit pouvoir changer.

LiteLLM convient mieux lorsqu’il faut fournir une façade commune à de nombreuses applications. Le proxy peut être utilisé avec un client OpenAI en modifiant principalement l’URL de base, puis en sélectionnant un modèle déclaré dans la configuration. La documentation sépare clairement le proxy centralisé du SDK Python embarqué dans une application. Guide officiel du proxy LiteLLM

Portkey propose également des bibliothèques Python, JavaScript et REST, ainsi que des intégrations avec plusieurs frameworks d’agents. La vérification doit néanmoins se faire sur le chemin exact utilisé par l’application : une intégration d’agent peut être documentée, alors qu’un champ particulier du fournisseur ou un appel d’outil complexe nécessite encore un test réel. Dépôt officiel de Portkey Gateway

Point de contrôle : une requête qui renvoie correctement du texte ne constitue pas une validation suffisante. Le scénario d’acceptation doit inclure une réponse en flux, un appel d’outil, une sortie structurée et une erreur de fournisseur.

Comparaison des modèles et des backends

La deuxième différence porte sur la manière de connecter les modèles. Les trois produits peuvent se placer devant des fournisseurs hébergés, mais leur centre de gravité n’est pas identique.

Switchyard est conçu pour des cibles configurées explicitement. Le dépôt décrit des backends locaux ou privés, notamment vLLM, Ollama, NVIDIA NIM et les endpoints compatibles OpenAI. Cette approche est pertinente lorsque l’équipe connaît ses cibles et souhaite garder la logique de routage près de l’agent ou de son infrastructure Rust. Elle demande en contrepartie davantage de validation manuelle dès qu’un fournisseur introduit une extension API.

LiteLLM possède une couverture plus large pour les équipes qui changent souvent de fournisseur. Le proxy centralise les noms de modèles, les paramètres d’authentification, les déploiements et les règles de sélection. La documentation cite notamment OpenAI, Anthropic, xAI, Vertex AI, NVIDIA, Hugging Face, Azure OpenAI et Ollama, mais la liste évolue : elle doit être contrôlée dans la documentation officielle au moment du déploiement, plutôt que copiée depuis un article ancien.

Portkey se situe entre la façade universelle et le plan de contrôle. Il documente les modèles hébergés, les fournisseurs courants, les endpoints privés et les cibles locales via des hôtes personnalisés. La présence d’un catalogue ou d’une intégration ne signifie toutefois pas que toutes les modalités sont identiques : vision, audio, génération d’images, appels d’outils et flux doivent être testés par cas d’usage.

Critère de décision	Switchyard	LiteLLM	Portkey
Modèles locaux	Très pertinent si les cibles sont déclarées et maîtrisées	Pertinent via intégrations et endpoints compatibles	Possible via hôtes personnalisés et déploiements adaptés
Nombre de fournisseurs	Moins important que la maîtrise du routage	Point fort central du proxy	Large couverture, avec gestion via plateforme
Agent de codage local	Priorité naturelle	Possible, surtout pour unifier les fournisseurs	Possible, avec davantage de fonctions de contrôle
Audio, vidéo et multimodalité	À valider selon le backend et la traduction	À valider modèle par modèle	Fonctionnalités multimodales documentées
Extensions propriétaires	Risque de perte à tester explicitement	Normalisation utile, mais certaines différences subsistent	Configurations et intégrations, avec validation nécessaire

Pour les équipes qui travaillent sur de l’audio, de la vidéo ou du design génératif, Portkey mérite une évaluation spécifique, car sa documentation expose plusieurs catégories multimodales. LiteLLM peut également servir de façade, mais l’équipe doit confirmer que le format de fichier, le flux binaire, les métadonnées et la facturation remontent correctement jusqu’à ses journaux.

Routage, repli et fiabilité

Un routage automatique n’améliore pas mécaniquement la fiabilité. Il peut même masquer une régression si la passerelle bascule vers un modèle moins capable sans conserver la raison du changement ni mesurer la qualité de la réponse.

Switchyard propose plusieurs stratégies : classifieur LLM, stage router, escalade et répartition aléatoire. Le stage router est particulièrement intéressant pour un agent : un résultat d’outil, une erreur précédente ou un signal de conversation peut déclencher un autre niveau de modèle sans ajouter systématiquement un appel de classification. Le dépôt officiel précise cependant que le projet est pré-alpha et expérimental ; ce point doit peser davantage qu’une démonstration réussie sur un dépôt de test.

LiteLLM est davantage orienté vers les reprises entre déploiements, les règles de routeur, l’équilibrage et la gestion opérationnelle d’un ensemble de fournisseurs. Cette structure est adaptée lorsqu’une équipe veut déclarer plusieurs cibles pour un même nom logique, par exemple un modèle principal et un modèle de secours. La reprise doit être liée à des erreurs précises : une limite de débit ou une indisponibilité temporaire ne se traite pas comme une réponse tronquée ou une sortie non conforme.

Portkey documente les replis, les réessais automatiques, l’équilibrage de clés, le disjoncteur, les délais d’attente et le routage conditionnel. Son dépôt montre également un exemple de configuration avec cinq tentatives de réessai, mais cette valeur est un exemple de configuration, pas une recommandation universelle. Règles de routage et de fiabilité de Portkey

La règle de décision est simple :

• si le besoin principal est de router les étapes d’un agent selon ses signaux internes, Switchyard est le premier candidat ;
• si le besoin principal est de répartir le trafic entre plusieurs déploiements et fournisseurs, LiteLLM est généralement plus naturel ;
• si le besoin inclut une politique d’équipe, une console, des limites et une visibilité centralisée, Portkey mérite la priorité.

Identifiants, budgets et gouvernance

Les clés d’API constituent souvent la première raison de mettre en place une passerelle. Sans couche intermédiaire, chaque application, poste de développeur ou agent peut conserver son propre secret, ce qui rend l’attribution des coûts et la révocation difficiles.

LiteLLM documente l’authentification, les clés virtuelles, les budgets par projet ou utilisateur, les limites de débit et le suivi des dépenses. Le proxy peut donc servir de point d’entrée commun pour une équipe plateforme. Les fonctions Enterprise, notamment la gestion multi-équipe, les journaux d’audit, le SSO ou les garde-fous, doivent être séparées du socle open source avant toute décision d’architecture.

Portkey va plus loin sur l’expérience de gouvernance : gestion des clés, contrôle d’accès par rôle, espaces de travail, règles entrantes, limites de budget et fonctions de conformité sont documentés dans le dépôt et dans les pages de produit. Certaines capacités relèvent néanmoins de l’offre hébergée ou Enterprise. Il ne faut donc pas écrire « Portkey open source possède toute la gouvernance de la plateforme » sans préciser le mode de déploiement.

Switchyard est plus léger sur cet axe. Son intérêt se situe dans la traduction de protocoles, la sélection des cibles et les algorithmes de routage. Une organisation qui a besoin de quotas par équipe, de rotation de secrets, de facturation interne et de contrôles fins devra probablement ajouter ces composants autour du proxy.

Journaux et observabilité

Un tableau de bord esthétique ne suffit pas. Pour diagnostiquer une erreur de modèle, le journal doit montrer au minimum la cible choisie, la raison du routage, le type d’erreur, la latence, les jetons, l’identifiant de requête et le résultat du repli. Les données sensibles doivent également être masquées avant stockage, avec une politique de conservation définie.

Switchyard annonce des métriques Prometheus sur les requêtes, erreurs, latences, jetons et surcoût du routage. Cette base convient à une équipe qui possède déjà son système de supervision et veut intégrer le proxy à ses propres tableaux de bord.

LiteLLM fournit des points d’accroche pour l’authentification et les journaux, ainsi que le suivi des coûts et de la latence en fonction de la configuration. L’équipe devra décider si elle conserve les entrées et sorties complètes, uniquement les métadonnées, ou un échantillon. Cette décision devient importante pour les agents qui manipulent du code privé, des fichiers de design ou des contenus audio et vidéo.

Portkey met davantage l’accent sur les traces, la console et la corrélation des appels d’agents. Sa documentation d’observabilité indique que les journaux peuvent inclure l’utilisateur, l’équipe, l’outil, les paramètres, la réponse, la latence et le statut. Cela peut simplifier l’audit, mais l’équipe doit vérifier la résidence des données, la redaction des informations personnelles et la durée de conservation associées au plan choisi. Documentation officielle de l’observabilité Portkey

Autohébergement et coût d’exploitation

L’autohébergement ne se résume pas à lancer un conteneur. Il faut prévoir les secrets, la persistance des configurations, le contrôle des versions, la sauvegarde, la rotation des clés, la surveillance, le retour arrière et la procédure de reprise après incident.

Switchyard demande une attention particulière, car le chemin serveur officiel passe par Rust et Cargo, tandis que le chemin destiné aux agents utilise un outil Python. Cette séparation peut être avantageuse pour un environnement de développement, mais elle augmente le nombre de parcours à tester. La licence Apache 2.0 est indiquée dans le dépôt, tout comme le statut pré-alpha et l’avertissement de non-utilisation en production.

LiteLLM documente une installation par outil Python, un lancement Docker, un fichier de configuration et une base de données pour certains usages du proxy. L’approche est accessible, mais la maintenance d’un proxy généraliste implique de suivre les changements de fournisseurs, les dépendances, les migrations et les modifications de comportement des modèles.

Portkey peut être lancé localement avec npx @portkey-ai/gateway, et son dépôt montre un endpoint local ainsi qu’une console locale. Le produit distingue cependant la passerelle open source, le service hébergé et la version Enterprise, avec des chemins de déploiement privés pour certaines organisations.

Pour une équipe qui prépare un environnement isolé, la documentation d’aide de nuvcloud peut compléter la préparation opérationnelle : accès, séparation des environnements, livraison des identifiants et procédure de dépannage doivent être définis avant l’arrivée du trafic réel.

FAQ de sélection

Switchyard et LiteLLM pour Claude Code

Switchyard est le choix à examiner lorsque Claude Code doit rester sur son protocole natif et que l’agent doit être dirigé vers des modèles locaux ou un backend compatible. LiteLLM est préférable si Claude Code n’est qu’un client parmi d’autres et que l’objectif principal est de centraliser plusieurs fournisseurs, les clés et les budgets. Dans les deux cas, les appels d’outils et les réponses en flux doivent être validés sur le projet réel.

LiteLLM et Portkey pour une plateforme produit

LiteLLM fonctionne comme une couche de compatibilité et de routage très large, avec un proxy central et un SDK. Portkey ajoute une couche de pilotage plus visible, comprenant console, observabilité, garde-fous, configurations de routage et intégrations d’agents. Une équipe qui veut maîtriser le code et l’infrastructure peut commencer par LiteLLM ; une organisation qui veut réduire le développement interne de fonctions de gouvernance peut évaluer Portkey.

Autohébergement

Switchyard est séduisant pour un petit proxy local ou un laboratoire de routage, mais son statut pré-alpha interdit de le traiter comme un composant de production sans validation approfondie. LiteLLM constitue le choix généraliste le plus évident pour un proxy autohébergé multi-fournisseurs. Portkey devient pertinent lorsque l’équipe accepte de séparer le moteur local, la console et les fonctions de gouvernance selon l’édition retenue.

Repli et routage

La bonne méthode consiste à définir une matrice d’erreurs avant de configurer le repli. Une erreur de quota peut déclencher une autre clé ou un autre fournisseur ; une sortie structurée invalide peut imposer une nouvelle tentative avec un schéma corrigé ; une réponse de mauvaise qualité doit être évaluée par un test métier, et non simplement considérée comme une panne. Les règles doivent être observables et réversibles.

Équipe de développement

Pour une équipe individuelle ou un petit groupe qui veut expérimenter avec un agent de codage, Switchyard offre une direction claire, à condition d’accepter son niveau de maturité. Pour une équipe produit en croissance, LiteLLM apporte généralement le meilleur compromis entre compatibilité et contrôle du proxy. Pour une plateforme d’entreprise, Portkey doit être évalué lorsque l’audit, les équipes, les budgets et la visibilité des agents sont prioritaires.

Grille d’acceptation avant production

Avant de remplacer l’architecture actuelle, l’équipe devrait cocher chaque point avec les trois solutions présélectionnées :

• [ ] Le client réel fonctionne avec son API native, y compris le streaming.
• [ ] Les appels d’outils conservent leurs paramètres, identifiants et résultats.
• [ ] Les sorties structurées sont vérifiées avec plusieurs modèles.
• [ ] Les extensions propres au fournisseur sont documentées ou volontairement exclues.
• [ ] Une panne de fournisseur, une limite de débit et un délai d’attente ont été injectés.
• [ ] Le journal indique la cible, la raison du routage et le résultat du repli.
• [ ] Les secrets ne sont jamais écrits dans les journaux applicatifs.
• [ ] Les coûts sont attribuables à une équipe, un projet ou un utilisateur.
• [ ] La procédure de retour à la configuration précédente a été testée.
• [ ] La qualité des réponses de secours est mesurée sur les tâches réelles de l’agent.

Cette étape est plus fiable qu’un classement fondé sur des scores de performance non reproductibles. Le routage doit être évalué sur les erreurs réellement observées, le taux de réussite des outils, la qualité des sorties et la capacité de l’équipe à maintenir la configuration.

Choix final selon le type d’équipe

Pour un agent de codage personnel ou local : Switchyard est le candidat logique si l’objectif est de relier Claude Code à des modèles locaux, d’expérimenter le routage par étapes ou de contrôler directement la logique dans un environnement Rust. Son statut pré-alpha impose cependant un périmètre isolé et une solution de retour immédiat.

Pour une application AI en croissance : LiteLLM est généralement le meilleur point de départ lorsque l’application doit changer de fournisseur, équilibrer plusieurs déploiements, appliquer des reprises et suivre les dépenses sans construire elle-même toute la couche d’abstraction.

Pour une plateforme d’entreprise : Portkey mérite l’évaluation prioritaire lorsque la décision inclut une console, des traces d’agents, des espaces de travail, des règles d’accès, des limites budgétaires et un parcours de gouvernance. L’équipe doit comparer séparément les fonctions open source, hébergées et Enterprise.

Le choix ne devrait être officialisé qu’après un test avec les vrais clients, les vrais backends et des erreurs injectées. Une configuration qui fonctionne avec une simple requête de discussion peut encore échouer dès qu’un agent enchaîne un appel d’outil, une réponse en flux et un repli vers un autre fournisseur.

Si l’architecture actuelle repose sur des clés dispersées dans les postes de développement, des scripts de repli propres à chaque application et des journaux incomplets, elle crée trois défauts durables : les coûts sont difficiles à attribuer, les pannes sont plus longues à diagnostiquer et les changements de modèle deviennent risqués. Pour une équipe qui doit seulement tester un AI Gateway, isoler un agent de codage ou valider un backend local, louer un environnement Mac auprès de nuvcloud peut offrir un cadre plus propre qu’un poste partagé ou qu’une machine temporaire mal documentée. La location ne remplace pas un serveur permanent pour une charge lourde et stable, mais elle convient mieux à une phase d’essai, à une validation de protocole ou à un environnement de développement séparé. Les équipes qui envisagent ce type de séparation peuvent consulter la présentation de nuvcloud et de ses environnements Mac avant de définir leur procédure de livraison des identifiants et d’acceptation des pannes.