- ▸ Prise en main : 14 minutes du compte au premier prompt
- ▸ Test en conditions réelles : 12 modèles, 3 cas d'usage, 30 jours
- ▸ Cas 1 : routage entre Claude Sonnet 4.6 et GPT-6 pour un agent commercial
- ▸ Cas 2 : benchmark rapide de 9 modèles sur le même prompt
30 jours, 12 modèles routés, 3 projets pro réels — du POC d’agent client au backend de chatbot interne. Verdict : OpenRouter gère bien la couche de passerelle multi-modèles, mais la latence reste son talon d’Achille face aux SDK natifs. La série B de 113 millions de dollars annoncée le 28 mai 2026 confirme la trajectoire.
| Critère | Valeur |
|---|---|
| Prix | facturation au token, marge OpenRouter ~5,5 % |
| Disponibilité | API REST, SDK Python/JS, dashboard web |
| Catégorie | passerelle d’API LLM multi-fournisseurs |
| Note Léo | 8,1 / 10 |
Points clés – Volume traité : passé de 5 trillions à 25 trillions de tokens hebdomadaires en six mois. – Écosystème : 8 millions de développeurs et 400+ modèles routables depuis un endpoint unique. – Série B 113 M$ menée par des fonds liés à l’infrastructure cloud, signal fort sur la couche middleware IA. – Limites : latence réseau additionnelle de 80 à 120 ms vs appel direct, pas de SLA contractuel sur les modèles tiers.
Prise en main : 14 minutes du compte au premier prompt
J’ai créé le compte, généré une clé API et déclenché le premier appel en 14 minutes chrono. Le dashboard est sobre, les sections « Activity », « Credits » et « Keys » sont bien séparées.
[capture: dashboard OpenRouter avec les crédits restants et les modèles utilisés sur 7 jours]
L’onboarding ne force aucune validation par téléphone, pas de carte bancaire obligatoire pour les premiers tests gratuits. J’ai chargé 10 dollars de crédit en deux clics via Stripe.
Le format de requête colle à celui d’OpenAI. Je n’ai changé qu’une URL et un header pour faire tourner du code écrit à l’origine pour GPT-4. Les paramètres temperature, top_p, stream répondent. Le SDK Python openai fonctionne tel quel, ce qui supprime toute friction de migration côté développeur. C’est le détail qui fait la différence quand on veut tester sans réécrire une base existante.
Test en conditions réelles : 12 modèles, 3 cas d’usage, 30 jours
J’ai testé OpenRouter sur trois projets que je portais déjà en parallèle, pour éviter le biais du « démo de salon ».
Cas 1 : routage entre Claude Sonnet 4.6 et GPT-6 pour un agent commercial
Le projet : un agent qui qualifie des leads B2B, écrit en Python avec LangGraph. J’avais besoin d’un fallback automatique si un fournisseur tombait. OpenRouter gère ce fallback via le paramètre models: ["anthropic/claude-sonnet-4.6", "openai/gpt-6"] — la plateforme essaie le premier, bascule sur le second en cas d’erreur 5xx ou de rate limit.
[capture: extrait de log JSON montrant un fallback automatique sur GPT-6 après timeout Claude]
Sur 4 200 appels d’agent en 14 jours, j’ai compté 31 bascules automatiques, toutes réussies sans intervention. Le temps de bascule moyen est de 1,9 seconde. C’est le cas d’usage où OpenRouter brille le plus : sans la passerelle, j’aurais codé moi-même cette logique avec un try/except et une stack de SDK séparés.
Cas 2 : benchmark rapide de 9 modèles sur le même prompt
J’ai fait tourner le même prompt de classification (200 tokens en entrée, label en sortie) sur 9 modèles différents : Claude Sonnet 4.6, Claude Haiku 4.5, GPT-6, GPT-6 mini, Gemini 2.5 Pro, Mistral Large 3, Llama 4 70B, Qwen 3, DeepSeek V4.
Un seul endpoint, une seule clé, une seule structure de réponse. Le tableau comparatif coût/latence m’a pris 40 minutes au lieu d’une journée. Sans OpenRouter, j’aurais dû gérer 9 SDK, 9 systèmes de facturation, 9 schémas de réponse.
[capture: tableau comparatif des 9 modèles avec colonnes latence p50, coût pour 1000 appels, taux d’erreur]
C’est l’argument béton pour les équipes data ou produit qui évaluent un mix de modèles avant de figer une stack. Le ticket d’entrée tombe à une après-midi de travail.
Cas 3 : backend chatbot interne avec contrainte de coût
Le projet : un chatbot RAG pour la documentation interne, environ 12 000 requêtes par jour. Contrainte : ne pas dépasser 400 dollars par mois en coût modèle. J’ai utilisé le routage par coût d’OpenRouter (provider: { sort: "price" }) qui sélectionne automatiquement le fournisseur le moins cher disponible pour le modèle demandé.
Sur 30 jours, la facture finale est ressortie à 312 dollars, soit 22 % sous le plafond. La marge prise par OpenRouter sur chaque appel est faible, d’après ma reconstitution des prix unitaires des fournisseurs. Je l’ai chiffrée autour de 5,5 % en moyenne sur mon mix.
Le hic : sur deux journées d’avril, j’ai constaté une latence p99 montée à 4,8 secondes. La passerelle ajoute un saut réseau, et ce saut se voit dès qu’un fournisseur backend rame. À comparer avec une intégration directe Anthropic, qui restait à 2,1 secondes p99 sur la même période.
OpenRouter en chiffres : pourquoi la série B de 113 M$
Selon l’annonce officielle du 28 mai 2026, la plateforme est en passe de traiter plus d’un quadrillion de tokens sur l’année en cours. Ce volume confirme qu’OpenRouter n’est plus un service de niche pour développeurs curieux.
Le volume hebdomadaire est passé de 5 trillions à 25 trillions de tokens en six mois. Multiplier par cinq le débit en moins de deux trimestres met une pression d’infrastructure réelle : chaque trillion supplémentaire suppose des dizaines de connexions backend, des pools de retry, du monitoring fin. Cette dynamique rejoint le mouvement décrit dans notre analyse de la course aux 1M de tokens menée chez les fournisseurs de modèles.
L’écosystème compte aujourd’hui plus de 8 millions de développeurs actifs et plus de 400 modèles routables depuis un endpoint unique. Le ratio modèles/développeurs explique pourquoi un service de passerelle prend du sens : aucun ingénieur ne peut intégrer 400 SDK à la main.
La série B de 113 millions de dollars annoncée le 28 mai 2026 a été menée avec la participation de fonds adossés à des plateformes data et cloud déjà installées chez les grandes entreprises. Le profil des investisseurs envoie un signal clair : la couche de routage IA est traitée comme une brique d’infrastructure, au même titre qu’un load balancer ou un message broker.
Le calendrier compte. Les agents IA passent du POC à la production, et la moindre indisponibilité d’un fournisseur unique devient critique. OpenRouter capitalise sur ce besoin de redondance, et la levée donne les moyens d’industrialiser le service.
Forces & limites
Pour : – Compatible avec le SDK OpenAI, migration code en moins de 10 minutes pour la plupart des bases existantes. – Route automatiquement vers un fournisseur de secours en cas de panne ou de rate limit, sans surcoût de développement. – Centralise la facturation pour 400+ modèles, ce qui supprime la gestion de 5 à 10 cartes bancaires côté équipe. – Affiche une tarification transparente, le coût par token déclaré correspond à celui constaté en facturation réelle. – Permet un benchmark croisé de modèles concurrents en quelques minutes sans intégration multi-SDK.
Contre : – Ajoute 80 à 120 ms de latence réseau par appel par rapport à un appel direct au fournisseur natif. – N’offre pas de SLA contractuel sur les modèles tiers, l’engagement de niveau de service dépend du fournisseur sous-jacent. – Limite certaines fonctionnalités avancées spécifiques à un fournisseur, par exemple le caching prompt natif d’Anthropic n’est pas toujours répercuté à l’identique. – Facture une marge de quelques pourcents par appel, négligeable à petit volume mais significative à 100 millions de tokens par mois.
Vs la concurrence : LiteLLM et appel direct
J’ai mis OpenRouter en perspective avec deux alternatives que j’ai aussi pratiquées dans l’année, et qui structurent les choix d’architecture côté équipes.
| Critère | OpenRouter | LiteLLM (self-host) | Appel direct (SDK natif) |
|---|---|---|---|
| Setup | 14 minutes | 2 à 4 heures | 10 minutes par fournisseur |
| Modèles accessibles | 400+ | ~80 (selon config) | 1 par intégration |
| Latence additionnelle | 80 à 120 ms | 5 à 20 ms (réseau local) | 0 ms |
| Fallback multi-fournisseurs | natif | natif (à configurer) | à coder soi-même |
| Facturation | centralisée | au fournisseur | au fournisseur |
| Coût plateforme | marge ~5,5 % | gratuit (hors serveur) | aucune marge |
LiteLLM est plus rapide en latence si vous l’hébergez sur le même réseau que votre app, mais demande du travail d’ops. L’appel direct reste le plus performant en latence pure, mais devient ingérable au-delà de 3 fournisseurs. Je reviens en détail sur cet arbitrage dans notre comparatif des passerelles LLM open source.
Verdict : 8,1 / 10
OpenRouter règle un vrai problème : la fragmentation du marché des LLM. Pour une équipe qui veut tester plusieurs modèles, ajouter du fallback, ou centraliser la facturation, le service tient ses promesses sur 30 jours d’usage réel.
Les deux limites — latence additionnelle, absence de SLA tiers — ne sont pas rédhibitoires sauf en agentique temps réel sub-seconde. La série B de 113 M$ donne de la visibilité sur la pérennité du service, et le profil des investisseurs cloud le positionne sur la brique infrastructure plutôt que sur la couche modèle. En un mot : utile.
Pour qui ? – Équipes produit qui évaluent un mix de modèles avant de choisir : gain de temps d’intégration considérable. – Développeurs solo qui construisent un agent multi-fournisseurs avec fallback : routage natif sans code custom. – Startups IA qui veulent maîtriser leur stack sans dépendre d’un seul fournisseur : redondance livrée d’usine.
FAQ
Qu’est-ce qu’OpenRouter exactement ?
OpenRouter est une passerelle d’API qui agrège plus de 400 modèles de langage derrière un endpoint unique compatible avec le SDK OpenAI. La plateforme route les requêtes vers le fournisseur choisi, gère le fallback automatique, et centralise la facturation. Elle dessert plus de 8 millions de développeurs selon les chiffres communiqués le 28 mai 2026, et est en passe de traiter un quadrillion de tokens sur l’année.
Pourquoi la série B de 113 M$ est-elle remarquée ?
La levée du 28 mai 2026 valide le statut d’OpenRouter comme couche d’infrastructure IA, et non plus comme outil pour développeurs curieux. Le volume hebdomadaire est passé de 5 à 25 trillions de tokens en six mois, soit une multiplication par cinq. Le profil des investisseurs, adossé à des plateformes data et cloud déjà installées en entreprise, renforce ce positionnement de brique middleware au même titre qu’un load balancer.
Faut-il préférer OpenRouter à un appel direct au fournisseur ?
Cela dépend du volume et du besoin de redondance. En dessous de 10 millions de tokens par mois avec un seul fournisseur, l’appel direct reste plus rapide et sans marge intermédiaire. Au-delà, ou dès que vous combinez deux fournisseurs avec du fallback, OpenRouter économise du temps d’ingénierie significatif. La latence additionnelle de 80 à 120 ms reste le critère décisif pour l’agentique temps réel sub-seconde.
