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.

Cette couche isole l'entreprise de ses fournisseurs de tokens : le modèle devient un paramètre de politique, remplaçable par une règle de routage sans que les utilisateurs changent d'outil. Le déploiement de Qonto, raconté par Edgee le 22 septembre 2026, en donne la version de terrain. Au 10 septembre, 500 ingénieurs passaient leurs agents de codage par la passerelle ; la première règle de routage, le 1er septembre, a déplacé le trafic d'exécution d'un modèle frontier vers un modèle frontier moins cher de même classe ; l'analyse DORA de Qonto classe la passerelle en prestataire TIC tiers non critique, parce que les harnais peuvent retomber directement sur les fournisseurs de modèles en cas de panne. Kevin Prettre, qui dirige l'infrastructure de Qonto, y décrit aussi pourquoi une passerelle applicative n'a pas suffi : elle suppose des services connus, des requêtes de forme stable et une identité de service, trois hypothèses que le trafic d'agents ne respecte pas. Et il situe la limite de l'outil : aucune passerelle ne dimensionne le modèle par tâche à la place d'une plateforme d'évaluation.

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 ; le prompt caching est la discipline qui en fixe les règles.

Reste à décider qui prend la décision de routage. Le routeur automatique la prend dans la passerelle, à partir du prompt ; l'escalade par seuil de confiance la laisse dans le code de l'application : le modèle bon marché répond avec un score de confiance en sortie structurée et, sous un seuil que vous fixez, la requête repart vers le modèle fort. OpenRouter documente cette seconde voie depuis le 1er octobre 2026 en rappelant que les chaînes de secours ne se déclenchent que sur une erreur, jamais sur une réponse valide mais peu sûre. Le lendemain, ses Model Router Benchmarks comparent sept routeurs sur six benchmarks et admettent que ces techniques peuvent parfois donner de moins bons résultats qu'un modèle unique appelé directement, le cache d'entrée se reconstruisant à chaque changement de modèle. Dans les deux cas, le seuil et le routeur se calibrent avec des evals sur votre propre trafic, pas sur un classement public.

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é.