OUTILS IA — CHOISIR, MESURER, CONTRÔLER · 05 / 10 · PASSERELLES & ROUTAGE
Documentations officielles, pages tarifaires et textes de licence relevés au 19 juillet 2026. Aucun comparatif tiers, aucune exécution de code n'a servi de source.
Changer de modèle ne devrait pas être un projet. Dans la plupart des applications, c'est pourtant le cas : la clé d'un fournisseur est câblée dans le code, son format de requête aussi, ses particularités de réponse également. Basculer vers un autre modèle suppose alors de retoucher chaque point d'appel, de refaire les tests, et de recommencer six mois plus tard.
La couche qui répond à ce problème porte un nom simple : la passerelle. Elle place un point de passage unique devant tous vos appels, expose une interface stable, et transforme le changement de modèle en ligne de configuration. Le gain est réel. Mais elle introduit aussi un intermédiaire de plus dans le chemin critique, et — c'est le point que cet article documente — la promesse commerciale la plus visible du secteur, le routage automatique par coût ou par latence, n'est tenue que par une minorité des acteurs. Le reste se démontre par les textes de licence et les pages tarifaires, pas par la rhétorique.
Ce qu'une passerelle fait, et ce qu'elle ne fait pas
Une passerelle centralise. C'est à peu près tout, et c'est déjà beaucoup. Elle détient les clés des fournisseurs à la place de votre application, ce qui retire des secrets de votre code. Elle voit passer chaque requête, ce qui donne un point unique où mesurer la dépense. Elle connaît la liste des destinations possibles, ce qui lui permet d'en essayer une autre quand la première échoue.
Elle ne fait pas le reste, et le malentendu commence là. Une passerelle n'améliore pas la qualité des réponses : le modèle appelé répond exactement comme il aurait répondu en direct. Elle ne rend pas les modèles interchangeables : elle harmonise le format de l'appel, pas le comportement du modèle appelé, et une consigne système réglée pour l'un ne produit pas le même résultat chez l'autre. Elle ne supprime pas la dépendance : elle la déplace vers elle-même.
Ce dernier point mérite d'être posé tout de suite, parce qu'il structure le reste de l'article. Adopter une passerelle, c'est accepter d'échanger une dépendance forte à un fournisseur de modèles contre une dépendance plus faible à plusieurs, plus une dépendance nouvelle à l'intermédiaire. L'arbitrage est souvent bon. Il n'est jamais gratuit — et c'est exactement le problème posé en amont dans « Ne pas dépendre d'un seul fournisseur », dont cet article est la mise en œuvre technique.
Le point de passage unique concentre les clés, la mesure et la décision de routage. Deux couches de décision s'y superposent, souvent confondues : choisir quel modèle répond, puis choisir quel fournisseur sert ce modèle. Les outils du marché n'automatisent pas les deux, et rarement la même.
Interface unifiée : le vrai gain, et ses angles morts
Le bénéfice le plus solide de la passerelle est le moins spectaculaire : un seul format d'appel. Vercel AI Gateway résume la promesse d'une formule — « une clé, des centaines de modèles » — et documente une compatibilité avec plusieurs conventions d'API répandues, ce qui permet à un code existant de basculer sans réécriture massive. OpenRouter revendique de son côté plus de 400 modèles auprès de plus de 70 fournisseurs derrière la même interface.
Concrètement, l'équipe cesse d'écrire du code d'adaptation. Ajouter un modèle candidat à une évaluation ne demande plus qu'une chaîne de caractères. Retirer un fournisseur dont le contrat se termine devient une opération de configuration. Pour toute organisation qui compare régulièrement des modèles, ce seul gain justifie souvent la couche.
Les angles morts sont réels, et rarement énoncés. Le premier : l'unification se fait par le plus petit dénominateur commun. Les fonctions propres à un fournisseur — un mode de raisonnement particulier, un format de sortie structuré spécifique, une gestion fine du cache de contexte — sont exposées de façon inégale, quand elles le sont. Une équipe qui s'appuie sur une optimisation propre à un fournisseur, comme celles décrites dans « Prompt caching et cache clé-valeur », doit vérifier que la passerelle la transmet réellement plutôt que la supposer.
Le deuxième : l'interface unifiée ne rend pas les résultats comparables. Deux modèles derrière la même signature d'appel n'ont ni la même façon de suivre une consigne, ni la même verbosité, ni le même comportement de refus. Le changement de modèle reste un changement fonctionnel qui exige de rejouer un jeu de cas — la méthode détaillée dans « Mesurer la qualité d'un assistant IA en production ». La passerelle rend le basculement facile, pas sûr.
Le troisième : la latence ajoutée. Chaque appel traverse un service de plus. L'effet reste modeste comparé au temps de génération, mais il existe, et il s'additionne aux réessais lorsque le repli s'active.
Router selon quoi — et pourquoi la moitié du panorama ne le fait pas pour vous
C'est ici que le discours commercial s'écarte le plus de la documentation. « Routage intelligent », « routage optimisé par le coût », « routage par la latence » : ces formules laissent entendre qu'un mécanisme automatique arbitrera à votre place. Chez la moitié des acteurs relevés, ce mécanisme n'existe pas.
LiteLLM est le seul du panorama à exposer l'arbitrage comme des stratégies nommées et documentées. Sa documentation de routage liste notamment cost-based-routing — « choisit un déploiement en fonction du coût le plus bas » — et latency-based-routing — « choisit le déploiement au temps de réponse le plus faible ». S'y ajoutent une stratégie de répartition simple présentée comme le défaut recommandé en production, des variantes conscientes des limites de débit, une stratégie qui vise le déploiement le moins occupé, et la possibilité d'écrire sa propre stratégie. C'est, sur ce critère précis, l'outillage le plus complet.
OpenRouter automatise aussi, mais sur deux couches distinctes qu'il ne faut jamais confondre. La première choisit le modèle : un routeur automatique classe la requête parmi une trentaine de types de tâches, puis applique un paramètre d'arbitrage entre coût et qualité sur une échelle graduée, dont la valeur par défaut ne laisse survivre qu'environ le tiers le moins cher des candidats. La sélection s'appuie sur un classement pondéré par la dépense réelle de la communauté sur une fenêtre glissante. La seconde couche choisit le fournisseur d'un modèle déjà décidé : un paramètre de tri permet de privilégier le prix, le débit ou la latence. Le point à retenir : l'arbitrage par la latence n'apparaît qu'à la seconde couche, celle du fournisseur, et n'est pas documenté au niveau du choix de modèle. Réserve supplémentaire : la page tarifaire présente le routage automatique comme une fonction des paliers payants, pas du palier gratuit.
Portkey et Cloudflare AI Gateway se rangent dans une autre catégorie, malgré un vocabulaire proche. Le routage conditionnel de Portkey s'appuie sur des conditions que vous définissez — métadonnées, paramètres de requête, chemins d'URL — et sa documentation n'expose aucun arbitrage automatique par coût ni par latence ; la fonction est en revanche annoncée disponible sur l'ensemble des paliers. Cloudflare propose un routage dynamique décrit comme sensible au contenu de la requête, également fondé sur des règles. Dans les deux cas, la décision « quel modèle mérite cette requête » reste écrite à la main par quelqu'un de votre équipe.
Cette section ne peut donc pas être un mode d'emploi. Le constat utile est ailleurs : chez deux des cinq acteurs, l'arbitrage économique est un travail que vous ferez, pas une fonction que vous achèterez. Et il suppose de savoir ce qu'un appel coûte réellement — sujet traité dans « Le vrai coût d'un modèle », préalable à toute règle de routage sensée.
| Outil | Routage par coût | Routage par latence | Nature réelle du mécanisme |
|---|---|---|---|
| LiteLLM | Oui — stratégie nommée cost-based-routing. |
Oui — stratégie nommée latency-based-routing. |
Automatique, documenté, avec stratégies personnalisables. |
| OpenRouter | Oui, sur deux couches : arbitrage coût / qualité au choix du modèle, et tri par prix au choix du fournisseur. | Oui, mais au choix du fournisseur uniquement — pas au choix du modèle. | Automatique, à condition de distinguer les deux couches. Annoncé sur les paliers payants. |
| Portkey | Non documenté. | Non documenté. | Routage conditionnel par règles : métadonnées, paramètres, chemins d'URL. Disponible sur tous les paliers. |
| Cloudflare AI Gateway | Non documenté. | Non documenté. | Routage dynamique par contenu et règles, orienté haute disponibilité. |
| Vercel AI Gateway | Non documenté à cette lecture. | Non documenté à cette lecture. | Page dédiée aux options de fournisseur : routage, repli et préférences configurables. |
Repli automatique et quotas : la partie qui sauve la production
C'est, de loin, le point le mieux tenu du panorama — et paradoxalement le moins mis en avant. Les cinq acteurs documentent officiellement un repli automatique vers une autre destination en cas d'échec, et quatre documentent en plus des mécanismes de quota ou de limitation de débit.
Chez OpenRouter, le repli est activé par défaut, et la documentation indique que les requêtes sont réparties par défaut entre les meilleurs fournisseurs pour maximiser la disponibilité. C'est un choix de conception notable : la haute disponibilité y est le comportement de base, pas une option à cocher. LiteLLM documente un basculement entre fournisseurs avec ordre de préférence explicite et un mécanisme de reprise pondérée qui réessaie au sein du même groupe de modèles avant d'escalader. Portkey annonce les replis automatiques, les réessais, les délais d'expiration et la répartition de charge dès le déploiement auto-hébergé gratuit. Cloudflare associe ses replis automatiques à une limitation de débit et à des plafonds de dépense configurables par passerelle ou par requête. Vercel annonce un réessai automatique vers d'autres fournisseurs en cas d'échec ; le détail de ses quotas n'a pas été consulté à cette passe et reste non vérifié.
Deux réserves de lecture s'imposent. D'abord, un repli automatique change le modèle qui répond : en incident, votre application ne sert plus la même qualité ni le même coût par requête, et cela doit apparaître dans vos journaux, faute de quoi une dégradation de qualité sera imputée au mauvais endroit. Ensuite, les plafonds de dépense sont une protection contre l'emballement, pas contre l'erreur de conception : un agent qui boucle consommera son plafond avant que quiconque le remarque — mécanique détaillée dans « Combien coûte vraiment un agent IA ».
Panorama : cinq unités de facturation qui ne se comparent pas
Voici le fait le plus utile de l'article, et celui qu'aucune page d'accueil ne formule : comparer des passerelles n'est pas comparer des prix, c'est comparer des unités de facturation différentes. Les cinq acteurs relevés facturent sur cinq bases distinctes, dont deux s'opposent frontalement.
OpenRouter prélève un pourcentage sur l'inférence : 5,5 % de frais de plateforme en paiement à l'usage, sans dépense minimale. En apportant vos propres clés fournisseur, la documentation annonce 5 % du coût normal, exonérés sur le premier million de requêtes mensuelles. Des seuils d'exonération existent au-delà de volumes annoncés très élevés. Le palier gratuit donne accès à plus de 25 modèles gratuits chez 4 fournisseurs, dans la limite de 50 requêtes par jour.
Vercel AI Gateway occupe la position exactement inverse et l'affiche en toutes lettres : « aucune majoration sur les jetons… les jetons coûtent la même chose que chez le fournisseur en direct, majoration nulle, y compris avec vos propres clés ». Le contraste avec le modèle précédent est frontal, et il est le fait marquant du tableau. Les paliers de facturation associés n'ont pas été consultés à cette passe : non vérifié.
Portkey ne facture ni les jetons ni les requêtes, mais la finesse de l'observabilité : le volume de journaux enregistrés. Le palier développeur inclut 10 000 journaux par mois ; le palier production est annoncé à 49 $ par mois pour 100 000 journaux, avec un dépassement à 9 $ par tranche de 100 000. L'auto-hébergement est gratuit. Conséquence pratique : votre facture suit votre appétit de traçabilité, sans rapport avec votre usage des modèles — logique voisine de celle décrite pour les plateformes d'observabilité dans l'article précédent de cette série.
Cloudflare AI Gateway cumule deux logiques. D'un côté un quota de journaux persistants adossé au plan Workers : 100 000 journaux toutes passerelles confondues sur le plan gratuit, 10 millions par passerelle sur le plan payant. De l'autre, des frais de 5 % sur tout achat de crédits en facturation unifiée, l'éditeur précisant que les tarifs d'inférence des fournisseurs ne subissent aucune majoration supplémentaire. S'y ajoutent l'export de journaux au-delà de 10 millions de requêtes mensuelles, facturé 0,05 $ par million, et des garde-fous facturés séparément à l'inférence. La page rappelle que ces prix sont susceptibles d'évoluer. Notons-le, car l'erreur circule : cette tarification est bien publiée — simplement sur une page de référence distincte de la page produit.
LiteLLM, enfin, ne publie aucun prix pour son offre entreprise : « la tarification dépend de la taille de votre déploiement — contactez-nous pour la cadrer ». Le support est annoncé en heures ouvrées sur un fuseau donné, sans délai de réponse garanti, un engagement de service continu étant proposé en supplément. L'unité facturée est le siège utilisateur, ce qui nous conduit au point suivant.
Cinq bases de facturation incommensurables : pourcentage sur l'inférence, majoration nulle, volume de journaux, quota de journaux cumulé à un pourcentage sur les crédits, et sièges à prix non publié. Un tableau comparatif de prix serait ici trompeur : les colonnes ne mesurent pas la même chose.
La passerelle est un point de défaillance unique — et un nouveau dépendant
Une passerelle concentre le trafic. Elle concentre donc aussi le risque : si elle s'arrête, tous vos appels s'arrêtent, y compris ceux vers des fournisseurs parfaitement disponibles. Le repli qu'elle orchestre ne la protège pas d'elle-même. C'est l'argument le plus solide en faveur des variantes auto-hébergées, où l'indisponibilité relève de votre exploitation plutôt que du calendrier d'un tiers.
Mais l'auto-hébergement pose une autre question, et c'est là que la lecture des licences est plus instructive que n'importe quel argumentaire. Une passerelle open source peut basculer en licence propriétaire au moment précis où elle devient utile en équipe.
Le cas est documenté et vérifiable. Le dépôt de LiteLLM est classé NOASSERTION par la plateforme d'hébergement, et non MIT. Son fichier de licence racine énonce que tout le contenu résidant sous le répertoire enterprise/ relève d'une licence définie séparément, le reste étant sous MIT. Et cette licence séparée conditionne l'usage en production à un abonnement valide couvrant le nombre correct de sièges utilisateurs ; la copie et la modification n'y sont autorisées que pour le développement et le test, et la redistribution y est interdite. Côté fonctions, l'authentification unique est gratuite jusqu'à 5 utilisateurs, au-delà desquels une licence entreprise est requise. S'y rattachent également le provisionnement des comptes, l'administration par équipe ou par organisation, les garde-fous par clé, la gestion des secrets et la rotation des clés.
Autrement dit : l'outil est libre tant qu'il sert un développeur qui expérimente. Dès qu'il porte le trafic d'une équipe — c'est-à-dire dès qu'il remplit sa fonction — il entre dans un périmètre commercial dont le prix n'est pas publié. Ce n'est ni un piège ni une malhonnêteté ; c'est un modèle économique parfaitement lisible, à condition de l'avoir lu. C'est aussi la démonstration la plus nette du fait que la passerelle recrée une dépendance : celle-ci n'est pas technique, elle est contractuelle.
Le contrepoint mérite d'être noté avec la même précision. Portkey est le seul MIT authentique du panorama : sa licence racine est une MIT sans réserve, et aucun répertoire de type enterprise/ n'apparaît à la racine du dépôt. Son offre commerciale porte sur les journaux du service hébergé, pas sur le droit d'exploiter le logiciel. La distinction entre les régimes de publication du code et leurs implications réelles fait l'objet de « Open weights, open source, fermé » ; elle vaut pour l'outillage autant que pour les modèles.
Comment le vérifier vous-même
Rien de ce qui précède ne remplace un relevé sur votre propre trafic : les pages officielles décrivent des unités de facturation, des licences et des capacités annoncées, jamais le comportement de votre application. Le protocole ci-dessous se déroule sur quelques jours et produit une décision défendable, chiffres à l'appui.
Une passerelle est un bon investissement d'architecture, pour une raison qui n'est pas celle qu'on met en avant : elle rend le changement possible, et le changement est la seule protection durable contre un marché qui bouge tous les trimestres. Elle ne rendra pas vos réponses meilleures, ne choisira pas le modèle à votre place dans la moitié des cas, et vous rendra dépendant d'elle. Le bon réflexe d'entrée n'est donc pas de choisir un outil, mais de compter votre trafic dans les cinq unités qui le factureront, puis d'ouvrir les fichiers de licence. Ces deux relevés tiennent en une journée et survivront à tous les changements de grille tarifaire.
Une question, un projet IA ?
Vous envisagez d'introduire une passerelle devant vos appels de modèles et cherchez à en mesurer le coût réel — échangeons sur votre contexte et vos contraintes.
Prendre contact →Pour aller plus loin : côté stratégie, « Ne pas dépendre d'un seul fournisseur » pose le problème dont cet article est la réponse technique. Côté méthode, « Le vrai coût d'un modèle » donne les grandeurs sans lesquelles aucune règle de routage n'a de sens, et « Open weights, open source, fermé » explique pourquoi une licence se lit avant de se citer. L'ensemble de nos décryptages de concepts IA reste consultable en accès libre.