Tarifer un SaaS dont chaque usage coûte des tokens : marge unitaire, quotas et paliers d'abonnement

---

title: "Tarifer un SaaS dont chaque usage coûte des tokens : marge unitaire, quotas et paliers d'abonnement" seoTitle: "Tarifer un SaaS qui consomme des tokens" description: "Un abonnement forfaitaire suppose que servir un client de plus ne coûte presque rien. Avec un LLM dans la boucle, c'est faux : les dix pour cent d'utilisateurs les plus actifs peuvent consommer plus que ce qu'ils paient. Voici comment calculer la marge unitaire, où placer le quota inclus et quelle structure de prix tient." seoDescription: "Marge unitaire, quota inclus, prix du dépassement : comment structurer le prix d'un SaaS dont chaque usage consomme des tokens, sans vendre à perte." date: "2026-10-11" author: "Équipe Raicode" tags: ["saas", "mvp", "IA", "architecture"] category: "SaaS & MVP" keywords: ["tarifer un SaaS IA", "marge unitaire SaaS LLM", "coût par utilisateur tokens", "quota inclus abonnement", "facturation à l'usage LLM", "pricing SaaS intelligence artificielle", "coût variable SaaS IA", "dépassement de quota SaaS"]

Votre plan Pro est à 49 € par mois. Il a été fixé en regardant trois concurrents, et il tenait très bien tant que le produit était un CRUD au-dessus d'une base Postgres : un client de plus coûtait quelques centimes de stockage et de bande passante. Depuis que chaque document déposé déclenche une extraction par un LLM, la phrase « un client de plus ne coûte presque rien » est devenue fausse, et personne dans l'équipe ne sait exactement à partir de combien de documents ce client devient déficitaire.

C'est la question que l'arrivée d'un modèle pose à la structure de prix, et c'est rarement celle qu'on traite en premier : on commence par essayer de faire baisser la facture d'API. C'est utile, mais c'est le second problème — un coût variable divisé par deux reste un coût variable, et une tarification qui l'ignore finira par vendre à perte à ses meilleurs utilisateurs. Le sujet ici n'est donc pas la réduction des coûts, mais la structure de prix — forfait, crédits, quota inclus, palier au-delà duquel on facture à l'usage — et le calcul de marge unitaire qui la décide.

Ce qui change quand le coût marginal cesse d'être nul

Le modèle économique du SaaS classique repose sur une marge brute de 75 à 85 %. Elle vient d'une propriété simple : le coût de servir un utilisateur supplémentaire est dominé par des charges fixes déjà payées. Les investisseurs, les comparateurs et vos propres projections de trésorerie supposent cette propriété.

Une fonctionnalité LLM la casse de trois façons.

D'abord, le coût suit l'usage et non le nombre de comptes : deux clients qui paient le même prix peuvent coûter dix fois moins et vingt fois plus que la moyenne. Ensuite, ce coût est non borné par défaut — rien, dans un produit qui n'a pas été conçu pour, n'empêche un utilisateur de déclencher mille traitements dans la nuit, ou un script de le faire à sa place. Enfin, il est volatil : un changement de modèle, un prompt système qui grossit, une étape de vérification ajoutée après un incident qualité, et le coût unitaire double sans qu'aucune ligne de la page de prix ne bouge.

La conséquence pratique : une page de prix devient une décision d'architecture produit. On ne peut pas annoncer un quota qu'on ne sait pas compter, ni facturer un dépassement qu'on ne sait pas attribuer à un client.

Calculer la marge unitaire : le seul chiffre qui compte

La marge unitaire est la différence entre ce qu'un client paie sur un mois et ce qu'il vous coûte réellement en variable sur ce mois. Pour la calculer, il faut d'abord choisir la bonne unité.

Ne comptez pas les appels d'API, comptez l'unité métier que l'utilisateur reconnaît : un document analysé, un ticket traité, une réunion résumée, une fiche produit générée. C'est la seule unité qu'on peut à la fois facturer, afficher dans un compteur et expliquer au téléphone. Un utilisateur comprend « 150 documents inclus ». Il ne comprendra jamais « 4 millions de tokens inclus », et vous ne voulez pas d'une conversation commerciale où il faut expliquer ce qu'est un token.

