801168fc74
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>
196 lines
11 KiB
Markdown
196 lines
11 KiB
Markdown
# Spécification produit — Rubis Sur l'Ongle
|
|
|
|
> 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.
|
|
|
|
---
|
|
|
|
## 1. Vision
|
|
|
|
Rubis Sur l'Ongle libère le temps des dirigeants de TPE-PME en automatisant la relance des factures impayées. Là où les concurrents proposent des outils de "recouvrement" complexes pour DAF d'ETI, on propose un outil **émotionnellement orienté temps libéré**, conçu pour qu'un boulanger ou une consultante puisse l'utiliser en autonomie en moins de 5 minutes.
|
|
|
|
## 2. Cible
|
|
|
|
### Profil principal
|
|
|
|
- **Taille** : TPE-PME, 5 à 50 salariés
|
|
- **Volume** : 10 à 200 factures émises par mois
|
|
- **Décideur** : le dirigeant lui-même, ou son comptable interne (1 personne max)
|
|
- **Pas de** : crédit manager, DAF, équipe finance dédiée
|
|
- **Outils existants** : facturation déjà gérée ailleurs (Sage, Pennylane, Henrri, Excel) — **on ne remplace pas** le logiciel de facturation, on relance ce qui sort de là
|
|
|
|
### Persona type
|
|
|
|
> "Sophie, 42 ans, gérante d'une SARL de prestation B2B (5 salariés). Elle émet 30 factures/mois, 6 sont en retard à tout moment. Elle relance le lundi soir entre 19h et 20h, à la main, en pestant. Elle a essayé un Excel de suivi qui n'a pas tenu 3 mois. Elle gagne 80 €/h facturés. Sa douleur : ne pas pouvoir oublier les retards mentalement."
|
|
|
|
### Anti-persona
|
|
|
|
- DAF d'ETI > 250 salariés (use case Dunforce/Upflow)
|
|
- Freelance unique avec 3 factures/mois (volume insuffisant pour ressentir la douleur)
|
|
- Pure facturation B2C (pas notre cas d'usage)
|
|
|
|
## 3. Principes UX
|
|
|
|
1. **3 clics maximum** pour lancer une relance sur une nouvelle facture. Idéal : 2 si plan par défaut bien configuré.
|
|
2. **Mobile first** sur le geste rapide (photo de facture en déplacement). Desktop pour la config et le suivi.
|
|
3. **L'OCR fait 90 %, l'humain 10 %** — l'utilisateur corrige, ne saisit pas.
|
|
4. **Plans pré-fournis** — 4 modèles par défaut, l'utilisateur n'arrive jamais sur une page blanche.
|
|
5. **Le ton monte progressivement** — rappel doux → relance ferme → mise en demeure (jamais auto).
|
|
6. **Toute action irréversible passe par une modale de confirmation** — envoyer une mise en demeure, supprimer un plan utilisé, archiver une facture en cours.
|
|
|
|
## 4. Fonctionnalités V1 (IN)
|
|
|
|
### 4.1 Authentification & onboarding
|
|
|
|
- Inscription email/password (2 champs minimum)
|
|
- 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)
|
|
3. Signature email (nom, fonction, coordonnées) — sera utilisée dans tous les emails de relance
|
|
|
|
### 4.2 Gestion des factures
|
|
|
|
- **Drag & drop** : zone d'upload acceptant PDF, PNG, JPG, jusqu'à 20 fichiers en simultané
|
|
- **OCR automatique** sur l'upload — extrait : client, email, numéro de facture, montant TTC, date d'échéance
|
|
- **Vérification OCR** : interface split (PDF à gauche, formulaire pré-rempli à droite). Tous les champs déjà remplis, l'utilisateur corrige uniquement
|
|
- **Saisie manuelle** : modale 6 champs avec recherche client autocomplete
|
|
- **Liste filtrable** : par statut (toutes, à relancer, en relance, encaissées, litige) via chips
|
|
- **Actions en lot** : checkboxes pour relancer manuellement, changer le plan, archiver
|
|
|
|
### 4.3 Plans de relance
|
|
|
|
- **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)
|
|
|
|
> Remplace l'intégration banking en V1.
|
|
|
|
**Comment ça marche** :
|
|
1. L'utilisateur configure dans son plan : "Vérifier auprès de moi avant chaque relance" (oui/non + délai en jours, ex. T-2 jours avant la relance suivante)
|
|
2. À T-2 du prochain envoi prévu, Rubis envoie un email **à l'utilisateur** : *"Avez-vous été payé pour la facture F-2024-0042 (1 240 €, Boulangerie Martin) ?"* avec deux boutons : **Oui (stopper le plan)** / **Non (continuer la relance)**
|
|
3. Si l'utilisateur répond "Oui" → la facture est marquée encaissée, le plan est arrêté
|
|
4. Si l'utilisateur répond "Non" ou ne répond pas dans le délai → la relance part comme prévu
|
|
|
|
**Pourquoi cette mécanique** :
|
|
- Évite les relances "fantômes" sur des factures déjà payées hors plateforme
|
|
- Conserve l'utilisateur en boucle sans le surcharger
|
|
- Architecture compatible avec le futur banking : à terme, le check-in sera automatique via la banque, l'email user devient fallback
|
|
|
|
**À prévoir côté architecture V1** :
|
|
- Modèle d'événement réutilisable (`payment_status_check`) qui peut être déclenché par email-réponse OU plus tard par webhook bancaire
|
|
- Le statut de la facture (`pending`, `paid`, `awaiting_user_confirmation`, `cancelled`) doit être pivotable, pas spécifique au flow email
|
|
|
|
### 4.5 Mise en demeure
|
|
|
|
- **Toujours validation manuelle** via modale de confirmation. Pas de checkbox d'auto-envoi, c'est une décision produit forte.
|
|
- Modale affiche : montant, client, contenu de l'email, conséquences légales rappelées (loi LME)
|
|
- Utilisateur doit explicitement cliquer "Envoyer la mise en demeure" pour activer l'envoi
|
|
- Email envoyé en accusé de réception possible (option), pas par défaut
|
|
|
|
### 4.6 Dashboard & rubis
|
|
|
|
- **Hero** : compteur de rubis du mois en cours, conversion en heures libérées
|
|
- **KPIs** : factures à relancer, en relance, encaissé du mois, DSO moyen
|
|
- **Activité du jour** : flux des actions automatiques exécutées par Rubis
|
|
- **Top mauvais payeurs** : top 3 clients avec le plus de retards (interne uniquement, jamais visible côté client)
|
|
|
|
### 4.7 Détail facture
|
|
|
|
- Timeline mixant passé (plein) et futur (estompé) des étapes du plan
|
|
- Tracking d'ouverture des emails (X ouvertures)
|
|
- Bouton "Relancer maintenant" pour envoi manuel hors cadence
|
|
- Notes internes en libre
|
|
|
|
### 4.8 Mobile
|
|
|
|
- Responsive web (pas d'app native en V1)
|
|
- Action prioritaire : "Photo de facture" (use de la caméra → OCR)
|
|
- Tab bar 4 entrées max : Accueil · Factures · Plans · Réglages
|
|
- Le rubis reste hero du mobile
|
|
|
|
## 5. Fonctionnalités OUT (V2+)
|
|
|
|
### V2 (planifié)
|
|
|
|
- **SMS** : étape de relance par SMS, **réservé au plan le plus cher**
|
|
- **Multi-utilisateurs** : invitations, rôles (admin / éditeur / lecteur), **réservé aux plans payants**
|
|
- **Personnalisation avancée des emails** : signature HTML, logo client, branding sortant
|
|
- **Wordmark logo** (direction C) : à monter en complément du logo A
|
|
|
|
### V3+ (plus tard, à anticiper en archi)
|
|
|
|
- **Intégration banking** : Bridge / GoCardless / Tink, réconciliation automatique. Le check-in V1 devient un fallback
|
|
- **Intégrations comptable** : Sage, Pennylane, Quickbooks, Pennylane, Cegid
|
|
- **Multi-devises et multi-langues**
|
|
- **API publique** pour les ERP partenaires
|
|
- **App native** iOS/Android
|
|
|
|
### Hors scope définitif
|
|
|
|
- Émission de factures (on ne devient pas un Henrri-bis)
|
|
- CRM / pipeline commercial (on ne devient pas Sellsy)
|
|
- Gestion de trésorerie complète (on ne devient pas Agicap)
|
|
|
|
## 6. User flows clés (résumé)
|
|
|
|
### Flow 1 — Première facture (onboarding hot path)
|
|
|
|
1. Inscription (2 champs) → setup wizard 3 étapes → arrivée sur Factures (vide)
|
|
2. Drag PDF dans la dropzone → OCR → vérification 30 sec → "Valider"
|
|
3. Plan par défaut sélectionné → "Lancer la relance" → écran récompense rubis
|
|
|
|
**Cible** : moins de 4 minutes du début de l'inscription au premier rubis.
|
|
|
|
### Flow 2 — Routine hebdomadaire
|
|
|
|
1. Lundi matin, l'utilisateur reçoit un email check-in : "3 factures en attente — avez-vous été payé ?"
|
|
2. L'utilisateur clique "Oui" sur 1, "Non" sur 2 → les 2 relances partent automatiquement
|
|
3. Total temps utilisateur : <60 secondes
|
|
|
|
### Flow 3 — Mise en demeure
|
|
|
|
1. Étape J+20 d'un plan → notification dans l'app : "Brouillon prêt"
|
|
2. L'utilisateur ouvre la facture → relit le contenu → clique "Envoyer la mise en demeure"
|
|
3. Modale de confirmation avec rappel légal → confirme → envoi
|
|
|
|
## 7. Pricing (esquisse à tester)
|
|
|
|
| Plan | Prix | Cible | Limites | V1 |
|
|
|---|---|---|---|---|
|
|
| **Free** | 0 € | Freelance, test | 5 factures actives en relance, 1 utilisateur, plans standards seulement | ✓ |
|
|
| **Pro** | 19 €/mois | TPE 1-5 salariés | Illimité factures + OCR + plans, 1 utilisateur | ✓ |
|
|
| **Business** | 49 €/mois | PME 5-50 salariés | + multi-utilisateurs, + branding email, + SMS (V2) | partiel |
|
|
|
|
**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 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`, `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
|
|
- **Jobs/scheduler** : la cadence des relances et check-ins est un job persistant — préférer Inngest/Trigger.dev/queue dédiée à `setTimeout`
|
|
|
|
## 9. Métriques produit à instrumenter
|
|
|
|
- **Activation** : % d'utilisateurs ayant lancé leur 1ère relance dans les 7 jours suivant l'inscription
|
|
- **Engagement** : nombre de rubis gagnés par utilisateur par mois
|
|
- **Rétention** : MAU / WAU
|
|
- **Conversion business** : taux de passage Free → Pro
|
|
- **Satisfaction métier** : DSO moyen des comptes (avant/après Rubis)
|
|
- **Anti-métrique** : taux de "non" sur les check-in emails (si trop bas, on relance trop tôt et c'est inutile)
|