OpenRouter expliqué : une API pour tous les LLM, et ce que cela signifie pour les équipes européennes

Si vous développez avec des grands modèles de langage, vous connaissez la douleur : chaque fournisseur a son propre SDK, sa propre auth, ses propres rate limits, ses propres particularités. Passer d'un modèle à un autre, ou se couvrir contre une panne, signifie réécrire le code d'intégration. OpenRouter est l'une des réponses les plus populaires à ce problème. Mais pour une entreprise européenne, "populaire à San Francisco" et "sûr pour y faire passer des données client" sont deux questions très différentes.

Cet article traite les deux aspects. D'abord, ce qu'est réellement OpenRouter et comment il fonctionne sous le capot. Ensuite, la partie la plus importante pour nous en Europe : le paysage concurrentiel, qui est basé dans l'UE ou aux États-Unis, et ce que cela signifie pour le RGPD et la résidence des données.

Remarque sur les sources. Presque tout ce qui est dit ci-dessous sur le comportement propre d'OpenRouter provient de sa documentation publique. Elle fait autorité sur ce qu'OpenRouter déclare faire, mais rien n'est audité indépendamment, nous signalons donc ces affirmations comme telles. Les détails sur les concurrents proviennent en grande partie des pages marketing des fournisseurs et doivent être confirmés contractuellement avant d'être pris comme base.

Ce qu'est OpenRouter

OpenRouter est une passerelle API unifiée, parfois appelée agrégateur ou routeur LLM, qui s'intercale entre votre application et les fournisseurs de modèles. Au lieu d'intégrer OpenAI, Anthropic, Google, Mistral, les hébergeurs de Llama de Meta et des dizaines d'autres un par un, vous intégrez OpenRouter une seule fois et obtenez l'accès à tous via un seul endpoint.

Trois propriétés le définissent :

• Une interface pour 400+ modèles chez 60+ fournisseurs. Un seul compte, une seule clé API et une seule relation de facturation donnent accès à la grande majorité des modèles commercialement disponibles. Ces chiffres sont ceux d'OpenRouter et évoluent avec le temps.
• Compatibilité OpenAI drop-in. OpenRouter implémente la spécification API OpenAI, ce qui permet d'utiliser le SDK officiel OpenAI directement. Dans la plupart des bases de code, l'adoption revient à changer l'URL de base et le nom du modèle, pas à réécrire l'intégration.
• Une couche de routage, pas un modèle. OpenRouter n'entraîne rien lui-même. C'est du plumbing : il transfère votre requête vers un fournisseur amont puis renvoie la réponse en streaming.

Le modèle mental est celui que vous connaissez déjà avec les passerelles de paiement ou les CDNs : un point d'intégration unique qui abstrait un marché d'approvisionnement fragmenté.

Comment cela fonctionne

Routage et load balancing

Le même modèle est souvent servi par plusieurs fournisseurs avec des prix et des niveaux de fiabilité différents. Par défaut, OpenRouter fait du load balancing basé sur le prix : il écarte d'abord tout fournisseur ayant subi une panne significative dans les 30 dernières secondes, puis choisit parmi les autres avec une pondération inverse au carré du prix. Dans l'exemple fourni par OpenRouter, un fournisseur facturant 1 dollar par million de tokens a environ 9 fois plus de chances d'être choisi qu'un fournisseur facturant 3 dollars. Vous pouvez remplacer ce comportement, imposer un ordre de fournisseurs, fixer un plafond de prix ou trier par débit ou par latence.

Fallbacks

C'est la fonctionnalité phare côté fiabilité. Le failover entre fournisseurs est activé par défaut : si le fournisseur choisi renvoie une erreur, OpenRouter retente de façon transparente le même modèle chez le fournisseur suivant. En plus de cela, les fallbacks au niveau modèle sont opt-in : vous pouvez définir une chaîne comme "essaie Claude, puis GPT, puis Llama", afin qu'une requête se dégrade proprement au lieu d'échouer. Vous pouvez également verrouiller cela avec allow_fallbacks: false pour restreindre le routage aux fournisseurs explicitement approuvés.

Tarification, et l'astérisque du "sans marge"

L'affirmation tarifaire emblématique d'OpenRouter est qu'il ne facture aucune marge sur l'inférence : vous payez le même prix par token que directement chez le fournisseur sous-jacent. Des revues indépendantes confirment que les tarifs du catalogue correspondent aux prix publics des fournisseurs.

Mais "sans marge" ne veut pas dire "sans frais", et la distinction compte pour votre budget :

• ~5,5 % de frais sur les achats de crédit avec un minimum, actuellement autour de 0,80 dollar, lorsque vous rechargez par carte.
• ~5 % de frais de recharge en crypto comme alternative.
• ~5 % de frais BYOK, voir ci-dessous, même si le premier million environ de requêtes BYOK par mois est gratuit.

