Stripe absorbe OpenRouter (7 Md$) : rendre votre passerelle LLM réellement interchangeable

Une acquisition d’infrastructure ne devrait pas déclencher de migration. Elle devrait déclencher un audit. Le rachat d’OpenRouter par Stripe est l’occasion idéale de vérifier une hypothèse que beaucoup d’équipes ont laissée implicite depuis deux ans : pouvons-nous changer de passerelle LLM en moins d’une semaine, sans régression de qualité ? Pour la plupart, la réponse honnête est non — et ce n’est pas à cause d’un contrat, c’est à cause d’un identifiant de modèle codé en dur dans quarante fichiers.

Ce qui a été annoncé, et seulement ce qui est confirmé

La chronologie est courte. Une première rumeur relayée par le Wall Street Journal en juillet 2026 évoquait des discussions autour de 10 milliards de dollars. Bloomberg a rapporté un accord imminent les 16-17 août, avant un communiqué officiel de Stripe les 18-19 août, repris par TechCrunch et CNBC : l’opération valorise OpenRouter à plus de 7 milliards de dollars, majoritairement en titres selon Axios.

Ce qu’OpenRouter représente est plus intéressant que le montant. C’est une passerelle unifiée exposant une API compatible OpenAI devant plus de 400 modèles et plus de 80 fournisseurs, avec plusieurs millions de développeurs revendiqués. Autrement dit : une couche d’indirection que d’innombrables équipes ont adoptée précisément pour éviter le verrouillage fournisseur — et qui est devenue, par succès, un verrouillage à part entière.

Le cofondateur a communiqué le message attendu dans ce genre d’opération : même nom, même produit, même feuille de route. Il faut le lire pour ce qu’il est. Un engagement de continuité produit à court terme n’engage ni la politique tarifaire, ni les règles de priorisation du routage, ni les conditions de traitement des données à 18 mois. Ce n’est pas un procès d’intention : c’est simplement la portée réelle de ce type de déclaration, quel que soit l’acquéreur.

Pourquoi c’est un sujet d’architecture, pas de finance

Un routeur LLM n’est pas un proxy passif. À chaque requête, il décide quel fournisseur sert vos tokens, à quel prix, avec quelle latence et sous quelle juridiction. C’est simultanément un point de décision économique et un point de défaillance unique. Les deux propriétés méritent une gouvernance explicite, indépendamment de l’actionnaire.

C’est précisément ce qu’ont soulevé les fils Hacker News dans les heures suivant l’annonce, avec une constance remarquable : la question de la neutralité. Les classements de modèles publiés par une passerelle influencent les choix de milliers d’équipes ; le routage par défaut vers le fournisseur le moins cher ou le plus disponible est une décision opaque prise pour vous ; et aucun engagement public sur les règles de routage n’accompagne l’opération. Rien de tout cela n’est un scandale — mais tout cela devient un risque de concentration lorsque l’intermédiaire est adossé à l’acteur qui traite aussi le paiement.

L’inverse est vrai aussi : la convergence passerelle / paiement laisse présager des primitives de facturation à l’usage pour les agents (métering fin, répartition des coûts par utilisateur final, paiements machine-à-machine). Cette perspective est intéressante. Elle ne doit pas décider de votre architecture aujourd’hui.

Audit express : quelle est votre exposition réelle ?

Quatre questions, une demi-journée de travail.

1. Cartographier les appels. Combien de services parlent à la passerelle en direct, et combien passent par une couche d’abstraction interne ? Un grep suffit souvent à cadrer le chantier :

rg -n "openrouter\.ai|OPENROUTER_API_KEY" --stats -g '!node_modules'
rg -n '"model"\s*:\s*"[a-z-]+/' -g '*.{py,ts,go,yaml}'

2. Repérer les usages non portables. Ce sont eux qui coûtent cher en migration : identifiants de modèles préfixés par fournisseur (anthropic/claude-..., google/gemini-...), objet provider (order, only, allow_fallbacks, data_collection), transformations de prompt automatiques, dépendance aux classements de modèles pour le choix par défaut, et crédits prépayés non remboursables.

