Si tu construis des choses avec l'IA depuis un moment, tu connais la douleur : aujourd'hui tu veux tester Claude pour raisonner, demain GPT pour écrire, la semaine prochaine un modèle open source pas cher pour des tâches idiotes. Chacun a sa propre API, sa propre clé, son propre SDK, sa propre façon de facturer. Et chaque fois que tu veux changer, il faut réécrire des bouts de code et te créer encore un compte de plus.
OpenRouter existe pour tuer cette douleur. L'idée est d'une simplicité trompeuse : une seule clé pour tous les modèles. Voyons ce qu'il y a vraiment derrière et quand ça vaut le coup, sans fumée.
Note
Ce guide est technique mais utile, que tu programmes ou que tu veuilles juste comprendre pourquoi tant d'outils d'IA « fonctionnent avec OpenRouter ». Pas besoin d'être dev pour saisir l'idée ; la partie code est optionnelle.
Qu'est-ce qu'OpenRouter et quel problème il résout
OpenRouter est une passerelle (gateway) de modèles d'IA. Traduit : c'est une couche intermédiaire qui se place entre ton application et les centaines de modèles éparpillés dans le monde. Toi, tu parles à OpenRouter ; OpenRouter parle à OpenAI, à Anthropic, à Google, à Meta, à Mistral, à des dizaines de fournisseurs de modèles open source. Une seule clé, une seule URL de base, une seule facture.
Le problème qu'il résout, c'est la fragmentation. Aujourd'hui, le marché de l'IA est découpé en silos : chaque laboratoire a son API, son système de facturation et ses bizarreries. Si tu veux utiliser trois modèles de trois entreprises différentes, tu maintiens trois intégrations. Si un meilleur modèle sort demain, il te faut ouvrir un autre compte et brancher un autre SDK. C'est de la friction pure, et la friction tue l'expérimentation.
OpenRouter fait s'effondrer tout ça en un seul point d'entrée. Il donne accès à des centaines de modèles de dizaines de fournisseurs via la même interface. Et le détail qui le rend addictif pour qui programme : son API est compatible avec celle d'OpenAI. Ça veut dire que si ton projet utilise déjà le SDK d'OpenAI, migrer revient pratiquement à changer deux choses —l'URL de base et la clé— puis à invoquer n'importe quel modèle du catalogue avec le même code.
Il y a aussi un chat web (playground) pour ceux qui ne veulent pas toucher au code : tu entres, tu choisis un modèle dans un menu déroulant gigantesque et tu discutes, en comparant les réponses de GPT, Claude ou Gemini sur le même écran sans sauter d'onglet en onglet. C'est la façon la plus rapide de « goûter » les modèles avant de les mettre en production.
Comment l'utiliser : clé, URL de base et choix du modèle
Le parcours pour démarrer est court. Tu t'inscris, tu génères une clé API et tu pointes ton code vers l'URL de base d'OpenRouter :
import requests, json
response = requests.post(
url="https://openrouter.ai/api/v1/chat/completions",
headers={
"Authorization": "Bearer <TA_CLE_OPENROUTER>",
"HTTP-Referer": "https://tondomaine.com",
"X-Title": "Ton App",
},
data=json.dumps({
"model": "anthropic/claude-sonnet",
"messages": [
{"role": "user", "content": "Résume ça en une phrase : ..."}
]
})
)L'important dans ce bloc, ce n'est pas la syntaxe, c'est ce qu'il implique. L'URL de base est toujours https://openrouter.ai/api/v1. Le modèle se choisit avec un slug du type fournisseur/modèle (anthropic/claude-sonnet, openai/gpt-..., google/gemini-..., meta-llama/...). Tu veux passer de Claude à GPT ? Tu changes la chaîne du champ model. Une ligne. Le reste du code ne bouge pas.
C'est là toute la magie opérationnelle : le modèle cesse d'être une décision d'architecture pour devenir un paramètre. Tu peux faire de l'A/B testing entre deux modèles dans la même fonction, mettre le modèle dans une variable d'environnement, ou l'exposer comme réglage pour que l'utilisateur final choisisse. Le tout sans réécrire d'intégrations.
Comme l'API imite celle d'OpenAI, presque n'importe quelle librairie ou outil qui « parle OpenAI » fonctionne avec OpenRouter en changeant ces deux champs. C'est pour ça que tu vois autant d'apps d'IA, de clients de chat et de frameworks qui le prennent en charge d'origine : pour eux, prendre en charge OpenRouter, c'est prendre en charge tout le marché d'un coup.
Tarification : crédits et paiement à l'usage
Ici, mieux vaut être précis pour éviter les mauvaises surprises. OpenRouter fonctionne avec des crédits et un paiement à l'usage, pas avec un abonnement.
- Tu charges du solde (par carte ou en crypto) et il se déduit au fil des tokens à mesure que tu fais des appels.
- Pas de minimum, pas de forfait mensuel, pas d'expiration du solde. Tu paies ce que tu consommes, point.
- Le prix par token de chaque modèle correspond à ce que facture le fournisseur d'origine. OpenRouter ne gonfle pas le prix par token.
- La commission se trouve sur le rechargement : autour de 5,5 % à l'ajout de crédits par carte (un peu plus élevée en crypto).
C'est un modèle honnête et facile à raisonner : tu vois le prix de chaque modèle dans son catalogue, tu sais que c'est celui du fournisseur, et la seule couche supplémentaire, c'est cette commission au moment d'ajouter du solde. Pour des ordres de grandeur (à ne pas prendre comme prix exact), les modèles puissants tournent autour de quelques dollars par million de tokens et les légers descendent à des centimes ; le catalogue est toujours à jour à l'intérieur.
Astuce
Avant de dépenser un euro, tire parti des modèles gratuits : OpenRouter propose des dizaines de modèles à coût zéro par token (avec des limites de requêtes par minute et par jour). Parfaits pour prototyper, monter ton flux et comparer la qualité avant de brancher un modèle payant.
Routing et fallbacks : la partie qui apporte vraiment
Si « une seule clé » est l'accroche, le routing intelligent est ce qui justifie d'avoir une couche intermédiaire en production. OpenRouter ne se contente pas de réacheminer ta requête : il décide comment et où l'exécuter.
Répartition entre fournisseurs. Un même modèle (disons un gros Llama) est souvent servi par plusieurs fournisseurs de calcul à la fois. OpenRouter équilibre la charge entre eux et, si l'un tombe ou ralentit, il réessaie automatiquement sur un autre. Pour ton app, le modèle « reste en vie » même si un fournisseur précis passe une mauvaise journée.
Optimiser par vitesse ou par prix. Tu peux affiner cette répartition avec des suffixes dans le slug du modèle :
:nitroprivilégie la performance (le plus de tokens par seconde). Idéal pour un chat face à l'utilisateur, où chaque milliseconde se remarque.:floorprivilégie le prix (le fournisseur le moins cher disponible). Idéal pour des travaux en lot où ce qui compte est le coût, pas la latence.
Fallback entre modèles différents. La répartition précédente garde en vie un modèle. Mais si tu veux que, quand un modèle entier échoue (panne totale, dépassement de la limite de contexte, blocage par rate limit ou modération), il bascule vers un autre modèle différent ? Pour ça, tu passes un tableau de modèles par ordre de priorité : OpenRouter essaie le premier et, en cas d'erreur, descend au suivant de la liste. Ton plan B (et C) automatisé.
Et si tu ne veux même pas décider, il existe l'Auto Router (openrouter/auto) : tu lui passes le prompt et OpenRouter choisit le modèle à ta place selon ce qu'il détecte. Utile quand tu ne sais pas quel type de requêtes va t'arriver. Règle simple : utilise l'Auto Router quand tu ne contrôles pas l'entrée ; utilise le tableau de fallback quand tu sais quel modèle tu veux et que tu cherches juste de la résilience derrière.
Le bon et le mauvais, sans maquillage
Avantages
- Une seule clé et une seule intégration pour des centaines de modèles de nombreux fournisseurs.
- API compatible OpenAI : changer de modèle revient à changer une chaîne, pas à réécrire du code.
- Routing avec fallback automatique entre fournisseurs : plus de résilience en production.
- Paiement à l'usage transparent, sans abonnement, et des dizaines de modèles gratuits pour tester.
- Tu ne t'attaches à personne : tu compares et migres de modèle en minutes, pas en sprints.
Inconvénients
- Ça ne rend pas le token moins cher : le prix est celui du fournisseur plus une commission au rechargement (~5,5 %).
- C'est une couche intermédiaire de plus : un point de dépendance supplémentaire et une latence possible.
- Pour un seul fournisseur à grand volume, y aller directement peut revenir au même, voire mieux.
- Certaines fonctions très spécifiques d'un fournisseur peuvent ne pas être exposées de la même façon.
- Gérer le solde et surveiller la dépense par tokens demande ta propre discipline.
Pour qui est fait OpenRouter ?
OpenRouter n'est pas « l'endroit le moins cher pour appeler l'IA » ; c'est la façon de ne t'attacher à aucun. Et ça colle à merveille pour les uns et c'est de trop pour les autres.
Ça t'intéresse si : tu développes et veux tester et comparer des modèles sans monter trois intégrations ; tu as besoin de résilience en production et le fallback automatique te va comme un gant ; tu construis une app où le modèle est une préférence configurable ; ou tu ne veux tout simplement pas tout miser sur un fournisseur dont le meilleur modèle d'aujourd'hui pourrait ne plus l'être dans trois mois. Aussi si tu es créateur ou curieux et veux un playground unique pour goûter GPT, Claude et Gemini côte à côte.
Ça ne t'intéresse pas si : tu sais déjà que tu vas utiliser un seul modèle d'un seul fournisseur, de façon stable et à grand volume —là, l'intégration directe t'épargne une couche et une commission—, ou si tu as besoin de fonctions très spécifiques que seule expose l'API native de ce fournisseur.
Le cas réel le plus honnête : un dev qui monte un assistant pour un client démarre avec un modèle open source gratuit pour prototyper, le fait passer à un Claude puissant pour la version sérieuse, laisse un GPT en fallback au cas où le premier tombe, et fait tout ça en touchant une poignée de chaînes de caractères, avec une seule clé et une seule facture. Cette agilité —pas le prix— c'est ce que vend OpenRouter. La question n'est pas « est-ce le moins cher ? », mais « combien ça vaut pour moi de pouvoir changer de modèle sans rien réécrire ? ». Si c'est ton métier, ça vaut souvent pas mal.