L'économie par token est donc bien en pass-through ; la plateforme monétise le mouvement d'argent et la commodité du BYOK, pas les tokens eux-mêmes. Présenter "sans marge" à un décideur sans mentionner ces frais conduit à sous-budgéter.

BYOK, Bring Your Own Key

Vous pouvez fournir vos propres clés API fournisseurs, par exemple votre clé Azure OpenAI ou Anthropic existante. OpenRouter les chiffre et les utilise pour les requêtes routées vers ce fournisseur, de sorte que l'usage est imputé à votre compte fournisseur, vos rate limits et souvent vos tarifs négociés ou vos conditions de conformité. Les frais BYOK d'environ 5 % s'appliquent au-delà du niveau gratuit. Un point à connaître : par défaut, OpenRouter bascule sur ses endpoints partagés si votre clé échoue, à moins de configurer explicitement "toujours utiliser ma clé pour ce fournisseur".

Les avantages

• Une intégration, tout le marché. Ajouter ou remplacer des modèles sans toucher au code d'intégration. C'est une vraie assurance contre le vendor lock-in et contre les changements de prix ou de politique d'un fournisseur.
• Une vraie résilience. Le failover inter-fournisseurs met en commun la disponibilité de plusieurs fournisseurs. Quand un hébergeur rencontre un incident, votre trafic continue.
• Expérimentation rapide. Essayer un nouveau modèle se résume à une ligne de changement, ce qui est précieux sur un marché qui publie un nouvel état de l'art toutes les quelques semaines.
• Des leviers de contrôle des coûts. Plafonds de prix et routage pondéré par le coût vous permettent de viser automatiquement l'hébergeur le moins cher acceptable.
• Des réglages de confidentialité raisonnables par défaut. La zero data retention sur le contenu des prompts est par défaut, pas vendue en upsell.

Les inconvénients

• C'est une dépendance supplémentaire dans le chemin critique. Une passerelle devant tous les modèles est aussi un point de défaillance unique et une nouvelle frontière de confiance. Sa disponibilité et sa sécurité bornent désormais les vôtres.
• Le "sans marge" inclut quand même des frais. Les frais d'achat de crédit et de BYOK sont faciles à oublier.
• Surcoût de latence. Ajouter un hop ajoute des millisecondes. Généralement négligeable, parfois non ; benchmarkez les chemins critiques en latence.
• Comportements fournisseurs hétérogènes. Le "même" modèle peut se comporter différemment selon l'hôte amont, quantization, limites de contexte, support de fonctionnalités. Le pinning des fournisseurs aide, mais réintroduit une partie de la complexité que vous cherchiez à éviter.
• Le point clé pour nous : la résidence des données n'est pas dans l'UE par défaut. Voir la section suivante.

La question européenne : RGPD et résidence des données

Ici, une équipe liée au RGPD doit ralentir, car la configuration pratique par défaut et la configuration conforme ne sont pas la même chose.

Où se situe OpenRouter

OpenRouter est une entreprise basée aux États-Unis, et son endpoint par défaut n'est pas résident UE. Pour une équipe soumise au RGPD, c'est le point central : par défaut, les prompts, qui contiennent fréquemment des données personnelles, peuvent être traités sur une infrastructure américaine et routés vers des fournisseurs dans différentes juridictions.

OpenRouter propose une option de routage in-region UE via un endpoint dédié eu.openrouter.ai. D'après sa documentation, les requêtes y sont déchiffrées et traitées entièrement dans l'UE et routées uniquement vers des fournisseurs opérant dans la région. Deux réserves importantes :

1. C'est réservé aux offres d'entreprise, sur demande, ce n'est pas quelque chose que l'on active dans le dashboard sur un compte gratuit.
2. C'est une auto-déclaration du fournisseur. Au cours de notre recherche, les affirmations les plus fortes du type "les données ne quittent jamais l'UE" n'ont pas pu être vérifiées indépendamment. Il faut donc traiter cela comme une garantie documentée à confirmer dans un DPA, pas comme un fait audité. Le routage in-region UE offre aussi une sélection de modèles plus réduite que l'endpoint global.

Confidentialité et journalisation, les contrôles existants

À son crédit, OpenRouter propose des contrôles de confidentialité assez granulaires et des valeurs par défaut raisonnables :

• Zero Data Retention, ZDR, par défaut. OpenRouter ne stocke pas vos prompts ni vos complétions, même en cas d'erreur, sauf si vous le demandez explicitement. Notez que "zero retention" couvre le contenu prompt/réponse ; les métadonnées de requête, volumes de tokens, latence, horodatages, restent conservées.
• Contrôles par requête et par compte. Vous pouvez exiger uniquement des endpoints ZDR, zdr: true, router seulement vers des fournisseurs qui ne collectent pas les données, data_collection: "deny", et configurer un opt-out global d'entraînement pour qu'OpenRouter ne route pas vers des fournisseurs qui entraînent sur les entrées.
• Chaque amont conserve sa propre politique. OpenRouter agrège et affiche les conditions de rétention et d'entraînement de chaque fournisseur plutôt que d'en imposer une unique. Le "ZDR" dépend donc du fournisseur qui sert réellement la requête.

