Après le SaaS, STRIPE veut aider les opérateurs IA à facturer leurs offres
📩 Pour nous contacter: redaction@fw.media
En rachetant OpenRouter, une plateforme donnant accès à plus de 400 modèles d’IA, Stripe ne se contente plus d’encaisser les revenus de ses clients. Le groupe remonte vers leurs coûts de production, mesure leur consommation de tokens et se place au moment où chaque requête devient une décision d’achat. Après avoir fourni la caisse du SaaS, il veut devenir à la fois la centrale d’achat, le compteur et le système de facturation de l’intelligence. C’est l’une des informations marquantes de l’été, sélectionnée et décodée par la rédaction de FW.MEDIA (Pour nous contacter: redaction@fw.media).
Trois mois. C’est à peu près le temps qu’il aura fallu à OpenRouter pour passer d’une valorisation de 1,3 milliard de dollars à un prix de cession supérieur à 8 milliards.
En mai 2026, la startup avait levé 113 millions de dollars lors d’un tour mené par CapitalG avec une valorisation d’environ 1,3 milliard selon le New York Times. Le 19 août dernier, Stripe annonçait avoir conclu un accord pour la racheter. Un écart qui suffit à poser la première question, qu’est-ce que Stripe a découvert en quelques semaines pour accepter de payer plus de six fois la valeur attribuée à OpenRouter lors de son dernier tour de table ?
La réponse officielle tient dans un mot : les tokens. Selon Stripe, OpenRouter traite désormais plus de 10 000 milliards de tokens par jour, donne accès à plus de 400 modèles auprès de plus de 80 fournisseurs et rassemble plus de 10 millions de développeurs et d’entreprises.
Mais Stripe ne rachète pas simplement un tuyau transportant des requêtes, il acquiert l’endroit où une entreprise choisit quelle intelligence acheter, combien la payer et comment la transformer en revenu. Pour comprendre l’ampleur du pari, il faut d’abord revenir à ce que Stripe savait déjà faire.
Le SaaS avait besoin d’une caisse
Le succès de Stripe a accompagné celui du SaaS sans se confondre entièrement avec lui. La société n’a pas produit les logiciels de gestion, de marketing, de recrutement ou de cybersécurité vendus par ses clients. Elle a pris en charge la fonction qu’ils partageaient tous : convertir un produit logiciel en revenu.
Le modèle était relativement régulier. Une entreprise facturait un abonnement mensuel ou annuel, souvent calculé par utilisateur. Le coût marginal d’un client supplémentaire restait limité. Le revenu pouvait être suivi à travers quelques indicateurs devenus la grammaire du secteur : ARR, churn, coût d’acquisition et lifetime value.
Stripe a progressivement absorbé les tâches situées autour de cette transaction : paiement, abonnement, relance des cartes refusées, facturation, calcul des taxes, reconnaissance du revenu, gestion de la fraude. L’éditeur pouvait se concentrer sur son produit, Stripe s’occupait de faire entrer l’argent, avec la discrétion d’une plomberie qui prélève néanmoins sa commission à chaque passage.
C’est cet équilibre que l’intelligence artificielle vient bousculer, elle conserve l’apparence du logiciel, mais en modifie l’économie. Une fonctionnalité SaaS traditionnelle peut être utilisée mille fois sans devoir être reconstruite à chaque clic. Une réponse produite par un modèle doit, elle, être recalculée, chaque usage entraîne une consommation de tokens, de calcul, de mémoire et parfois de services extérieurs.
Le coût ne dépend donc plus seulement du nombre de clients, mais de ce qu’ils demandent au produit, du modèle mobilisé, de la longueur du contexte, du nombre d’étapes de raisonnement et des éventuelles tentatives nécessaires avant d’obtenir un résultat exploitable.
| Économie du SaaS | Économie de l’IA |
|---|---|
| Prix par utilisateur | Prix par usage, crédit, tâche ou résultat |
| Coût marginal limité | Coût à chaque inférence |
| Fournisseur technique relativement stable | Multiplicité de modèles et de fournisseurs |
| Marge relativement prévisible | Marge dépendante de la consommation |
| Facturation principalement en aval | Arbitrage nécessaire des coûts en amont |
Deux applications affichant le même revenu récurrent peuvent ainsi présenter des marges radicalement différentes. Un abonnement à 20 euros sera très rentable avec un utilisateur occasionnel, et déficitaire avec celui qui mobilise chaque jour le modèle le plus coûteux, lui transmet des documents interminables et laisse ses agents multiplier les tentatives.
Si dans le SaaS, Stripe gérait la récurrence du revenu, dans l’IA, il veut gérer la variabilité de la marge, et il se trouve qu’une entreprise avait déjà bâti l’infrastructure pour le faire.
OpenRouter était déjà une fintech
Si OpenRouter est généralement présenté comme un gateway, autrement dit une interface permettant d’accéder à plusieurs modèles sans devoir intégrer séparément les API d’OpenAI, d’Anthropic, de Google, de DeepSeek ou d’autres fournisseurs, cette description bien que techniquement correcte, est économiquement incomplète.
Car OpenRouter possède déjà son propre système de crédits libellés en dollars. Les utilisateurs approvisionnent leur compte, puis le coût de chaque requête est déduit de leur solde. La plateforme affirme répercuter les tarifs publics des fournisseurs sans majoration sur l’inférence, mais prélève 5,5 % lors de l’achat des crédits, avec un minimum de 0,80 dollar. Les clients apportant leurs propres clés de fournisseurs peuvent également être facturés au-delà de certaines limites.
Ainsi vu, OpenRouter est moins un simple aiguillage qu’une place de marché dotée de son registre de consommation, de son unité de compte et de son prélèvement sur les flux, autant dire une fintech spécialisée dans l’achat d’intelligence artificielle, avec une API pour devanture.
La proximité entre les deux entreprises n’est d’ailleurs pas nouvelle, en janvier 2026, Stripe annonçait déjà qu’OpenRouter utilisait ses services pour la facturation, le calcul des taxes et la lutte contre la fraude. La plateforme revendiquait alors cinq millions de développeurs. Six mois plus tard, ce client est devenu une cible d’acquisition.
Stripe rachète un système économique qui fonctionnait déjà sur ses propres rails, ce qui rend d’autant plus intéressante la question de ce qu’il a réellement payé.
Pourquoi payer huit milliards de dollars ?
Le communiqué de Stripe ne fournit aucun chiffre sur le revenu d’OpenRouter, sa marge, le montant des crédits vendus ou la part payante de son trafic. Il est donc impossible de rapporter sérieusement le prix annoncé à des performances financières observables.
Le nombre de tokens, tout aussi spectaculaire qu’il soit, ne suffit pas non plus. Un token traité gratuitement ne génère pas le même revenu qu’un token vendu dans un modèle de raisonnement haut de gamme, et les prix varient également entre les entrées, les sorties, les contextes mis en cache, les images et les appels à certains outils.
Une simulation permet seulement de mesurer l’ampleur de l’incertitude. Si les 10 000 milliards de tokens quotidiens revendiqués étaient tous payants, et si leur coût moyen atteignait un dollar par million, ils représenteraient environ 3,65 milliards de dollars de dépenses d’inférence annualisées. Une commission théorique de 5,5 % correspondrait alors à environ 201 millions de dollars. À 0,25 dollar par million, elle tomberait autour de 50 millions. À 5 dollars, elle dépasserait le milliard.
Attention ces montants ne constituent pas des estimations du revenu d’OpenRouter (ils ignorent les modèles gratuits, les conditions négociées avec les entreprises, les crédits inutilisés, les remises, les clés apportées par les clients et les autres modes de facturation), Ils montrent surtout que l’on ne peut déduire la valeur économique du trafic à partir de son seul volume.
Stripe peut donc payer pour autre chose que le revenu actuel. D’autant que si OpenRouter lui apporte une distribution massive auprès des développeurs, une position au milieu des fournisseurs de modèles et une quantité considérable de données économiques : modèles réellement utilisés, prix acceptés, changements de fournisseurs, latence, taux d’échec et sensibilité des clients aux arbitrages entre coût et qualité, le groupe achète aussi du temps. Construire un routeur est possible, déplacer des millions d’intégrations déjà installées l’est beaucoup moins.
Selon Axios, la transaction serait financée majoritairement en actions Stripe. Rapporté à la valorisation de 159 milliards de dollars retenue lors d’une opération sur titres en février 2026, le montant évoqué représenterait environ 5 % de la valeur du groupe, même si les références de valorisation et les modalités précises de l’échange peuvent différer. Stripe utilise ainsi ses actions privées comme une monnaie d’acquisition, sans avoir besoin de passer par la Bourse.
Pour les actionnaires d’OpenRouter, l’opération ne constitue donc pas nécessairement une sortie intégralement liquide. Elle peut aussi représenter un échange entre deux paris : une participation dans le marché du routage contre une participation dans l’infrastructure financière qui espère l’absorber.
Stripe remonte vers le coût de production
Ce qui change, au fond, c’est la position de Stripe dans la chaîne. Jusqu’à présent, l’entreprise intervenait principalement après la création du service : l’éditeur produisait son logiciel, le client l’utilisait, puis Stripe présentait la facture et encaissait le paiement, avec OpenRouter, le groupe remonte avant la réponse.
Lorsqu’une requête arrive, le routeur peut choisir un modèle selon la complexité de la tâche, son prix, sa vitesse, sa disponibilité ou les règles de confidentialité imposées par l’entreprise. Une demande simple peut être confiée à un modèle léger. Une analyse plus complexe sera dirigée vers un système plus puissant. En cas de panne ou de saturation, un autre fournisseur pourra prendre le relais. Chaque requête devient ainsi une petite décision d’achat.
Si la direction technique conserve la responsabilité de la qualité et de la sécurité, le directeur financier entre dans l’API : le choix du modèle détermine désormais le coût par utilisateur, la marge brute et parfois la viabilité du produit.
En parallèle, Stripe développe parallèlement une offre de facturation des tokens. Sa documentation prévoit plusieurs modèles : revente avec marge, facturation à l’usage, forfait comprenant un volume de consommation, dépassements ou packs de crédits. L’entreprise donne même l’exemple d’une application souhaitant conserver une marge constante de 30 % au-dessus du coût brut des modèles. A noter que ce service reste cependant présenté comme une expérimentation en accès privé.
À terme, la boucle pourrait néanmoins être complète. OpenRouter sélectionnerait le modèle et constaterait son prix. Stripe mesurerait la consommation, appliquerait la marge souhaitée, générerait la facture et encaisserait le client. Une position inédite pour Stripe, qui ne connaîtrait plus seulement le chiffre d’affaires de l’entreprise, mais participerait au calcul de son coût des ventes.
Le routeur devient le service achats de l’intelligence
Bien entendu, Stripe n’est pas seul à voir cette opportunité. Le lancement de Router.com par Ramp, annoncé la même semaine, ou encore la levée de fonds de Sapiom début août, confirment que cette couche est en train de devenir un produit autonome. Ramp affirme envoyer chaque demande vers le modèle le moins coûteux respectant un niveau de performance défini, et annonce 40 % d’économies moyennes parmi ses premiers utilisateurs.
Le choix d’un modèle n’est plus une décision prise une fois pour toutes lors de la conception du produit. Il devient un arbitrage répété en temps réel. Les grands clouds travaillent dans la même direction : Amazon Bedrock propose un routage tenant compte de la qualité et du coût, et Microsoft Foundry peut sélectionner différents modèles selon la complexité, la latence et le niveau de performance recherché.
La question n’est donc pas de savoir si les entreprises utiliseront des routeurs, elle est de déterminer si cette fonction restera une catégorie autonome ou deviendra une simple option offerte par les clouds.
Dans le premier scénario, OpenRouter peut bénéficier d’effets de réseau : plus la plateforme attire de clients, plus elle concentre de demande ; plus elle concentre de demande, plus elle peut attirer de fournisseurs, améliorer ses conditions et enrichir ses données de comparaison. Dans le second, le routage devient une commodité, les entreprises restent chez AWS, Microsoft ou Google, déjà référencés par leurs services achats et intégrés à leur gouvernance informatique ; les modèles proposent eux-mêmes des gammes suffisamment étendues pour retenir leurs clients ; les routeurs open source permettent aux plus grandes organisations de conserver le contrôle.
Stripe aurait alors payé plusieurs milliards pour une fonction que les plateformes dominantes finiront par intégrer à leurs contrats existants. C’est le premier grand risque de l’opération, le second touche à une promesse plus fondamentale, celle de la neutralité.
La neutralité a toujours un propriétaire
OpenRouter fonde une partie de sa valeur sur sa neutralité. Aucun modèle ne serait optimal pour toutes les tâches, le routeur doit donc sélectionner le meilleur fournisseur sans préférence préalable.
Cette promesse devient plus délicate lorsque le propriétaire du routeur facture aussi la consommation, vend des crédits et entretient ses propres accords commerciaux avec les fournisseurs. Le modèle le moins coûteux pour le client ne sera pas nécessairement le plus rémunérateur pour l’intermédiaire. Une remise négociée peut être répercutée, conservée ou utilisée pour orienter la demande. Un algorithme peut optimiser le prix affiché, la marge du routeur, la fiabilité ou une combinaison de ces critères, les quatre objectifs ne produisent pas toujours le même résultat.
L’enjeu ne tient donc pas seulement aux performances techniques. Il porte sur la gouvernance du marché :
- les critères de sélection seront-ils vérifiables ?
- les clients pourront-ils imposer une liste de fournisseurs ?
- les accords commerciaux influenceront-ils le classement ?
- les remises obtenues seront-elles répercutées ?
- l’entreprise pourra-t-elle reconstituer la raison pour laquelle un modèle précis a traité une demande ?
OpenRouter permet déjà de définir des règles de confidentialité, d’exiger une absence de conservation des données et, pour certains clients entreprises, de maintenir le traitement dans l’Union européenne. La plateforme indique également ne pas conserver les prompts par défaut. Mais les politiques diffèrent selon les fournisseurs auxquels les requêtes sont transmises : la multiplication des choix ne supprime donc pas le travail de conformité, et le déplace dans le moteur de routage.
Le routeur réduit d’ailleurs une dépendance pour en créer une autre. Si l’entreprise peut plus facilement passer d’OpenAI à Anthropic ou DeepSeek, elle devient néanmoins dépendante de l’API, du système de crédits, des contrats et des règles d’OpenRouter.
Les modèles ne sont pas des fournisseurs parfaitement interchangeables
Cette question de gouvernance en soulève une autre, plus technique : celle de savoir si l’on peut réellement traiter les modèles comme des commodités substituables. Le raisonnement économique du routage suppose qu’une même tâche puisse être confiée à plusieurs modèles dès lors qu’ils dépassent un seuil de qualité. Cette hypothèse fonctionne pour une traduction simple, un résumé ou la classification d’un message.
Elle devient plus fragile lorsqu’un modèle intervient dans une décision juridique, financière, médicale ou industrielle. Deux systèmes ne présentent pas les mêmes taux d’erreur, les mêmes capacités d’utilisation des outils, les mêmes règles de sécurité ni les mêmes politiques de données. Une mise à jour peut également modifier leur comportement sans que l’application cliente ait changé une ligne de code.
Le « modèle le moins cher suffisamment performant » soulève alors une question que les tableaux de benchmarks résolvent mal : suffisamment performant pour qui, sur quelle tâche et avec quelle responsabilité en cas d’erreur ? Même Microsoft recommande d’évaluer son routeur sur les charges de travail réelles de l’entreprise en comparant qualité, coût et latence, il n’existe pas de seuil universel séparant l’intelligence suffisante de celle qui ne l’est pas.
Cette limite rapproche encore l’ingénierie de la finance. Économiser 30 % sur le coût d’une requête n’a aucun intérêt si le nombre de corrections humaines double ou si l’application dégrade discrètement le service rendu.
Le token n’est pas encore une monnaie
Le fondateur de Stripe, Patrick Collison présente les tokens comme la monnaie centrale des entreprises d’IA. Si la formule sert parfaitement le récit d’un groupe spécialisé dans la circulation de l’argent, elle demeure toutefois une métaphore.
Un token n’est pas fongible, chaque modèle peut utiliser son propre système de découpage. Les fournisseurs distinguent tokens d’entrée, de sortie, de raisonnement ou de cache, les images, les vidéos et les appels à des outils obéissent encore à d’autres unités. Surtout, un million de tokens produits par deux modèles différents ne fournit ni la même qualité ni la même quantité de travail utile.
Le token mesure l’effort facturé par la machine, or le client préférera payer le résultat. L’économie de l’IA pourrait ainsi évoluer du prix par utilisateur vers le prix par token, avant d’adopter des crédits plus abstraits puis une facturation par tâche ou par résultat : une facture rapprochée, un ticket résolu, un contrat analysé, u encore une réservation effectuée.
Le véritable enjeu pour Stripe ne consiste donc pas uniquement à compter les tokens, et consiste à traduire une consommation technique devenue illisible en une unité commerciale que le client accepte d’acheter.
Des tokens moins chers peuvent produire une facture plus élevée
Le routage promet de diminuer le coût de chaque requête, or cela ne signifie pas nécessairement que les entreprises dépenseront moins.
Un modèle moins cher permet d’analyser davantage de documents, d’ajouter des étapes de raisonnement, de multiplier les agents et d’automatiser des tâches auparavant jugées trop coûteuses. Chaque unité d’intelligence devient plus accessible, et sa consommation totale augmente. L’économie numérique connaît bien ce phénomène : les gains d’efficacité finissent rarement dans un coffre, et sont la plupart du temps réinvestis dans davantage d’usage.
Après les entreprises, les agents
Le rachat d’OpenRouter s’inscrit enfin dans une stratégie plus large, en avril 2026, Stripe a présenté des wallets permettant à des agents d’effectuer des paiements pour le compte de leurs utilisateurs. Deux mois plus tard, le groupe annonçait avec AWS un mécanisme permettant à un agent de payer automatiquement pour accéder à un article, une base de données ou une API.
Dans cette économie, l’agent ne se contente plus de produire une réponse, mais achète du calcul, consulte une source payante, appelle un service extérieur et engage une dépense avant de facturer éventuellement le résultat à son propriétaire. Le moment où il choisit un modèle devient donc aussi celui où il effectue un achat.
OpenRouter peut fournir le marché, Stripe, le moyen de paiement, Token Billing, le compteur. Les wallets pour agents, l’acheteur automatique.
L’ensemble ne forme pas encore un système pleinement intégré. Plusieurs produits restent expérimentaux, les fournisseurs de modèles conserveront leur pouvoir et les grandes plateformes cloud défendront leur relation directe avec les entreprises, mais la tendance apparaît désormais assez clairement.
Notre politique éditoriale concernant l'intelligence artificielle
Les analyses et articles sont rédigées par des journalistes.
L'IA peut être utilisée comme outil d'assistance (traduction, synthèse, recherche documentaire ou amélioration stylistique).
Les faits, chiffres et analyses sont systématiquement vérifiés et validés par la rédaction.
Les illustrations générées ou modifiées par IA sont explicitement signalées.
