Roadmap d'implémentation
Statut d'implémentation (2026-10-02). Ce document décrit un modèle cible, pas ce que la plateforme fait. Ce que le code fait aujourd'hui : frais marketplace vendeur 3 % (BOOSTECOM_MARKETPLACE_FEE_RATE…
Statut d'implémentation (2026-10-02). Ce document décrit un modèle cible, pas ce que la plateforme fait. Ce que le code fait aujourd'hui : frais marketplace vendeur 3 % (
BOOSTECOM_MARKETPLACE_FEE_RATE,src/types/marketplace.ts), parrainage 30 % sur 12 factures versé en argent sans minimum (affiliate.md), boutiques illimitées sur les plans payants (ADR 0037), add-on boutique retiré. Non implémentés : take rate marketplace 25 %, split agents/workflows 80/20, bounty 70/30, cash-out 75 $ et minimum vendeur 50 $, Partner tier 35 % sur 6 mois, commission sur achats de crédits (10 % ou 15 %), remise de 10 % sur le premier mois d'un filleul. Les lignes concernées ci-dessous sont marquées « non implémenté » ou « historique ».
Phases d'implémentation du business model. Chaque item est checkable. Status : à coder / en cours / livré.
Légende
- 🔴 À coder (pas commencé)
- 🟡 En cours
- 🟢 Livré
- ⚪ Reporté / différé
Phase 1 — Pivot v2.0 (livré) puis v3.0 (en cours)
v2.0 livré : Pro $49 / Max 5x $149 / Max 20x $299 avec 50% credits + caps usage par session. v3.0 livré (2026-05-12) : credits 1.0× du sub + daily bonus per-Org ($1/$3/$5) + caps msg/5h supprimés + stores extras $9 + ecosystem ajusté (cible, non implémentée : M9+ 25%, runs 80/20 ; le code facture 3 % côté marketplace). Les 13 workstreams v3.0 sont livrés ; le résiduel ouvert vit dans le backlog (
backlog/billing/0006dashboard breakdown store/agent,backlog/billing/0007setup Stripe opérateur).
| # | Item | État | Notes |
|---|---|---|---|
| 1.1 | Paid-plan gate sur chat / workflow / workspace | 🟢 | requirePaidPlan + paidPlanRequiredResponse (commit 09f3179) |
| 1.2 | Paid-plan gate sur credit purchase | 🟢 | Commit 09f3179 |
| 1.3 | Paid-plan gate sur affiliate redeem | 🟢 | Commit 09f3179 |
| 1.4 | Paid-plan gate sur daily bonus | 🟢 | Commit 09f3179 |
| 1.5 | UI paywall workspace + workflow | 🟢 | <PaidGate> + <UpgradeWall> (commit 084c263) |
| 1.6 | Refonte plans dans billing-plans.ts | 🟢 | Type Plan élargi avec pro/max-5x/max-20x, PLAN_PRICING + PLAN_LIMITS + PLAN_USAGE_CAPS ajoutés. "unlimited" gardé comme alias rétro-compat |
| 1.7 | Cron reset-credits : credits = 100% du sub (le 50% v2.0 a été annulé par la v3.0) | 🟢 | Le cron lit PLAN_PRICING[plan].includedCredits. Sous v3.0, à 1.0× du prix : Pro $49, Max 5x $149, Max 20x $299. Depuis v4.0 (ADR 0012) ce sont les mêmes montants ($49/$149/$299), mais fixes et découplés du prix, qui a lui monté. Cette ligne a annoncé « 50% » et « $24.50 » en 🟢 alors que le code n'a jamais eu ces valeurs en v3.0 |
| 1.8 | Caps usage par tier (Upstash sliding window) | 🟢 | Session cap câblé dans handler.ts via rateLimit(chat:session:orgId, caps.sessionMessages, 5h). 429 avec message + retryAfter quand atteint. Opus/workflow caps à activer plus tard quand tools-level metering en place |
| 1.9 | 🔴 | Abandonné le 2026-09-06. Cette ligne était 🟢 parce qu'une constante était exportée, et une constante exportée que rien n'appelle ne facture personne : CREDIT_PURCHASE_MARKUP = 2.0 n'a jamais eu de lecteur, et le calculateUserPriceForPurchase de la case « à utiliser dans purchase route » n'a jamais été écrit. Le markup est porté par le plan, 1.5×, quelle que soit l'origine du credit (ADR 0010). Facturer les achats plus cher est une hausse de prix : billing/0411 | |
| 1.10 | Min achat du slider credits | 🟢 | CREDITS_PURCHASE_CONFIG.minAmount = 10 : le $25 de la v2.0 est revenu à $10 en v3.0, cette ligne annonçait encore $25 |
| 1.11 | Stripe price IDs : Pro/Max5x/Max20x mensuel + annual | 🟡 | Schema env + config plans.ts en place. 6 price IDs à créer dans Stripe Dashboard puis renseigner dans Vercel env vars (NEXT_PUBLIC_STRIPE_PRO_MONTHLY, etc.) |
| 1.15 | UI plan picker 3 cards (4 avec Free) | 🟢 | Pricing page lit PLANS.filter(!hidden) → affiche Free / Pro / Max 5x / Max 20x / Custom. Legacy "unlimited" caché |
| 1.12 | Supprimer le daily bonus | 🟢 | Route DELETE, marketing UI cleaned, schéma DB conservé pour rétro-compat |
| 1.13 | Rate-limit MCP free Upstash 100/min, 5k/jour | 🟢 | applyMcpRateLimit() au top des handlers POST/GET |
| 1.14 | UI paywall sur le chat input (free user voit l'upsell) | 🟢 | 402 (paid plan required) + 429 (session cap hit) handlés dans guardedFetch du chat — banner upsell avec requiredAction: "upgrade_plan" dispatch via CustomEvent boostecom:credits-exhausted |
| 1.15 | UI plan picker 3 cards (Pro/Max5x/Max20x) | 🔴 | Comparison clear, default Pro |
| 1.16 | UI usage caps display (sessions remaining, Opus today, etc.) | 🟡 | API endpoint /api/usage/caps créé (renvoie limit / Opus/jour / workflows simultanés du tier). Composant badge à brancher dans le shell chat — utiliser le payload de 429 pour live remaining. Foundation prête |
| 1.17 | Per-conversation $ cap ($X.XX configurable) | 🟢 | MAX_PER_CONVERSATION_USD ($10 default, env override). Abort sur runningCost >= cap dans onStepFinish |
| 1.18 | Audit log sur tout write Shopify (mutation GraphQL) | 🔴 | Compliance + rollback prep |
| 1.19 | Confirmation modal avant action destructive (delete, theme push) | 🔴 | UX safety |
| 1.20 | Theme Live runtime protection (refuser publish dans le code, pas juste rule) | 🟢 | updateThemeFile query la role MAIN avant write, refuse sauf allowLive: true |
| 1.21 | Idempotency keys sur tous les writes Shopify | 🔴 | Data integrity |
| 1.22 | CGV + Privacy Policy + DPA rédigés (avocat) | 🔴 | Legal launch blocker |
| 1.23 | Sentry configuré + alerts sur error rate | 🔴 | Operational |
| 1.24 | Database backup test (restaurer un snapshot Neon) | 🔴 | Disaster recovery |
| 1.25 | Test cross-org data leak (automatisé) | 🔴 | Tenancy guarantee |
| 1.26 | Daily org $ cap user-defined | 🔴 | Trust building |
| 1.27 | OAuth Authorization Code grant fallback Shopify | 🔴 | Future-proof si Shopify retire client_credentials |
| 1.28 | AI Gateway fallback Anthropic → GPT-5.4 sur 5xx errors | 🟢 | Câblé dans streamText({ providerOptions.gateway.models: [primary, fallback] }). AI Gateway gère le retry transparent quand le primary 5xx |
| 1.29 | DELETE legacy BRAIN_MODELS + ModelSelector legacy switcher | 🟢 | Supprimé (les vrais modèles vivent dans UI_MODELS du nouveau chatbot home — voir model-curation.md) |
| 1.30 | Verifier IDs UI_MODELS pointent sur les bonnes versions Claude | 🟡 | Test runtime requis — les alias claude-sonnet-4/claude-opus-4 sont résolus par AI Gateway. À monitorer dans les logs production |
| 1.31 | Implémenter resolveModelForAuto() server-side | 🟢 | client.ts + handler.ts. Commit 0777f2c |
| 1.32 | Respect strict des choix user | 🟢 | handler.ts ligne ~358 : si clientModel.includes("/"), utilisé tel quel. Seul atlas-auto déclenche le résolveur. Commit 0777f2c |
| 1.33 | Update PROVIDER_COSTS avec prix Anthropic actuels | 🟢 | Remplacé : les prix sont DÉRIVÉS du catalogue (src/config/ai-models.ts), ne plus les recopier ici. Ce qui y était écrit (Haiku 4.5, Sonnet 4.6, Opus 4.6 à $15/$75) est périmé depuis septembre 2026 |
| 1.34 | Routing auto Haiku pour agents dispatch | 🟢 | Détection ^@(maya|marco|otis|faye|sam|atlas) + texte court → @Atlas Mini (GPT 5.6 Luna depuis 2026-09-25). Couvert dans resolveModelForAuto |
| 1.35 | Markup ajustable clause dans CGV | 🔴 | Hedge contre hausse providers — légal, à rédiger avec avocat |
| 1.36 | Image generation flow validé (Gemini Nano Banana) | 🟢 | Confirmé : handler.ts:696 utilise google/gemini-3.1-flash-image-preview quand uiGenerateImages toggle on |
Phase 2 — Pricing UI complet
Active le plan picker, les achats crédits, et les notifications.
| # | Item | État | Notes |
|---|---|---|---|
| 2.1 | retiré | ADR 0037 : boutiques illimitées sur les plans payants, l'add-on n'existe plus | |
| 2.2 | UI input libre crédits ($10-$5000) avec preview margin | 🔴 | Existe partiellement, à raffiner |
| 2.3 | UI annual toggle gated J+30 | 🔴 | Flag check sur subscription.createdAt |
| 2.4 | Settings → Subscription : upgrade/downgrade tier | 🔴 | Self-serve |
| 2.5 | Email notification : crédits faibles ($X restant) | 🔴 | Threshold configurable |
| 2.6 | Email notification : caps session atteint (push upgrade) | 🔴 | Critique pour conversion Pro→Max |
| 2.7 | Email notification : crédits épuisés (top-up ou attente next cycle) | 🔴 | Service Resend |
Phase 3 — Affiliate program
Active la première vraie source d'acquisition organique.
| # | Item | État | Notes |
|---|---|---|---|
| 3.1 | Stripe Connect Express setup | 🔴 | Activer dans Stripe dashboard |
| 3.2 | API : créer un code affilié | 🔴 | POST /api/affiliate/codes |
| 3.3 | API : list codes + stats par code | 🔴 | Dashboard data |
| 3.4 | UI dashboard affilié (filleuls actifs, MRR commissions, payouts) | 🔴 | New page /account/affiliate |
| 3.5 | Commission ledger : 30% subs sur 12 factures (la ligne credits 15 % n'est pas implémentée) | 🔴 | Webhook Stripe → AffiliateCommission table |
| 3.6 | Schéma DB : ajouter AffiliateCommission(affiliateId, sourceType, amount, payoutAt) | 🔴 | Migration Prisma |
| 3.7 | Cron payout mensuel (1er du mois) | 🔴 | Stripe Connect transfers |
| 3.8 | Cap $5000/mo + manual review queue | 🔴 | Admin alert si hit |
| 3.9 | -10% premier mois pour filleuls (Stripe coupon) | 🔴 | Non implémenté, aucun coupon n'est créé à l'usage du code |
| 3.10 | Anti-fraud : détection same-IP / same-card | 🔴 | Stripe Radar rules customs |
Phase 4 — Marketplace foundation
Schéma DB et API. Pas exposé publiquement.
| # | Item | État | Notes |
|---|---|---|---|
| 4.1 | Schéma DB : Item, ItemVersion, ItemListing | 🔴 | Migration Prisma |
| 4.2 | Schéma DB : MarketplaceOrder, SellerPayout | 🔴 | Migration Prisma |
| 4.3 | API : seller onboarding (Stripe Connect Express) | 🔴 | KYC requis avant first listing |
| 4.4 | API : create / update / publish item | 🔴 | Avec modération queue |
| 4.5 | API : list items (filtres, search, categories) | 🔴 | Pas exposé public M3-M6 |
| 4.6 | API : purchase item (one-shot, sub, per-run) | 🔴 | Charge en crédits ou euros |
| 4.7 | API : payout seller (Stripe Connect transfer) | 🔴 | Cron hebdomadaire ou on-demand |
| 4.8 | Modération queue admin | 🔴 | Approve/reject premier item par seller |
| 4.9 | Audit trail des transactions marketplace | 🔴 | auditBilling() events |
| 4.10 | Anti-fraud : userId !== sellerId enforced | 🔴 | Validation à l'achat |
Phase 5 — Marketplace public (M9+)
Activation publique du marketplace.
| # | Item | État |
|---|---|---|
| 5.1 | UI publique du marketplace (route /marketplace) | 🔴 |
| 5.2 | UI seller dashboard (mes items, ventes, payouts) | 🔴 |
| 5.3 | UI buyer flow (panier, checkout, library d'items achetés) | 🔴 |
| 5.4 | Reviews + ratings (1 review par buyer vérifié) | 🔴 |
| 5.5 | Featured slots system (admin curation) | 🔴 |
| 5.6 | Categories navigation | 🔴 |
| 5.7 | Search + filtres | 🔴 |
| 5.8 | Refund flow buyer (7 jours money-back si seller flagué) | 🔴 |
| 5.9 | Take rate switch invite-only 0% → public 25% (le code facture 3 %) | 🔴 |
Phase 6 — Agent / Workflow runs
Mécanique différenciante : monétisation des agents et workflows par leurs créateurs.
| # | Item | État |
|---|---|---|
| 6.1 | Schéma DB : PublishedAgent, AgentSubscription, AgentRun | 🔴 |
| 6.2 | Schéma DB : PublishedWorkflow, WorkflowSubscription, WorkflowRun | 🔴 |
| 6.3 | API : publish agent custom | 🔴 |
| 6.4 | API : publish workflow | 🔴 |
| 6.5 | API : per-run billing en crédits avec split 75/25 | 🔴 |
| 6.6 | UI : publier un agent/workflow | 🔴 |
| 6.7 | UI : explorer les agents/workflows publics | 🔴 |
| 6.8 | UI : installer un agent/workflow dans son espace | 🔴 |
| 6.9 | Anti-fraud : self-runs detection (orgId !== creatorOrgId) | 🔴 |
| 6.10 | Anti-fraud : volume anormal (>100x baseline → alert) | 🔴 |
Phase 7 — Community
Bounty program, partner tier, sponsored slots.
| # | Item | État |
|---|---|---|
| 7.1 | Bounty backoffice : poster une bounty, manager la queue | 🔴 |
| 7.2 | Bounty user UI : voir les bounties dispos, claim | 🔴 |
| 7.3 | Bounty payout (crédits ou cash via Stripe Connect) | 🔴 |
| 7.4 | Partner tier onboarding (manuel, max 50) | 🔴 |
| 7.5 | Partner tier dashboard (35% commission 6 mois, non implémenté) | 🔴 |
| 7.6 | Sponsored slots system (featured items, agents, newsletter) | 🔴 |
| 7.7 | Sponsored billing (Stripe Subscription weekly) | 🔴 |
Timeline indicative
| Phase | Durée | Cible |
|---|---|---|
| Phase 1 | 2-3 jours | Avant lancement public (M0) |
| Phase 2 | 1-2 semaines | Lancement public (M0) |
| Phase 3 | 1-2 semaines | M1 |
| Phase 4 | 2 semaines | M2-M3 |
| Phase 5 | 1 mois | M9 |
| Phase 6 | 2-3 semaines | M6 |
| Phase 7 | Continu | M3+ |
Décisions critiques en attente
Ces points doivent être tranchés avant la phase concernée.
| Décision | Phase | Deadline |
|---|---|---|
| Slider step minimum : $9 ou $19 ? | 2 | Avant Phase 2 |
| Marketplace take rate (le code facture 3 % fixe) : 25% ou variable par catégorie ? | 4 | Avant Phase 4 |
| Reviews : 1-5 stars ou seulement positive (👍 vibe) ? | 5 | Avant Phase 5 |
| Sponsored slots : à quelle audience activer ? | 7 | M9-M12 |
| Daily bonus permanent : activer si churn > X% à M6 ? | n/a | M6 review |
Anti-patterns à éviter
- Lancer la Phase 5 avant la Phase 4 : marketplace public sans foundation = chaos modération
- Activer Phase 3 sans Stripe Connect : pas de payouts = perte de confiance affiliés
- Activer le marketplace public avant 50+ items : ghost town effect, mauvaise première impression
- Skip Phase 1.6/1.7/1.8 : marge dégradée + DoS possible = dette critique
- Coder Phase 6 avant Phase 4 : agent runs sans marketplace = fonctionnalité orpheline
Mise à jour de cette roadmap
À chaque livraison :
- Cocher l'item dans la table phase concernée (🔴 → 🟢)
- Ajouter le commit hash en colonne "Notes"
- Si timeline glisse, mettre à jour la timeline indicative + commenter pourquoi
- Si découverte d'une nouvelle Phase nécessaire, ajouter une section + bumper version README
Was this page helpful?