> ## Content Index
> Fetch the complete content index at: https://mauricemendy.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Et si Stripe rachetait OpenRouter ?
- URL: https://mauricemendy.com/et-si-stripe-rachetait-openrouter/
- Published: 2026-07-24T15:15:57.000Z
- Updated: 2026-08-19T19:44:06.000Z
- Author: Maurice MENDY
- Tags: stratégie IA entreprise, agents IA

J'utilise OpenRouter en production. Comme beaucoup d'ingénieurs qui construisent avec des LLMs, j'ai fait ce choix d'abord pour une question de coût et de choix de modèles. Le catalogue donne accès à des centaines de LLMs, dont beaucoup en open-weight, à des tarifs par token très inférieurs à ceux des modèles frontier propriétaires. Pour la plupart des usages, on trouve un modèle open-source qui fait le boulot pour une fraction du prix, sans setup infrastructure ni gestion de GPUs.

L'annonce de la semaine change le calcul. Stripe est en discussion pour racheter OpenRouter pour près de 10 milliards de dollars, selon le Wall Street Journal repris par The Information. L'entreprise valait 1,3 milliard en mai 2026 d'après PitchBook. Multiplication par huit en deux mois. Databricks aurait aussi eu des discussions préliminaires.

![Logo OpenRouter, plateforme de routage multi-modèles rachetée par Stripe](https://mauricemendy.com/content/images/2026/07/OpenRouter-.jpg)

Deux questions pour ceux qui, comme moi, ont bâti leur stack sur OpenRouter. Qu'est-ce qu'un acteur du paiement va faire d'une infrastructure LLM qui n'est pas son cœur de métier ? Et quelles sont les alternatives réelles en 2026?

## Ce que change un acquéreur pour qui l'AI n'est pas le core business

Stripe traite déjà les paiements d'OpenRouter. En rachetant, ils remontent d'un cran dans la chaîne : plus seulement processeur de flux AI, mais propriétaire de l'infrastructure sur laquelle les développeurs choisissent leurs modèles. Le mouvement s'inscrit dans leur trajectoire d'expansion j'imagine (hors du core payments

Chez Stripe, l'infrastructure LLM sera gérée comme un actif d'expansion, avec la logique de portefeuille qui va avec, pas comme la conviction produit d'un pure player. À long terme, la différence se voit dans la cadence produit, l'allocation des ressources d'ingénierie, et les arbitrages entre l'intérêt du produit et celui du groupe acquéreur. Les rachats d'infrastructure développeur par des acteurs adjacents donnent des trajectoires très variables. GitHub sous Microsoft a plutôt bien tenu. Skype s'est étiolé jusqu'à disparaître.

OpenRouter n'est pas seul dans cette dynamique. Portkey, l'autre grand gateway AI open-source, a été acquis par Palo Alto Networks fin avril 2026, un mois après avoir open-sourcé sa gateway complète sous Apache 2.0\. Les couches middleware AI qui traitent aujourd'hui des trillions de tokens par jour attirent les acteurs d'infrastructure adjacents, du payment à la cybersécurité en passant par les data platforms.

## Le paysage réel des alternatives en 2026

Avant de lister, il faut être précis sur ce qu'on cherche à reproduire. OpenRouter combine une API unifiée, un catalogue large, un routing qualité mesuré, une neutralité entre providers, et une facturation unique sans setup. Aucune alternative aujourd'hui ne fournit exactement cette combinaison.

LiteLLM est l'option la plus complète côté open-source. Licence MIT, 140 providers, plus de 2500 modèles, un historique de support day-zero pour les nouveaux modèles. Quand GPT-5.5 est sorti en avril 2026, le support était disponible le jour même. Virtual keys, budgets par équipe, fallbacks automatiques, spend tracking, support MCP natif. En contrepartie, on prend la responsabilité opérationnelle. Il faut Docker, PostgreSQL, Redis, un load balancer devant, un plan de scaling. Il faut aussi mentionner l'incident de supply chain de mars 2026, avec des versions compromises publiées sur PyPI. La réponse de l'équipe a été rapide, mais l'épisode rappelle que self-héberger un proxy critique demande de suivre les CVEs.

Portkey Gateway est la seconde option en self-hosted. Depuis mars 2026, la gateway 2.0 est intégralement open-source sous Apache 2.0 avec circuit breakers, gouvernance, MCP Gateway, 1600+ modèles chez 250+ providers. Palo Alto Networks a racheté l'entreprise fin avril, ce qui introduit une incertitude sur la suite. Apache 2.0 protège l'existant, mais la cadence produit sur le repo public dépendra désormais des priorités PANW.

Requesty est le concurrent direct d'OpenRouter côté managed, avec un positionnement EU. 400 à 600 modèles, endpoint compatible OpenAI, prompt caching qui économise 40 à 60 % sur les prompts répétés, RBAC à cinq couches, conformité SOC-2 et ISO 27001\. Et surtout la data residency UE, un point sur lequel OpenRouter n'a jamais eu de réponse claire. La contrepartie tient à leur maturité (3M$ levés en 2024) et au fait que c'est un autre managed service, avec les mêmes risques structurels que celui qu'on chercherait à quitter.

Le retour aux APIs natives, avec une petite couche maison de 200 à 500 lignes qui expose une interface unique par-dessus les SDKs officiels d'Anthropic, OpenAI, Google. On y perd le catalogue, la comparaison de prix instantanée, le routing qualité. En échange, on récupère le contrôle total du path de dégradation, aucune couche de latence supplémentaire, aucune donnée qui transite chez un intermédiaire. Pour un outil interne qui appelle un ou deux modèles sur un flux bien défini (chat support, extraction de données, pipeline de résumé), c'est probablement le bon choix. Pour un stack multi-modèles avec routing dynamique, autant réécrire OpenRouter à la main.

Deux outils sont souvent confondus avec des alternatives à OpenRouter, alors qu'ils jouent un autre rôle. NotDiamond ne remplace pas un gateway. C'est une couche qui recommande, par requête, quel modèle a la meilleure probabilité de bien répondre, et qui s'utilise devant un gateway, pas à la place. Cloudflare AI Gateway est un proxy à l'edge sans routing intelligent, utile si vous êtes déjà sur Cloudflare mais insuffisant comme couche unique.

## Que faire dès maintenant, sans paniquer

L'acquisition n'est pas conclue. Le WSJ précise que les discussions peuvent capoter. Rien n'oblige à sortir d'OpenRouter aujourd'hui. Ce qui est utile, c'est de faire le travail de préparation qu'on aurait dû faire de toute façon.

Le point de départ, c'est un audit rapide du couplage. Quelle part du code applicatif dépend spécifiquement d'OpenRouter au-delà de l'endpoint HTTP ? Utilisation des Skills OpenRouter, du scoring propriétaire d'Auto Exacto, des metadata de routing ? Une heure suffit pour la plupart des stacks. Vient ensuite l'écriture d'une couche d'abstraction si elle n'existe pas, un interface commun côté application avec `complete(model, messages, tools)` et deux ou trois implémentations concrètes. Un ou deux jours de travail pour une équipe classique. Reste enfin un test de bascule à froid, deux ou trois heures pour vérifier que le code peut pointer vers LiteLLM auto-hébergé, vers Requesty, ou vers les APIs natives, sans changer la logique applicative.

L'ensemble représente quelques jours de travail. À comparer avec ce que coûte une bascule dans l'urgence si l'acquisition dérape, où on parle de plusieurs semaines à quelques mois de reconstruction sous pression, avec des trade-offs pris sans temps de réflexion.

Il y a un piège à éviter dans les deux sens. Fuir un outil qu'on aime parce qu'il change de main, ou s'y accrocher simplement parce qu'on le connaît. Aucun des deux n'est un choix d'ingénieur.

Le middleware AI est en train de se consolider. Portkey vers Palo Alto Networks fin avril, OpenRouter vers Stripe peut-être. Rien n'indique que le mouvement s'arrête à ces deux acteurs. Pour ceux qui construisent sur cette couche, la vraie question est devenue celle du niveau d'optionalité qu'on garde dans son stack.  
  
![Infographie comparative des gateways LLM : OpenRouter et alternatives 2026](https://mauricemendy.com/content/images/2026/07/gateways-llm-infographie-1.png)

##