Le palier de jetons à −92 % : ce que vous cédez quand la même API coûte dix fois moins

---

title: "Le palier de jetons à −92 % : ce que vous cédez quand la même API coûte dix fois moins" seoTitle: "API LLM à −92 % : ce que vous cédez" description: "Un palier tarifaire à −92 % sur la même API, c'est le prix des droits d'entraînement sur vos données. Ce que dit le contrat, ce que personne ne signe, et comment arbitrer." seoDescription: "Un palier LLM à −92 % se paie en droits d'entraînement sur vos données : ce que dit le contrat, ce que personne ne signe, et comment arbitrer." date: "2026-10-05" author: "Équipe Raicode" tags: ["IA", "coûts", "conformité", "architecture"] category: "IA & Automatisation" keywords: ["prix API LLM", "droits d'entraînement données", "palier contributor", "coût token LLM", "zero data retention", "conformité LLM", "contrat fournisseur IA", "marge unitaire SaaS IA", "reprise projet IA"]

Le changement tient en une chaîne de caractères. Quelqu'un remplace l'identifiant du modèle dans un fichier de configuration, la facture mensuelle passe de 4 200 € à 340 €, et la fonctionnalité répond exactement pareil. Personne n'a menti, personne n'a contourné quoi que ce soit : le fournisseur publie bien deux tarifs pour le même modèle, et l'écart est affiché sur sa page de prix. Ce qui n'est écrit nulle part dans le fichier de configuration, c'est la contrepartie.

Depuis l'ouverture du palier Contributor de Muse Spark début septembre 2026, cette question est arrivée dans à peu près toutes les revues de coûts qu'on nous demande de faire. Le palier Standard est à 1,25 $ par million de jetons d'entrée, le palier Contributor à 0,10 $ — soit −92 % sur l'entrée, et un rapport comparable sur la sortie, à 0,20 $ contre un tarif Standard proportionnel. Même modèle, mêmes poids, même qualité de réponse. La différence, le fournisseur l'écrit noir sur blanc : sur le palier bas, il s'entraîne sur vos requêtes et sur les réponses qu'il vous renvoie.

Ce n'est pas une remise de volume, ce n'est pas une offre de lancement, et ce n'est pas réservé à un acteur. Mistral conditionne le quota de son palier d'expérimentation à la même acceptation. Google utilise les requêtes passées par AI Studio pour améliorer ses modèles, sauf pour les utilisateurs situés dans l'Union européenne, au Royaume-Uni et dans l'EEE. Le modèle économique s'est installé : le jeton pas cher se paie en données.

Cet article s'adresse à l'équipe qui a déjà une fonctionnalité LLM en production, qui regarde sa facture, et à qui quelqu'un vient de proposer de diviser le coût par dix. Il décrit ce que le palier bas achète réellement, ce qu'il coûte au-delà du prix affiché, et la manière de trancher sans s'en remettre à l'intuition de celui qui tient le fichier de configuration.

Le prix affiché n'est pas le seul écart

Avant même d'ouvrir le sujet des données, le palier bas n'est pas le même service. Sur Muse Spark, le palier Contributor plafonne à 100 requêtes par minute, contre 3 000 sur le palier Standard : un facteur 30 sur le débit, à côté du facteur 12 sur le prix. Ce détail décide à lui seul une partie des cas.

Pour un traitement par lots nocturne, 100 requêtes par minute suffisent largement, et l'économie est réelle. Pour une fonctionnalité synchrone exposée à des utilisateurs, c'est une limite qu'on atteint à un volume très ordinaire — une centaine d'utilisateurs actifs simultanés qui déclenchent chacun deux ou trois appels, et les requêtes commencent à être rejetées. L'équipe ajoute alors une file d'attente, un mécanisme de reprise, une surveillance de la saturation. Ce travail a un coût en jours-homme et un coût en complexité permanente, et il annule une bonne partie des 3 860 € économisés chaque mois.

C'est le même piège que celui qu'on décrit dans les six leviers pour reprendre le contrôle d'une facture d'API LLM : on compare un prix unitaire alors que la variable qui compte est le coût complet de la fonctionnalité, infrastructure et maintenance comprises. Un palier moins cher qui impose une file d'attente n'est pas un palier moins cher, c'est une architecture différente.

Ce que le contrat dit, et surtout ce qu'il ne dit pas

La partie coûteuse n'est pas dans ce que le fournisseur annonce. Elle est dans ce qu'il ne publie pas.

