ADR-0037 — Les plans sont des paliers d'usage, pas des nombres de boutiques

Jusqu'au 2026-09-25, un plan limitait deux fois la meme valeur : un nombre de boutiques (Free 1, Pro 1, Max 5x 5, Max 20x 20, les noms « 5x / 20x » etant ce nombre) ET un budget de credits. Les sieges etaient deja…

Statut

Accepté · 2026-09-25

Piliers : billing, growth-web

Contexte

Trois consequences concretes :

une marque mono-boutique n'avait aucune raison de monter de palier, et un Pro qui voulait une seconde boutique etait envoye a Max 5x, puisque Free et Pro incluaient tous deux une boutique ;
l'add-on « +$9 par boutique » ajoutait une seconde facturation au nombre de boutiques, synchronisee par sept portes de creation et de suppression ;
la plateforme paie a l'usage (/admin/revenue/platform-costs) : une boutique connectee qui ne fait rien ne coute presque rien, un tour @Atlas coute toujours. La limite « boutiques » ne suivait pas le cout.

Sur PlanLimits, seuls stores et seats etaient appliques ; seize des vingt et un champs n'etaient lus par aucune porte.

Tranche backlog/billing/2988 le 2026-09-25 : option c.

Décision

Un plan est un palier de credits inclus et de capacites reellement appliquees. Boutiques et membres sont illimites sur tous les plans payants ; Free reste l'essai a une boutique et un membre. L'add-on boutique a $9 est retire. Aucun prix ni aucun montant de credits ne change, et les abonnements existants gardent leur Price Stripe.

Les paliers se distinguent par ce que le code applique, chaque ligne lue a sa source :

Capacite	Source
Prix, credits inclus	`PLAN_PRICING`
Bonus quotidien	`PLAN_DAILY_BONUS_USD`
Tours IA simultanes	`PLAN_AI_CONCURRENCY`
Workflows concurrents	`PLAN_USAGE_CAPS` (table par palier, sans lien avec les boutiques)
Appels MCP	`PLAN_MCP_RATE_LIMITS`
Minutes de scan	`PLAN_SCAN_MINUTES`
Skills premium (Max 5x+)	`features/ai/skills/skill-access.ts`
Profondeur Store Intelligence	`lib/hub/field-gate.ts` (`FEATURE_MIN_TIER`)
Detail affilie par filleul (Max 5x+)	`config/affiliate.ts`
WhatsApp, veille par l'extension (payant)	`requirePaidPlan` / `resolveEntitlement`

Les noms « Max 5x » et « Max 20x » restent, pour les abonnes existants ; ils ne comptent plus de boutiques et la copie ne les presente pas comme des multiples exacts de credits, puisqu'ils ne le sont pas.

PlanLimits ne garde que stores, seats et tokens (lu par GET /api/usage). Les champs sans lecteur sont supprimes plutot qu'appliques : on ne vend pas ce qui n'existe pas, et on n'invente pas d'application pour justifier une ligne.

Alternatives écartées

Option	Pourquoi non
a. Boutiques (statu quo)	Double limite avec les credits, sans lien avec le cout reel
b. Membres (sieges)	Pousse au partage de compte ; le premier client est souvent seul
d. Prix par boutique connectee + credits	Plus complexe a expliquer, et une boutique inactive ne coute rien
Garder l'add-on $9 a cote de boutiques illimitees	Il n'y a plus rien a vendre a l'unite
Gater la vente marketplace pour Free, comme la page le disait	Deux portes creent une annonce, dont une soumission publique ouverte aux anonymes (le tunnel `/sell`) : gater l'une seulement laisserait la page fausse, gater les deux est une decision du pilier marketplace. La page dit donc ce que le code fait : ouvert a tous

Conséquences

Argent. Un client paie moins pour plus de boutiques : un Pro qui voulait une seconde boutique n'a plus a payer $9/mois ni a monter en Max 5x. Le revenu de l'add-on disparait, et le revenu devient plus dependant de l'usage (credits, top-ups).
Etape operateur. Aucun code n'appelle plus Stripe pour la ligne extra-store. Un abonnement qui porte encore un item a ce prix continue d'etre facture jusqu'a ce qu'un operateur le retire dans le dashboard Stripe (avec ou sans prorata : choix). Le Price est a archiver. Cf. docs/business-model/plans.md, « Stores additionnels ».
Garde. billing-every-door.test.ts refuse qu'un fichier source nomme a nouveau l'add-on, et quota.test.ts tient boutiques et sieges illimites sur chaque palier payant.
Signal pour revisiter. Si le cout d'une boutique connectee cesse d'etre negligeable (ingestion, vecteurs, crons par boutique), une limite par boutique redevient defendable, et c'est a mesurer dans platform-costs avant de la reintroduire.

Was this page helpful?