Router ses requêtes LLM : passerelle cloud type OpenRouter ou proxy souverain

Dès qu’un projet IA dépasse un seul modèle, une question d’architecture se pose : par où passent les appels aux LLM ? Coder en dur l’API d’un fournisseur, c’est se lier à lui pour le prix, la disponibilité et la confidentialité. La réponse consiste à insérer une couche intermédiaire, une passerelle, qui reçoit toutes les requêtes et décide vers quel modèle les envoyer. Deux familles s’opposent : la passerelle cloud clé en main, dont OpenRouter est le représentant le plus connu, et le proxy que l’on héberge soi-même, comme LiteLLM. Le choix n’est pas anodin pour une organisation soucieuse de souveraineté.

Ce que fait une passerelle LLM

Quelle que soit sa forme, une passerelle apporte les mêmes fonctions clés :

Interface unique : une seule API, généralement compatible avec celle d’OpenAI, devant des dizaines de modèles. On change de modèle en modifiant une chaîne de caractères, sans réécrire le code.
Repli automatique (failover) : si un fournisseur tombe ou sature, la requête bascule vers un autre modèle sans interruption pour l’utilisateur.
Routage intelligent : orienter chaque requête selon le coût, la latence, la disponibilité ou la sensibilité du contenu.
Suivi centralisé : consommation de jetons, dépenses et quotas mesurés au même endroit, par application ou par équipe.
Gestion des clés : une clé interne unique côté application, les clés des fournisseurs restant cachées dans la passerelle.

OpenRouter : la passerelle cloud clé en main

OpenRouter est un service en ligne qui donne accès à plus de 300 modèles de tous les grands fournisseurs (Anthropic, OpenAI, Google, DeepSeek, Meta, Mistral, xAI, etc.) derrière une API unique compatible OpenAI. Son intérêt est la simplicité : pas d’infrastructure à gérer, un seul compte, une seule facture, et l’accès immédiat à des modèles qu’il faudrait sinon contractualiser un par un. Le modèle économique est un passthrough, à savoir le coût natif du modèle plus une commission de plateforme (de l’ordre de 5,5 % sur l’achat de crédits). Il propose même des modèles gratuits, soumis à des limites de débit.

La contrepartie est structurelle : OpenRouter est un service propriétaire, et toutes vos requêtes, donc vos prompts et vos données métier, transitent par son infrastructure avant d’atteindre le modèle. Pour de la donnée sensible, cela ajoute un tiers dans la chaîne de traitement, avec les questions de conformité que cela implique.

LiteLLM : le proxy que l’on héberge

LiteLLM répond au même besoin d’abstraction, mais sous forme d’une brique open source que l’on installe sur sa propre infrastructure. Il expose lui aussi une API compatible OpenAI et sait router entre des modèles locaux (Ollama, vLLM) et des API cloud, avec repli, gestion des clés, quotas et suivi des coûts. La différence est le point de contrôle : la passerelle vous appartient, les données ne sortent que vers les fournisseurs que vous autorisez explicitement, et rien ne transite par un intermédiaire non maîtrisé. Ce sujet a déjà été détaillé sur le site.

Comment choisir

Le bon arbitrage dépend de la nature des données et du niveau de maîtrise recherché :

Prototype, données non sensibles, besoin de tester beaucoup de modèles : une passerelle cloud comme OpenRouter fait gagner un temps précieux et évite de multiplier les contrats.
Données métier ou personnelles, contrainte de conformité, exigence de souveraineté : un proxy auto-hébergé comme LiteLLM garde la maîtrise du flux et permet de router le sensible vers un modèle local et le reste vers le cloud.
Approche mixte : rien n’interdit d’héberger LiteLLM et d’y déclarer OpenRouter comme l’un des fournisseurs en aval, ce qui combine le contrôle du point d’entrée et l’ampleur du catalogue.

Stratégies de routage à penser dès le départ

Au-delà de l’outil, le vrai sujet est la politique de routage. Quelques axes structurants : router selon le coût en réservant les gros modèles aux tâches complexes et en confiant le volume à des modèles plus légers ou locaux, router selon la confidentialité en interdisant à toute donnée sensible de sortir vers une API externe, router selon la latence pour les usages temps réel, et prévoir systématiquement un repli pour la résilience. Une passerelle rend ces règles applicables sans toucher au code applicatif, ce qui permet de les faire évoluer au fil du temps.

Points de vigilance

Une passerelle centralise les appels, elle devient donc un point critique : sa disponibilité conditionne celle de toute l’application, et sa compromission exposerait l’ensemble des clés. En cloud, il faut lire attentivement les conditions de traitement des données et considérer que ce qui sort n’est plus sous votre contrôle. En auto-hébergement, la disponibilité et la supervision de la passerelle deviennent votre responsabilité. Dans les deux cas, coupler la passerelle à une couche d’observabilité (par exemple Langfuse) et, pour le sensible, à une anonymisation en amont, complète utilement le dispositif.