OpenRouter : comment une « station de transfert de modèles » peut-elle devenir une entreprise d'un milliard de dollars ?

作者：张艾拉

Aujourd'hui, parlons des plateformes de relais.

En termes simples, une plateforme de relais de modèles connecte différents modèles comme OpenAI, Claude, Gemini, DeepSeek, etc., derrière une même entrée, permettant aux développeurs d'utiliser une seule interface, un seul compte et une seule facturation pour appeler plusieurs modèles, et de choisir, basculer ou avoir des solutions de secours entre différents modèles ou fournisseurs.

Bien sûr, pour les utilisateurs chinois, la raison majeure d'utiliser ces plateformes est d'accéder aux modèles étrangers et de bénéficier de tarifs plus avantageux.

Tout le monde comprend cela, nous n'allons pas nous attarder sur les plateformes chinoises. Aujourd'hui, nous allons principalement présenter OpenRouter.

D'ici 2026, OpenRouter aura levé 113 millions de dollars en série B, et sa valorisation approchera les 1,3 milliard de dollars.

Cela signifie qu'il est déjà devenu une licorne.

Analysons donc pourquoi une plateforme de relais de modèles qui « ne crée pas de modèles » peut valoir autant d'argent ?

Que fait exactement OpenRouter ?

La définition officielle d'OpenRouter est : une interface unifiée pour les grands modèles.

OpenRouter prend aujourd'hui en charge plus de 400 modèles et plus de 70 fournisseurs de modèles.

Le site officiel indique également que la plateforme traite déjà 100 billions de tokens par mois et compte plus de 10 millions d'utilisateurs dans le monde.

Dans l'annonce de la série B de mai 2026, il est mentionné qu'au cours des six derniers mois, le volume hebdomadaire traité par OpenRouter est passé de 5 billions à 25 billions de tokens, et qu'il sert plus de 8 millions de développeurs.

Ces chiffres montrent une chose :

OpenRouter n'est plus un simple outil de développeur de niche, mais une importante porte d'entrée pour les appels d'IA.

La façon dont les développeurs l'utilisent est également très simple.

Auparavant, il fallait se connecter séparément à OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI, etc.

Pour chaque fournisseur, il fallait consulter la documentation, demander une clé API, lier une facturation, gérer les différences d'interface, vérifier les limites 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 l'interface OpenAI nécessite simplement de modifier l'URL de base, de changer la clé API et de spécifier le nom du modèle pour appeler un autre modèle via OpenRouter.

C'est l'une des raisons de sa croissance rapide au début : faible coût de migration.

Pourquoi les développeurs ne se connectent-ils pas directement aux entreprises de modèles ?

En apparence, les développeurs pourraient contourner OpenRouter et aller directement sur le site officiel des entreprises de modèles pour obtenir une API.

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 véritable métier, il est difficile de ne dépendre que d'un seul modèle.

Par exemple, un outil d'écriture d'IA peut avoir plusieurs types de tâches :

Générer des titres : un modèle bon marché suffit ;

Écrire des articles longs : besoin d'une capacité textuelle plus forte ;

Analyser des documents : besoin d'un modèle à long contexte ;

Effectuer une modération de contenu : besoin d'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 de données ;

En période de pointe, le modèle est limité en débit, il faut basculer automatiquement 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 le moins cher, quel fournisseur est le plus rapide, quel fournisseur a le taux d'échec le plus bas, comment basculer en cas de problème, comment imputer les factures, comment isoler les données des clients entreprises.

Plus ennuyeux encore, le marché des modèles évolue très rapidement.

Aujourd'hui, Claude est bon pour coder, demain, Gemini a un avantage en long contexte, après-demain, DeepSeek ou un modèle open source réduit les prix.

Les capacités des modèles, les prix, la longueur du contexte, les politiques des fournisseurs changent constamment.

C'est là que réside la valeur d'OpenRouter.

Il ne rédige pas les applications d'IA à la place des développeurs, mais il gère pour eux « quel modèle utiliser, comment l'appeler, comment assurer une solution de secours, comment maîtriser les coûts ».

Pas seulement un supermarché de modèles, mais une couche d'orchestration de modèles

Si l'on considère OpenRouter simplement comme un « supermarché de modèles », on sous-estime sa valeur.

Le supermarché de modèles résout le problème de « voici beaucoup de modèles, vous pouvez choisir ».

Mais la véritable capacité importante d'OpenRouter réside dans l'orchestration entre les modèles et les fournisseurs.

