La couche de routage est le mécanisme, pas le choix de fournisseur

Une lecture Honest Architect de LLM API Gateway Guide: Choose the Right One (2025), publié le 20 mars 2026 par Ofox sur ofox.ai.

L'affirmation de surface de l'article est un guide d'achat : choisissez l'un des six LLM API gateways (OpenRouter, LiteLLM, Portkey, Ofox, Helicone, Kong AI Gateway) selon la taille de votre équipe et vos priorités. Le Honest Architect le lit pour le mécanisme sous la comparaison et en trouve six. Celui qui porte la charge est la couche de routage elle-même : un gateway s'intercale entre votre application et les fournisseurs de LLM, vous donnant une interface unifiée, un fallback automatique et un contrôle centralisé des coûts. Theorem 3 dans le HAI Engine d'Everythink affirme la même forme : une propriété est garantie exactement quand son mécanisme est implémenté et mesure. Ici la propriété est « votre application continue de fonctionner quand un fournisseur tombe » ; le mécanisme est « la couche de routage fait un fallback vers un autre fournisseur avant que l'application ne voie l'erreur ».

Une note de portée avant les mécanismes : la source est un guide d'achat d'infrastructure IA commercial d'un vendor de gateways, et favorise naturellement le pattern de gateway. Les six formes de mécanisme ci-dessous sont ✅ — extractibles de la propre évidence de l'article. Les parallèles cross-domaine vers Everythink sont ⚠️ — structurels, pas une affirmation que notre plateforme de prévision civile et défensive tourne sur un gateway LLM multi-fournisseur. La configuration des fournisseurs LLM d'Everythink est OpenAI-compatible uniquement (un protocole comme port, tout fournisseur compatible comme adaptateur) — même forme architecturale, portée plus étroite.

Un gateway LLM multi-fournisseur commercialisé comme produit Everythink est 🔵 Roadmap — pré-revenu, ne fait pas partie de la plateforme civile et défensive actuelle.

Mécanisme 1 — L'API unifiée est le mécanisme de stabilité-de-port

