Pourquoi on a construit HiWay : une alternative BYOK européenne
Les trois problèmes qui nous ont fait passer de 'on fera avec' à 'on va le construire'

Je suis Johan Bretonneau, co-fondateur de Mytm-Group avec Antoine Brodiez. On construit des apps et outils IA pour des entreprises européennes. HiWay2LLM est notre gateway LLM, et voilà pourquoi on a fini par la shipper nous-mêmes au lieu d'utiliser quelque chose qui existait déjà.

Ce n'est pas un storytelling marketing. C'est la séquence honnête de "on a essayé X, voilà ce qui a cassé, on a essayé Y, voilà ce qui a cassé, OK, on le construit."

Le point de départ : 200 $ à 3h du mat

Début 2026 on faisait tourner une poignée de produits IA — certains internes, certains pour des clients. Notre dépense LLM mensuelle grimpait vite. Pas à l'échelle startup — on ne cramait pas de VC — mais assez pour se faire remarquer.

Puis un mardi matin j'ouvre la console Anthropic et je vois un charge de 200 $ daté de 3h du mat. Un agent était entré dans une boucle de retry contre Claude Opus. Personne n'était réveillé. Aucune alerte ne s'était déclenchée. La facture avait juste grimpé pendant quatre heures jusqu'à ce que le rate limiter finisse par la rattraper.

C'est le moment où on a arrêté de shopper "une bonne gateway LLM" et commencé à évaluer sérieusement toutes les options sur la table, parce que notre stack existante avait échoué d'une façon précise et coûteuse.

Ce qu'on a essayé : LiteLLM self-hosted

LiteLLM est la réponse OSS évidente. On l'a déployé sur notre VPS, pointé nos apps dessus, et ça a marché. Pendant quelques semaines.

Voilà ce qui a cassé pour nous :

Charge ops. Chaque changement d'API provider voulait dire un update de config, un cycle de test, un redéploiement. Les upgrades de quota provider n'étaient pas centralisées. Quand la clé d'un client devait être rotate, on le faisait à la main.

On-call. LiteLLM qui tombe voulait dire que nos features IA tombaient. Personne ne te paye pour fixer ta propre gateway à 2h du mat.

Trous de features. LiteLLM avait routing et fallbacks. Il n'avait pas les trucs dont on avait vraiment besoin — alertes burn-rate, détection de boucles agentiques, budgets par endpoint qui auto-downgradent au lieu de juste bloquer. On a commencé à patcher.

Les patches se sont empilés. Chaque semaine on passait 4-6 heures sur le boulot gateway au lieu de shipper du produit. On a calculé le coût fully-loaded du self-hosting : à notre échelle, c'était pire que payer un service managé.

LiteLLM est un super bout de soft. C'est le mauvais bout de soft pour une équipe qui veut shipper du produit et n'a pas de platform engineer dédié.

Ce qu'on a essayé : OpenRouter

On a regardé OpenRouter sérieusement. Signup rapide, catalogue de modèles large, breadth vraiment impressionnant. On l'a piloté sur un produit.

Trois problèmes sont remontés :

Le markup sur des factures en croissance. Le markup d'OpenRouter sur l'inférence est petit en pourcentage, mais notre trajectoire de dépense était verticale. À 500 $/mois c'était du bruit. Projection à 5K-10K $/mois, le markup devenait un line item qu'on devait justifier. Nos clients le verraient. On devrait l'expliquer.

US-hosted, pas d'option UE. La plupart de nos clients sont européens. Plusieurs sont dans des secteurs régulés. "On fait passer les prompts de tes utilisateurs via un tiers US dont la liste de sous-processeurs est X et dont le DPA dit Y" était une conversation que je n'avais pas envie d'avoir à répétition. L'EU AI Act entrait en vigueur. Schrems II était encore un sujet vivant. L'hosting US est devenu rédhibitoire.

