LLM router hébergé en Europe

La plupart des LLM gateways dont tu as entendu parler tournent sur des infras US. C'était acceptable tant que personne ne posait de questions sur le chemin des prompts. En 2026, ces questions sont partout — dans les grilles d'achat, chez le DPO, et dans l'équipe juridique qui a enfin lu correctement l'AI Act. Si tu livres à des utilisateurs européens, ou si tu opères depuis l'Europe, le pays d'hébergement de ta couche de routing n'est plus un détail.

Cette page explique ce qui a vraiment changé, où sont physiquement hébergées les gateways principales, et à quoi ressemble un LLM router réellement aligné EU.

Pourquoi l'hébergement EU compte en 2026

Trois piliers réglementaires se superposent, et ils ne tirent pas dans la même direction.

RGPD (en vigueur depuis 2018). Dès qu'une requête LLM contient une donnée personnelle — un nom client, un email, un ticket support, tout ce qui identifie un humain — tu traites de la donnée personnelle. Ça déclenche toute la machinerie RGPD : base légale, minimisation, règles sur les transferts hors UE, DPA avec chaque sous-traitant, et un droit à l'effacement qui se marie mal avec des modèles black-box.

Schrems II (CJUE, 2020). C'est l'arrêt qui a invalidé le Privacy Shield et rendu fragile juridiquement le transfert de données personnelles vers les US. Le Data Privacy Framework EU-US (DPF, 2023) l'a remplacé, mais il est déjà attaqué devant les tribunaux. L'incertitude est le point central : chaque fois que tu routes un prompt vers une gateway hébergée aux US, tu paries que le mécanisme de transfert actuel sera toujours valide dans dix-huit mois. Certaines équipes juridiques ne sont plus prêtes à prendre ce pari sans mesures compensatoires.

AI Act (phases 2025–2027). C'est le bloc que la plupart des équipes sous-estiment. L'AI Act ne régule pas juste les fournisseurs de modèles. Il régule quiconque met un système d'IA sur le marché EU — y compris les couches infra. Les articles 9 (gestion des risques), 10 (gouvernance des données), 12 (logging), 15 (précision et robustesse) créent des obligations de documentation et de traçabilité. Si ta couche de routing ne peut pas produire un audit trail par requête, ou ne peut pas te dire quels sous-traitants ont touché un prompt, tu vas avoir une conversation difficile avec ton auditeur.

Les trois ensemble amènent à une conclusion opérationnelle simple : moins tes prompts traversent de juridictions, et plus ton infra sait se documenter, moins tu portes de risque.

Où sont vraiment hébergées les gateways LLM principales

D'après leur doc publique au 2026-04-22 :

• OpenRouter — hébergé aux US. Pas de région EU. Prompts loggés par défaut (opt-out possible).
• LiteLLM Cloud — hébergé aux US (AWS). La version OSS self-hosted te permet de tourner où tu veux, y compris dans une région EU.
• Vercel AI Gateway — tourne sur l'edge Vercel, qui a des PoPs EU, mais le control plane et les logs sont aux US.
• Portkey — région primaire US ; déploiement dédié EU dispo sur leurs tiers entreprise.
• Helicone — hébergé aux US. Principalement une couche d'observabilité ; la donnée prompt est stockée dans leur infra.
• Cloudflare AI Gateway — tourne sur l'edge global Cloudflare ; la localité data passe par leur add-on regional services.
• HiWay2LLM — hébergé en EU sur OVH (France). Aucun control plane US. Zero prompt logging par défaut.

Ce n'est pas dire que US-hosted est mauvais. Pour une équipe US servant des clients US, c'est souvent le bon choix par défaut. C'est dire que si tu as besoin d'un data path européen, le marché dans sa majorité ne te le donnera pas sans contrat entreprise ou effort de self-hosting.

Ce que "hébergé en EU" doit vraiment vouloir dire

"Nos serveurs sont à Francfort" ne suffit pas. Un LLM router proprement aligné EU doit répondre à six questions :

1. Où tourne le control plane ? Pas juste l'edge qui sert la requête, mais le dashboard, la DB métadonnées, le système de billing, les logs. Si un seul de ces éléments est aux US, tes prompts passent par les US dès que tu ouvres le dashboard.

2. Quel est l'opérateur juridique ? Une société enregistrée en Irlande avec un parent US n'est pas la même chose qu'une SAS française. C'est la juridiction du parent qui s'applique sous Schrems II.

