OpenRouter : une API pour 400+ modèles et 60+ fournisseurs

Ce qu'OpenRouter unifie réellement

Je ne qualifierais pas OpenRouter de nouveauté : en août 2026, il constitue déjà une couche établie entre l'application et les fournisseurs de modèles. Son intérêt pratique est simple : une clé API, un format de requête commun et un solde unique, plutôt que des intégrations séparées avec OpenAI, Google, Anthropic et d'autres fournisseurs.

Les descriptions actuelles du service évoquent plus de 400 modèles provenant de plus de 60 fournisseurs. Il faut considérer ces chiffres comme une photographie du catalogue, non comme une garantie contractuelle : modèles, fournisseurs et disponibilité évoluent sans cesse. Pour l'ingénierie, l'essentiel est qu'une application puisse choisir un modèle sans réécrire toute son intégration.

Le routage ne sert pas seulement à changer de modèle manuellement. La documentation d'OpenRouter sur les itinéraires de secours décrit une liste de modèles : si l'option principale est indisponible, limitée en débit ou bloque une requête par modération, le système essaie la suivante. Si le secours échoue aussi, le client reçoit une erreur. Il s'agit de résilience, pas d'une magie sans limite.

La facturation exige de lire les petites lignes. La page tarifaire d'OpenRouter indique une offre gratuite sans frais de plateforme, tandis que l'annonce des frais prévoit 5,5 % pour les recharges classiques, avec un minimum de $0,80. Les paiements en cryptomonnaie sont affichés à 5 %, sans montant minimal.

Ce minimum se remarque particulièrement sur les petits montants : une recharge de $5 entraîne $0,80 de frais, soit 16 % effectifs. Ce n'est plus « seulement cinq virgule cinq pour cent », mais un prix sensible pour la commodité.

Quand une API unifiée change réellement la donne

Le principal avantage n'est pas le nombre de modèles, mais la réduction du couplage entre l'application et une API donnée. Il devient possible de répartir les tâches simples et complexes entre plusieurs modèles, de modifier la route lors d'une panne et de suivre les dépenses au même endroit.

La dépendance ne disparaît toutefois pas : elle monte d'un étage. Au lieu de dépendre d'un fournisseur de modèles, vous dépendez du routeur, de sa disponibilité, de sa politique de paiement et de sa logique de sélection. Je vérifierais donc d'abord la latence, les nouvelles tentatives, le traitement des erreurs, le modèle réellement choisi et l'écart entre le coût prévu et le coût final.

À grande échelle, un proxy autonome comme LiteLLM ou lm-proxy offre davantage de contrôle sur les clés, budgets et règles de routage, mais doit être maintenu. Un fournisseur direct tel que Deepinfra peut être plus simple pour un ensemble restreint de modèles. OpenRouter est pertinent lorsque la rapidité d'intégration et l'étendue du choix comptent plus que le contrôle total.

Il ne supprime pas le vendor lock-in : il échange une forme de dépendance contre une autre, plus pratique et observable. La vraie qualité de cette couche ne se mesure pas au nombre de logos du catalogue, mais à la prévisibilité de son comportement lorsqu'une panne survient.

Nous avons déjà analysé comment les proxys LLM et les couches d'abstraction aident à réduire le verrouillage fournisseur avec différents fournisseurs de modèles. Cela complète directement l'approche d'OpenRouter, où le routage devient un élément de l'architecture plutôt qu'une dépendance à une seule API.