Classement 2026 des proxys LLM : 4 choix comparés

Vous jonglez entre plusieurs clés API, des formats incompatibles et des factures difficiles à attribuer ? Pour le classement 2026 des proxys LLM, choisissez LiteLLM pour un gateway auto-hébergé généraliste, Switchyard pour les agents de programmation et les modèles ouverts, OpenRouter pour démarrer vite avec du routage hébergé, et Portkey si la gouvernance et l’observabilité priment.

Qui doit lire ce comparatif

Ce guide s’adresse aux équipes qui construisent une entrée unique pour plusieurs modèles, aux développeurs qui veulent réduire le code d’intégration et aux architectes qui hésitent entre auto-hébergement, service hébergé et architecture hybride.

Le classement n’est pas un ordre absolu de 1 à 4. Un proxy performant pour un laboratoire local peut être un mauvais choix pour une plateforme réglementée.

Dernière mise à jour : 13 août 2026. Les fonctions et modes de déploiement ont été vérifiés à partir des dépôts et documentations officielles disponibles à cette date. Les scores doivent être réévalués après une évolution de licence, de politique de données ou de couverture fournisseur.

Commencer par séparer les familles

La première erreur consiste à placer les quatre outils dans un tableau de notes unique. Ils ne jouent pas exactement le même rôle.

LiteLLM est un proxy et un gateway que vous pouvez exécuter dans votre environnement. Sa documentation décrit une interface compatible avec plus de 100 modèles, des retraits de fournisseurs, des clés virtuelles, le suivi des dépenses et des budgets par projet. Il vise donc une fonction de plateforme interne. Consultez la documentation officielle de LiteLLM.

Switchyard est un proxy Python orienté trafic LLM. Son dépôt officiel met en avant la traduction entre les formats OpenAI Chat, Anthropic Messages et OpenAI Responses, ainsi que des lanceurs pour des agents comme Claude Code ou Codex. C’est une proposition plus spécialisée, utile lorsque l’agent doit conserver son protocole habituel tout en ciblant un modèle ouvert, vLLM, Ollama ou un endpoint compatible OpenAI. Le dépôt officiel de Switchyard constitue la référence à vérifier avant tout déploiement.

OpenRouter est un service de routage hébergé. Vous déléguez l’exploitation du proxy et accédez à plusieurs fournisseurs derrière une interface commune. Ses réglages de confidentialité peuvent filtrer les endpoints qui déclarent une politique de conservation nulle, y compris au niveau d’une requête. La documentation officielle sur la conservation nulle d’OpenRouter détaille ce mécanisme.

Portkey se situe entre passerelle et plateforme de gouvernance. Sa documentation présente le routage conditionnel, les replis, les tentatives automatiques, la mise en cache, les limites budgétaires, les garde-fous et l’observabilité. Le gateway open source peut être lancé localement, mais l’expérience de gouvernance complète dépend du périmètre de la plateforme retenue. Reportez-vous à la documentation officielle du gateway Portkey.

Lire le classement selon votre équipe

Voici le seul tableau de synthèse de l’article. Il ne mélange pas les solutions comme si elles avaient le même mode d’exploitation.

Ces scores sont des scores de décision, pas des mesures de débit ou de latence. Les données disponibles ne permettent pas de conclure honnêtement sur un vainqueur universel en performances.

Choisir OpenRouter pour un démarrage rapide

OpenRouter convient à une équipe qui veut tester rapidement plusieurs modèles sans construire immédiatement une couche d’exploitation. Vous évitez le déploiement d’un serveur, la rotation initiale de vos propres composants et une partie de la configuration des fournisseurs.

Le coût caché est ailleurs. Vous devez comprendre quel endpoint reçoit réellement la requête, quelles règles de classement sont appliquées et quelles données sont conservées. La documentation d’OpenRouter distingue la conservation des données, l’utilisation pour l’entraînement et les politiques propres à chaque endpoint. Si la plateforme ne peut pas confirmer clairement la politique d’un endpoint, elle indique adopter une approche prudente et le traiter comme conservant et utilisant potentiellement les données pour l’entraînement.

Pour un prototype audio, vidéo ou design, cette approche est efficace : vous pouvez comparer rapidement plusieurs modèles de transcription, de vision ou de génération sans refaire l’intégration à chaque essai. Pour un produit manipulant des contrats, du code propriétaire ou des données personnelles, le réglage « ZDR » doit être contrôlé par modèle et par fournisseur, puis confronté au contrat réel.

