LiteLLM : posséder son plan de contrôle LLM

Une clé OpenAI collée dans le canal Slack de l'équipe data en 2024. Une facture Anthropic qui triple en mars sans qu'on sache quel projet l'a fait grimper. Un 429 en pleine démo client parce qu'un batch nocturne a mangé le quota. Ces trois incidents ont le même diagnostic : personne ne possède le plan de contrôle. Les clés, les budgets, les journaux et la bascule vivent chez les fournisseurs, ou nulle part.

LiteLLM est la réponse open source à ce problème : un proxy Python sous licence MIT qui expose plus d'une centaine d'API de modèles derrière un endpoint compatible OpenAI, et qui tourne dans votre infrastructure¹. C'est le plan de contrôle de notre grille des trois métiers. Là où OpenRouter prélève une commission et opère pour vous, LiteLLM ne prélève rien et vous laisse l'exploitation. Le reste de l'article chiffre cet arbitrage.

Un projet Y Combinator devenu standard de fait

LiteLLM est édité par BerriAI, société fondée en 2023 à San Francisco par Krrish Dholakia et Ishaan Jaffer, passée par Y Combinator (promotion W23). Le cœur est open source sous licence MIT ; une édition entreprise commerciale ajoute l'authentification unique SAML, la multi-location, la résidence des données et la gestion fine des rôles. Modèle open-core classique¹.

L'adoption se lit dans le dépôt : plus de 50 000 étoiles sur GitHub à la mi-2026, et une liste de clients qui inclut, selon les bases de données de place, la NASA, Adobe, Netflix, Stripe et Nvidia, pour un revenu annuel récurrent rapporté à 7 millions de dollars².

Le financement est mal documenté : 1,6, 2,1 ou 4 millions de dollars d'amorçage selon la base consultée². Pour un choix d'architecture, l'information utile est ailleurs : une société de cette taille, avec 7 millions de revenu récurrent, porte un composant dont Netflix, Adobe et la NASA figurent parmi les clients cités. La question de la pérennité se pose, et la licence MIT y répond en partie : le code reste.

Ce que « posséder le plan de contrôle » veut dire concrètement

La liste des fonctions du proxy est la traduction opérationnelle de cette possession.

Les clés virtuelles. Une clé fournisseur unique reste dans le proxy ; les équipes, les projets et les agents reçoivent des clés dérivées, révocables individuellement, associées à des droits. Une clé compromise se coupe sans rien renégocier chez le fournisseur, et sans interrompre les autres consommateurs. C'est la fonction qui, à elle seule, justifie la couche dès qu'il y a plus d'une équipe.

Les budgets. Plafonds durs par projet, par équipe, par clé, avec limitation de débit. Un budget qui bloque vaut mieux qu'une alerte qui informe : l'expérience des premières factures d'agents autonomes a montré que la dépense d'une nuit peut dépasser celle d'un mois. Le sujet est développé dans notre analyse du TCO d'un agent autonome.

La bascule automatique. Le composant Router gère les tentatives, les replis inter-déploiements (d'une instance Azure vers l'API OpenAI, par exemple) et la répartition de charge. Les exceptions sont normalisées au format OpenAI, ce qui évite de coder un traitement d'erreur par fournisseur.

Le cache. Un cache Redis en amont, qui répond aux requêtes identiques sans les envoyer.

L'observabilité. Des rappels vers Langfuse, Lunary, MLflow, Prometheus, Sentry, Helicone et OpenTelemetry, plus un suivi de coût intégré. La donnée d'usage reste chez vous, ce qui change la nature des tableaux de bord que l'on peut construire, et celle des conversations que l'on peut avoir avec le contrôle de gestion.

Auto Router v2 : la décision de modèle intégrée au proxy

Longtemps, LiteLLM routait sur des règles et laissait la décision fine à l'appelant. L'Auto Router v2, livré dans la série 1.94 à partir de juillet 2026 et encore en bêta, fusionne trois stratégies dans un routeur unique³.

• Complexité : un classifieur, appuyé sur un modèle de langage et des règles par mots-clés, range la requête sur quatre niveaux : SIMPLE, MEDIUM, COMPLEX, REASONING. Chaque niveau pointe vers un ensemble de modèles.
• Sémantique : une correspondance par embeddings, appuyée sur la bibliothèque semantic_router, avec une agrégation par maximum plutôt que par moyenne, ce qui évite qu'un ensemble d'exemples tièdes noie un exemple parfaitement pertinent.
• Adaptatif : un échantillonnage de Thompson qui explore les modèles d'un même palier et converge vers celui qui donne les meilleurs résultats observés.

