docs(audit-1/3): aligner top-level + produit sur le code

Issu d'un audit de cohérence doc-vs-code. Corrige les claims périmés
sur le périmètre V1, la nomenclature des plans, les statuts de
facture et les sources typographiques.

CLAUDE.md
- IN/V1 : ajout Microsoft SSO + Stripe billing + mode démo (livrés)
- IN/V1 : « admin blog (à venir PR3) » → admin blog livré
- IN/V1 : 4 plans nommés concrètement (Standard B2B, Rapide, Patient,
  Ferme) au lieu de la mention vague « 4 plans fournis »
- Glossaire : « Check-in » → « Confirmation » (terme migré dans
  flow.md depuis ADR-008, alignement)
- Brand identité : typo Bricolage + Inter sont self-hosted via
  @fontsource-variable, pas Google Fonts via <link>
- Brand : lien `/brand-identity.html` → `/docs/brand-identity.html`
  (chemin réel) + retrait du caveat « or accent obsolète » (HTML
  sera nettoyé dans le batch brand)
- Bumpé la dernière maj 2026-05-07 → 2026-05-09

docs/produit.md
- §4.1 : ajout Microsoft SSO
- §4.3 : 4 plans réels (Standard B2B / Rapide / Patient / Ferme),
  variables Mustache réelles ({{client.name}}, {{amount}},
  {{dueDate}}), tons réels (amical | courtois | ferme |
  mise_en_demeure)
- §7 : trial commercial 30 jours (vs 14j historique). Note
  l'incohérence avec la « grâce 3 mois » dans billing.ts à fixer
  dans un PR séparé
- §8 : statut `relanced` → `in_relance` (constants/index.ts) +
  « check-in » → « confirmation »
- Header bumpé 2026-05-05 v0.1 → 2026-05-09 v0.2

docs/flow.md
- §6.1 : tons d'étapes corrigés (était amical|ferme|stricte —
  réel : amical|courtois|ferme|mise_en_demeure)
- Slug exemple : `standard-b2b` → `standard-30j` (réel)

docs/wireframes-mvp.html
- Compteur « 13 écrans » nuancé : c'était le scope low-fi initial,
  la SPA livrée en compte ~15 + onboarding multi-étapes

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CLAUDE.md

@@ -36,12 +36,12 @@ TPE-PME françaises, 5 à 50 salariés, qui émettent 10 à 200 factures par moi
 | **Couleur primaire** | `#9F1239` — rubis profond légèrement violacé. *Anti-Coca-Cola.* |
 | **Couleur secondaires** | `#771328` (deep), `#C9415C` (light), `#FBE4EA` (glow) |
 | **Neutres** | Crème `#FAF7F2`, encre chaude `#1A1410`. Jamais de blanc pur, jamais de noir pur. |
-| **Typo display** | Bricolage Grotesque (500–800), Google Fonts |
+| **Typo display** | Bricolage Grotesque (500–800), self-hosted via `@fontsource-variable/bricolage-grotesque` |
-| **Typo body** | Inter (400–700), Google Fonts |
+| **Typo body** | Inter (400–700), self-hosted via `@fontsource-variable/inter` |
 | **Icônes** | Lucide (regular weight) |
 | **Pas de** | or, bleu, vert, violet, emojis joaillerie 💎💰, mot "recouvrement" en com publique |
 