Un même modèle peut être fourni 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. Les prix, la vitesse et la stabilité des différents fournisseurs ne sont pas les mêmes.

La documentation d'OpenRouter mentionne une capacité appelée « provider routing », c'est-à-dire le routage des fournisseurs.

Les développeurs peuvent, en fonction de conditions telles que le prix, la latence, le débit, l'ordre des fournisseurs, faire en sorte que les requêtes soient automatiquement orientées vers 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 de modèles » et la « gestion des pannes » du code métier pour les confier à une plateforme spécialisée.

Pourquoi les entreprises ont-elles besoin de cette couche ?

Au début de l'adoption de l'IA en entreprise, le problème est souvent « est-ce que ça marche ? », mais très vite, il devient « comment gérer cela ? ».

Une entreprise peut avoir de nombreuses équipes utilisant l'IA.

L'équipe marketing pour créer du contenu, l'équipe de service client pour répondre aux utilisateurs, l'équipe de R&D pour coder, l'équipe des opérations pour analyser les données, l'équipe juridique pour traiter les contrats.

Si chaque équipe se connecte elle-même aux modèles, les problèmes se multiplient :

Factures non attribuées ; sélection de modèles non uniforme ;

Politiques de données opaques ; redondance des connexions entre équipes ;

Personne ne sait quel appel a causé un problème ;

Le changement de fournisseur de modèle entraîne des difficultés d'adaptation système.

Les espaces de travail, le contrôle budgétaire, les journaux d'appels, les stratégies fournisseurs, le routage avec rétention zéro de données qu'OpenRouter propose, sont autant de solutions à ces problèmes.

Prenons la rétention zéro de données.

Pour de nombreuses entreprises, toutes les requêtes ne peuvent pas être envoyées à n'importe quel fournisseur de modèles sans précaution. Les informations clients, les contrats, les données médicales, les données financières peuvent être soumises à des exigences strictes.

La documentation d'OpenRouter prend en charge la « Zero Data Retention », c'est-à-dire la rétention zéro de données.

Les développeurs peuvent configurer pour que les requêtes ne soient envoyées 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 pour une requête unique.

Autre exemple : le « prompt caching », soit la mise en cache des invites.

De nombreuses applications d'IA utilisent de manière répétée de longs messages système, des contenus de base de connaissances ou du contexte. Si tout est recalculé à chaque fois, le coût est élevé.

OpenRouter permet d'augmenter le taux de hits du cache grâce au routage par affinité fournisseur, en essayant de faire passer les requêtes suivantes par le même point de terminaison fournisseur, réduisant ainsi le coût des contextes répétés.

Ce genre de fonctionnalité n'est pas spectaculaire, mais très pratique. Et plus l'application d'IA est grande, plus les économies réalisées sont visibles.

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 appelés et des tokens consommés.

OpenRouter l'indique clairement :

La plateforme prélève des frais de 5,5 % lors de l'achat de crédit, avec un minimum de 0,8 dollar ; les prix des modèles sous-jacents des fournisseurs sont répercutés à l'utilisateur sans majoration sur le prix d'inférence du modèle.

C'est une activité typique de « péage de 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 les applications d'IA sont nombreuses et plus les tokens consommés sont importants, plus le business d'OpenRouter prospère.

Mais il a aussi une caractéristique : la commission par appel est faible, donc il faut compter sur l'échelle.

C'est pourquoi le volume de tokens traités est crucial pour OpenRouter.

Son indicateur clé n'est pas le nombre d'utilisateurs enregistrés, mais le nombre de tokens qui transitent par lui chaque semaine ou chaque mois.

En 2025, le volume annuel traité par OpenRouter est passé d'environ 10 billions de tokens à plus de 100 billions.

D'ici 2026, OpenRouter aura atteint un volume annualisé d'environ 1,5 quadrillion de tokens.

C'est la logique sous-jacente de ce métier.

Tant que de plus en plus d'applications d'IA s'exécuteront sur des systèmes multi-modèles, OpenRouter pourra prélever des frais de service sur ces appels.

Pourquoi une croissance aussi rapide récemment ?

La croissance d'OpenRouter, en résumé, repose sur trois évolutions.

La première évolution : de plus en plus de modèles.

Auparavant, pour développer une application d'IA, de nombreuses équipes utilisaient OpenAI par défaut. Ce n'est plus le cas aujourd'hui.

Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, ainsi qu'une multitude de modèles open source et à poids ouverts, ont tous des avantages dans différents scénarios.