Ensuite, additionnez tout ce que cette unité déclenche réellement :

| Poste | Ce qu'on oublie systématiquement | | --- | --- | | Appel principal | Le prompt système, les exemples et le contexte injecté pèsent souvent plus que la donnée utilisateur | | Passes supplémentaires | Vérification, reformulation, extraction en deux temps, appel de garde-fou | | Reprises | Les tentatives après erreur, dépassement de limite de débit ou sortie invalide | | Travaux abandonnés | Les traitements que l'utilisateur lance puis jette : ils coûtent plein tarif | | Indexation | Embeddings, réindexation à chaque modification du document | | Stockage et traces | Journaux d'appels conservés pour l'audit, souvent volumineux |

Prenons un cas chiffré, celui d'un SaaS d'analyse de documents. Un document de douze pages représente environ 18 000 tokens d'entrée ; la passe de vérification en rajoute 6 000, et la sortie fait 2 500 tokens. Avec un modèle de milieu de gamme facturé 3 € le million de tokens en entrée et 15 € en sortie, on obtient 0,072 € d'entrée et 0,037 € de sortie, soit environ 0,11 €. En ajoutant 8 % de reprises et les travaux abandonnés, le coût d'un document traité s'établit autour de 0,12 €.

Ce chiffre seul ne dit encore rien. Il devient exploitable quand on le confronte au prix : sur un plan à 49 €, en visant 75 % de marge brute, le budget variable disponible est de 12 € par mois et par client, soit 100 documents. Toute la discussion de tarification tient dans la question suivante : combien de vos clients dépassent 100 documents par mois ?

Si vous ne savez pas répondre, le travail à faire n'est pas de choisir une structure de prix — c'est d'instrumenter. Chaque traitement doit écrire une ligne avec l'identifiant du client, l'unité métier, les tokens consommés et le coût estimé. C'est le même chantier de télémétrie que celui décrit dans notre article sur la facture d'API LLM qui explose, mais utilisé pour une autre décision : là-bas on cherchait où couper, ici on cherche où placer le curseur du prix.

La moyenne ment, la distribution décide

Le réflexe est de diviser la facture mensuelle du fournisseur par le nombre de comptes actifs. C'est le chiffre le plus trompeur du dossier, parce que la consommation d'une fonctionnalité IA n'est jamais répartie de façon symétrique.

Voici une distribution typique sur un parc de 120 comptes payants, avec notre coût de 0,12 € par document :

| Percentile | Documents par mois | Coût variable | Marge sur un plan à 49 € | | --- | --- | --- | --- | | Médiane | 22 | 2,64 € | 95 % | | Moyenne | 61 | 7,32 € | 85 % | | P90 | 180 | 21,60 € | 56 % | | P99 | 900 | 108 € | −120 % |

La moyenne raconte une histoire rassurante : 85 % de marge, le modèle tient. La distribution raconte la vraie histoire : les 10 % d'utilisateurs les plus actifs consomment une part de la facture totale largement supérieure à leur part du chiffre d'affaires, et une poignée de comptes coûte plus cher que son abonnement. Ces comptes sont généralement vos meilleurs clients en termes d'usage — ceux qui ont le plus adopté le produit, qui parlent de vous, et que vous ne voulez surtout pas punir.

Deux conséquences : la décision de prix se prend sur les percentiles, pas sur la moyenne, et le danger n'est pas le niveau actuel de la facture mais sa pente. Un produit qui gagne en adoption voit sa distribution se déplacer vers la droite ; une marge de 85 % qui devient 60 % en deux trimestres est un signal plus important que le total du mois.

Quatre structures, et ce que chacune fait à la marge

Le forfait pur par utilisateur

Simple à vendre, prévisible pour l'acheteur, et le choix par défaut de la plupart des équipes. Il ne tient que dans un cas : quand l'usage est naturellement borné par le temps humain. Un copilote de rédaction relu sortie par sortie a un plafond implicite ; un traitement par lot déclenché en un clic sur un dossier de 500 fichiers n'en a aucun. Le test tient en une phrase : si un utilisateur peut multiplier sa consommation par vingt sans multiplier son temps de travail par vingt, le forfait pur est un pari sur la modération de vos clients.