Deux détails d'implémentation valent plus que la liste des stratégies. Le premier est l'affinité de session, optionnelle : elle épingle le modèle choisi au premier tour pour ne pas invalider le cache de préfixe du fournisseur en cours de conversation. Sans elle, un routeur qui bascule vers un modèle moins cher peut coûter plus cher que s'il n'avait rien fait, puisque le contexte est repayé intégralement. Le second est l'escalade en cours de tâche : un message public du cofondateur rapporte un taux de réussite passant de 38,9 % à 52,8 % lorsque le routeur détecte un blocage et escalade vers un modèle supérieur⁴. Chiffre éditeur, protocole non publié, à traiter comme une indication de direction plutôt que comme un résultat.

L'ancien routeur sémantique reste supporté pour les configurations existantes, mais est déprécié.

Ce qu'il faut opérer

C'est le prix réel de LiteLLM, et il ne figure sur aucune page tarifaire. Le proxy est une application FastAPI qui a besoin d'une base PostgreSQL et d'un Redis, et qui, en production, se déploie en haute disponibilité derrière un répartiteur de charge.

L'outillage est correct : images Docker estampillées -stable après douze heures de tests de charge, chart Helm pour Kubernetes, modules Terraform publics pour AWS, et une architecture componentisée qui sépare la passerelle, le backend et l'interface sur des services distincts, avec bases et stockage objet managés⁵. Le projet expose aussi la notion de plan de contrôle global : une instance qui sert l'interface d'administration sans router elle-même le trafic, ce qui permet de piloter plusieurs passerelles régionales depuis un point unique.

Traduit en charge d'équipe : un composant de plus dans la chaîne critique, avec ses mises à jour, sa supervision, ses astreintes et ses tests de montée de version. Une organisation qui exploite déjà Kubernetes et PostgreSQL absorbe cela sans difficulté. Une équipe de cinq personnes sans plateforme le paiera plus cher qu'une commission de 5 %.

La contrepartie : une surface d'attaque au milieu de tout

Un proxy qui détient les clés de tous les fournisseurs et voit passer tous les prompts est une cible de valeur. L'année 2026 l'a rappelé, et les faits demandent d'être énoncés avec leur niveau de certitude.

En mars 2026, un incident de chaîne d'approvisionnement est suspecté sur des publications PyPI non autorisées, avec une recommandation de montée en version. En avril 2026, une vulnérabilité d'injection SQL référencée CVE-2026-42208 aurait été exploitée dans les trente-six heures suivant sa divulgation, exposant potentiellement des identifiants de fournisseurs d'IA et des données cloud ; un litige aurait été déposé au tribunal fédéral du Texas le même mois⁶. Ces éléments proviennent d'agrégateurs de renseignement sur les menaces, pas d'un avis de sécurité de l'éditeur ni d'une fiche consultée dans la base CVE. Ils sont rapportés ici comme tels, et méritent d'être recoupés avant d'entrer dans un dossier de décision.

Ce qu'ils changent, quel que soit leur degré de confirmation, c'est la classification du composant. Un plan de contrôle LLM appartient au périmètre critique : il se patche comme un reverse proxy exposé, ses accès administrateur se traitent comme des accès privilégiés, et sa base de données contient des secrets. Le même raisonnement vaut d'ailleurs pour toute la chaîne agentique, comme nous l'avons développé à propos de la sécurité du codage agentique.

À noter dans l'autre sens : BerriAI a ouvert le code de sa plateforme d'agents et rejoint l'écosystème de passerelles ouvertes de CrowdStrike, ce qui va dans le sens d'une intégration aux outillages de sécurité plutôt que d'une île isolée².

LiteLLM ou une marketplace : le calcul

Trois variables suffisent à trancher.

Variable	Penche vers la marketplace	Penche vers LiteLLM
Volume mensuel de tokens	Quelques centaines à quelques milliers de dollars	Au-delà, la commission dépasse le coût d'exploitation
Nature des données	Public, prototype, données non sensibles	Données clients, secteur régulé, exigence de résidence
Maturité plateforme	Pas d'équipe pour opérer un composant critique	Kubernetes et PostgreSQL déjà en production

Une organisation qui coche « au-delà » sur la première ligne et « déjà en production » sur la troisième n'a pas de raison de payer une commission. Une équipe produit de cinq personnes qui livre un prototype n'a pas de raison d'opérer un proxy. Entre les deux, le critère qui tranche est presque toujours le second : la nature des données décide plus souvent que le prix.