Ce n'est pas un marché où « un modèle remplace totalement les autres ».

Certains modèles sont bons pour coder, d'autres sont bon marché, d'autres ont un long contexte, d'autres sont rapides, d'autres sont adaptés au jeu de rôle, d'autres sont bons pour les documents d'entreprise, d'autres sont adaptés 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.

La deuxième évolution : les applications d'IA commencent à se soucier des coûts.

De nombreux produits utilisent d'abord le meilleur modèle, car ils doivent d'abord obtenir des résultats.

Mais dès que le produit a des utilisateurs, le coût du modèle devient rapidement un problème.

Un robot de service client, un produit de recherche d'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 est rapidement grignotée.

Une approche plus mature consiste à diviser les tâches :

Tâches simples : modèle bon marché ;

Tâches complexes : modèle puissant ;

Tâches fréquentes : privilégier un modèle à faible latence ;

En cas d'échec, basculer vers un modèle de secours ;

Pour les données sensibles, n'utiliser que les fournisseurs conformes à la politique de données.

C'est exactement le cas d'usage d'OpenRouter.

Il ne vous aide pas forcément à trouver le « meilleur modèle », mais il vous aide à trouver un équilibre entre efficacité, prix, rapidité et stabilité.

La troisième évolution : les applications d'IA passent de la boîte de dialogue aux agents.

Les agents appellent des outils, lisent des fichiers, recherchent sur le web, exécutent des tâches, et effectuent également des appels de modèles en continu.

Par rapport à une simple conversation, les agents consomment plus de tokens et dépendent davantage de la stabilité.

C'est une bonne nouvelle pour OpenRouter.

Car plus le nombre d'appels est élevé et plus la chaîne est longue, plus les développeurs ont besoin de routage, de solutions 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 critiques de production et à des scénarios d'agents.

Sa croissance provient essentiellement de l'augmentation du volume d'appels d'IA.

Ce métier comporte aussi des risques

La position d'OpenRouter est bonne, mais pas sans danger.

Il se trouve entre les entreprises de modèles, les fournisseurs de cloud et les développeurs d'applications. Cette position est à la fois précieuse et susceptible d'être comprimée.

Premier risque : les grandes entreprises peuvent le développer en interne.

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 également être réalisés en interne, ou confiés au fournisseur de cloud.

En particulier les clients des secteurs financier, médical, gouvernemental, qui peuvent être plus soucieux du contrôle des données et du 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 entreprise.

Deuxième risque : les fournisseurs de cloud peuvent également créer des passerelles de modèles.

Les plateformes cloud comme AWS, Google Cloud, Azure ont déjà des clients entreprises, des systèmes de facturation, des systèmes d'autorisation et des capacités de conformité.

Elles peuvent tout à fait proposer comme service cloud l'appel multi-modèle, le routage, la surveillance et la gestion des coûts.

L'avantage d'OpenRouter est son ouverture et sa neutralité, sa couverture de modèles plus large et son intégration plus rapide.

Mais l'avantage des fournisseurs de cloud réside dans la relation client et les processus d'achat en entreprise. C'est une compétition de long terme.

Troisième risque : la relation avec les fournisseurs de modèles.

OpenRouter apporte du trafic aux entreprises de modèles, mais il éloigne également ces dernières des développeurs finaux.

Lorsque la plateforme devient plus grande, elle contrôle davantage de relations utilisateurs et de données d'utilisation des modèles.

Les fournisseurs de modèles veulent à la fois être distribués et craignent que leur pouvoir de négociation ne soit affaibli.

Ces plateformes intermédiaires sont généralement bien accueillies par les fournisseurs au début ; mais une fois qu'elles prennent de l'ampleur, la relation devient plus délicate.

Quatrième risque : les frais de plateforme peuvent être réduits.

OpenRouter prélève 5,5 % de frais de plateforme, ce qui semble faible pour l'instant.

Mais si des services similaires se multiplient, les développeurs compareront les prix, la stabilité, la couverture des modèles et les fonctionnalités entreprise.

Si certains concurrents proposent des frais plus bas, ou si les fournisseurs de cloud intègrent ce type de capacité dans leurs services existants, OpenRouter devra prouver qu'il n'est pas simplement un « transmetteur de requêtes ».

Il doit constamment offrir un meilleur routage, une couverture de modèles plus large, des prix plus transparents, un service plus stable et un contrôle entreprise plus complet.