Ce qui est publié est clair : sur le palier à bas prix, les requêtes et les réponses sont utilisées pour entraîner et améliorer les modèles. Le fournisseur présente cela comme un abaissement de la barrière d'entrée pour le prototypage et les tests d'intégration, « là où l'entraînement sur vos données est acceptable ». La formulation est honnête. Elle renvoie la qualification du caractère acceptable à vous, ce qui est juridiquement correct et opérationnellement inconfortable.

Ce qui n'est pas publié, à ce jour, constitue la liste des questions qu'un DPO posera :

• Aucune durée de conservation. On ne sait pas combien de temps les requêtes envoyées sur le palier bas sont stockées.
• Aucune information sur la revue humaine. On ne sait pas si des annotateurs lisent les échantillons, ni sous quel encadrement.
• Aucun mécanisme de révocation. Il n'existe pas de procédure documentée pour retirer une requête déjà envoyée du périmètre d'entraînement.

Ce troisième point est le seul qui soit vraiment structurant, parce qu'il rend la décision asymétrique. Changer de palier est réversible : on remet l'identifiant Standard dans la configuration, on repaie le tarif plein, et c'est terminé. Les données déjà envoyées, elles, ne reviennent pas. En l'absence de procédure publiée, la seule hypothèse de travail défendable est qu'une requête passée sur le palier bas est un don définitif. Vous ne décidez pas pour un mois, vous décidez pour chaque requête émise pendant ce mois, et cette décision-là ne se défait pas.

Un dernier point mérite d'être connu : la rétention nulle existe, mais elle n'est pas un interrupteur. Elle passe par une demande commerciale, traitée au cas par cas. Autrement dit, elle est accessible à qui a un interlocuteur commercial et un contrat-cadre, pas à l'équipe de quatre personnes qui a ouvert un compte avec une carte bancaire.

Personne ne signe, et c'est précisément le problème

Dans un achat logiciel normal, céder un droit d'usage sur des données passe par un document. Quelqu'un lit, quelqu'un vise, quelqu'un signe, et il reste une trace de qui a engagé l'entreprise.

Ici, le consentement s'exprime par un identifiant de modèle dans un fichier de configuration. Il n'y a pas de case à cocher, pas d'avenant, pas de notification. Un développeur qui cherche à faire baisser une facture — ce qu'on lui a explicitement demandé — modifie une chaîne de caractères, et l'entreprise a cédé un droit d'entraînement sur l'intégralité de ce qui transite par cet appel. Le changement passe en revue de code comme une optimisation de coût, parce que c'en est une, et qu'il est impossible de deviner autre chose en lisant la ligne modifiée. La presse spécialisée l'a formulé sans détour : ce consentement est placé là où les outils de sécurité ne vont pas le chercher.

C'est ce qui rend le sujet sérieux, bien plus que le fond de l'arbitrage. Il existe des cas parfaitement légitimes d'usage du palier bas. Le problème est qu'aucun processus existant ne garantit que ces cas soient les seuls, parce que la décision est prise à un endroit — la configuration applicative — que ni le juridique, ni le DPO, ni la sécurité ne surveillent.

Dans les audits de reprise que nous menons, c'est un point de contrôle systématique de la première semaine, au même titre que la gestion des secrets. La question « quels identifiants de modèle sont réellement appelés en production, et depuis quand » n'a presque jamais de réponse immédiate, et elle fait souvent apparaître un palier que personne n'avait validé. C'est l'une des raisons pour lesquelles notre reprise de projet IA commence par un inventaire des appels sortants avant toute discussion sur la qualité du modèle : on ne peut pas arbitrer un risque qu'on n'a pas cartographié.

Les trois questions qui tranchent

L'arbitrage se fait requête par requête, pas application par application. Un même produit peut légitimement envoyer certains appels sur le palier bas et d'autres sur le palier plein.

Première question : qu'est-ce qui part dans le corps de la requête ? Pas « est-ce que l'application traite des données clients », mais ce qui est effectivement sérialisé dans l'appel. Une requête de classification qui envoie uniquement une phrase de catégorie produit ne pose aucun problème. Un assistant qui injecte quinze documents de contexte avant la question de l'utilisateur en pose un, et il faut regarder ce qu'il y a dans les quinze documents. C'est exactement l'exercice de qualification décrit dans notre article sur les trois architectures pour faire tourner un LLM sur données sensibles, à une différence près : ici, l'architecture ne change pas. La donnée part au même endroit, chez le même fournisseur, sur la même infrastructure. Seul l'usage qu'il en fait change. C'est ce qui rend le sujet invisible aux contrôles habituels, qui regardent des flux réseau et des localisations, pas des conditions contractuelles.

