AI gateway

Une couche d'exploitation entre les applications et le marché des modèles

Un AI gateway est un reverse proxy spécialisé dans le trafic d'API de modèles de langage. Il normalise les requêtes entre fournisseurs, ajoute le routage, la bascule automatique en cas d'erreur, le contrôle des coûts, la mise en cache et l'observabilité, sans que le code applicatif change — l'endpoint exposé reste presque toujours compatible avec l'API OpenAI.

Le vocabulaire distingue deux fonctions que le marketing agrège. Le gateway est le point d'accès unifié : un endpoint, une authentification, une limitation de débit, une observabilité. Le router est la décision prise par requête : quel modèle répond, et quel fournisseur sert ce modèle. La seconde question existe parce qu'un même modèle open-weights est servi par plusieurs hébergeurs, à des prix, des latences et des politiques de rétention différentes.

Trois métiers sous une même étiquette

Le marché vend trois produits distincts sous un même nom, et les confondre conduit à de mauvais achats. La marketplace répond à « comment appeler des centaines de modèles avec une seule clé » et se rémunère par une commission. Le plan de contrôle répond à « comment posséder le routage, les budgets, les clés et les journaux » et se déploie chez le client. L'optimiseur d'agents répond à « comment réduire la facture des agents de codage sans casser la session » en compressant le contexte.

À côté de ces trois métiers vivent les cerveaux de routage — RouteLLM, Not Diamond — qui décident quel modèle appeler sans être eux-mêmes la passerelle. En pratique, les acteurs installés empilent les fonctions : aucun ne se présente plus comme un simple répartiteur de charge.

• Marketplace : OpenRouter, Vercel AI Gateway, Cloudflare AI Gateway.
• Plan de contrôle : LiteLLM, Portkey, Bifrost.
• Optimiseur d'agents : Edgee.

Comment la décision de routage se prend

Quatre stratégies coexistent et se superposent le plus souvent. Les règles (modèle A si vision ou outils, modèle B si requête courte, bascule si erreur serveur) sont auditables et couvrent l'essentiel des besoins réels. Les attributs fournisseur trient par prix plafond, débit, latence, disponibilité et région. La complexité fait classer le prompt par un classifieur, qui l'oriente vers le palier de modèle correspondant. Le contexte de l'agent agit sur la session elle-même : réduction des sorties d'outils, réduction de la surface MCP, redirection en cours de tâche quand un budget saute.

Le levier financier principal n'est plus le seul choix du modèle. Il combine routage, cache de prompt et compression. Le cache de préfixe étant indexé sur le contenu, un routeur qui change de modèle en cours de session invalide le cache et fait repayer le contexte entier : l'économie théorique du modèle moins cher est absorbée par la relecture. L'affinité de session, qui épingle le modèle du premier tour, est de ce fait devenue une fonctionnalité affichée.

Les risques à instruire

Une passerelle hébergée lit les prompts, et dans le cas d'un optimiseur d'agents, les appels d'outils. La rétention zéro s'active explicitement et n'est presque jamais le comportement par défaut de bout en bout ; pour un secteur régulé, l'auto-hébergement ou le locataire dédié en résidence européenne redevient la réponse défendable. L'enfermement, lui, se déplace plus qu'il ne disparaît : adopter une passerelle pour éviter de dépendre d'un fournisseur de modèles, c'est dépendre de la passerelle. La parade consiste à garder une interface compatible OpenAI côté application et à placer les politiques dans le gateway plutôt que dans le code métier.

Deux autres pièges reviennent. Un classifieur mal calibré envoie une analyse sensible vers le modèle le moins cher : un routeur automatique se fait tourner en observation sur son propre trafic avant d'être généralisé. Et les frais qui ne figurent pas au tarif — commission de plateforme, sièges par développeur, journaux facturés, infrastructure du proxy, conversion de devise — déplacent le point de bascule entre offre hébergée et proxy possédé.