Facturez au token et la tarification semble réglée : l’usage monte, le revenu monte, en parfaite synchronie avec le coût. En pratique la synchronie se rompt presque tout de suite, parce que le coût par token n’est pas un seul chiffre. Une question factuelle courte et la rédaction d’un long document peuvent porter la même étiquette « par requête » et un coût complètement différent, et une grille tarifaire construite autour d’un tarif unique au token perd discrètement de l’argent sur la seconde, à chaque fois.
Comment tarifer un produit d’IA à l’usage sans perdre sa marge ?
Un tarif forfaitaire au token ignore que les tokens d’entrée, les tokens de sortie, le contexte mis en cache et les appels de recherche portent des coûts différents, et que les gros utilisateurs se concentrent de façon disproportionnée sur les requêtes les plus coûteuses. Une tarification rentable sépare ces inducteurs de coût, valorise les tokens de sortie plus haut que ceux d’entrée là où l’écart est réel, et contrôle la marge brute par palier d’abonnement sur des données d’usage réelles, pas sur la requête moyenne que le modèle tarifaire supposait.
Pourquoi « au token » n’est pas un seul prix
Les fournisseurs de modèles facturent déjà les tokens d’entrée et de sortie différemment, souvent d’un facteur trois à cinq, parce que produire un token coûte plus de calcul que d’en lire un. Les produits qui revendent l’accès à un tarif unique mélangé héritent de cette asymétrie sans la facturer : un utilisateur qui pose des questions courtes et reçoit de longues réponses coûte plus par requête que la moyenne sur laquelle le tarif a été construit, et un utilisateur qui colle un long document pour obtenir une réponse d’un mot coûte moins. Sans suivre la répartition entrée/sortie par client, le modèle tarifaire devine une moyenne que peu d’utilisateurs réels atteignent.
Le contexte et la recherche font partie de la facture, pas des frais généraux
Chaque token de contexte envoyé au modèle, historique de conversation, documents récupérés, instructions système, est facturé comme un token d’entrée alors que l’utilisateur ne l’a jamais tapé. Une fonctionnalité qui conserve un long historique ou récupère plusieurs documents par question peut dépenser plus de tokens en contexte qu’en mots de l’utilisateur, et ce coût évolue avec des choix de conception produit, pas avec quoi que ce soit que le client contrôle. La mise en cache du contexte répété le réduit, mais elle a son propre coût d’infrastructure qu’un prix au token prend rarement en compte séparément.
Les gros utilisateurs ne consomment pas seulement plus, ils consomment autrement
Une tarification forfaitaire par siège ou par token suppose que l’usage se répartit uniformément dans la base de clients, et ce n’est jamais le cas. Une petite part des comptes porte en général une part disproportionnée des tokens, et ces comptes lancent souvent les types de requêtes les plus chers : longues fenêtres de contexte, chaînes d’agents à plusieurs étapes, tâches à forte production de tokens. Un modèle tarifaire rentable sur le client moyen peut être largement déficitaire sur le décile supérieur, et ce décile est justement celui qu’un produit en croissance a besoin de retenir.
Construire une marge brute défendable
Tarifer un produit d’IA sur de vraies unités économiques commence comme tout exercice TDABC : définir l’activité, un tour de conversation, un résumé de document, une tâche d’agent, et tracer les inducteurs de coût qu’une unité consomme réellement, séparément pour les tokens d’entrée, les tokens de sortie, les appels de recherche et toute remise liée au contexte mis en cache. Une fois ces éléments séparés, la marge brute peut être testée par palier d’abonnement sur le mélange d’usage que les clients réels produisent, et non sur celui que la grille tarifaire supposait. C’est ce qui transforme « nous facturons au token » en un chiffre que la finance peut défendre.
Un tarif unique au token facture la requête moyenne. Votre marge est décidée par les requêtes qui ne sont pas moyennes.
Ce qu’il faut vérifier avant la prochaine révision tarifaire
Avant d’ajuster un prix au token ou par utilisateur, vérifiez que la répartition entre tokens d’entrée et de sortie est mesurée par segment de clients et non supposée. Vérifiez que les coûts de contexte et de recherche sont affectés à la fonctionnalité qui les provoque, au lieu d’être dilués dans une ligne d’infrastructure partagée. Et vérifiez que la marge brute est contrôlée sur le décile le plus consommateur autant que sur la moyenne : un prix qui fonctionne en moyenne et échoue sur vos meilleurs clients est un prix qu’il faudra bientôt changer de nouveau.
Réservez une démonstration en direct de CostCtrl et voyez comment les coûts de tokens d’entrée, de sortie, de recherche et de relecture se rejoignent en une seule marge réelle par offre.
À lire également : la décision de prix avec l’IA et le coût à servir avec l’IA.