Pas de BYOK. OpenRouter payait. L'usage de nos clients apparaissait sous notre compte OpenRouter, pas sous leurs comptes Anthropic. Les hausses de quota passaient par OpenRouter. La rotation de clés passait par OpenRouter. Tout passait par OpenRouter. Le moment où on voudrait partir, il faudrait toucher à chaque intégration.

Aucune de ces raisons n'est pour dunker sur OpenRouter. Ils sont bons à ce qu'ils font. Ils ne sont juste pas adaptés à la forme précise de problème qu'on avait : équipe UE, servant des clients UE, avec une dépense en croissance et une préférence BYOK dure.

Ce qu'on a essayé : APIs directes avec un shim maison

Pendant quelques semaines on a considéré juste appeler Anthropic et OpenAI directement et construire une couche minimale maison de routing/budgets.

C'est le classique piège "c'est un projet d'un weekend". Tu esquisses, ça a l'air facile, et puis :

• Il te faut de la logique retry avec backoff.
• Il te faut du rate limiting par endpoint.
• Il te faut un cap budgétaire qui downgrade au lieu d'erreurer.
• Il te faut de la détection de burn-rate.
• Il te faut du tracking de coût par requête.
• Il te faut le streaming.
• Il te faut le tool use.
• Il te faut les structured outputs.
• Il te faut suivre les changements d'API de chaque provider.

Ce qui commence comme "200 lignes de glue code" devient un projet plateforme de six mois. On avait du produit à shipper. Ce chemin était un piège.

Ce qu'on a décidé de construire

Après ces trois impasses, on a écrit ce qu'on voulait vraiment. Les contraintes étaient précises :

1. BYOK. Clés provider de nos clients, leurs comptes, leur facturation. Pas de markup sur l'inférence.
2. UE-hosted. Sur infra européenne, avec un DPA qu'on peut remettre à la compliance, des sous-processeurs qu'on peut nommer.
3. Contrôles de coût qui valent leur nom. Alertes burn-rate, budgets par endpoint, downgrade automatique aux seuils, le truc qu'aucun provider n'offre parce que ça nuirait à son revenu.
4. Compatible OpenAI. Zéro réécriture SDK pour migrer dedans ou dehors.
5. Pricing flat. Notre marge ne devrait pas compounder contre nos clients à mesure qu'ils grossissent.

HiWay2LLM est ce que ces contraintes ont produit :

• BYOK sur Anthropic, OpenAI, Google, Mistral, Groq, DeepSeek, xAI, Cerebras — 60+ modèles en tout.
• Hosté sur OVH, infra française. DPA dispo. Zéro prompt logging par défaut.
• Smart routing qui lit chaque requête en moins d'1 ms et choisit le tier optimal. Alertes burn-rate via Slack. Budgets par endpoint. Logique de downgrade automatique.
• Endpoints compatibles OpenAI. Swap drop-in pour toute app qui utilise un SDK OpenAI.
• Pricing flat par requête : Free à 2 500 req/mois, Build à 15 €/mois pour 100K, Scale à 39 €/mois pour 500K, Business à 249 €/mois pour 5M, enterprise custom.

Pas de markup sur l'inférence, jamais. Si tu route 100M tokens par chez nous, tu payes tes providers pour 100M tokens et tu nous payes rien en plus. Notre revenu c'est l'abonnement flat. C'est tout.

Pourquoi le pricing flat par requête spécifiquement

Celui-là mérite qu'on déroule parce que c'est le choix le plus opinionated qu'on a fait.

Le markup par token aligne les intérêts de la gateway avec l'upsell provider. Plus de tokens, plus de revenu. La gateway gagne plus d'argent quand ta facture monte, ce qui veut dire que les features qui feraient baisser ta facture — smart routing vers des modèles moins chers, caching agressif, alertes burn-rate — sont des features que la gateway n'a aucune incitation à shipper.

Le pricing metered au-dessus des coûts provider (style Vercel AI Gateway) est une version plus douce du même problème. Le revenu de la gateway grandit quand même avec ton usage.

