2 Commits

Author	SHA1	Message	Date
ordinarthur	f9cba50b5e	feat(billing,landing): plan Free 2 factures + scaffold preuves sociales/SEO ... Suite des chantiers structurants de landing-optimisations.md. #5 — Plan Free : 5 → 2 factures actives (cf. ADR-023) - PLAN_CAPS.free.activeInvoicesLimit dans apps/api/app/services/billing.ts - Tests unitaires alignés (4 → 1, 5 → 2 cap, delta 3 → delta 2) - billing:scenario command : commentaires + valeur par défaut - PlanLimitBanner : copy dynamique via {limit} au lieu de "5" hardcodé - /parametres/abonnement : H1 + tile Free (3 mois → 14 jours, 5 → 2) - billing.test.tsx (fixtures + cas test) - landing copy : hero feature pill, Pricing tile, FinalCTA, CGV §5 - CLAUDE.md pricing table #7 — Scaffold <TrustedBy /> (preuve sociale) - Composant qui render null tant que copy.trustedBy.{logos,testimonials} sont vides — pas de placeholder bidon. - Structure data dans copy.ts avec commentaires sur les prérequis avant d'ajouter une entrée (accord signé, photo, citation chiffrée). - Section insérée juste avant <Pricing /> (cf. doc §4). #8 — Plan articles SEO + brouillon article 1 - docs/marketing/seo-articles.md : 5 articles ciblés, mots-clés, structure type, lead magnet, calendrier 5 semaines. - Article 1 ("Modèle d'email de relance facture impayée") en brouillon complet, prêt à valider via l'admin blog (apps/api). #6 — Plan détaillé migration Stripe trial 14 j (code reporté) - docs/tech/stripe-trial-with-card.md : état actuel vs cible, architecture (Stripe Checkout + trial_period_days), modifs DB (trial_ends_at), API (start-trial + webhook trial_will_end), SPA (onboarding/billing), 3 emails transactionnels avec contenu intégral, risques + mitigations, plan d'exécution 2,5 j. - Implémentation reportée à une session focus avec accès Stripe test mode (cartes 3DS, webhook signing secret). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-18 10:38:52 +02:00
ordinarthur	4dcd85f912	test(billing): unit tests backend (17) + frontend (7) ... Backend (`apps/api/tests/unit/billing.spec.ts`) — 17 tests : - PLAN_CAPS sanity : Free 5 invoices/1 user, Pro illimité, Business 5 sièges - countActiveInvoices : • compte les 4 statuts actifs (pending, awaiting, in_relance, litigation) • exclut paid + cancelled • isolation par org (ne fuit pas entre orgs) - canCreateInvoices : • Free + grace period → autorisé même à 50+ actives • Free post-grace + 4 actives + delta=1 → autorisé (≤ limite) • Free post-grace + 5 actives + delta=1 → BLOQUÉ + bonne raison/limit/current • Free post-grace + 3 actives + delta=3 → BLOQUÉ (over par batch) • Pro + Business → toujours autorisé • paid n'occupe pas de slot (5 paid + delta=5 → autorisé) - getOrgSubscriptionState : • inGracePeriod=true quand date future • inGracePeriod=false quand date passée • Pro reflète subscription_status / billing_cycle / current_period_end • activeInvoicesCount inclut bien les 4 statuts Frontend (`apps/web/src/lib/billing.test.tsx`) — 7 tests : - useSubscription : appelle /billing/subscription, retourne le state - useIsAtFreeLimit : • false en loading • false sur Pro avec 200 factures • false en grace period même si activeCount > limit (12) • true sur Free post-grace + activeCount = limit (5/5) • true sur Free post-grace + activeCount > limit (8/5) • false sur Free post-grace + activeCount < limit (4/5) Setup : - vitest.config.ts : ajout de `env: {VITE_API_URL, ...}` pour stub les variables exigées par src/lib/env.ts au chargement (sinon plante au boot des tests). - Mock vi.spyOn(api, "get") pour éviter les vraies requêtes HTTP. - QueryClient avec retry:false pour fail-fast. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-07 16:43:40 +02:00