From 801168fc741b1ae0bdb7747e1a24e1dce503ac47 Mon Sep 17 00:00:00 2001 From: ordinarthur <@arthurbarre.js@gmail.com> Date: Sat, 9 May 2026 19:06:59 +0200 Subject: [PATCH] docs(audit-1/3): aligner top-level + produit sur le code MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 - 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 --- CLAUDE.md | 20 +++++++++++--------- docs/flow.md | 19 +++++++++++-------- docs/produit.md | 25 +++++++++++++------------ docs/wireframes-mvp.html | 2 +- 4 files changed, 36 insertions(+), 30 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index f8a02ed..82d4b50 100644 --- a/CLAUDE.md +++ b/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 body** | Inter (400–700), Google Fonts | +| **Typo display** | Bricolage Grotesque (500–800), self-hosted via `@fontsource-variable/bricolage-grotesque` | +| **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.* diff --git a/docs/flow.md b/docs/flow.md index cb991a3..fcc5bd5 100644 --- a/docs/flow.md +++ b/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" -├── description: "Plan équilibré pour la majorité des factures" +├── slug: "standard-30j" +├── description: "Cadence sobre, ton qui monte progressivement." └── steps[] - ├── PlanStep { offsetDays: 3, tone: "amical", subject, body, requiresManualValidation: false } - ├── PlanStep { offsetDays: 10, tone: "ferme", subject, body, requiresManualValidation: false } - └── PlanStep { offsetDays: 25, tone: "stricte", subject, body, requiresManualValidation: true } - ↑ - mise en demeure → bouton manuel, - jamais d'envoi auto + ├── PlanStep { offsetDays: 3, tone: "amical", subject, body, requiresManualValidation: false } + ├── PlanStep { offsetDays: 10, tone: "courtois", subject, body, requiresManualValidation: false } + └── PlanStep { offsetDays: 25, tone: "ferme", subject, body, requiresManualValidation: true } + ↑ + mise en demeure → bouton manuel, + 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 diff --git a/docs/produit.md b/docs/produit.md index 702f097..92aa4a9 100644 --- a/docs/produit.md +++ b/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 - - *Standard B2B* : J+3, J+10, J+20 (mise en demeure brouillon) - - *Premium clients VIP* : J+7, J+15, J+30 — ton doux - - *Court cash flow tendu* : J+1, J+5, J+10 — ton ferme - - *Personnalisable* : à créer par l'utilisateur -- **Éditeur** : cadence à gauche, contenu email à droite. Variables sous forme de chips drag-to-insert (`{{prenom_client}}`, `{{numero}}`, `{{montant}}`, `{{date_echeance}}`, `{{signature}}`) -- **Tonalité** affichée comme tag visible (Doux / Standard / Ferme) +- **Bibliothèque** : 4 plans pré-fournis par défaut (cf. `apps/api/app/services/default_plans.ts`) + - *Standard B2B* (`standard-30j`) : J+3, J+10, J+25 — *amical → courtois → mise en demeure* + - *Rapide* (`rapide-15j`) : J+1, J+7, J+15 — cadence resserrée pour récurrents / délais courts + - *Patient* (`patient-60j`) : J+15, J+30 — clients de longue date, on laisse respirer + - *Ferme* (`ferme-7j`) : cadence stricte pour clients à risque +- **Personnalisation** : l'utilisateur crée ses propres plans via `/plans/nouveau` (variantes / sur-mesure) +- **É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 -- **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 +- **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 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 diff --git a/docs/wireframes-mvp.html b/docs/wireframes-mvp.html index a4c07fb..b5d4a9c 100644 --- a/docs/wireframes-mvp.html +++ b/docs/wireframes-mvp.html @@ -415,7 +415,7 @@

Rubis Sur l'Ongle — Wireframes MVP v0.1

-
Low-fidelity · niveaux de gris · 13 écrans · centré sur la promesse "3 clics maximum"
+
Low-fidelity · niveaux de gris · 13 écrans low-fi initiaux (la SPA livrée en compte ~15 + onboarding multi-étapes — cf. apps/web/src/routes/_app/) · centré sur la promesse "3 clics maximum"