Deuxième question : qu'avez-vous promis à vos propres clients ? C'est elle qui disqualifie le plus souvent le palier bas, et c'est la seule que le fournisseur ne peut pas vous aider à trancher. Si votre politique de confidentialité, votre page sécurité, un questionnaire fournisseur rempli il y a huit mois ou une clause de votre contrat-cadre indique que les données client ne sont pas utilisées pour entraîner des modèles tiers, le palier bas vous met en infraction le jour où il est activé — indépendamment de la sensibilité réelle des données. La plupart des équipes ont écrit cette phrase. Peu savent où.

Troisième question : que vaut vraiment l'économie ? À 4 200 € par mois de facture, −92 % représente 46 000 € par an, ce qui mérite une vraie discussion. À 180 € par mois, l'économie annuelle est de 2 000 €, soit moins que les deux jours de travail qu'il faudra pour documenter la décision, la faire valider et la surveiller. Et c'est le cas le plus fréquent, parce que la tentation du palier bas arrive souvent avant que le volume ne justifie quoi que ce soit.

Le même calcul, vu par un founder

Pour un produit dont chaque usage consomme des jetons, le raisonnement se déplace. La question n'est plus la conformité d'une fonctionnalité interne, c'est la marge unitaire d'un abonnement.

Quand le coût d'inférence représente 30 à 40 % du prix payé par l'utilisateur — ce qui est courant sur un produit facturé 29 € par mois avec un usage généreux — le palier bas ne fait pas gagner quelques points de marge, il décide de la viabilité du tarif. C'est précisément ce qui le rend dangereux : il devient structurant. Vous construisez votre grille tarifaire sur une hypothèse de coût qui dépend d'une cession de droits sur les données de vos clients, et vous ne pouvez plus en sortir sans refaire vos prix.

La conséquence pratique est simple, et elle rejoint ce qu'on explique sur les fondations de facturation d'un SaaS qu'on ne rattrape pas après coup : construisez la grille sur le tarif plein. Si le produit ne tient pas à ce prix-là, le problème n'est pas le palier, c'est le modèle économique — trop de jetons par utilisateur, pas assez de cache, pas de quota, ou un prix trop bas. Le palier bas peut financer une phase d'expérimentation sur des données qui ne sont pas celles de vos clients. Il ne peut pas tenir lieu de modèle de coût.

Ce qu'on met en place, concrètement

Trois mesures suffisent, et elles tiennent en une journée de travail.

Une liste blanche d'identifiants de modèles, vérifiée en intégration continue. Les identifiants autorisés en production sont déclarés dans un fichier unique, et un test échoue si un appel sortant utilise autre chose. Le changement de palier cesse d'être une modification anodine de configuration : il devient une modification d'une liste explicite, qui apparaît en revue de code pour ce qu'elle est.

Une classification par route, pas par application. Chaque point d'entrée qui appelle un LLM porte une étiquette — données client, données internes, données publiques — et cette étiquette détermine les paliers autorisés. Cela rend l'arbitrage réutilisable : la prochaine fonctionnalité hérite de la règle au lieu de rouvrir le débat.

Une ligne dans le registre des traitements et une dans le questionnaire fournisseur. Si vous utilisez un palier avec droits d'entraînement, cela se documente là où un auditeur ira chercher. C'est aussi le moyen le plus efficace de s'assurer que la décision a été vue par quelqu'un d'autre que l'auteur du commit.

Ce qu'il faut retenir

Un écart de −92 % sur un prix unitaire, à modèle identique, n'est jamais une remise commerciale. C'est le prix d'achat de quelque chose, et dans ce cas précis le fournisseur dit clairement de quoi il s'agit. Le sujet n'est pas de refuser par principe : pour du traitement par lots sur des données non sensibles, c'est une économie réelle que ce serait dommage de laisser passer.

Le sujet est que cette cession se décide aujourd'hui dans un fichier de configuration, sans trace, sans validation et sans réversibilité sur les données déjà envoyées, pendant que tout le dispositif de contrôle de l'entreprise regarde ailleurs. Remettez la décision à sa place : une liste blanche versionnée, une classification par route, et une grille tarifaire calculée au tarif plein.

L'action à faire cette semaine tient en une commande : listez les identifiants de modèles réellement appelés par votre production, et comparez-les à ceux que vous croyez utiliser. Dans un projet sur trois que nous reprenons, les deux listes diffèrent.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.