-Voir `/docs/marque.md` pour la référence complète et `/brand-identity.html` pour la présentation visuelle (note : la mention de l'or accent dans ce fichier est obsolète, à ignorer).
+Voir `/docs/marque.md` pour la référence complète et `/docs/brand-identity.html` pour la présentation visuelle.
 
 ## Voix
 
@@ -55,7 +55,7 @@ Direct, concret, chaleureux, précis, empathique. *On parle comme un bon associ
 - **Rubis** : unité de gamification. **1 rubis = 10 minutes libérées** = 1 relance qu'on n'a pas eu à faire à la main.
 - **Plan de relance** : cadence d'emails automatisés (ex. J+3, J+10, J+20). Chaque facture est associée à un plan.
 - **Étape** : un email programmé dans un plan (ex. "J+10 — relance ferme").
-- **Check-in** : email envoyé **à l'utilisateur** (pas au client) pour confirmer si une facture a été payée avant l'envoi de la prochaine relance. Remplace l'intégration banking en V1.
+- **Confirmation** *(anciennement « check-in »)* : email envoyé **à l'utilisateur** (pas au client) pour confirmer si une facture a été payée avant l'envoi de la prochaine relance. Remplace l'intégration banking en V1.
 - **Mise en demeure** : étape ferme du plan. **Toujours sous validation manuelle** via modale de confirmation, jamais auto.
 - **DSO** : Days Sales Outstanding. Métrique secondaire dans l'app, jamais dans la com publique.
 - **LME** : loi de modernisation de l'économie (2008). Plafonne les délais de paiement à 60 jours (ou 45 jours fin de mois). Sanctions DGCCRF jusqu'à 2 M€.
@@ -64,18 +64,20 @@ Direct, concret, chaleureux, précis, empathique. *On parle comme un bon associ
 
 ### IN
 
-- Auth email/password + Google SSO
+- Auth email/password + Google SSO + Microsoft SSO
 - Onboarding 3 étapes (compte, entreprise, signature email)
 - Upload drag-and-drop + OCR factures (PDF, PNG, JPG)
 - Saisie manuelle (fallback)
-- Bibliothèque de plans (4 plans fournis par défaut)
+- Bibliothèque de plans (4 plans fournis par défaut : *Standard B2B*, *Rapide*, *Patient*, *Ferme*)
 - Éditeur de plan (cadence + templates email avec variables)
-- Check-in email à l'utilisateur (cadence configurable) → confirme si payé → relance ou stop
+- Confirmation par email à l'utilisateur (cadence configurable) → confirme si payé → relance ou stop. *Anciennement « check-in ».*
 - Dashboard avec compteur rubis + KPIs (à relancer, encaissé, DSO)
 - Liste filtrable des factures
 - Détail facture avec timeline des relances
+- Stripe billing (checkout, portal, webhook) + période de grâce post-signup
+- Mode démo (sandbox in-app sans engagement)
 - App mobile (web responsive)
-- **Blog `rubis.pro/blog`** — SSR par `apps/landing` (Astro 6), contenu en DB (`posts`) servi par `apps/api` via `/api/v1/posts/*`, admin de validation côté `app.rubis.pro/admin/blog` (à venir PR3), génération hebdomadaire IA via cron (Sonnet 4.6) avec review humaine obligatoire. Détails dans `/docs/tech/architecture.md`.
+- **Blog `rubis.pro/blog`** — SSR par `apps/landing` (Astro 6), contenu en DB (`posts`) servi par `apps/api` via `/api/v1/posts/*`, admin de validation côté `app.rubis.pro/admin/blog`, génération hebdomadaire IA via cron (Sonnet 4.6) avec review humaine obligatoire. Détails dans `/docs/tech/architecture.md`.
 
 ### OUT (V2 ou plus tard)
 
@@ -180,4 +182,4 @@ Détails dans `/docs/tech/backend.md` §12.5.
 
 ---
 
-*Dernière mise à jour : 2026-05-07 · Maintenu par Arthur + Claude.*
+*Dernière mise à jour : 2026-05-09 · Maintenu par Arthur + Claude.*

docs/flow.md

@@ -265,15 +265,18 @@ Toutes appellent in fine la même logique métier (mêmes mutations DB, mêmes e
 ```
 Plan
 ├── name: "Standard B2B"
-├── slug: "standard-b2b"
+├── slug: "standard-30j"
-├── description: "Plan équilibré pour la majorité des factures"
+├── description: "Cadence sobre, ton qui monte progressivement."
 └── steps[]
-    ├── PlanStep { offsetDays: 3,  tone: "amical",  subject, body, requiresManualValidation: false }
+    ├── PlanStep { offsetDays: 3,  tone: "amical",          subject, body, requiresManualValidation: false }
-    ├── PlanStep { offsetDays: 10, tone: "ferme",   subject, body, requiresManualValidation: false }
+    ├── PlanStep { offsetDays: 10, tone: "courtois",        subject, body, requiresManualValidation: false }
-    └── PlanStep { offsetDays: 25, tone: "stricte", subject, body, requiresManualValidation: true }
+    └── PlanStep { offsetDays: 25, tone: "ferme",           subject, body, requiresManualValidation: true  }
-                                                                                            ↑
+                                                                                                       ↑
-                                                          mise en demeure → bouton manuel,
+                                                                         mise en demeure → bouton manuel,
-                                                          jamais d'envoi auto
+                                                                         jamais d'envoi auto
+
+Tons disponibles : `amical | courtois | ferme | mise_en_demeure`
+(cf. `apps/api/app/services/default_plans.ts:18`).
 ```
 
 ### 6.2 Plans pré-fournis

docs/produit.md

@@ -1,6 +1,6 @@
 # Spécification produit — Rubis Sur l'Ongle
 
-> Version : 0.1 (MVP) · Dernière maj : 2026-05-05
+> Version : 0.2 (MVP — blog + Stripe livrés) · Dernière maj : 2026-05-09
 
 Ce document est la source de vérité produit. Il décrit ce qu'on fait, pour qui, comment, et **ce qu'on ne fait pas**. Quand un wireframe et ce document divergent, ce document gagne.
 
@@ -44,7 +44,7 @@ Rubis Sur l'Ongle libère le temps des dirigeants de TPE-PME en automatisant la
 ### 4.1 Authentification & onboarding
 
 - Inscription email/password (2 champs minimum)
-- Google SSO en option
+- Google SSO + Microsoft SSO en option (via Adonis Ally)
 - Onboarding 3 étapes au max :
   1. Compte (email, mot de passe)
   2. Entreprise (nom, SIRET facultatif, secteur, volume mensuel via chips)
@@ -61,13 +61,14 @@ Rubis Sur l'Ongle libère le temps des dirigeants de TPE-PME en automatisant la
 
 ### 4.3 Plans de relance
 
-- **Bibliothèque** : 4 plans pré-fournis par défaut
+- **Bibliothèque** : 4 plans pré-fournis par défaut (cf. `apps/api/app/services/default_plans.ts`)
-  - *Standard B2B* : J+3, J+10, J+20 (mise en demeure brouillon)
+  - *Standard B2B* (`standard-30j`) : J+3, J+10, J+25 — *amical → courtois → mise en demeure*
-  - *Premium clients VIP* : J+7, J+15, J+30 — ton doux
+  - *Rapide* (`rapide-15j`) : J+1, J+7, J+15 — cadence resserrée pour récurrents / délais courts
-  - *Court cash flow tendu* : J+1, J+5, J+10 — ton ferme
+  - *Patient* (`patient-60j`) : J+15, J+30 — clients de longue date, on laisse respirer
-  - *Personnalisable* : à créer par l'utilisateur
+  - *Ferme* (`ferme-7j`) : cadence stricte pour clients à risque
-- **Éditeur** : cadence à gauche, contenu email à droite. Variables sous forme de chips drag-to-insert (`{{prenom_client}}`, `{{numero}}`, `{{montant}}`, `{{date_echeance}}`, `{{signature}}`)
+- **Personnalisation** : l'utilisateur crée ses propres plans via `/plans/nouveau` (variantes / sur-mesure)
-- **Tonalité** affichée comme tag visible (Doux / Standard / Ferme)
+- **Éditeur** : cadence à gauche, contenu email à droite. Variables sous forme de chips drag-to-insert (`{{client.name}}`, `{{numero}}`, `{{amount}}`, `{{dueDate}}`, `{{signature}}`)
+- **Tonalité** affichée comme tag visible — 4 valeurs : `amical`, `courtois`, `ferme`, `mise_en_demeure` (la dernière déclenche `requiresManualValidation: true`)
 
 ### 4.4 Check-in email (réconciliation V1)
 
@@ -171,14 +172,14 @@ Rubis Sur l'Ongle libère le temps des dirigeants de TPE-PME en automatisant la
 
 **Stratégie** : prix d'entrée agressif vs Sellsy/Axonaut (~30 €) défendable parce qu'on est mono-produit. Argument : *"moins cher qu'une heure de votre temps mensuel"*.
 
-**Trial** : 14 jours offerts sans CB, puis fallback automatique sur Free.
+**Trial commercial** : 30 jours d'essai sans carte bancaire (CTA landing : *« Commencer l'essai 30 jours »*). Le code utilise actuellement une *« période de grâce 3 mois »* post-signup côté `apps/api/app/services/billing.ts` — incohérence à aligner sur 30 jours dans un PR séparé (cf. `docs/decisions.md`).
 
 ## 8. Notes architecture (à formaliser avec stack)
 
 Quelques contraintes produit qui doivent guider l'architecture :
 
-- **Statuts de facture pivotables** : `pending`, `awaiting_user_confirmation`, `paid`, `relanced`, `litigation`, `cancelled` — pas hardcodés au flow email
+- **Statuts de facture pivotables** : `pending`, `awaiting_user_confirmation`, `paid`, `in_relance`, `litigation`, `cancelled` — pas hardcodés au flow email (cf. `packages/shared/src/constants/index.ts`)
-- **Modèle d'événement abstrait** pour le check-in : un `payment_status_check` peut être déclenché par email-réponse en V1, par webhook banking en V2 — l'app ne doit pas savoir d'où vient le signal
+- **Modèle d'événement abstrait** pour la confirmation : un `payment_status_check` peut être déclenché par email-réponse en V1, par webhook banking en V2 — l'app ne doit pas savoir d'où vient le signal
 - **Multi-tenant dès le jour 1** : même si V1 est mono-user par compte, la structure DB doit supporter `organization` → `users` → `invoices` pour ne pas refactorer en V2
 - **OCR** : provider abstrait derrière une interface — on doit pouvoir switcher Mindee → Document AI → Tesseract sans toucher au reste
 - **Email outbound** : provider abstrait (Resend / Postmark / SendGrid) avec retry et tracking

docs/wireframes-mvp.html

@@ -415,7 +415,7 @@
 
 <header class="page-header">
   <h1>Rubis Sur l'Ongle — Wireframes MVP <span style="color:var(--ink-3); font-weight: 400;">v0.1</span></h1>
-  <div class="meta">Low-fidelity · niveaux de gris · 13 écrans · centré sur la promesse "3 clics maximum"</div>
+  <div class="meta">Low-fidelity · niveaux de gris · 13 écrans low-fi initiaux (la SPA livrée en compte ~15 + onboarding multi-étapes — cf. <code>apps/web/src/routes/_app/</code>) · centré sur la promesse "3 clics maximum"</div>
   <nav class="toc">
     <a href="#onboarding">1. Onboarding &amp; Auth</a>
     <a href="#upload">2. Upload &amp; OCR</a>