OpenRouter permet aussi de définir des préférences de routage et de sélectionner certains fournisseurs. Ces réglages améliorent la lisibilité du chemin d’exécution, mais ils ne suppriment pas la nécessité de vérifier le fournisseur réellement utilisé en cas de repli. La documentation officielle du routage et de la sélection des fournisseurs doit être consultée avant une mise en production.

Éliminez OpenRouter dans trois cas : votre réseau doit bloquer toute sortie directe vers un agrégateur, vos journaux doivent être entièrement conservés dans votre infrastructure, ou votre service juridique refuse une chaîne de sous-traitants difficile à cartographier.

Retenir LiteLLM pour une plateforme auto-hébergée

Pour répondre à la question du gateway auto-hébergé, LiteLLM est le choix le plus équilibré des quatre. Il fournit une interface commune, des mécanismes de reprise et de routage, des clés virtuelles, des limites de dépense et des fonctions de suivi. La documentation distingue clairement le serveur proxy central du SDK Python intégré directement dans une application.

Cette centralisation résout plusieurs problèmes concrets :

• les clés des fournisseurs ne sont plus dispersées dans chaque dépôt ;
• les équipes peuvent recevoir des clés virtuelles limitées à un projet ou à un usage ;
• les dépenses peuvent être attribuées à un service plutôt qu’à une facture globale ;
• les changements de fournisseur se font derrière un endpoint interne ;
• les replis peuvent éviter qu’une panne d’un déploiement interrompe toute l’application.

Mais LiteLLM n’est pas une architecture de production complète. Vous devez ajouter un stockage de secrets, une base de données si votre configuration l’exige, un cache adapté, des métriques, une collecte de journaux, une politique de rotation et un mécanisme de déploiement redondant. Le proxy devient alors un composant critique du chemin des données. Une panne, une mauvaise règle de routage ou une clé trop permissive peut toucher plusieurs applications à la fois.

Pour une équipe de développement, attribuez une clé virtuelle par service, imposez une liste de modèles autorisés et distinguez les budgets de test, de préproduction et de production. Pour une équipe vidéo ou créative, séparez aussi les appels image, audio et texte : les unités de coût, les délais d’attente et les exigences de conservation ne sont pas identiques.

LiteLLM est moins approprié si vous recherchez uniquement une expérience prête à l’emploi sans responsabilité d’exploitation. Dans ce cas, le temps consacré aux sauvegardes, à la supervision, à la gestion des certificats et aux mises à jour peut dépasser le bénéfice d’un contrôle complet.

Évaluer Switchyard pour les agents de programmation

Switchyard doit être évalué comme un outil de routage spécialisé, pas comme un remplaçant automatique d’un portail d’administration d’entreprise. Le dépôt officiel indique qu’il peut traduire plusieurs protocoles et lancer des clients d’agents avec une configuration locale. Il collecte également des statistiques par requête, notamment la latence, les jetons et le coût.

Son intérêt apparaît lorsque vous voulez conserver le comportement d’un agent tout en changeant le backend. Un agent qui parle Anthropic Messages peut être relié à un modèle servi par un endpoint compatible OpenAI. Vous pouvez aussi définir des profils, tester plusieurs modèles ou créer un routage par étapes.

La limite de décision est opérationnelle. Avant d’en faire l’entrée commune de plusieurs équipes, vérifiez au minimum :

1. le mode d’authentification exposé par votre déploiement ;
2. la protection de l’endpoint d’administration ;
3. la rotation et le stockage des secrets ;
4. la persistance des statistiques ;
5. la compatibilité avec vos outils de supervision ;
6. la stratégie de mise à jour et de retour arrière.

Pour une équipe qui expérimente des modèles locaux, Switchyard peut être plus naturel que LiteLLM grâce à ses lanceurs et à sa traduction de protocoles. Pour une organisation qui doit appliquer des budgets par département, des rôles, des journaux d’audit et une haute disponibilité documentée, LiteLLM ou Portkey mérite une validation prioritaire.

Dans un flux de développement assisté, ne mesurez pas uniquement la réussite de la requête. Contrôlez aussi la conservation du format des outils, la gestion des appels interrompus, la répétition éventuelle d’une commande et le comportement lorsque le modèle de repli ne prend pas en charge la même fonction.

