ADR-0012 — Le prix de l'abonnement se decouple du grant de credits

Statut

Accepté · 2026-09-06

Piliers : billing, growth-web

Contexte

Le catalogue v3.0 vendait chaque tier payant comme rendant 100% de son prix en credits : Pro $49/mo -> $49 de credits, Max 5x $149/mo -> $149, Max 20x $299/mo -> $299 (PLAN_PRICING, src/types/billing-plans.ts). Trois defauts, mesures plutot que supposes :

1. Zero marge fixe sur la subscription elle-meme. Le seul mecanisme de marge etait le sous-usage du pool de credits (hypothese modelisee a 50%/40%/25% d'utilisation selon le tier dans financial-model.md). Une organisation qui consomme reellement son pool en entier ramene la marge de cette subscription a zero avant meme de compter Stripe et l'infra — le modele entier reposait sur l'hypothese que la majorite des clients sous-consomment, jamais sur une marge garantie par construction.
2. La runway d'un power user est courte, et le catalogue ne le disait pas. $49 de credits sur Pro, aux tarifs retail du repo (src/config/model-pricing.ts : Sonnet $3/$15 pour 1M tokens, Opus $7.5/$37.5), s'epuise en quelques jours pour un utilisateur qui "rush" comme la plupart des utilisateurs d'outils IA agentiques — chaque tour d'audit ou de scan appelle une dizaine d'outils (navigation, extraction, lecture DOM) avant de repondre, et un tour Opus complexe peut a lui seul couter l'equivalent de plusieurs dollars de credits. Vendre "$49 de credits" a cote de "$49/mo" invite a lire les deux comme equivalents en duree d'usage, alors que le second s'epuise en une fraction du mois pour l'usage reel que le produit encourage.
3. Positionnement generique dans un marche qui vend deja plus cher pour moins. Benchmark concurrentiel fait le 2026-09-10 : l'outil "spy" mono-feature de reference du marche (une fraction de ce que couvrent les Systems de ce depot — AEO, CRO, vitals, tracking, intelligence, marketplace, studio), facture Starter $59/mo, Pro $89/mo, Business $149/mo. Un Pro BoostEcom a $49/mo pour un operateur IA complet (chat + audit + marketing + merchandising + ops + intelligence + marketplace) se vendait donc sous le prix d'un outil qui fait un dixieme du travail. Categorie adjacente (copilotes IA generiques, off-the-shelf) : $20-30 /utilisateur/mo — non comparable, ce sont des sieges sur un outil passif, pas un operateur qui execute. La categorie pertinente est celle des agents verticaux qui remplacent un role : ces produits ne se vendent jamais au prix ou au grant qu'ils consomment en interne, ils se vendent a la valeur du travail remplace.

Décision

Le prix de l'abonnement et le grant de credits inclus sont deux nombres independants dans PLAN_PRICING. Le prix monte (Pro $79/mo, Max 5x $199/mo, Max 20x $399/mo — ADR non retroactive, les figures completes sont dans financial-model.md), le grant de credits reste exactement ce qu'il etait sous v3.0 ($49 / $149 / $299 respectivement). Rien ne change dans le ledger, le systeme de credits, le markup de consommation (1.5×, ADR 0010) ou le solde d'un abonne existant : seul ce que le plan facture bouge.

Consequence mecanique directe : la subscription porte desormais une marge FIXE, garantie avant meme de savoir combien l'organisation va consommer — le probleme (1) du contexte. Chiffrage complet dans financial-model.md : marge sub Pro 52% -> 69%, Max 5x 62% -> 71%, Max 20x 74% -> 80%, consolide 62% -> 68% gross.

Alternatives écartées

Conséquences

• Toute copy qui affirmait "prix = credits 1:1" est fausse et devait etre reecrite : pricing.subtitle, la FAQ credits/tokens, les hints de la matrice de comparaison et des cartes de plan, dans les six locales. Le bloc credits dedie sur /pricing (model-pricing-cards.tsx) est supprime plutot que reecrit : il n'existait que pour raconter cette equivalence, et la matrice de comparaison + les cartes de plan portent deja le montant de credits sans lui.
• Le levier "Pricing Pro $59 / Max 5x $169 / Max 20x $329" dans la section "Leviers d'ajustement" de financial-model.md est obsolete : c'etait un levier de BAISSE de prix sous l'hypothese v3.0 ou baisser le prix baissait aussi le grant. Sous v4.0, baisser le prix sans toucher au grant est le mouvement inverse de cette decision, a documenter separement si jamais envisage.
• La marge desormais garantie ne dispense pas de la marge de sous-usage du pool : les deux s'additionnent, elles ne se substituent pas. Le modele financier recalcule les deux dans le meme tableau.
• Aucun changement pour un abonne existant : meme grant, meme balance, meme date de reset. Le prix affiche au renouvellement suit le nouveau catalogue comme tout changement de PLAN_PRICING — pas de migration de donnees requise.
• Le signal qui imposerait de revisiter ce choix : une chute mesurable de la conversion Free -> Pro suite au repricing (a suivre via billing_checkout_open vs conversions reelles), qui indiquerait que $79/mo depasse ce que le segment vise est pret a payer sans avoir encore vu la valeur de l'operateur complet.

Comment c'est appliqué

• src/types/billing-plans.ts — PLAN_PRICING est la seule source ; monthlyPrice et includedCredits sont deux champs independants du meme record, sans formule reliant l'un a l'autre.
• src/test/pricing-matches-enforcement.test.ts — encode desormais l'inverse de l'ancienne regle : le grant est verrouille aux montants v3.0 ($49/$149/$299) ET le prix doit rester strictement superieur au grant sur chaque tier paye, pour qu'un futur changement ne puisse pas re-coupler silencieusement les deux.
• src/test/financial-model-margins.test.ts — recalcule le tableau d'achat de credits et le total du mix depuis le code ; ne couvre pas (encore) les trois tableaux de marge par tier, recalcules a la main dans cette revision et a refaire a la main au prochain changement de prix tant qu'aucun garde ne les derive.
• pnpm docs:claims — pin les prix publies dans CLAUDE.md, docs/business-model/plans.md et content/docs/en/plans-and-limits.mdx sur PLAN_PRICING.