3. Quantifier. Part du trafic effectivement routée, dépense mensuelle, et surtout : combien de modèles distincts utilisez-vous réellement ? Dans la majorité des applications en production, la réponse est deux ou trois — sur 400 disponibles. Ce chiffre change radicalement l’équation de sortie.

4. Sortie de données. Où sont vos logs de requêtes et de réponses, avec quelle rétention, et sous quel DPA ? Point d’attention pratique : sur beaucoup de passerelles, le DPA signé est réservé au palier entreprise.

Le calcul de coût honnête, sans idéologie

Décomposez la facture en trois lignes, pas une :

1. Coût des tokens — largement comparable d’un chemin à l’autre, à modèle identique.
2. Frais de plateforme — au moment de la rédaction, OpenRouter applique environ 5,5 % sur l’achat de crédits, avec un minimum de 0,80 $ par transaction. Ce minimum pénalise mécaniquement les petites recharges : sur une recharge de 10 $, le taux effectif dépasse largement le taux affiché. Vérifiez la grille en vigueur avant de conclure.
3. Surcoût de latence — un saut réseau supplémentaire, à mesurer chez vous plutôt qu’à recopier d’un billet de blog. Instrumentez-le avant de le budgéter.

Le seuil de bascule (BYOK, intégration directe ou passerelle auto-hébergée) se calcule simplement :

Coût mensuel passerelle SaaS = tokens + frais_plateforme
Coût mensuel auto-hébergé   = tokens + runtime + (jours_ingé × TJM) / amortissement + astreinte

Seuil atteint quand : frais_plateforme > runtime + amortissement + astreinte

Avec des frais de plateforme à ~5,5 %, un budget tokens de 2 000 $/mois génère ~110 $/mois de frais : très en dessous du coût d’exploitation d’une passerelle maison. À 60 000 $/mois, on parle de ~3 300 $/mois, et l’arbitrage s’inverse. Faites le calcul avec vos chiffres, dans un tableur à trois colonnes : direct / SaaS / auto-hébergé, en incluant explicitement une ligne d’astreinte.

Le contre-argument mérite d’être chiffré avec la même rigueur. Ce que vous payez, ce n’est pas un proxy : c’est le basculement automatique en cas de panne fournisseur, la découverte et l’évaluation de nouveaux modèles, et une facture unique là où vous auriez huit contrats. Réinternaliser ces trois fonctions a un coût réel — souvent sous-estimé par ceux qui ne l’ont jamais fait.

Rendre la passerelle interchangeable : le patron d’architecture

L’objectif n’est pas de sortir. C’est de pouvoir sortir. Quatre règles.

Une interface interne stable. L’application ne nomme jamais un modèle : elle nomme une tâche.

# ❌ couplage direct
resp = client.chat.completions.create(model="anthropic/claude-sonnet-4", ...)

# ✅ nom logique de tâche
resp = llm.run(task="extraction-json", input=doc, schema=InvoiceSchema)

Une table de correspondance versionnée en configuration, pas dans le code :

# llm-routes.yaml
tasks:
  extraction-json:
    primary:  { provider: openrouter, model: "anthropic/claude-sonnet-4" }
    fallback: { provider: azure-openai, model: "gpt-4.1-mini" }
    constraints: { max_latency_p95_ms: 4000, data_residency: eu }
  resume-court:
    primary:  { provider: mistral-direct, model: "mistral-large-latest" }
    fallback: { provider: openrouter, model: "mistralai/mistral-large" }

Un contrat de test. Un jeu de prompts de référence avec assertions de format (schéma JSON valide, champs obligatoires présents, longueur bornée, absence de fuite de prompt système), rejoué en CI à chaque changement de route. Sans cela, changer de fournisseur revient à déployer sans tests : la régression ne sera pas une erreur 500, elle sera silencieuse et qualitative.

Une observabilité indépendante du fournisseur. Coût, latence p95, taux d’erreur et taux de repli, ventilés par tâche, exportés en OpenTelemetry vers votre stack — pas seulement consultables dans le tableau de bord de la passerelle. Le jour où vous voulez comparer deux chemins, il vous faut la même métrique des deux côtés.