L'article affirme qu'un gateway vous donne « One interface format for all providers — call GPT, Claude, and Gemini with the same code ». Le Honest Architect lit cela comme une affirmation de stabilité de port : votre application survit à un changement de fournisseur est garanti par l'interface unifiée étant implémentée, non par votre application connaissant le SDK de chaque fournisseur. Le mécanisme qui produit « changer de modèle est un changement de configuration, pas un changement de code » est « le gateway expose une interface et traduit derrière ». L'API unifiée est le mécanisme ; le SDK natif du fournisseur ne l'est pas. ✅ Production — l'article nomme le mécanisme (API unifiée, une interface pour tous les fournisseurs) et la propriété (changement de modèle est un changement d'une ligne).

L'article est honnête sur ce que l'interface unifiée coûte : « It's not an abstraction that hides model differences (you still choose which model to call) ». Le port est stable ; le choix derrière reste le vôtre.

Le parallèle cross-domaine vers les ports hexagonaux basés sur traits d'Everythink est seulement structurel. Les dépôts AppState d'Everythink sont Arc<dyn Trait> pour que les tests échangent des mocks — l'application dépend du trait, pas de l'adaptateur Pg* concret. Le « votre code dépend de l'interface unique du gateway, pas de trois SDK de fournisseur » de l'article et le « votre use-case dépend du trait de port, pas de l'adaptateur concret » d'Everythink partagent la même forme : un port stable est le mécanisme d'interchangeabilité. ⚠️ Partiel — domaines différents, même forme : un port stable est le mécanisme d'interchangeabilité.

Mécanisme 2 — Le fallback automatique est le mécanisme de disponibilité

L'article affirme que « If Provider A is down, transparently retry with Provider B » et « If GPT-5.2 is unavailable or rate-limited, the gateway automatically routes to Claude — your app never sees an error ». Le Honest Architect lit cela comme une affirmation de disponibilité : le temps de disponibilité est garanti par le fallback étant implémenté et routant, non par un seul fournisseur étant fiable. Le mécanisme qui produit « votre application ne voit jamais l'erreur » est « le gateway réessaie avec le Fournisseur B avant de surfacer l'échec ». Le fallback automatique est le mécanisme ; un seul fournisseur fiable ne l'est pas. ✅ Production — l'article nomme le mécanisme (fallback automatique, retry transparent) et la propriété (l'application ne voit jamais l'erreur du fournisseur).

L'article est honnête que ceci n'est pas hypothétique : « In 2025 alone, every major LLM provider experienced at least one significant service disruption ». Le fallback existe parce que la garantie d'un seul fournisseur n'existe pas.

Le parallèle cross-domaine vers l'ensemble de l'Oracle d'Everythink est seulement structurel. L'Oracle fusionne les sorties de plusieurs Sisters typées (analyst, contrarian, disruptor, historian, institutionalist) en un ensemble normalisé — si le draft d'une Sister est faible ou manquant, l'ensemble tient sur les autres. Le « Fournisseur A tombe → Fournisseur B prend le relais » de l'article et l' « une Sister faible → l'ensemble continue de fusionner » de l'Oracle partagent la même forme : le fallback multi-source est le mécanisme de disponibilité. ⚠️ Partiel — l'Oracle sert la prévision civile et défensive, le gateway LLM sert l'infrastructure IA commerciale. Domaines différents, même forme : le fallback multi-source est le mécanisme de disponibilité.

Mécanisme 3 — La gestion des clés est le mécanisme de souveraineté-de-crédential

L'article affirme que « One gateway key in your code; provider keys stay in the gateway config ». Le Honest Architect lit cela comme une affirmation de souveraineté de crédential : la crédential du fournisseur n'atteint jamais l'application est garanti par la gestion des clés étant centralisée, non par l'application étant soigneuse. Le mécanisme qui produit « le code de l'application détient une clé de gateway, pas trois clés de fournisseur » est « les clés de fournisseur vivent dans la config du gateway, et l'application ne les voit jamais ». La gestion des clés est le mécanisme ; l'hygiène des clés au niveau application ne l'est pas. ✅ Production — l'article nomme le mécanisme (une clé de gateway dans le code, clés de fournisseur dans la config du gateway) et la propriété (les crédentials de fournisseur n'atteignent jamais l'application).

L'article est honnête sur pourquoi cela compte : sans cela, « each team member has their own API keys » et il n'y a « no unified dashboard showing total spend across providers ». La prolifération des crédentials est le symptôme ; le mécanisme de gestion des clés manquant est la cause.

Le parallèle cross-domaine vers la souveraineté du Eye Key d'Everythink est seulement structurel. Le Eye Key est la crédidential possédée par l'utilisateur — le texte clair ne touche jamais le disque ; seul le HMAC et l'empreinte vont à Postgres, et la clé de l'utilisateur est la frontière de limite de débit. Le « les clés de fournisseur restent dans la config du gateway, l'application détient une clé de gateway » de l'article et le « le texte clair est montré une fois en mémoire, la plateforme stocke seulement le HMAC » du Eye Key partagent la même forme : la séparation des crédentials est le mécanisme de souveraineté. ⚠️ Partiel — le Eye Key régit la souveraineté d'API pour la prévision civile et défensive, la gestion des clés du gateway régit l'infrastructure IA commerciale. Domaines différents, même forme : la séparation des crédentials est le mécanisme de souveraineté.

Mécanisme 4 — Le suivi des coûts est le mécanisme d'observabilité-des-dépenses

L'article affirme que « Without centralized cost tracking, you can't answer basic questions: Which model costs the most per task? Would switching providers save money? Are there runaway processes burning tokens? » et décrit le trou noir des coûts : « You discover at month-end that someone left a batch job running against GPT-5 all weekend. Your API bill is 4x what you budgeted ». Le Honest Architect lit cela comme une affirmation d'observabilité des dépenses : les dépenses sont contrôlées est garanti par le suivi des coûts étant implémenté et visible, non par l'équipe étant disciplinée. Le mécanisme qui produit « vous attrapez le batch job en fuite avant la fin du mois » est « le tableau de bord centralisé montre les dépenses totales across les fournisseurs en temps réel ». Le suivi des coûts est le mécanisme ; la discipline de l'équipe ne l'est pas. ✅ Production — l'article nomme le mécanisme (tableau de bord centralisé des coûts, dépenses par-modèle par-tâche) et la propriété (les dépenses en fuite sont attrapées).

L'article est honnête que la configuration la moins chère sur papier (appels directs, $0 de coût de gateway) cache le vrai coût : « factor in engineering time — maintaining three SDKs, building custom fallback logic, debugging three different error formats, and reconciling three separate invoices — and the total cost of ownership shifts heavily toward using a gateway ». La mesure qui compte est le coût total de possession, pas le coût d'API par ligne.

Le parallèle cross-domaine vers l'ensemble à entropie estampée d'Everythink est seulement structurel. L'Oracle normalise les probabilités à exactement un endroit et estampe l'entropie en nats sur chaque merge — l'entropie est le signal de calibration qui vient gratuitement de la normalisation, pas une affirmation séparée de confiance. Le « le tableau de bord centralisé montre les dépenses across les fournisseurs, pas les factures par-fournisseur » de l'article et l' « l'entropie est estampée sur chaque merge, pas affirmée séparément » de l'Oracle partagent la même forme : une mesure qui vient gratuitement du mécanisme central est le signal de statut honnête. ⚠️ Partiel — domaines différents, même forme : une mesure sous-produit gratuite est le signal de statut honnête.

Mécanisme 5 — Le routage des modèles est le mécanisme de décision-à-la-frontière

L'article affirme qu'un gateway fournit « Route requests to different models based on cost, latency, or capability » et la config de fallback prend un paramètre routing ("routing": "cost"). Le Honest Architect lit cela comme une affirmation de décision à la frontière : le bon modèle est choisi par requête est garanti par la règle de routage étant implémentée dans le gateway, non par l'application hardcodant le modèle. Le mécanisme qui produit « la requête va au fournisseur adéquat le moins cher » est « la règle de routage évalue le coût, la latence ou la capacité dans le gateway avant l'envoi ». Le routage des modèles est le mécanisme ; la chaîne de modèle hardcodée dans l'application ne l'est pas. ✅ Production — l'article nomme le mécanisme (règle de routage sur coût/latence/capacité, paramètre routing) et la propriété (sélection de modèle par-requête).

L'article est honnête que le routage est une politique, pas de la magie : le cadre de décision demande aux équipes de scorer les gateways sur modèle de prix, couverture de modèles, compatibilité SDK, fiabilité, option de self-host et expérience développeur. La règle de routage encode la politique ; la politique n'est pas implicite.

Le parallèle cross-domaine vers la topologie « the space is the router » d'Everythink est seulement structurel. La topologie network → community → room d'Everythink route une requête avant que quoi que ce soit réponde — l'espace est le routeur, et le routage se fait en amont du calcul. Le « le gateway route avant que le fournisseur réponde » de l'article et le « la topologie route avant que l'agent réponde » d'Everythink partagent la même forme : le routage avant réponse est le mécanisme de décision-à-la-frontière. ⚠️ Partiel — « the space is the router » régit la topologie de prévision civile et défensive, le routage du gateway régit l'infrastructure IA commerciale. Domaines différents, même forme : le routage avant réponse est le mécanisme de décision-à-la-frontière.

Mécanisme 6 — La traduction de format est le mécanisme de parsing-de-frontière

L'article affirme que certains gateways supportent les SDK natifs sans traduction (Ofox : « three protocols natively — OpenAI, Anthropic, and Gemini SDKs all work without translation ») tandis que d'autres traduisent (LiteLLM : « Anthropic SDK ✅ (translation) »). Le Honest Architect lit cela comme une affirmation de parsing de frontière : l'application parle le format de son SDK choisi est garanti par le gateway traduisant à la frontière, non par l'application se conformant au format de chaque fournisseur. Le mécanisme qui produit « votre code du SDK Anthropic fonctionne à travers le gateway » est « le gateway parse la requête en format Anthropic et la traduit dans le format natif du fournisseur ». La traduction de format est le mécanisme ; la conformité de format côté application ne l'est pas. ✅ Production — l'article nomme le mécanisme (support de SDK natif sans traduction, ou traduction dans le gateway) et la propriété (le code SDK de l'application fonctionne sans modification).

L'article est honnête sur le compromis : le support natif signifie « you can use each provider's SDK with its full feature set, all through a single API key », tandis que la traduction signifie que vous obtenez l'interface unifiée mais pouvez perdre des fonctionnalités spécifiques au fournisseur. La frontière parse ; ce que la frontière préserve est un choix de conception.

Le parallèle cross-domaine vers la frontière Zod-au-runtime d'Everythink est seulement structurel. Les wire types d'Everythink sont définis une fois dans Zod dans @everythink/types, et les réponses sont parsées à la frontière réseau ; un mauvais payload surgit comme un ApiError typé, jamais un crash. Le « le gateway parse le format de requête à la frontière, l'application n'infère pas » de l'article et le « le parseur valide le payload à la frontière, l'application n'infère pas » d'Everythink partagent la même forme : le parsing explicite à la frontière est le mécanisme d'interprétation correcte. ⚠️ Partiel — domaines différents, même forme : le parsing explicite à la frontière est le mécanisme d'interprétation correcte.

Ce que ceci implique pour portée et limites

L'article d'Ofox est un guide d'achat d'infrastructure IA commercial d'un vendor de gateways. Les six formes de mécanisme sont réelles et extractibles de la propre évidence de l'article. Les parallèles cross-domaine vers la plateforme de prévision civile et défensive d'Everythink sont structurels — ils partagent des formes de mécanisme, pas des marchés. Le Honest Architect les marque ⚠️.

La propre configuration des fournisseurs LLM d'Everythink est OpenAI-compatible uniquement (async-openai) : un protocole comme port, tout fournisseur compatible (OpenAI, vLLM, OpenRouter, Together) comme adaptateur. Ceci est le même pattern de port hexagonal appliqué à une portée plus étroite — un protocole, pas trois. Pas de dépendance directe au SDK Anthropic. La forme architecturale tient ; la portée d'implémentation est plus étroite. Ceci est ⚠️ Partiel, pas une affirmation qu'Everythink exécute la comparaison des six gateways.

Ce que l'article n'affirme pas mérite aussi une marque. Il n'affirme pas qu'un gateway élimine les pannes de fournisseur — il affirme que le fallback les cache à l'application. Il n'affirme pas que l'API unifiée élimine les différences de modèle — il affirme que le gateway traduit le format, tandis que vous continuez à choisir le modèle. Il n'affirme pas que le suivi des coûts réduit les dépenses — il affirme que le suivi rend les dépenses visibles. Ces limites de portée sont l'honnêteté de l'article, et ce billet les préserve.

Points clés

• Votre application survit à un changement de fournisseur est garanti par l'interface unifiée étant implémentée, non par votre application connaissant le SDK de chaque fournisseur. L'API unifiée est le mécanisme. ✅ Production.
• Le temps de disponibilité est garanti par le fallback étant implémenté et routant, non par un seul fournisseur étant fiable. Le fallback automatique est le mécanisme. ✅ Production.
• La crédential du fournisseur n'atteint jamais l'application est garanti par la gestion des clés étant centralisée, non par l'application étant soigneuse. La gestion des clés est le mécanisme. ✅ Production.
• Les dépenses sont contrôlées est garanti par le suivi des coûts étant implémenté et visible, non par l'équipe étant disciplinée. Le suivi des coûts est le mécanisme. ✅ Production.
• Le bon modèle est choisi par requête est garanti par la règle de routage étant implémentée dans le gateway, non par l'application hardcodant le modèle. Le routage des modèles est le mécanisme. ✅ Production.
• L'application parle le format de son SDK choisi est garanti par le gateway traduisant à la frontière, non par l'application se conformant au format de chaque fournisseur. La traduction de format est le mécanisme. ✅ Production.
• Les parallèles cross-domaine vers les ports hexagonaux basés sur traits (port stable est interchangeabilité), l'ensemble de l'Oracle (fallback multi-source est disponibilité), la souveraineté du Eye Key (séparation des crédentials est souveraineté), l'ensemble à entropie estampée (mesure sous-produit gratuite est signal de statut honnête), « the space is the router » (routage avant réponse est décision-à-la-frontière) et la frontière Zod-au-runtime (parsing explicite à la frontière est interprétation correcte) sont seulement structurels — marchés différents, mêmes formes de mécanisme. ⚠️ Partiel.
• La propre configuration LLM d'Everythink est OpenAI-compatible uniquement (un protocole comme port, tout fournisseur compatible comme adaptateur) — même pattern de port hexagonal à portée plus étroite ; pas une affirmation d'exécuter la comparaison des six gateways. ⚠️ Partiel.

Sources

• LLM API Gateway Guide: Choose the Right One (2025), Ofox, publié le 20 mars 2026. https://ofox.ai/blog/why-llm-api-gateway-how-to-choose-2026/ (récupéré le 2026-08-23).
• Architecture de la plateforme Everythink : HAI Engine en production depuis 2016 ; Theorem 3 (une propriété est garantie exactement quand son mécanisme est implémenté et mesure) ; topologie « the space is the router » (network → community → room) ; World Monitor (géo-signaux routés par préfixe de geohash, passerelle multi-source avec auto-désactivation par source, les clients lisent le cache pas les upstreams) ; normalisation de l'ensemble de l'Oracle avec entropie en nats estampée sur chaque merge ; Sisters typées (analyst, contrarian, disruptor, historian, institutionalist) chargées au runtime depuis des fichiers TOML ; ports hexagonaux basés sur traits avec adaptateurs interchangeables (Arc<dyn Trait> dans AppState) ; wire types de Zod définis une fois dans @everythink/types, parsés à la frontière réseau, mauvais payload → ApiError typé ; souveraineté du Eye Key (HMAC et empreinte enregistrés, le texte clair ne touche jamais le disque, la clé de l'utilisateur est la frontière de limite de débit) ; fournisseurs LLM OpenAI-compatible uniquement via async-openai (un protocole comme port, tout fournisseur compatible comme adaptateur, pas de dépendance directe au SDK Anthropic).