theopenco/llmgateway : une passerelle unique devant vos fournisseurs de LLM

Le problème concret : N fournisseurs, N SDK, N tableaux de bord

Une équipe qui appelle OpenAI pour le raisonnement, Anthropic pour les longs contextes et Vertex AI pour des raisons de résidence des données finit avec trois jeux de clés, trois formats de réponse et trois façons de compter les jetons. La facturation arrive éclatée, et comparer le coût réel d'un même prompt d'un fournisseur à l'autre demande un travail manuel. LLM Gateway se place comme intergiciel entre l'application et ces fournisseurs. Le README annonce quatre fonctions : router vers plusieurs fournisseurs, gérer les clés au même endroit, suivre les jetons et les coûts, analyser les métriques de performance. Le public visé est donc celui qui a déjà dépassé le stade du prototype mono-fournisseur, et qui veut un point d'observation unique sans écrire lui-même la couche d'abstraction. Le format d'API exposé est celui d'OpenAI, ce qui veut dire qu'un client existant change surtout son URL de base et sa clé, pas son code.

Ce que la documentation ne tranche pas

Le README décrit les intentions et l'installation, pas l'implémentation. Impossible d'affirmer depuis ce matériel comment le routage choisit un fournisseur : par modèle demandé, par règle de coût, par disponibilité ? Le champ model de l'exemple est gpt-4o, un identifiant OpenAI, donc le cas simple est un passage direct vers le fournisseur correspondant. Au-delà, rien n'est documenté. Les topics du dépôt mentionnent rate-limiting et guardrails, mais le README ne décrit ni la politique de limitation de débit ni la nature des garde-fous. De même, la gestion des clés est annoncée comme une fonction, sans détail sur le chiffrement au repos. Ce sont des zones à vérifier dans le code avant de s'engager, pas des défauts prouvés. Une passerelle qui voit passer toutes vos requêtes devient un composant critique : savoir ce qu'elle journalise compte autant que savoir ce qu'elle route.

Architecture : un monorepo pnpm, pas un binaire unique

La structure des dossiers montre une application découpée. apps/gateway porte le routage des requêtes LLM, apps/api est un backend Hono, apps/ui un tableau de bord Next.js, et packages/db contient le schéma et les migrations Drizzle. Autour gravitent des applications moins centrales : apps/playground pour le chat, apps/code, apps/airside comme portail fournisseurs auto-service, apps/docs. ee/admin est le tableau de bord d'administration interne. Deux conséquences pratiques. D'abord, la persistance passe par PostgreSQL et Redis, ce que confirment les deux volumes nommés dans la commande docker run. Ensuite, la surface de code est large : qui veut auditer la passerelle doit lire apps/gateway et packages/models, pas l'ensemble du monorepo. packages/models mérite une lecture attentive, puisque c'est là que vivent les définitions de modèles et de fournisseurs, donc la liste réelle de ce qui est supporté.

Démarrage auto-hébergé : deux secrets et des volumes nommés

Le README propose deux chemins. Le premier, hébergé, se limite à créer un compte sur llmgateway.io et récupérer une clé. Le second, auto-hébergé, passe par une image unifiée. La séquence donnée est explicite : générer un secret avec openssl rand -base64 32, faire de même pour GATEWAY_API_KEY_HASH_SECRET, puis lancer ./scripts/run-unified-container.sh. Pour un docker run ponctuel, le README insiste sur un point : utiliser des volumes nommés, pas un montage de répertoire hôte sur /var/lib/postgresql/data. La raison donnée est que l'initialisation de PostgreSQL dans le conteneur doit poser des permissions sur ce répertoire, ce qui peut échouer selon le système de fichiers et le propriétaire côté hôte. Les variables attendues sont AUTH_SECRET et GATEWAY_API_KEY_HASH_SECRET, et l'image est ghcr.io/theopenco/llmgateway-unified:latest. Les ports publiés dans l'exemple vont de 3002 à 4002. Côté développement, pnpm i && pnpm run setup installe les dépendances, démarre les services Docker, synchronise le schéma et injecte des données initiales. Le README signale aux utilisateurs WSL2 d'activer l'intégration Docker Desktop.

L'appel côté client ne change presque pas