span.set_attribute("gen_ai.request.model", route.model)
span.set_attribute("gen_ai.system", route.provider)
span.set_attribute("app.llm.task", "extraction-json")
span.set_attribute("app.llm.fallback_used", used_fallback)

Les options de repli, et à qui elles conviennent

• Intégration directe chez deux fournisseurs. La plus simple, et souvent la bonne, si vous n’utilisez réellement que deux ou trois modèles. Vous portez le basculement vous-même.
• LiteLLM. Couverture fournisseurs maximale, écosystème mature, configuration déclarative. Le coût de la runtime Python devient perceptible en très haut débit : mesurez avant d’industrialiser.
• Bifrost. Binaire Go, surcoût par requête très faible. Pertinent quand la latence de la couche de routage compte autant que sa couverture.
• Envoy AI Gateway. Le bon choix si vous exploitez déjà Envoy ou Istio et souhaitez traiter le trafic IA comme le reste : mêmes politiques, mêmes métriques, mêmes équipes.
• Kong AI Gateway. Cohérent si l’investissement Kong existe déjà ; peu justifiable sinon.
• Passerelles SaaS à résidence européenne, pour les charges soumises à contrainte de localisation.

Grille de décision : volume mensuel, nombre de modèles réellement utilisés, exigence de résidence des données, maturité de votre plateforme. Si trois de ces quatre critères sont bas, restez sur une passerelle SaaS et investissez plutôt dans l’abstraction interne.

Conformité et données : ce qu’il faut verrouiller maintenant

Ne comptez pas sur les réglages par défaut du compte : ils peuvent changer, et ils ne sont pas versionnés avec votre code. Forcez les contraintes au niveau de la requête.

{
  "model": "anthropic/claude-sonnet-4",
  "provider": {
    "only": ["anthropic", "google-vertex"],
    "data_collection": "deny",
    "allow_fallbacks": false,
    "zdr": true
  }
}

Restreindre explicitement la liste des fournisseurs autorisés par charge de travail n’est pas de la paranoïa : un routage « au moins cher » avec allow_fallbacks actif peut faire sortir vos données de la zone que vous aviez promise à votre DPO. Enfin, un rachat est exactement le bon moment pour relire deux clauses de votre contrat : l’état de votre DPA, et la clause de changement de contrôle.

Plan d’action en 30 jours

• Semaine 1 — Audit d’exposition (les quatre questions ci-dessus) et instrumentation du coût et de la latence par tâche.
• Semaine 2 — Introduction de la couche d’abstraction interne, suppression des identifiants de modèles en dur, externalisation des routes en configuration.
• Semaine 3 — Mise en place d’un second chemin (intégration directe ou passerelle auto-hébergée) sur 5 % du trafic, en observation, avec comparaison des métriques par tâche.
• Semaine 4 — Game day chronométré : « la passerelle est indisponible » et « les tarifs changent de 40 % ». On mesure le temps de bascule réel, on documente la décision — rester, doubler, ou sortir — et on la date.

Ce qu’il ne faut pas faire : migrer dans l’urgence sur la foi d’une rumeur, ou construire une abstraction maison plus complexe que le problème qu’elle résout. Une table de correspondance YAML et une fonction run(task, input) suffisent à 90 % des équipes ; un framework interne de routage multi-fournisseurs avec sa propre DSL est une dette que vous paierez plus cher que 5,5 %.

Le rachat ne rend pas OpenRouter moins bon. Il rend simplement visible une dépendance que l’abondance de l’offre avait masquée : la couche que vous aviez adoptée pour rester libre est devenue le seul composant de votre chaîne que vous ne pouvez pas remplacer en une journée. Le bon indicateur n’est pas « avons-nous quitté la passerelle », c’est le temps mesuré de votre dernier exercice de bascule. Si vous ne connaissez pas ce chiffre, vous connaissez déjà votre chantier de la semaine prochaine.