Le pricing flat par requête casse ça. On facture pareil pour une requête qui route vers Haiku et une requête qui route vers Opus. Ce qui veut dire que notre meilleur move aligné c'est de router ton trafic vers le modèle le moins cher qui fait quand même le boulot. Quand on ship des améliorations de smart routing, tu économises et on perd rien.

Le calcul marche parce que nos coûts sont largement fixes. Faire tourner la gateway, la stack d'observability, le moteur burn-rate — ces coûts ne scalent pas avec si tu tapes Haiku ou Opus. Ils scalent avec le nombre de requêtes. Donc on facture au nombre de requêtes.

Ce qu'être une boîte UE veut dire concrètement pour nous

Être une boîte UE n'est pas juste un angle marketing. Ça veut dire :

• Notre infra est sur OVH, cloud provider français.
• Notre DPA est construit contre le RGPD, pas contre le EU-US Data Privacy Framework.
• Notre liste de sous-processeurs est courte et européenne là où on peut.
• On ne logge pas les corps de prompts par défaut. Si tu veux du prompt logging pour debug, tu opt-in, par clé API, et la rétention est bornée.
• On suit les guidances EU AI Act sur les systèmes à haut risque, même quand l'usage de nos clients n'est pas classé haut risque, parce que les définitions bougent.

Pour une PME française qui vend à des hôpitaux français, des banques allemandes, des assureurs belges — c'est la différence entre "on peut deployer ça" et "on peut pas, le légal ne signera pas".

Certains de nos concurrents US ont des régions UE. Beaucoup n'en ont pas. Aucun d'eux ne nous bat sur "on est une vraie entité UE, sous loi UE, avec des gens basés UE qui répondent à tes demandes data subject". C'est pas un petit truc.

Ce qu'on a appris en chemin

Trois leçons qui peuvent être utiles si tu penses à un boulot infra similaire.

1. Le calcul "je vais juste le construire moi-même" est presque toujours faux au premier estimé. On estimait 2 semaines pour le MVP. Le compte honnête y compris outillage ops, moteur burn-rate, observability, et onboarding était plus proche de 4 mois d'ingé réel. On est contents de l'avoir fait, mais ce n'était pas un projet d'un weekend.

2. Le pricing flat est une discipline, pas juste un label. Ça te force à être efficace parce que tu ne peux pas planquer les coûts dans la marge. Quand Anthropic release un nouveau modèle, on ajoute le support la même semaine. Pas parce qu'on adore le boulot, mais parce que notre revenu ne dépend pas de ce que tu restes sur des modèles plus vieux et plus chers.

3. Les incitations de ton client t'apprennent quoi construire. On a shippé les alertes burn-rate parce qu'on s'était fait avoir par les 200 $ à 3h du mat. On a shippé le pricing par requête parce que nos clients demandaient sans arrêt "je peux modéliser ce coût de façon prévisible pour le budget de l'année prochaine ?". On a shippé l'hosting UE parce que chaque call de vente enterprise tapait le même mur compliance. La roadmap s'écrit toute seule depuis les frictions client.

Pour qui HiWay est fait

Pas tout le monde. Si ta dépense fait 20 $/mois et ta seule contrainte c'est "est-ce que ça marche", utilise Anthropic direct. Si tu es US-only et adore Vercel, utilise le Vercel AI Gateway. Si ton équipe a un platform engineer dédié et tu veux le contrôle max, self-host LiteLLM.

HiWay est pour les équipes qui :

• Font tourner des appels LLM en prod avec une dépense en croissance.
• Se soucient de l'hosting UE pour des raisons compliance ou de préférence.
• Veulent du BYOK — clés dans leurs comptes, facturation directe des providers.
• Veulent des contrôles de coût qui se déclenchent vraiment avant que le budget soit parti.
• Veulent passer leurs semaines à shipper du produit, pas à faire de l'ops gateway.

Si ça te ressemble, on aimerait gagner ton trafic. Sinon, une des dix alternatives dans notre autre post est probablement mieux adaptée, et on espère sincèrement que tu trouves la bonne.

---

Prochain : LiteLLM vs gateways managées — le vrai trade-off.