3. Est-ce que tu logges les prompts par défaut ? Si oui, tu as un sous-traitant qui héberge les données personnelles de tes utilisateurs. Si non, tu as dramatiquement réduit ta surface d'attaque.

4. Peux-tu signer un DPA ? À tous les tiers, pas juste entreprise. Le DPA article 28 est une obligation dure sous RGPD, pas un levier de négociation.

5. Publies-tu tes sous-traitants ? Les providers vers lesquels tu routes (OpenAI, Anthropic, Google) sont tous des sous-traitants. Si la gateway ne les liste pas, ton registre article 30 est incomplet.

6. Peux-tu produire un audit log par workspace ? L'obligation de logging article 12 AI Act n'est pas satisfaite par "on a des logs quelque part". Il faut que ce soit requêtable et attribuable à une requête précise.

Un router qui répond oui aux six, c'est un vrai hébergement EU. Un qui répond oui à un ou deux, c'est du marketing.

La posture HiWay

Pour la transparence, voilà où on se situe sur les six points :

1. Le control plane tourne sur les serveurs OVH en France. Aucun composant US dans le data path.
2. L'opérateur juridique est Mytm-Group, SAS française — donc droit français, et donc RGPD et AI Act s'appliquent nativement, sans mécanisme de transfert requis.
3. Zero prompt logging par défaut. Les prompts transitent en mémoire et ne sont jamais persistés. Tu peux activer le logging par workspace si tu veux (pour du debug par exemple), et tu contrôles la rétention.
4. DPA disponible sur tous les plans, y compris le gratuit. Rien derrière un appel commercial.
5. Sous-traitants publiés sur la page légale et mis à jour quand on change quoi que ce soit. Aujourd'hui la liste : OpenAI, Anthropic, Google, Mistral, Groq, DeepSeek, xAI, Cerebras (les providers vers lesquels tu choisis de router), OVH (hébergement), Stripe (billing), Postmark (email transactionnel).
6. Audit log par workspace requêtable depuis le dashboard et exportable en JSON ou CSV.

Ce n'est pas un argument marketing pour bien paraître. C'est ce que la stack réglementaire EU exige, et c'est comme ça que le produit a été construit.

Comparaison sur les axes EU/compliance

Ce tableau se concentre strictement sur la compliance EU. Pour une comparaison fonctionnelle plus large, voir les pages compare par concurrent.

La checklist acheteur

Si tu évalues des LLM routers pour un produit qui sert l'EU, la short-list de questions à envoyer à chaque vendor :

1. Dans quelle juridiction est enregistrée l'entité opératrice ?
2. Dans quelles régions le control plane est-il physiquement hébergé, et peut-on le changer ?
3. Les prompts et complétions sont-ils loggés par défaut ? Quelle rétention ? Peut-on désactiver ?
4. Peut-on signer un DPA sous l'article 28 du RGPD ? À quel tier ?
5. Quels sous-traitants utilisez-vous ? La liste est-elle consultable publiquement et mise à jour quand elle change ?
6. Peut-on produire un audit log par requête, attribuable à un workspace, une clé API et un appel modèle précis ?
7. Est-ce qu'une partie du flux de données exige un mécanisme de transfert EU–US (CCT, DPF) ?
8. Fournissez-vous un mécanisme pour répondre à une demande d'accès ou d'effacement RGPD sur les traces passées par votre infra ?
9. Que deviennent logs, métadonnées et backups quand un workspace est supprimé ? SLA documenté pour l'effacement complet ?
10. Pouvez-vous produire, sur demande, une documentation qui mappe votre produit sur les obligations AI Act qui vous concernent ?

Un vendor qui peut répondre aux dix sans rendez-vous commercial, c'est un vendor dont la posture de compliance est réelle. Un qui ne peut pas, c'est un que tu expliqueras à ton auditeur plus tard.

FAQ

Conclusion

Le marché des LLM routers est majoritairement construit aux US, pour des raisons compréhensibles — l'écosystème, le capital, la première vague de clients étaient tous aux US. Ça change. Les équipes européennes et les secteurs régulés appliquent une vraie pression compliance, et l'AI Act fait passer cette pression du nice-to-have au must-have.

Si ton produit sert des utilisateurs EU, la question n'est pas de savoir si l'hébergement EU compte. C'est de savoir dans combien de temps ton auditeur posera la question, et si tu auras une réponse claire. Choisir un router hébergé EU enlève une catégorie de risque de ta stack en une décision.