Le forfait avec quota inclus et dépassement à l'usage

La structure par défaut pour un SaaS à coût variable significatif, et celle que nous recommandons dans la grande majorité des cas : l'acheteur garde un prix de référence prévisible, vous gardez une borne, et les gros consommateurs financent ce qu'ils consomment. Elle a un prix d'entrée — un compteur fiable, visible dans le produit, et une politique claire du dépassement. Un quota qu'on ne peut pas consulter en temps réel génère plus de tickets de support qu'il ne protège de marge.

Les crédits prépayés

Adaptés aux usages en rafale — un cabinet qui traite trois cents dossiers en mars et vingt en août. Ils améliorent la trésorerie et déplacent la discussion vers la valeur d'un traitement. En contrepartie, il faut trancher l'expiration, le report et le sort des crédits non consommés : le revenu ne se reconnaît pas à l'encaissement.

La facturation à l'usage pure

Elle aligne parfaitement la marge, et c'est la plus difficile à vendre à une entreprise : un acheteur qui doit faire valider un budget refuse une facture qu'il ne peut pas annoncer à l'avance. Elle fonctionne sur des produits destinés à des développeurs, beaucoup moins sur un SaaS métier — en pratique, on la retrouve surtout comme composante du dépassement.

Où placer le quota, et à quel prix le dépassement

Trois règles qui évitent de refaire la page de prix six mois plus tard.

Placez le quota inclus entre le P75 et le P85 de votre distribution réelle. En dessous, trop de clients voient une ligne de dépassement dès le premier mois et perçoivent une facture piégeuse. Au-dessus, le quota ne protège plus rien. Dans notre exemple, le P80 tourne autour de 140 documents : un quota annoncé à 150, bien au-dessus des 100 documents que le prix finance à 75 % de marge, reste défendable parce que l'écart est financé par les comptes médians à 22 documents. Le quota ne se calcule pas par client, il se calcule sur le parc.

Fixez le prix du dépassement entre 2,5 et 4 fois le coût marginal. À 0,12 € de coût, un dépassement à 0,40 € le document donne 70 % de marge sur la partie variable et reste explicable. En dessous de 2 fois, le dépassement finance à peine le support qu'il génère ; au-delà de 5 fois, il est perçu comme une pénalité et pousse les clients à contourner le produit.

Posez deux plafonds, pas un. Un seuil souple qui notifie à 80 % du quota et laisse passer le dépassement en le facturant, et un plafond dur, très au-dessus, qui arrête le traitement. Le plafond dur ne protège pas la marge mais contre l'accident : la boucle d'un agent qui se rappelle lui-même, le script d'import relancé quarante fois, le compte compromis. Son déclenchement doit alerter votre équipe avant le client.

Quand l'arrêt net n'est pas acceptable, la dégradation gracieuse est une troisième voie : au-delà du quota, basculer sur un modèle moins cher ou passer en file d'attente asynchrone. L'utilisateur garde le service, votre coût unitaire baisse, et l'incitation à monter de plan reste.

Ce que la structure de prix impose au produit

Un prix à l'usage n'est pas une décision de page marketing : il s'appuie sur des mécanismes qui se construisent mal après coup.

Il faut un compteur d'usage — un journal d'événements en écriture seule, idempotent, portant l'identifiant du client, l'unité métier, les tokens consommés et le coût estimé. Idempotent, parce qu'une reprise réseau ne doit pas facturer deux fois le même document ; en écriture seule, parce qu'un litige de facturation se tranche sur des événements horodatés, pas sur un compteur qu'on a incrémenté puis corrigé à la main.

Il faut un rapprochement mensuel entre la somme des coûts de votre journal et la facture réelle du fournisseur. Un écart de 5 % est normal ; un écart de 40 % signifie qu'une partie de la consommation n'est attribuée à aucun client — tâches de fond, tests, préproduction qui tourne sur la clé de production.

