Tu paies au token. Ton fournisseur contrôle la longueur de la réponse. Et personne ne vérifie ce qui se passe entre les deux. Un audit de l'USTC vient de montrer comment un intermédiaire peut multiplier ta facture par 10 à 720 sans toucher au compteur — et 7 API sur 15 testées en présentent déjà le symptôme.
Tu ne paies pas un modèle, tu paies une longueur
Reprenons depuis le début. Quand tu appelles une API de langage, ta facture dépend du nombre de tokens générés en sortie. Pas de la qualité. Pas de l'utilité. De la longueur.
Le fournisseur, lui, contrôle toute la chaîne qui produit la réponse : le prompt système, le traitement de la requête, la représentation d'entrée, les couches du modèle. Il a donc un intérêt financier direct à ce que le modèle écrive plus long. Tant que tu ne t'en aperçois pas.
C'est exactement ce que décrit un papier de l'Université des sciences et technologies de Chine, soumis le 17 septembre 2026. Huit chercheurs. Un constat simple : le marché de l'API au token n'avait jamais formalisé ce risque. Ils l'ont baptisé PTIA, pour Provider-Side Token Inflation Attack.
Le point important, c'est ce que ce n'est pas. Ce n'est pas de la substitution de modèle — on ne te sert pas un modèle moins cher que celui annoncé. Ce n'est pas non plus de la fraude au comptage — on ne te facture pas des tokens qui n'existent pas. Non. Le modèle annoncé peut être réellement servi, chaque token réellement compté, et ta facture gonflée quand même.
Un chiffre pour donner l'échelle : une seule instruction invisible, glissée dans le prompt système côté fournisseur, peut multiplier la facture de sortie par plus de 13, tout en préservant l'utilité de la réponse. Une ligne. Treize fois la note.
Cinq façons de te faire écrire long
Les chercheurs n'ont pas théorisé dans le vide. Ils ont instancié cinq attaques, une par étage du pipeline.
La plus simple s'appelle HSPA. Une instruction de longueur fixe, cachée dans le prompt système, invisible pour toi. Réutilisable sur toutes les requêtes. Aucune optimisation par requête. Un fournisseur l'écrit une fois, il la sert à tout le monde, ad vitam.
POA ajoute un préfixe court à ta requête. Indépendant de la tâche, construit hors ligne par un modèle qui itère jusqu'à maximiser la longueur tout en gardant une réponse acceptable.
LSEA fait élaborer ta question par un petit modèle en une passe : contexte, dimensions d'analyse. Le texte est recollé à ta requête.
AS-TIA apprend un suffixe continu, purement latent, sans aucun texte visible. Un suffixe optimisé en deux étapes pour rallonger la génération sans casser le contenu. Toi, tu vois ta question. Le modèle, lui, voit ta question plus un truc invisible qui le fait bavarder.
FT-TIA ajuste le modèle lui-même. Micro-fine-tuning, injection de tokens, delta de poids. Le plus agressif des cinq. Le plus cher à installer, aussi.
Résultat ? Sur 500 questions de référence, les attaques multiplient la longueur de sortie par 10,2 à 720,2 fois par rapport à une génération normale. La seule attaque connue jusqu'ici — la retokenisation a posteriori, documentée par Velasco et ses collègues du Max Planck — plafonnait à 1,3-1,5 fois. On change d'ordre de grandeur.
Et le pire, c'est la discrétion. HSPA, POA et LSEA conservent l'exactitude : 79,8 %, 74,5 % et 77,3 % de précision, contre 77,9 % pour une génération propre. La naturalité tient bon aussi : 97 %, 83 % et 97 % de réponses jugées naturelles, contre 98,5 %. Autrement dit, les attaques les plus rentables sont précisément celles que tu ne verras jamais venir. FT-TIA, le plus agressif, garde 77,3 % de précision mais tombe à 25 % de réponses naturelles — du texte répétitif, gabaritique. Trop visible. Peu rentable.
Le constat est limpide : un fournisseur malhonnête a intérêt à être subtil.
L'astuce : le gonflage sature
Comment détecter ce genre de magouille sans modèle de référence, sans historique, sans des mois de données ? Les chercheurs ont trouvé un angle malin.
Le gonflage sature. Une première intervention fait chuter fortement la probabilité du token de fin de séquence, donc rallonge beaucoup la sortie. Mais empiler ou renforcer les interventions ensuite n'ajoute presque plus rien. Le ressort est déjà tendu.
D'où l'audit. Sur chaque question, tu envoies une requête originale, puis une requête sondée : tu appliques toi-même une petite intervention allongeante. En service normal, la sonde rallonge beaucoup. Sous gonflage, elle rallonge peu — le fournisseur a déjà pris la marge de rallongement disponible.
L'accordéon est déjà ouvert. Tu tires dessus, rien ne bouge. Voilà le signal.
La méthode ne demande qu'une sonde unique, aucune réponse propre de référence, et deux requêtes qui ressemblent à du trafic ordinaire — difficiles à repérer pour un fournisseur qui voudrait tricher uniquement sur la sonde.
Les chiffres de détection sont bons. Sur quatre modèles et cinq attaques, l'audit atteint 85,1 % de détection avec seulement 20 questions (40 appels), pour un taux de faux positifs de 0,02 %. Monte à 50 questions et tu es à 94,4 %. Les deux méthodes de comparaison font moins bien : le test d'uniformité par rang exige un modèle local de confiance et plafonne à 76,8 %, la comparaison d'historique s'effondre à 7,25 % sur un cas.
Le coût ? Quarante appels au modèle cible. C'est tout.
7 services sur 15 présentent le signal
Les chercheurs sont passés au réel. Quinze services vendant des modèles de la famille GPT via des endpoints compatibles OpenAI, anonymisés P01 à P15. Vingt questions, deux requêtes chacune, quarante appels par service, six cents appels au total.
Résultat : 7 services sur 15, soit 46,7 %, présentent un signal compatible avec le gonflage. Les modèles annoncés par ces services : gpt-4o-mini, gpt-5.4, gpt-5.4-mini, gpt-5.6-luna.
Et là, halte. Il faut être précis, parce que c'est exactement l'endroit où un article racoleur basculerait dans l'accusation.
Un signal n'est pas une preuve. Les chercheurs l'écrivent noir sur blanc. Les configurations backend réelles sont inconnues, non reproductibles. Un prompt système long peut exister pour des raisons produit : sécurité, garde-fous, style maison. Une chaîne d'outils verbeuse, du raisonnement étendu, un cache mal géré. Tout ça produit des sorties longues sans intention frauduleuse.
Les noms sont anonymisés. On ne peut ni recouper, ni demander une réaction aux fournisseurs. C'est frustrant, et c'est sain. Ce papier n'est pas une liste d'accusés. C'est un outil de dépistage à utiliser avant d'adopter un fournisseur, et à répéter périodiquement.
Le point important n'est donc pas « qui triche ». C'est que 46,7 % des services testés ne peuvent pas être blanchis par ce test simple — et que personne, ni toi ni moi, n'a aujourd'hui les moyens de trancher.
Ce n'est pas un incident. C'est une industrie opaque.
Ce papier n'arrive pas dans le vide. Il s'inscrit dans une série de travaux qui, depuis 2025, démontent méthodiquement la confiance dans les API de langage.
Velasco et ses collègues avaient déjà montré que la tarification au token crée une incitation à surfacturer, et que la seule parade théorique est de facturer linéairement sur le nombre de caractères. Personne ne l'a fait.
L'audit des « shadow APIs » a identifié 17 API fictives utilisées dans 187 papiers académiques, la plus populaire cumulant près de 6 000 citations — des chercheurs qui publient sur des modèles qu'ils n'ont jamais réellement appelés.
Une étude sur les routeurs achetés sur Taobao et Shopify a trouvé huit routeurs gratuits qui injectent activement du code malveillant, dix-sept qui touchent des identifiants AWS appartenant aux chercheurs, un qui vide une clé privée Ethereum.
Et côté client, cette fois, l'analyse communautaire de deux bugs de cache de Claude Code mesure 10 à 20 fois d'inflation de tokens, en avril 2026.
Ajoute à ça l'échelle du marché : OpenRouter dit router vers plus de 70 fournisseurs, servir plus de 8 millions de développeurs sur plus de 400 modèles, et traiter 25 000 milliards de tokens par semaine.
Tu saisis le tableau. Une industrie entière de courtage de tokens où personne ne peut vérifier ce qui se passe dans le backend. La facture au token n'est pas un prix affiché. C'est un prix reconstruit, par un intermédiaire qui a intérêt à ce qu'il soit haut.
Verdict
Franchement, ce papier m'a mis mal à l'aise, et pas pour les raisons racoleuses.
Pas parce que « 7 fournisseurs sur 15 trichent ». Parce qu'on ne peut pas le savoir. La vraie nouvelle, ce n'est pas la fraude. C'est qu'après trois ans d'explosion des API de langage, il n'existe toujours aucun moyen standard de vérifier qu'on te facture ce que tu consommes. La preuve est asymétrique : le fournisseur sait tout, toi tu devines.
Les contre-mesures, elles, sont étonnamment simples. Un audit de 40 appels avant de signer. Des limites de dépense pour plafonner l'exposition — ça ne révèle rien, mais ça borne le dégât. Et la question qui devient contractuelle : « comment prouvez-vous le nombre de tokens facturés ? » Un fournisseur sérieux devrait pouvoir répondre sans toussoter.
La solution propre existe, et elle est théorique : facturer au caractère, pas au token. Velasco l'avait proposé. Aucun fournisseur majeur ne l'a adopté. Pose-toi la question de pourquoi.
En attendant, rappelle-toi la règle de base : tu ne paies pas un modèle, tu paies une longueur. Et la longueur, c'est l'autre qui la choisit.
Sources
- https://arxiv.org/abs/2609.20370 — « The More It Says, the More You Pay: A Black-Box Audit of Provider-Side Token Inflation in LLM Services », USTC, 17 septembre 2026
- https://arxiv.org/html/2609.20370 — texte intégral du papier (attaques, protocole d'audit, résultats P01-P15)
- https://arxiv.org/abs/2505.21627 — Velasco et al., « Is Your LLM Overcharging You? Tokenization, Transparency, and Incentives » (ICML 2026)
- https://arxiv.org/abs/2603.01919 — « Real Money, Fake Models: Deceptive Model Claims in Shadow APIs »
- https://arxiv.org/abs/2604.08407 — « Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain »
- https://github.com/ArkNill/claude-code-cache-analysis — analyse de deux bugs de cache de Claude Code (10-20× d'inflation), avril 2026
- https://news.ycombinator.com/item?id=49763307 — fil Hacker News sur le papier, 19 septembre 2026
Idée d'illustration
✦ Un compteur de taxi géant façon rétro, dont les chiffres défilent à toute vitesse pendant que la voiture est à l'arrêt. En arrière-plan, un panneau « TARIF AU TOKEN » et, assis côté passager, un développeur qui regarde le compteur avec un mélange de suspicion et de résignation. Style néobrutaliste, couleurs acides (jaune taxi, noir d'encre), grain d'impression sérigraphie. L'idée : on te facture une course pendant que la voiture ne bouge pas — et le chauffeur, hors champ, tient la main sur le compteur.