Positionner Portkey sur la gouvernance

Portkey devient intéressant quand le problème n’est plus seulement « comment appeler plusieurs modèles ? », mais « comment encadrer ces appels dans un produit exploité par plusieurs équipes ? ».

Sa documentation liste des replis, du routage conditionnel, des délais d’expiration, des disjoncteurs, de l’équilibrage de clés, des tests canari, des limites de budget et des limites de débit. Elle mentionne aussi une mise en cache simple ou sémantique et des garde-fous intégrés.

Ces fonctions répondent à des coûts souvent oubliés : une boucle d’agent qui multiplie les appels, une clé fournisseur limitée par le débit, un modèle indisponible dans une région, ou une invite sensible copiée dans des journaux trop détaillés.

La séparation entre le composant open source et la plateforme hébergée est toutefois essentielle. Un gateway lancé localement ne signifie pas automatiquement que vos tableaux de bord, vos journaux, vos garde-fous et vos politiques sont également locaux. Demandez le chemin de chaque donnée : invite, réponse, métadonnées, identifiant utilisateur, contenu mis en cache et traces d’erreur.

Portkey est donc un choix de gouvernance, pas nécessairement le choix le plus simple. Une petite équipe qui ne possède ni responsable sécurité ni administrateur de plateforme peut exploiter seulement une partie de ses fonctions. Une équipe structurée peut, au contraire, justifier sa complexité par la réduction du nombre de contrôles dispersés dans les applications.

Contrôler les risques avant la mise en production

Un proxy LLM ajoute une couche de contrôle, mais aussi une nouvelle zone de confiance. Vous devez analyser au moins quatre limites.

Le trajet réseau. Une requête peut passer par votre application, le proxy, un agrégateur, un fournisseur principal et un fournisseur de repli. La conformité doit couvrir toute la chaîne, pas seulement votre serveur.

Les journaux. Les tokens, les invites et les réponses peuvent apparaître dans les traces applicatives ou les outils d’observabilité. Activez la minimisation des données et séparez les journaux de diagnostic des journaux d’audit.

La mise en cache. Une réponse mise en cache peut réduire les appels répétés, mais elle augmente la durée de vie potentielle d’un contenu. Pour un projet client, confirmez la portée de la clé de cache et la procédure d’effacement.

Les règles de fournisseur. Une option de conservation nulle ne signifie pas que tous les endpoints ont la même politique. Un agrégateur peut filtrer les fournisseurs compatibles avec certaines exigences, mais la responsabilité de vérifier l’application réelle de ces règles reste à votre équipe.

Attention : ne déduisez jamais la conformité d’un simple bouton « privé ». Faites valider le chemin des données, les sous-traitants, la conservation et l’entraînement par votre équipe sécurité ou juridique.

Déployer sans confondre proxy et haute disponibilité

Suivez cette séquence avant d’ouvrir le gateway à plusieurs applications :

1. Cartographiez les modèles. Classez-les par usage, région, données acceptables, limite de débit et coût de sortie.
2. Créez une identité par application. N’utilisez pas une seule clé maître dans tous les environnements.
3. Définissez les routes de secours. Précisez le comportement lorsque le fournisseur principal renvoie une erreur, dépasse un délai ou atteint sa limite.
4. Fixez les budgets. Ajoutez des plafonds par équipe, mais aussi des limites de débit afin de détecter une dépense anormalement rapide.
5. Testez les journaux. Envoyez une donnée fictive et vérifiez ce qui est conservé, masqué, exporté ou indexé.
6. Simulez une panne. Coupez un endpoint et mesurez si le repli conserve le format de réponse attendu par votre application.
7. Documentez le retour arrière. Une mise à jour du proxy ou d’un modèle doit pouvoir être annulée sans modifier tous les clients.
8. Répétez l’audit après chaque changement. Une nouvelle route, un nouveau fournisseur ou une nouvelle fonction de cache peut modifier le périmètre de risque.

Pour un environnement distant destiné à la compilation, aux tests d’agents ou à la création audio et vidéo, vérifiez aussi la stabilité de la connexion, l’accès SSH ou VNC, le stockage temporaire et les permissions locales. Vous pouvez commencer par examiner les environnements disponibles pour vos essais, puis choisir une région adaptée à votre équipe plutôt que de déplacer uniquement le proxy.

