OpenRouter : une seule API pour 417 modèles d’IA

OpenRouter est une passerelle unique qui donne accès, via une seule API compatible avec le SDK d’OpenAI, à des centaines de modèles de langage hébergés chez des dizaines de fournisseurs. Son intérêt tient en trois points : vous ne réécrivez pas votre code à chaque changement de modèle, vous payez le tarif du fournisseur sans marge ajoutée, et vos prompts ne sont pas journalisés par défaut.

Ce que fait OpenRouter, concrètement

Techniquement, c’est un proxy. Votre application appelle OpenRouter comme elle appellerait l’API d’OpenAI — mêmes routes, même format de requête, même SDK — et OpenRouter transmet l’appel au fournisseur du modèle demandé. Changer de modèle revient à changer une chaîne de caractères dans le corps de la requête.

Cela règle un problème très concret pour une équipe produit : l’adhérence au fournisseur. Sans passerelle, tester un modèle concurrent suppose un nouveau compte, une nouvelle clé, un nouveau SDK et un nouveau poste de facturation. Avec une passerelle, c’est un paramètre. La documentation de démarrage tient en quelques lignes de code : guide de démarrage OpenRouter.

Le catalogue en chiffres

Les chiffres qui suivent viennent de l’API publique du catalogue, relevée le 27 août 2026. Ils bougent en permanence, donc vérifiez-les avant d’en faire un argument.

• 417 modèles exposés
• 59 familles de fournisseurs distinctes
• 251 modèles multimodaux acceptant des images en entrée
• 20 modèles facturés à 0 $ en entrée comme en sortie
• 2 000 000 tokens de fenêtre de contexte pour le modèle le plus large du catalogue

Ce catalogue est interrogeable sans authentification : openrouter.ai/api/v1/models renvoie le tarif, la fenêtre de contexte et les modalités d’entrée de chaque modèle. C’est une source utile pour automatiser une veille tarifaire plutôt que de la tenir à la main.

Le modèle économique : pas de marge sur l’inférence

C’est le point le plus souvent mal compris. OpenRouter répercute le tarif du fournisseur sans marge : vous payez le même prix au token que si vous alliez directement chez lui. La rémunération se fait sur l’achat de crédits, pas sur la consommation.

Si vous préférez garder vos propres contrats fournisseurs, le mode BYOK permet d’utiliser vos clés à travers l’interface d’OpenRouter. Il comporte une franchise gratuite qui dépend du plan, calculée sur le coût d’inférence au prix catalogue et non sur le nombre de requêtes ; au-delà, un pourcentage s’applique. Les conditions détaillées sont dans la FAQ officielle.

Confidentialité : ce qui est journalisé, et ce qui ne l’est pas

Pour une entreprise, c’est souvent le critère décisif, et la position d’OpenRouter est nette. Sa FAQ indique qu’il n’y a aucune journalisation des prompts et des complétions par défaut, y compris en cas d’erreur. Une option permet de les journaliser volontairement, en échange d’une remise de 1 % sur le coût d’usage — soit l’inverse du réglage par défaut habituel.

Second point, plus subtil et plus important : OpenRouter indique ne pas router vers les fournisseurs qui journalisent, ou dont la politique n’a pas pu être confirmée, sauf si vous activez explicitement le réglage correspondant. Le choix de ne pas exposer vos données est donc le comportement par défaut, pas une case à cocher. C’est exactement ce qu’on cherche à pouvoir écrire dans un registre de sous-traitants.

Le routage automatique et les bascules

Au-delà du catalogue, OpenRouter peut choisir le modèle à votre place. Le routeur classe la requête par type de tâche, puis s’appuie sur la part de dépense observée sur une fenêtre glissante de sept jours — un signal de marché plutôt qu’une curation manuelle. Vous fixez une bande de coût via le paramètre cost_tier (de low à max), et les modèles retenus deviennent le choix principal puis les solutions de repli.

La conséquence opérationnelle est la disponibilité : si un fournisseur tombe, la requête bascule sur le suivant au lieu d’échouer. La documentation précise même que si le classement ou la classification sont indisponibles, le routeur retombe sur un jeu de modèles par défaut — une panne de l’infrastructure de routage ne fait pas échouer l’appel. Détail du mécanisme : documentation du routage de modèles.

Quand OpenRouter est pertinent, et quand il ne l’est pas

Une passerelle a un coût caché : elle ajoute un intermédiaire entre vous et le modèle. Cela vaut la peine dans trois cas, et beaucoup moins dans deux autres.

Pertinent quand vous êtes en phase d’exploration et que vous comparez plusieurs modèles ; quand vous voulez une facturation et une analytique agrégées plutôt qu’un compte par fournisseur ; ou quand la continuité de service prime et que les bascules automatiques vous évitent d’écrire votre propre logique de repli.

Moins pertinent quand vous êtes stabilisé sur un modèle unique en production, l’intermédiaire n’apportant alors plus grand-chose ; et quand vos contraintes réglementaires imposent de connaître et de contractualiser précisément l’hébergeur qui exécute l’inférence, ce qu’une couche de routage rend structurellement moins lisible.

Dans ce second cas, la question n’est plus « quelle passerelle » mais « quel hébergement » — un tout autre sujet, que nous traitons dans notre approche de la transformation IA.

Ce que nous en retenons

OpenRouter résout un problème réel et le résout proprement : l’adhérence au fournisseur pendant la phase où vous ne savez pas encore quel modèle vous garderez. Sa politique de journalisation par défaut est plus protectrice que la moyenne du marché, ce qui en fait un candidat sérieux même pour des usages internes sensibles.

Ce n’est pas pour autant une décision d’architecture définitive. La bonne façon de l’aborder est de s’en servir pour trancher — comparer, mesurer, décider — puis de réévaluer une fois le modèle choisi. Si vous en êtes là, notre cadrage IA sert précisément à poser ces arbitrages avant d’écrire du code.