rubis/docs/produit.md

# Spécification produit — Rubis Sur l'Ongle

> Version : 0.1 (MVP) · Dernière maj : 2026-05-05

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 en option
- 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
  - *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)

### 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** : 14 jours offerts sans CB, puis fallback automatique sur Free.

## 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
- **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)