Appliquer le classement par profil

Développeur individuel ou petite équipe : OpenRouter. Choisissez-le si votre priorité est l’expérimentation multi-modèles et la réduction du temps de démarrage. Éliminez-le si vos exigences imposent un contrôle réseau ou contractuel complet.

Plateforme interne : LiteLLM. Choisissez-le si vous acceptez d’exploiter un service central et ses dépendances. Éliminez-le si personne ne peut assurer la supervision, les correctifs et la rotation des secrets.

Agents de programmation et modèles ouverts : Switchyard. Choisissez-le si la traduction de protocoles et les profils d’agents sont votre besoin central. Éliminez-le comme gateway transversal tant que vos contrôles d’identité, d’administration et d’audit ne sont pas validés.

Entreprise orientée gouvernance : Portkey. Choisissez-le si les garde-fous, les limites, le cache et l’observabilité doivent être réunis dans une même expérience. Éliminez-le si le périmètre exact de la plateforme hébergée ne convient pas à vos règles de résidence ou de conservation.

Réponses aux questions de sélection

Quel proxy LLM convient le mieux à une entreprise en 2026 ?

Il n’existe pas de vainqueur universel. Pour une entreprise qui veut garder le contrôle de son réseau et de ses identités, LiteLLM constitue généralement le meilleur point de départ auto-hébergé. Portkey est plus pertinent si vous recherchez une plateforme de gouvernance et d’observabilité intégrée. OpenRouter convient surtout au routage multi-fournisseurs rapide, après validation contractuelle des politiques de données.

Que choisir pour un LLM Gateway auto-hébergé ?

Commencez par LiteLLM si vos priorités sont l’API unifiée, les clés virtuelles, les budgets par projet, les journaux et les mécanismes de reprise. Prévoyez toutefois une base de données, un stockage de secrets, un cache, des métriques et une stratégie haute disponibilité. Switchyard mérite plutôt une évaluation ciblée pour les agents de programmation et les modèles locaux.

Quelle différence entre OpenRouter et LiteLLM ?

OpenRouter est un service hébergé qui simplifie l’accès à plusieurs fournisseurs et propose des règles de routage ainsi que des options de conservation nulle. LiteLLM est principalement un proxy que vous pouvez déployer dans votre environnement. Le premier réduit l’exploitation quotidienne ; le second vous donne davantage de contrôle sur le chemin réseau, les clés et les journaux.

Portkey permet-il de gérer plusieurs modèles au même endroit ?

Oui, Portkey combine une API unifiée avec des fonctions de routage, reprise sur erreur, mise en cache, limites budgétaires, garde-fous et observabilité. Cette richesse est intéressante pour une équipe produit ou une DSI. Elle implique néanmoins de distinguer le composant de passerelle open source de la plateforme hébergée, puis de vérifier où sont stockés les journaux.

Quels risques liés aux données faut-il vérifier avant de choisir un proxy LLM ?

Examinez le trajet exact des requêtes, les journaux conservés, les invites utilisées pour l’analyse, la mise en cache, l’entraînement éventuel des fournisseurs et les règles de suppression. Une option « zéro conservation » ne remplace pas une revue contractuelle : la politique peut varier selon le modèle, le point d’accès et le fournisseur effectivement sélectionné.

Faire le dernier arbitrage avec votre environnement d’exécution

Un proxy hébergé vous fait gagner du temps, mais vous ajoutez une dépendance au routage externe, aux politiques de conservation et à la disponibilité d’un intermédiaire. Un proxy auto-hébergé vous donne davantage de contrôle, mais il vous impose les mises à jour, les sauvegardes, la surveillance, la gestion des secrets et la reprise après incident. Un poste local peut convenir pour un test ponctuel, mais il devient vite limité lorsque plusieurs agents, développeurs ou flux audio et vidéo doivent partager le même environnement.

Pour une expérimentation temporaire, une validation de pipeline ou un environnement de développement Mac distant, louer une machine auprès de VPSSpark peut être plus simple que d’acheter du matériel ou de transformer un poste personnel en serveur permanent. Vous pouvez comparer une région d’exécution Mac adaptée à vos tests, puis conserver le proxy choisi dans une architecture courte et réversible. Le bon choix reste celui qui correspond à votre durée d’usage, à vos données et au niveau d’exploitation que votre équipe peut réellement assumer.