Tarification à l'usage

Quatre pièces, et une seule est une décision de prix

La tarification par siège demande combien de personnes utilisent le produit. La tarification à l'usage demande combien de travail ce compte nous a donné. Cela ressemble à une question commerciale et c'est surtout une question d'ingénierie, car le modèle comporte quatre pièces et trois d'entre elles sont des systèmes à construire avant de pouvoir annoncer un chiffre.

• L'unité — ce que vous comptez. Un appel, un message, un crédit, un actif généré, un gigaoctet, un enregistrement actif. Choisissez quelque chose auquel le client pense déjà, sinon chaque facture devient un exercice de traduction.
• Le compteur — le système qui enregistre chaque unité au moment où elle survient, par client, de façon assez durable pour facturer à partir de là. S'il manque ou s'il est approximatif, rien d'autre dans cette liste n'est possible.
• Le tarif — le prix à l'unité, presque toujours assorti d'une enveloppe incluse, pour qu'un mois calme ne devienne pas une facture vexante et un mois chargé pas une surprise.
• Le plafond — ce qui empêche un compte emballé de générer une facture que personne ne peut payer. Optionnel en théorie. Structurant en pratique, surtout là où un flux automatisé peut boucler.

Seul le tarif est une décision de prix. Les trois autres relèvent de l'infrastructure, et c'est pourquoi les équipes qui annoncent une tarification à l'usage avant d'avoir un compteur fiable finissent par discuter avec leurs clients de leurs propres factures.

Usage pur, hybride et crédits

Trois formes couvrent presque tout ce qui se lance aujourd'hui, et les écarts touchent votre prévision de revenus bien plus que votre client.

• Usage pur. On paie ce qu'on consomme, sans plancher. Honnête et inquiétant : le revenu est difficile à prévoir, et un mois calme pour votre client est un mois calme pour vous.
• Hybride. Un abonnement avec une enveloppe incluse, puis du dépassement au-delà. C'est la réponse courante, car elle vous donne un revenu prévisible et donne au client un plancher prévisible.
• Crédits. Le client achète un solde et les actions le décomptent. Populaire pour les produits d'IA parce qu'un seul chiffre couvre des actions aux coûts réels très différents, et parce qu'on peut retarifer un modèle sans retarifer les offres.

Les crédits portent un piège précis qu'il vaut mieux nommer : dès qu'un crédit devient l'unité que lit votre code de contrôle, chaque future décision d'arrondi et chaque taux de conversion se transforme en bug de facturation plutôt qu'en changement d'affichage.

Ce que nous avons appris en tarifant notre propre produit ainsi

AgentCeres — the AI Growth Officer, sur agentceres.com — mesure la dépense de modèle par client et la présente sous forme de crédits. Deux décisions en sont sorties, toutes deux à l'inverse de l'évidence.

La première : tout le grand livre fonctionne en devise, et les crédits n'existent qu'au dernier instant avant qu'un chiffre n'atteigne un écran. Chaque limite, chaque solde stocké, chaque ligne de facture est en devise ; une unique frontière de conversion en fait les crédits que voit le client. Cela ressemble à une indirection inutile jusqu'à ce qu'on réalise que l'alternative — contrôler en crédits — transforme une décision d'arrondi en bug d'argent, durablement et partout à la fois.

La seconde : notre enveloppe incluse n'est délibérément pas le prix de l'offre converti à notre propre taux. Une conversion exacte donnerait des enveloppes que personne ne retient, alors nous arrondissons au chiffre lisible supérieur et acceptons la marge que cela coûte — et nous avons écrit la raison juste à côté de la constante, pour que personne ne vienne la "ranger" plus tard. C'est ce qu'une page de tarifs ne montre jamais : le prix et l'enveloppe sont deux décisions et non une seule, et les traiter comme une seule est la raison pour laquelle les textes se périment dès que l'une des deux bouge.

Quand ne pas l'utiliser

La tarification à l'usage n'est pas automatiquement le choix le plus moderne. Quatre situations où un forfait fixe vaut simplement mieux :

• Votre coût marginal est proche de zéro. Si une action de plus ne vous coûte rien, la mesurer vous achète surtout un client qui regarde un compteur au lieu d'utiliser le produit.
• Votre acheteur a besoin d'un chiffre fixe. Les achats d'une entreprise de taille moyenne préféreront payer un peu trop de façon prévisible plutôt que défendre une facture variable chaque trimestre.
• Vous ne savez pas encore mesurer. Une estimation suffit pour un tableau de bord et disqualifie une facture.
• L'unité n'est pas sous le contrôle du client. Facturer quelque chose qu'il ne se voit pas déclencher passe pour arbitraire, aussi juste soit le calcul.

Si vous cherchez le chiffre plutôt que le modèle, comment tarifer un produit d'IA traite de la manière d'arriver à un tarif quand le coût sous-jacent bouge. Si c'est le compteur qui manque, Flexprice est un endroit open source pour voir ce que contient cette couche avant de la construire. Et si vous êtes ici parce que vous envisagez de construire l'agent entier vous-même, cette décision a sa propre page.