Il faut enfin des droits lisibles par le produit : le code qui décide si un traitement part doit lire l'état de l'abonnement et la consommation du mois au même endroit. C'est exactement la fondation décrite dans notre article sur le multi-tenant et la facturation par abonnement — et la raison pour laquelle ces deux chantiers se traitent ensemble. Si vous en êtes au stade où le produit n'existe pas encore, c'est le bon moment pour les poser : c'est une partie de ce que nous cadrons dès la première semaine en développement de MVP et de SaaS, parce que rajouter un compteur fiable sur un produit qui facture déjà est un projet, pas une tâche.

Si au contraire la fonctionnalité IA est déjà en production et que la marge est déjà entamée, l'ordre est inverse : on instrumente, on mesure une distribution sur trente jours, puis on change le prix. Changer le prix sans la mesure revient à déplacer le problème d'un cran. C'est le premier livrable d'une reprise de projet IA : savoir ce que coûte réellement un client avant de décider quoi que ce soit.

Les leviers qui déplacent la marge sans toucher au prix

Avant d'augmenter le prix, trois leviers techniques changent le calcul.

Le cache de prompt s'applique à la partie stable du contexte — instructions système, exemples, documents de référence. Sur une fonctionnalité où 70 % des tokens d'entrée sont identiques d'un appel à l'autre, c'est presque toujours le gain le plus rapide à obtenir.

Le routage de modèle consiste à n'envoyer au modèle le plus cher que les étapes qui en ont besoin : classification, détection de langue, extraction de champs simples se traitent avec un petit modèle, et l'écart de prix entre gammes se compte en ordres de grandeur. L'erreur à éviter est de router sur l'intuition — il faut un jeu de cas et une mesure de qualité avant et après, sinon on échange une marge contre des régressions invisibles.

Le traitement par lot asynchrone est sous-utilisé : quand le résultat n'est pas attendu dans la seconde, les files de traitement différé des fournisseurs offrent des réductions substantielles pour un changement d'architecture modeste.

Un avertissement, enfin, sur les tarifs très agressifs : quand un fournisseur propose le même modèle à une fraction du prix habituel, lisez ce que les conditions disent de la réutilisation de vos données. Un gain de marge assorti d'une clause que vous ne pouvez pas répercuter à vos clients n'est pas un gain.

Trois erreurs qu'on retrouve dans presque tous les audits

Annoncer « illimité ». Le mot est un engagement commercial sur un coût non borné. Il se retire très mal : au moment où vous le remplacez par un quota, ce sont vos utilisateurs les plus engagés qui reçoivent la mauvaise nouvelle. S'il faut une formule généreuse, écrivez « usage raisonnable, dans la limite de X par mois » dès le premier jour.

Facturer au siège un coût qui suit l'usage. Un client qui ouvre vingt comptes utilisés dix minutes par semaine paie beaucoup et coûte peu ; un client à trois sièges qui automatise ses imports paie peu et coûte beaucoup. Si votre unité de facturation n'est pas corrélée à votre unité de coût, votre marge dépend du hasard de votre portefeuille.

Découvrir la marge dans le tableur du comptable. Le coût variable par client appartient au produit, pas à la clôture mensuelle. Un tableau de bord qui affiche la marge par compte et par plan transforme une surprise de fin de trimestre en décision de fin de semaine — même logique que pour lire un devis de MVP : le chiffre important n'est pas le total, c'est ce qui le compose.

Par où commencer

1. Choisissez l'unité métier que vous factureriez si vous deviez le faire demain — un document, un ticket, une conversation.
2. Instrumentez chaque traitement avec l'identifiant du client, l'unité, les tokens et le coût estimé, puis laissez tourner trente jours.
3. Sortez la distribution, pas la moyenne : médiane, P75, P90, P99, et la part du total consommée par les 10 % les plus actifs.
4. Calculez votre budget variable par plan à partir de la marge brute visée, et comparez-le au P80.
5. Posez le quota, le prix du dépassement et les deux plafonds, puis annoncez le changement avec un mois de préavis et un rapport d'usage personnalisé envoyé à chaque client concerné.

Une tarification qui tient n'est pas celle qui maximise le prix affiché : c'est celle dont vous connaissez la marge sur chaque segment d'usage, et qui reste vraie quand le produit gagne des utilisateurs. Le travail commence par la mesure, et il ne prend que quelques jours.

---

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