L'exemple fourni est un POST vers https://api.llmgateway.io/v1/chat/completions avec un en-tête Authorization: Bearer et un corps qui contient model et messages. C'est la forme OpenAI. Le coût de migration se réduit donc à l'URL de base et à la clé, à condition que le client utilisé ne dépende pas d'extensions propres à un fournisseur. C'est là que la compatibilité atteint sa limite : tout ce qui sort du format de chat standard, outils propriétaires, champs spécifiques à Anthropic ou à Vertex, dépend de ce que la passerelle relaie réellement. Le README ne donne aucun exemple de traduction d'un paramètre non standard. Si votre code s'appuie sur des fonctionnalités avancées d'un fournisseur précis, testez ce chemin avant de généraliser la bascule, car l'abstraction peut aplatir ce qui fait la valeur de ce fournisseur.

Licence : AGPLv3 pour le cœur, ee/ sous licence commerciale

Le projet se présente comme doublement licencié. Le cœur est en AGPLv3. Les fonctionnalités commerciales du dossier ee/ exigent une licence Enterprise, et l'administration multi-organisations une licence white-label. Le README liste ce qui relève de cette partie : facturation et abonnements avancés, rétention étendue (illimitée contre 30 jours), configurations de clés fournisseurs personnalisées, gestion d'équipes et d'organisations, support prioritaire. La rétention est le point le plus concret : si la version ouverte plafonne à 30 jours, toute exigence d'archivage au-delà pousse vers le commercial. L'AGPLv3, elle, a une conséquence directe pour qui modifierait la passerelle et l'exposerait comme service à des tiers. Je ne donne pas d'avis juridique : le fichier LICENSE et ee/LICENSE sont les seules sources à consulter, et le champ de métadonnées du dépôt indique NOASSERTION, ce qui ne remplace pas la lecture des fichiers.

Alternative : LiteLLM et l'approche par proxy Python

L'alternative la plus directement comparable est LiteLLM, un proxy Python qui expose lui aussi une interface compatible OpenAI devant de nombreux fournisseurs. La différence de conception est nette. LiteLLM vit dans l'écosystème Python et s'installe comme bibliothèque ou comme proxy ; llmgateway est un ensemble TypeScript avec un tableau de bord Next.js, un backend Hono et une base PostgreSQL, pensé comme un service à déployer. Si votre équipe écrit du Python et veut appeler les fournisseurs depuis le même processus que son application, LiteLLM s'intègre plus près du code. Si vous voulez un service séparé, avec une interface web d'analyse et une gestion centralisée des clés, la forme de llmgateway correspond mieux. Le second point de comparaison est plus radical : ne pas mettre de passerelle du tout et appeler chaque SDK directement. C'est viable tant que le nombre de fournisseurs reste faible et que personne ne demande de rapport de coûts consolidé.

Coût de maintenance et rythme de publication

Les releases récentes montrent un rythme hebdomadaire : v1.14.0, v1.15.0 et v1.16.0 à sept jours d'intervalle, la dernière datée du 7 septembre 2026, pour un dernier push au 9 septembre 2026. Un rythme soutenu signifie des mises à jour fréquentes de l'image ghcr.io/theopenco/llmgateway-unified. Comme la persistance repose sur PostgreSQL, toute évolution du schéma Drizzle implique une migration : prévoyez une sauvegarde avant de tirer une nouvelle version. La maintenance ne s'arrête pas là. Une passerelle de ce type doit suivre les changements d'API des fournisseurs, et packages/models est le fichier de référence à surveiller quand un modèle ou un prix bouge. Sur le plan opérationnel, il faut aussi héberger PostgreSQL et Redis, ce qui ajoute deux composants à superviser pour un service qui n'existait pas avant.

Conclusion éditoriale

À adopter si vous voulez auto-héberger une passerelle compatible OpenAI et garder la main sur vos clés de fournisseurs. À éviter si vous dépendez de la rétention longue ou de l'administration multi-organisations : ces fonctions vivent dans ee/ et supposent une licence commerciale. Avant de déployer, vérifiez le contenu exact de ee/LICENSE et la liste des variables attendues par scripts/run-unified-container.sh.

Sources officielles

1. Issues
2. Project website
3. README
4. Releases
5. theopenco/llmgateway on GitHub