Rien n'oblige d'ailleurs à choisir. Le montage courant place LiteLLM devant les flux de production, avec des clés fournisseur directes pour les gros volumes, et déclare une marketplace comme route de secours pour les modèles rares, une configuration que l'endpoint compatible OpenAI rend triviale à mettre en place, et qui répond aussi aux exigences de résilience d'une architecture multi-LLM.

FAQ

LiteLLM est-il gratuit ? Le cœur est sous licence MIT, sans commission ni redevance : vous payez vos tokens aux fournisseurs et l'infrastructure qui héberge le proxy. Une édition entreprise payante ajoute l'authentification unique, la multi-location, la résidence des données et la gestion fine des rôles.

Que faut-il pour l'exploiter en production ? Une base PostgreSQL, un Redis, des instances du proxy en haute disponibilité derrière un répartiteur de charge. Des images Docker estampillées stables, un chart Helm et des modules Terraform pour AWS sont fournis.

Qu'apporte l'Auto Router v2 ? Un routeur unique combinant classification par complexité sur quatre niveaux, correspondance sémantique par embeddings et exploration adaptative par échantillonnage de Thompson, avec affinité de session optionnelle pour préserver le cache de préfixe. La fonctionnalité est en bêta.

Faut-il s'inquiéter des vulnérabilités signalées en 2026 ? Les incidents rapportés (publications PyPI suspectes en mars, injection SQL CVE-2026-42208 en avril) proviennent d'agrégateurs et demandent recoupement avec l'avis officiel de l'éditeur. Indépendamment de leur confirmation, un proxy qui détient les clés de tous les fournisseurs se traite comme un composant critique : montées de version rapides, accès administrateur privilégiés, base de données chiffrée.

LiteLLM ou OpenRouter ? LiteLLM si vous voulez posséder le routage, les budgets et les journaux, et si vous avez de quoi l'opérer. OpenRouter si vous voulez démarrer aujourd'hui sans infrastructure. Les deux se combinent : le proxy devant les flux de production, la marketplace en secours et pour la longue traîne de modèles.

---

Sources

1. Dépôt BerriAI/litellm sur GitHub — licence MIT, SDK Python (litellm.completion(), litellm.Router) et serveur proxy FastAPI, plus de 100 API de modèles exposées au format OpenAI, édition Enterprise (SSO/SAML, multi-location, résidence des données, RBAC). Documentation éditeur. github.com
2. Dealroom, « LiteLLM raises $1.6M seed funding amid security challenges, hits $7M ARR », et fiches PitchBook et agrégateurs — montants d'amorçage divergents (1,6 M$, 2,1 M$, 4 M$ selon la source), participation d'a16z citée par une seule source, clients entreprise mentionnés (NASA, Adobe, Netflix, Stripe, Nvidia), ouverture du code de la plateforme d'agents et adhésion à l'Open Gateway Ecosystem de CrowdStrike. Données de place, non confirmées par l'éditeur. app.dealroom.co
3. LiteLLM, « Auto Router v2: one router for complexity, semantic, and adaptive routing » (blog officiel) et documentation « [Beta] Auto Routing » — fusion des routeurs complexité, sémantique et adaptatif, quatre niveaux SIMPLE / MEDIUM / COMPLEX / REASONING, règles par mots-clés, ensembles multi-modèles, échantillonnage de Thompson, agrégation par maximum, affinité de session, dépendance à semantic_router, livraison en série 1.94 à partir de juillet 2026, statut bêta, dépréciation de l'ancien routeur sémantique. docs.litellm.ai
4. Publication LinkedIn de Krrish Dholakia sur l'escalade en cours de tâche de l'Auto Router — « 38.9% without vs 52.8% with stall escalation ». Chiffre éditeur, protocole de mesure non publié.
5. Documentation de déploiement LiteLLM — images Docker -stable publiées après douze heures de tests de charge, chart Helm pour Kubernetes 1.24+, PostgreSQL et Redis, modules Terraform publics pour AWS sur le Terraform Registry, architecture componentisée (passerelle, backend, interface sur services séparés), notion de plan de contrôle global. github.com
6. IntelPilot, notes du 27 mars 2026 (publications PyPI non autorisées suspectées, correctif conseillé en v1.83.0 et suivantes) et du 19 avril 2026 (CVE-2026-42208, injection SQL, exploitation rapportée dans les ~36 h suivant la divulgation) ; litige rapporté par Dealroom comme déposé au tribunal fédéral du Texas en avril 2026. Sources d'agrégation, à recouper avec l'avis de sécurité officiel de BerriAI et la fiche CVE avant toute décision.