Auteur : Zhang Aila
Parlons aujourd'hui des stations relais.
En bref, une station relais pour modèles, c'est mettre des modèles différents comme OpenAI, Claude, Gemini, DeepSeek, etc., derrière une même porte d'entrée, permettant aux développeurs d'utiliser un ensemble d'interfaces, un compte et une facturation unifiés pour appeler plusieurs modèles, et de choisir, de basculer et de mettre en place des solutions de secours entre différents modèles ou fournisseurs.
Bien sûr, pour les utilisateurs en Chine, une raison plus importante d'utiliser une station relais est l'accès aux modèles étrangers, et aussi des prix plus avantageux.
Cela, tout le monde le comprend, nous n'en dirons pas plus sur les stations relais chinoises, aujourd'hui nous allons principalement présenter OpenRouter.
En 2026, OpenRouter a levé 113 millions de dollars lors d'un tour de financement de série B, sa valorisation approchant les 13 milliards de dollars.
En d'autres termes, c'est déjà une licorne.
Analysons donc pourquoi une station relais pour modèles qui « ne crée pas de modèles » peut valoir autant.
Que fait exactement OpenRouter ?
La définition qu'OpenRouter se donne officiellement est : une interface unifiée pour les grands modèles de langage.
OpenRouter prend actuellement en charge plus de 400 modèles et plus de 70 fournisseurs de modèles.
Le site officiel révèle également que la plateforme traite mensuellement 100 billions de tokens, avec plus de 10 millions d'utilisateurs dans le monde.
L'annonce du financement de série B de mai 2026 mentionnait aussi qu'au cours des 6 derniers mois, le volume de traitement hebdomadaire d'OpenRouter était passé de 5 billions à 25 billions de tokens, et qu'il desservait plus de 8 millions de développeurs.
Ces chiffres montrent une chose :
OpenRouter n'est plus un simple outil pour développeurs de niche, mais une grande porte d'entrée pour les appels d'IA.
La façon dont les développeurs l'utilisent est également simple.
Auparavant, il fallait se connecter séparément à OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI, etc.
Pour chaque connexion, il fallait consulter la documentation, demander une clé API, lier une facture, gérer les différences d'interface, comprendre les règles de limitation de débit, et gérer les exceptions.
Avec OpenRouter, les développeurs peuvent appeler différents modèles via la même interface.
Souvent, le code qui utilisait auparavant l'interface d'OpenAI ne nécessite que de changer l'URL de base, de remplacer la clé API, et de spécifier le nom du modèle pour appeler un autre modèle via OpenRouter.
C'est aussi l'une des raisons de sa croissance rapide initiale : un faible coût de migration.
Pourquoi les développeurs ne se connectent-ils pas directement aux sociétés de modèles ?
Il semblerait que les développeurs pourraient contourner OpenRouter et ouvrir directement une API sur le site officiel d'une société de modèles.
Mais dans le développement réel, ce n'est pas si simple.
Si un produit d'IA n'est qu'une démo, un seul modèle suffit. Mais dès qu'il entre dans un contexte commercial réel, il est difficile de ne dépendre que d'un seul modèle.
Par exemple, un outil d'écriture IA peut avoir plusieurs types de tâches différentes :
- Générer des titres, un modèle peu cher suffit ;
- Rédiger de longs articles, nécessite une meilleure capacité textuelle ;
- Analyser des documents, nécessite un modèle à contexte long ;
- Faire de la modération de contenu, nécessite une capacité de classification à faible coût et haute stabilité ;
- Les clients entreprises exigent que les données ne soient pas conservées, il faut donc choisir un fournisseur conforme à la politique des données ;
- En période de pointe, si le modèle est limité, il faut automatiquement basculer vers un modèle de secours.
À ce stade, le problème n'est plus seulement de « se connecter à une API ».
L'équipe doit maintenir un système complet d'appel de modèles :
Quel modèle est responsable de quelle tâche, quel modèle est moins cher, quel fournisseur est plus rapide, quel fournisseur a un taux d'échec plus faible, comment basculer en cas de problème, comment attribuer les factures, comment isoler les données des clients entreprises.
Plus ennuyeux, le marché des modèles évolue trop vite.
Aujourd'hui, Claude est adapté pour écrire du code, demain, le contexte long de Gemini a l'avantage, après-demain, DeepSeek ou un modèle open source fait baisser les prix.
Les capacités, les prix, la longueur du contexte, les politiques des fournisseurs des modèles changent constamment.
C'est là que réside la valeur d'OpenRouter.
Il ne s'agit pas d'écrire des applications d'IA à la place des développeurs, mais de gérer pour eux la question de « quel modèle utiliser, comment l'appeler, comment assurer la continuité, comment contrôler les coûts ».
Plus qu'un supermarché de modèles, c'est une couche d'orchestration
Si l'on ne comprend OpenRouter que comme un « supermarché de modèles », on le sous-estime.
Le supermarché de modèles résout le problème « il y a beaucoup de modèles ici, vous pouvez choisir ».
Mais la véritable capacité importante d'OpenRouter est d'orchestrer entre les modèles et les fournisseurs.
Le même modèle peut être proposé par différents fournisseurs pour le service d'inférence.
Par exemple, un modèle open source peut être hébergé par plusieurs fournisseurs de services cloud ou d'inférence. Le prix, la vitesse, la stabilité ne sont pas les mêmes selon les fournisseurs.
Dans la documentation d'OpenRouter, il y a une capacité appelée « provider routing », c'est-à-dire le routage des fournisseurs.
Les développeurs peuvent, en fonction de conditions comme le prix, la latence, le débit, l'ordre des fournisseurs, etc., faire passer automatiquement les requêtes par différents fournisseurs.
Il prend également en charge le « fallback », c'est-à-dire qu'en cas d'échec d'un modèle ou d'un fournisseur, le système bascule automatiquement vers une option de secours.
Pour les développeurs, OpenRouter équivaut à extraire la « sélection du modèle » et la « gestion des pannes » du code métier et à les confier à une plateforme spécialisée.
Pourquoi les entreprises auraient-elles besoin de cette couche ?
Lorsque les entreprises adoptent l'IA, les problèmes initiaux sont souvent « peut-on l'utiliser ? », mais ils deviennent rapidement « comment la gérer ? ».
Une entreprise peut avoir de nombreuses équipes utilisant l'IA en interne.
L'équipe marketing l'utilise pour rédiger du contenu, l'équipe de support client pour répondre aux utilisateurs, l'équipe de développement pour écrire du code, l'équipe opérationnelle pour analyser des données, l'équipe juridique pour traiter des contrats.
Si chaque équipe se connecte elle-même aux modèles, les problèmes vont se multiplier :
- Les factures ne sont pas claires ; le choix des modèles n'est pas uniforme ;
- Les politiques de données ne sont pas transparentes ; différentes équipes se connectent en double ;
- En cas de problème, personne ne sait quel appel est en cause ;
- Si le fournisseur de modèles change, le système est difficile à ajuster uniformément.
Les espaces de travail, le contrôle budgétaire, les journaux d'appels, les stratégies de fournisseurs, le routage sans conservation des données qu'OpenRouter propose, sont tous des solutions à ces problèmes.
Par exemple, l'absence de conservation des données.
Pour de nombreuses entreprises, toutes les requêtes ne peuvent pas être envoyées à n'importe quel fournisseur de modèles. Les informations clients, le contenu des contrats, les données médicales, les données financières peuvent avoir des exigences strictes.
La documentation d'OpenRouter prend en charge « Zero Data Retention », c'est-à-dire aucune conservation des données.
Les développeurs peuvent configurer le système pour n'envoyer les requêtes qu'aux fournisseurs qui ne stockent pas les données. Cette stratégie peut être appliquée globalement, par groupe de modèles, par règle de sécurité ou par requête individuelle.
Il y a aussi le « prompt caching », c'est-à-dire la mise en cache des invites.
De nombreuses applications d'IA utilisent de manière répétée de longues invites système, du contenu de base de connaissances ou des contextes. Si tout est recalculé à chaque fois, le coût est élevé.
OpenRouter prend en charge l'augmentation du taux de réussite du cache via le routage par affinité de fournisseur, en essayant de faire passer les requêtes suivantes par le même point de terminaison de fournisseur, réduisant ainsi le coût des contextes répétés.
Ce type de fonctionnalité ne semble pas sexy, mais il est très pratique, et plus l'échelle de l'application d'IA est grande, plus les économies réalisées sont importantes.
Comment OpenRouter gagne-t-il de l'argent ?
Le modèle économique d'OpenRouter est clair : gagner de l'argent en fonction de l'utilisation.
Les développeurs achètent d'abord du crédit sur la plateforme, puis paient en fonction des modèles réellement appelés et des tokens utilisés.
OpenRouter l'écrit très clairement :
La plateforme prélève des frais de 5,5 % lors de l'achat de crédits, avec un minimum de 0,8 dollar ; les prix des fournisseurs de modèles sous-jacents sont facturés aux utilisateurs au prix d'origine, sans majoration supplémentaire sur le prix de l'inférence des modèles.
C'est un commerce typique de « péage pour le trafic ».
L'avantage de ce modèle est que les revenus sont liés à l'utilisation.
Plus les développeurs appellent, plus les revenus de la plateforme sont élevés ; plus il y a d'applications d'IA, plus la consommation de tokens est importante, plus les affaires d'OpenRouter sont importantes.
Mais cela a aussi une caractéristique : la commission par transaction n'est pas élevée, donc il faut compter sur le volume.
C'est pourquoi le volume de traitement des tokens est si important pour OpenRouter.
Son indicateur clé n'est pas le nombre d'utilisateurs inscrits, mais le nombre de tokens qui transitent par lui chaque semaine, chaque mois.
En 2025, le volume de traitement annuel d'OpenRouter est passé d'environ 10 billions de tokens à plus de 100 billions de tokens.
En 2026, OpenRouter atteignait déjà un volume de traitement annualisé d'environ 1,5 billiard de tokens.
C'est la logique fondamentale de cette activité.
Tant que de plus en plus d'applications d'IA fonctionnent sur des systèmes multi-modèles, OpenRouter pourra continuer à prélever des frais de service sur ces appels.
Pourquoi la croissance a-t-elle été si rapide récemment ?
La croissance d'OpenRouter, pour résumer, a profité de trois changements.
Le premier changement, c'est l'augmentation du nombre de modèles.
Auparavant, pour créer une application d'IA, de nombreuses équipes utilisaient par défaut OpenAI. Maintenant, c'est différent.
Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, ainsi qu'un grand nombre de modèles open source et à poids ouverts, présentent des avantages dans différents scénarios.
Ce n'est pas un marché où « quelqu'un remplace complètement quelqu'un d'autre ».
Certains modèles sont bons pour écrire du code, d'autres sont moins chers, d'autres ont un contexte long, d'autres sont rapides, d'autres sont adaptés au jeu de rôle, d'autres aux documents d'entreprise, d'autres au multimodal.
Plus il y a de modèles, plus le coût de choix est élevé ; plus le coût de choix est élevé, plus la couche intermédiaire a de la valeur.
Le deuxième changement, c'est que les applications d'IA commencent à se soucier des coûts.
Beaucoup de produits utilisent d'abord le modèle le plus puissant, car il faut d'abord obtenir des résultats.
Mais une fois que le produit a des utilisateurs, le coût des modèles devient rapidement un problème.
Un robot de support client, un produit de recherche IA, un assistant de code, un outil de génération de contenu, si toutes les requêtes passent par le modèle le plus cher, la marge brute peut facilement être mangée.
Une approche plus mature consiste à décomposer les tâches :
- Les tâches simples utilisent un modèle peu cher ;
- Les tâches complexes utilisent un modèle puissant ;
- Les tâches à haute fréquence privilégient un modèle à faible latence ;
- En cas d'échec, basculer vers un modèle de secours ;
- Lorsqu'il s'agit de données sensibles, ne passer que par des fournisseurs conformes à la politique des données.
C'est précisément le scénario d'utilisation d'OpenRouter.
Il ne vous aide pas forcément à trouver le « modèle le plus puissant », mais il peut vous aider à équilibrer l'efficacité, le prix, la vitesse et la stabilité.
Le troisième changement, c'est que les applications d'IA passent de la boîte de dialogue à l'agent intelligent.
Les agents intelligents appellent des outils, lisent des fichiers, recherchent sur le web, exécutent des tâches, et appellent également le modèle de manière continue sur plusieurs tours.
Comparé au chat ordinaire, les agents intelligents consomment plus de tokens et dépendent davantage de la stabilité.
C'est bénéfique pour OpenRouter.
Car plus le nombre d'appels est élevé, plus la chaîne est longue, plus les développeurs ont besoin de routage, de secours, de journaux, de contrôle des coûts et de gestion des fournisseurs.
C'est pourquoi l'annonce de financement d'OpenRouter souligne que l'IA passe de l'expérimentation à des applications de production critiques et à des scénarios d'agents intelligents.
Sa croissance provient essentiellement de l'augmentation du volume d'appels d'IA.
Cette activité comporte aussi des risques
La position d'OpenRouter est bonne, mais pas sûre.
Il est coincé entre les sociétés de modèles, les fournisseurs de cloud et les développeurs d'applications. Cette position a de la valeur, mais elle est aussi facile à écraser.
Le premier risque, c'est que les grandes entreprises pourraient construire leur propre solution.
Pour les petites équipes, OpenRouter est très pratique.
Mais pour les grandes entreprises, le routage des modèles, les autorisations, les journaux, la gestion des coûts peuvent aussi être faits en interne, ou confiés aux fournisseurs de cloud.
En particulier les clients du secteur financier, médical, gouvernemental ou des entreprises, qui pourraient accorder plus d'importance au contrôle des données et au déploiement privé.
Pour pénétrer ces clients, OpenRouter ne peut pas se contenter d'« avoir beaucoup de modèles ». Il doit approfondir suffisamment les autorisations, l'audit, les politiques de données, la gestion des fournisseurs et le support aux entreprises.
Le deuxième risque, c'est que les fournisseurs de cloud feront aussi des passerelles de modèles.
AWS, Google Cloud, Azure, ces plateformes cloud ont déjà des clients entreprises, des systèmes de facturation, des systèmes d'autorisation et des capacités de conformité.
Elles peuvent parfaitement intégrer les appels multi-modèles, le routage, la surveillance et la gestion des coûts dans une partie de leurs services cloud.
L'avantage d'OpenRouter est son ouverture et sa neutralité, sa couverture de modèles plus large, et une intégration plus rapide.
Mais l'avantage des fournisseurs de cloud, c'est la relation client et les processus d'achat des entreprises, c'est une compétition à long terme.
Le troisième risque, c'est la relation avec les fournisseurs de modèles.
OpenRouter apporte du trafic aux sociétés de modèles, mais éloigne aussi ces sociétés des développeurs finaux d'un cran.
Lorsque la plateforme grandit, elle maîtrise davantage de relations utilisateurs et de données d'utilisation des modèles.
Les fournisseurs de modèles souhaitent à la fois obtenir une distribution, mais s'inquiètent aussi de voir leur pouvoir de négociation affaibli.
Ce type de plateforme intermédiaire est généralement bien accueilli par les fournisseurs au début ; lorsque l'échelle augmente, la relation devient plus délicate.
Le quatrième risque, c'est que les frais de plateforme pourraient être réduits.
OpenRouter prélève 5,5 % de frais de plateforme, ce qui semble peu pour le moment.
Mais si des services similaires se multiplient, les développeurs compareront les prix, la stabilité, la couverture des modèles et les fonctionnalités pour les entreprises.
Si certains concurrents sont prêts à proposer des taux plus bas, ou si les fournisseurs de cloud intègrent ce type de capacités dans leurs services existants, OpenRouter devra prouver qu'il n'est pas seulement un « redirecteur de requêtes ».
Il doit continuer à fournir un meilleur routage, une couverture de modèles plus forte, des prix plus transparents, des services plus stables et un contrôle d'entreprise plus complet.
