OpenRouter
Pourquoi c’est important
En profondeur
OpenRouter se place entre une application et les nombreux fournisseurs qui exécutent réellement les modèles. Un développeur envoie une requête de complétion de conversation à un seul point d'accès et nomme le modèle cible avec un identifiant préfixé par le fournisseur, par exemple une variante Claude d'Anthropic ou une publication Llama en poids ouverts. OpenRouter normalise la requête dans le format attendu par le fournisseur en amont, la transmet, compte les tokens et retourne la réponse dans un schéma unique et cohérent. La facturation passe par des crédits prépayés, donc une centaine de modèles différents apparaissent sur une seule facture au lieu d'une centaine d'abonnements distincts. Résultat : le choix du modèle cesse d'être une décision d'infrastructure pour devenir une ligne de configuration modifiable par requête, par fonctionnalité ou par expérience.
Une API, plusieurs dorsales
L'astuce centrale, c'est que la passerelle parle la forme d'API popularisée par OpenAI, donc la plupart du code existant fonctionne avec seulement une nouvelle adresse de base et une nouvelle clé. Les modèles de pointe d'Anthropic et de Google sont relayés depuis leurs API de première partie, tandis que les modèles en poids ouverts sont servis par des fournisseurs d'inférence indépendants comme Together AI et Fireworks AI. Comme plusieurs dorsales hébergent souvent le même modèle ouvert, OpenRouter peut router chaque requête selon le prix, le débit ou la disponibilité, et se rabattre sur un autre fournisseur quand le premier échoue ou atteint ses limites de débit. Ce seul basculement élimine toute une classe de pannes nocturnes pour les petites équipes qui ne peuvent pas négocier de la redondance avec chaque fournisseur elles-mêmes.
Ce que ça coûte et ce que ça suit
La tarification est à l'usage par token, refilant généralement les tarifs du fournisseur en amont avec de petits frais par-dessus, donc il n'y a pas d'abonnement à justifier avant d'expérimenter. Le compromis est simple : à faible et moyen volume, la commodité d'une facture unique et d'une configuration nulle par fournisseur l'emporte, tandis qu'à très gros volume un contrat direct avec un fournisseur revient habituellement moins cher. Le volet tableau de bord du produit est sans doute aussi utile que le routage. Chaque requête est journalisée avec son modèle, son compte de tokens, son coût et sa latence, ce qui facilite de voir ce qu'une fonctionnalité coûte réellement par utilisateur et d'attraper une modification de prompt qui a discrètement doublé la dépense. Pour les équipes qui font de l'évaluation rapide, pouvoir passer le même prompt dans une douzaine de modèles sur une seule facture, puis lire côte à côte le coût et la vitesse, comprime des semaines d'intégration de fournisseurs en un après-midi.
Le classement Rankings
Comme tant de trafic passe par une seule passerelle, OpenRouter publie un classement public des modèles selon le volume de tokens que ses utilisateurs leur envoient réellement. C'est un signal différent des bancs d'essai de qualité comme Chatbot Arena : il montre ce que les développeurs déploient en production, pas quel modèle gagne un vote en tête-à-tête, et il fait souvent ressortir des publications en poids ouverts en forte montée des semaines avant que l'industrie plus large s'en aperçoive. Les chiffres demandent une certaine prudence d'interprétation, puisque la base d'utilisateurs penche vers les développeurs et les amateurs plutôt que vers l'ensemble du marché, et que les modèles gratuits ou fortement escomptés reçoivent un coup de pouce naturel. N'empêche, comme lecture quasi en temps réel des modèles qui gagnent une véritable part d'usage, c'est devenu l'une des sources de données publiques les plus citées du domaine.
Elle n'exécute pas les modèles elle-même
Une idée fausse répandue veut qu'OpenRouter soit une entreprise de service de modèles dotée de sa propre flotte de GPU. En pratique, c'est surtout un mandataire et une place de marché : à de rares exceptions près, la requête quitte votre infrastructure, passe par OpenRouter et s'exécute sur le matériel d'un fournisseur tiers. Ça a de vraies implications. Les prompts et les réponses sont visibles par au moins deux parties additionnelles, et les conditions de conservation des données varient selon le fournisseur en amont plutôt que d'être fixées par la seule passerelle, donc les charges de travail sensibles exigent une vérification de politique par fournisseur plutôt qu'une approbation globale unique. Le saut réseau supplémentaire peut aussi ajouter de la latence, et une panne de la passerelle elle-même fait tomber tous les modèles d'un coup. Rien de tout ça n'annule la commodité, mais les équipes devraient traiter OpenRouter comme une couche de routage et de facturation avec sa propre surface de confiance, pas comme l'entité qui génère leurs réponses.