Une remise de 10 % sur de l'inférence IA peut venir d'un contrat volume. Une remise de 30 % peut encore s'expliquer par une marge faible, du routage entre modèles ou des crédits achetés à bon prix. Quand un intermédiaire promet durablement des modèles haut de gamme pour une fraction minuscule du tarif officiel, il faut cependant ajouter une question au benchmark : qui absorbe la différence ?
L'enquête publiée par Matt Lenhard sur le marché des relais de tokens décrit un écosystème où des services proxifient des requêtes vers de grands fournisseurs puis revendent l'accès à des prix parfois très inférieurs au catalogue.1 Hackaday a remis le sujet en lumière le 25 août 2026 avec une formule simple : le relais n'est pas frauduleux en soi ; le problème commence quand son stock d'inférence provient d'accès obtenus sans en payer normalement le coût.3
Cette nuance compte. Un proxy API peut très bien servir au load balancing, à l'observabilité ou à une facturation unifiée. Le problème économique se joue en amont du proxy.
Le prix manque
Chaque requête finit quelque part sur une facture : fournisseur de modèle, cloud, crédit promotionnel, abonnement logiciel ou produit tiers qui paie l'inférence pour ses utilisateurs.
Si le client paie très peu et que le revendeur gagne encore de l'argent, la marge vient forcément de quelque part : coût d'achat réellement bas, subvention assumée, ou facture déplacée vers une partie qui ne l'a pas choisie.
Lenhard documente plusieurs sources de ce troisième cas : crédits promotionnels abusés, factures qui ne seront pas honorées, moyens de paiement frauduleux, comptes ou clés compromis, et fonctions IA de produits tiers utilisées comme capacité d'inférence générale alors qu'elles n'avaient pas été conçues pour cela.1 Les méthodes varient, pas l'équation.
Le relais neutre
Il faut éviter un raccourci : pooler plusieurs clés API ne prouve rien, à lui seul, sur leur provenance.
Une entreprise peut avoir plusieurs projets, plusieurs fournisseurs ou plusieurs comptes autorisés et choisir un gateway pour distribuer les requêtes. Des plateformes vendent elles-mêmes du routage multi-modèles. Un intermédiaire peut également acheter légalement des crédits inutilisés à une autre entreprise, à condition que les contrats concernés l'autorisent.
Vectoral décrit d'ailleurs un second marché de « token brokers » qui proposent d'acheter et revendre des crédits inutilisés de startups.2 Là encore, le simple fait qu'un actif change de main ne suffit pas à conclure. Les conditions d'utilisation, l'origine des crédits et le droit de les transférer comptent.
Le doute devient sérieux lorsque le prix ne ressemble plus au coût officiel, que la provenance change sans cesse ou que le service peine à expliquer ce qu'il revend réellement.
Un prix anormalement bas ne constitue pas une preuve. Il justifie simplement de demander davantage de comptes avant d'intégrer le service.
L'inventaire invisible
Pour l'acheteur, un relais gomme presque toute la provenance. Il reçoit une URL compatible avec une API connue, une clé propre au revendeur et une liste de modèles. Derrière, le service peut changer de compte ou de fournisseur sans modifier l'intégration cliente.1
Cette abstraction rend le relais pratique, mais elle rend aussi le risque presque invisible côté client.
Deux requêtes identiques dans le SDK peuvent ainsi cacher deux histoires économiques opposées. L'une est facturée à un compte professionnel autorisé. L'autre consomme une ressource dont le propriétaire ignore l'usage.
L'opacité finit aussi par devenir un problème de continuité. Une source frauduleuse finit souvent par être coupée : carte bloquée, clé révoquée, crédit épuisé, endpoint corrigé. Le relais peut alors perdre brutalement une partie de sa capacité ou changer de route.
Le client qui avait choisi ce service uniquement pour son prix découvre que la remise contenait aussi un risque d'approvisionnement.
Votre feature devient un stock
Pour un maker ou une petite équipe, la leçon la plus concrète se trouve peut-être ailleurs que chez l'acheteur. Elle concerne l'application qui paie elle-même des tokens.
Lenhard raconte avoir rencontré des abus visant des fonctions IA intégrées à des produits : lorsqu'un backend accepte trop librement des requêtes utilisateur et les transmet à un modèle payé par l'éditeur, cette fonction peut devenir une source d'inférence pour quelqu'un d'autre.1
La clé amont peut rester parfaitement cachée et la facture partir quand même de travers. Une API interne peut rester côté serveur et être tout de même économiquement exploitable si elle n'impose pas de limites adaptées à son cas d'usage.
C'est ici que les recommandations classiques de sécurité des clés restent nécessaires mais insuffisantes. Anthropic recommande notamment de ne pas partager les clés, d'éviter leur présence dans les dépôts et d'utiliser des clés séparées selon les usages.4 Google recommande restrictions, isolation, rotation et surveillance de l'utilisation.5
Ces mesures protègent le credential. Elles ne bornent pas automatiquement le budget derrière ce credential.
Borner le produit
Une fonction « résumer ce ticket » n'a aucune raison d'accepter silencieusement n'importe quel texte, contexte ou cadence comme si elle vendait une API générale.
Il faut rapprocher la capacité technique du produit réellement vendu : authentification, quotas par utilisateur ou organisation, tailles maximales, modèles autorisés, budget par période, détection d'anomalies et coupure rapide d'une route suspecte.
L'objectif n'est pas l'invulnérabilité. Il est de rendre l'usage détourné assez borné et coûteux pour qu'il cesse d'être une source de tokens revendable à grande échelle.
Beaucoup d'abus économiques n'ont besoin d'aucune faille spectaculaire. Une petite asymétrie répétable à grande échelle suffit.
Acheter le risque
Côté acheteur, le calcul se retourne presque comme un miroir. Un relais extrêmement bon marché peut sembler idéal pour du prototypage ou des agents très consommateurs. Pourtant, le prix n'est qu'une partie du coût.
Au prix s'ajoutent stabilité, confidentialité des prompts, visibilité sur la sous-traitance, contrat, facturation utilisable et risque de coupure lorsque l'amont change ses règles.
Si le service ne peut pas répondre simplement à « d'où vient cette capacité ? », le développeur achète aussi cette incertitude.
Il ne s'agit pas pour autant de bannir tous les intermédiaires. Un routeur ou un revendeur peut apporter une vraie valeur : négociation volume, unification d'API, cache, observabilité, bascule entre fournisseurs. Mais cette valeur doit exister sans avoir besoin d'un coût amont mystérieusement proche de zéro.
La remise est une trace
Le marché transforme progressivement le token en quasi-matière première : on l'achète, on l'agrège, on le route et on le revend. Dès qu'un actif devient suffisamment liquide, un marché gris apparaît autour des écarts de prix et des contrôles imparfaits.2
La question utile n'est plus « ce relais est-il bon marché ? », mais quelle architecture économique rend ce prix possible ?
Un contrat volume peut l'expliquer. Un modèle moins cher derrière une couche compatible peut l'expliquer. Une subvention marketing temporaire peut l'expliquer.
Et parfois, la réponse est simplement que le coût n'a pas disparu. Il est arrivé sur le compte de quelqu'un d'autre.