Deux mécanismes de journalisation opt-in sont faciles à confondre, alors que la différence est juridiquement importante :

• Un toggle "discount de données" vous accorde environ 1 % de réduction en échange du droit pour OpenRouter d'utiliser vos prompts et complétions afin d'améliorer le produit, ce qui lui donne un droit irrévocable d'usage commercial sur ce contenu. Pour des données client, il vaut mieux l'éviter.
• Une fonctionnalité séparée Input & Output Logging vous permet de stocker de façon privée le contenu des requêtes et réponses pour votre propre debugging, chiffré au repos, conservé au moins trois mois, et explicitement non utilisé pour l'entraînement. Cette fonctionnalité ne s'applique pas au trafic eu.openrouter.ai.

En pratique, cela signifie qu'OpenRouter peut être configuré de manière défendable, mais que la configuration compatible RGPD est : endpoint UE d'entreprise, DPA, sous-traitants nommés et SCCs ou Data Privacy Framework pour tout ce qui touche l'endpoint US par défaut. C'est une discussion d'achat, pas une case à cocher.

Le paysage concurrentiel

OpenRouter est le routeur le plus connu, mais il évolue dans un champ très dense. Regroupés grossièrement :

Les classifications ci-dessus proviennent des documents propres aux fournisseurs ; vérifiez toujours les spécificités pour votre cas d'usage.

Fournisseurs UE vs US, le résumé honnête

• La plupart des pure-play routers sont des entreprises américaines : OpenRouter, Together, Fireworks, Portkey, Vercel, Helicone. Ils peuvent souvent être configurés pour des régions UE, mais la résidence UE n'est pas leur posture par défaut.
• Il existe un vrai groupe basé dans l'UE. Eden AI, Orq.ai et des routeurs positionnés UE comme Requesty, Cortecs et EUrouter font de la résidence des données UE et du DPA RGPD leur argument principal. Si "les données restent en Europe par défaut" est une exigence ferme, ils méritent une vraie évaluation, avec la réserve que leurs catalogues de modèles sont généralement plus petits que celui d'OpenRouter.
• Le self-hosting contourne la question. LiteLLM est open source : exécutez-le dans votre propre cloud européen et la résidence des données dépendra simplement de l'endroit où vous le déployez. Vous échangez du confort contre du contrôle.
• Les hyperscalers offrent l'histoire contractuelle la plus solide. AWS Bedrock, Azure OpenAI et Google Vertex AI tournent tous en régions UE avec DPA entreprise. À noter en particulier : les profils EU de cross-region inference de Bedrock garantissent que les requêtes démarrées depuis une région UE sont routées uniquement vers d'autres régions UE. La résidence est garantie par design plutôt que par configuration. Le compromis : une sélection de modèles plus étroite et plus de setup qu'avec un routeur. Mais au bout du compte, ce sont toujours des entreprises américaines.

Comment nous le regardons chez vensas

Il n'existe pas une seule bonne réponse, mais un bon ajustement entre le risque de la charge de travail et la posture de la passerelle. Voici comment nous le formulons pour nos clients :

• Prototypes, outils internes, données non personnelles : l'endpoint par défaut d'OpenRouter est difficile à battre en vitesse et en largeur de catalogue. Profitez de cette optionalité.
• Production avec données personnelles ou données client : l'endpoint par défaut n'est pas une option. Choisissez entre l'endpoint UE d'entreprise d'OpenRouter, une passerelle basée dans l'UE, comme Eden AI, Orq.ai ou Requesty, un LiteLLM auto-hébergé dans votre propre cloud européen, ou une région UE d'hyperscaler, puis sécurisez cela avec un DPA et une liste documentée de sous-traitants.
• Séparez toujours les deux questions. "Quel est le meilleur modèle ?" et "où les données ont-elles le droit d'aller ?" sont indépendantes. Une gateway est précisément la couche qui permet de changer la réponse à la première sans rouvrir en permanence la seconde.

La valeur la plus profonde d'un routeur n'est pas de rendre les tokens moins chers, mais de fournir de l'optionnalité. Dans un marché aussi volatil, la capacité à changer de modèles et de fournisseurs sans réécriture est stratégique. Il faut simplement s'assurer que la couche achetée pour la flexibilité ne devienne pas discrètement la couche qui envoie des données personnelles de l'autre côté de l'Atlantique.

Besoin d'aide ?

Vous essayez de choisir une passerelle LLM à la fois flexible et défendable au regard du RGPD ? Nous aidons les équipes européennes à concevoir des architectures IA qui gardent les données là où elles doivent être sans renoncer à l'accès aux meilleurs modèles. Contactez-nous via notre page de contact et nous analyserons cela ensemble.

Comment gérez-vous aujourd'hui le routage des modèles et la résidence des données dans votre propre stack ? Chez vensas, nous serions ravis d'échanger à ce sujet.