1acb273c1d
All checks were successful
Build & Deploy Landing / build-and-deploy (push) Successful in 24s
Documentation post-migration du setup email : - /docs/tech/backend.md §12.5 : architecture des 2 flux (Resend pour le sortant transactionnel via send.rubis.pro, OVH MX Plan pour l'entrant humain via @ rubis.pro) - /CLAUDE.md : tableau récap email infra + maj domaine principal rubis.pro / app.rubis.pro, suppression de la question ouverte "domaine définitif" (résolue) et "endpoint waitlist" (remplacé par CTA app) - /.claude/deploy-memory.md : section migration rubis.pro marquée ✅ avec checklist décommissionnement legacy - /landing/confidentialite.html : remplace privacy@rubis.pro par contact@rubis.pro (alignement avec les boîtes OVH créées) Adresses opérationnelles : - contact@rubis.pro (général + RGPD) - dev@rubis.pro (notifs techniques) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
182 lines
9.5 KiB
Markdown
182 lines
9.5 KiB
Markdown
# Rubis Sur l'Ongle
|
||
|
||
> **Le SaaS de relance de factures impayées pour TPE-PME françaises.** Drag-and-drop, OCR, plans de relance automatiques. 1 rubis = 10 minutes libérées.
|
||
|
||
Ce fichier est le contexte top-level. Il est court, dense, scannable. Pour les détails, voir `/docs/`.
|
||
|
||
---
|
||
|
||
## En une phrase
|
||
|
||
Vos factures se relancent toutes seules pendant que vous travaillez.
|
||
|
||
## Cible
|
||
|
||
TPE-PME françaises, 5 à 50 salariés, qui émettent 10 à 200 factures par mois, sans crédit manager dédié. Le décideur teste lui-même le produit (pas de cycle de vente long).
|
||
|
||
## Promesse de valeur
|
||
|
||
- **5 heures par semaine récupérées** (benchmark : 8h → <3h après automatisation).
|
||
- **Tonalité émotionnelle** : on vend du temps libéré, pas de la trésorerie. Le rubis gagné est la métrique-héros, pas le DSO.
|
||
- **2 à 3 clics maximum** pour lancer une relance sur une nouvelle facture.
|
||
|
||
## Principes produit (toujours valides)
|
||
|
||
1. **3 clics maximum** pour lancer une relance sur une facture neuve. Idéalement 2 si bien configuré.
|
||
2. **Mobile et desktop** — la photo de facture depuis le téléphone est un usage clé.
|
||
3. **Pure-player relance** — on ne fait pas CRM, pas facturation, pas comptabilité. On fait une chose et on la fait bien.
|
||
4. **Respectueux du client final** — le ton monte avec le retard, jamais avant. Pas d'agressivité par défaut.
|
||
5. **Le rubis est une vraie devise produit** — 1 rubis = 10 min libérées. La gamification doit être tangible et défendable.
|
||
|
||
## Identité de marque (TLDR)
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Logo** | Direction A — gem facetté géométrique. Le ◆ est un symbole produit autant qu'un logo. |
|
||
| **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 |
|
||
| **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).
|
||
|
||
## Voix
|
||
|
||
Direct, concret, chaleureux, précis, empathique. *On parle comme un bon associé, pas comme une DAF.*
|
||
|
||
- ✓ "Vos factures relancées toutes seules."
|
||
- ✗ "Optimisez votre processus de recouvrement amiable."
|
||
|
||
## Glossaire
|
||
|
||
- **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.
|
||
- **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€.
|
||
|
||
## Périmètre V1
|
||
|
||
### IN
|
||
|
||
- Auth email/password + Google 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)
|
||
- Éditeur de plan (cadence + templates email avec variables)
|
||
- Check-in email à l'utilisateur (cadence configurable) → confirme si payé → relance ou stop
|
||
- Dashboard avec compteur rubis + KPIs (à relancer, encaissé, DSO)
|
||
- Liste filtrable des factures
|
||
- Détail facture avec timeline des relances
|
||
- App mobile (web responsive)
|
||
|
||
### OUT (V2 ou plus tard)
|
||
|
||
- **SMS** — uniquement plan le plus cher en V2
|
||
- **Multi-utilisateurs** — uniquement plans payants en V2
|
||
- **Intégration banking / réconciliation auto** — l'architecture V1 doit l'anticiper, mais l'implémentation est V2+
|
||
- Multi-langues, multi-devises (FR/EUR only en V1)
|
||
- Intégration ERP/comptable (Sage, Pennylane, Quickbooks)
|
||
|
||
## Pricing (esquisse, à valider)
|
||
|
||
| Plan | Prix | Limite |
|
||
|---|---|---|
|
||
| **Free** | 0 € | 5 factures actives en relance, 1 utilisateur |
|
||
| **Pro** | 19 €/mois | Factures illimitées, OCR illimité, 1 utilisateur |
|
||
| **Business** | 49 €/mois | + multi-utilisateurs, + branding email, + SMS (V2) |
|
||
|
||
Argument de vente : *"moins cher qu'une heure de votre temps mensuel"*.
|
||
|
||
## Décisions clés validées (résumé)
|
||
|
||
Voir `/docs/decisions.md` pour le log complet avec rationale.
|
||
|
||
- 1 rubis = 10 minutes libérées
|
||
- Logo direction A (gem facetté), wordmark à monter en parallèle plus tard
|
||
- Palette rubis chaude, sans or, sans bleu
|
||
- Typo Bricolage Grotesque + Inter
|
||
- Iconographie Lucide
|
||
- Mise en demeure : validation manuelle obligatoire (modale)
|
||
- SMS et multi-users : V2 + plans payants seulement
|
||
- Banking intégration : pas en V1, remplacée par check-in emails
|
||
|
||
## Stack technique
|
||
|
||
| Couche | Choix | Source |
|
||
|---|---|---|
|
||
| Backend | **AdonisJS v7** (TS, MVC, Lucid ORM, auth & jobs intégrés) | ADR-014 |
|
||
| Frontend | **React + Vite** | ADR-014 |
|
||
| Routing client | **TanStack Router** | ADR-014 |
|
||
| State serveur | **TanStack Query** | ADR-014 |
|
||
| Base de données | **PostgreSQL** | ADR-014 |
|
||
| Hosting | **Proxmox + K3s** (perso) | ADR-014 |
|
||
| OCR provider | à benchmarker | ADR-020 (en attente) |
|
||
| Email outbound | à benchmarker | ADR-021 (en attente) |
|
||
|
||
**Architecture** : monorepo (`apps/api` + `apps/web` + `packages/shared`), API REST AdonisJS Bearer-auth, SPA React/Vite séparé, PG et MinIO existants sur LXC Proxmox. Détails dans `/docs/tech/architecture.md`.
|
||
|
||
**Décisions cadres** : ADR-014 (stack), ADR-015 (monorepo), ADR-016 (PG Proxmox existant), ADR-017 (Bearer tokens), ADR-018 (MinIO existant).
|
||
|
||
### Conventions techniques (cross-cutting)
|
||
|
||
- **Identifiants : UUID partout.** Toutes les PK et FK applicatives sont des UUID v4 (PG `uuid` avec default `gen_random_uuid()`). **Jamais d'`increments`/`serial`**, même pour les tables internes (auth tokens, sessions, refresh tokens, etc.). Les UUID protègent de l'énumération, simplifient la fédération multi-tenant et évitent les fuites de volumes par incrément. Les transformers exposent les UUID directement en string — pas de cast nécessaire.
|
||
|
||
## Documents associés
|
||
|
||
| Fichier | Rôle |
|
||
|---|---|
|
||
| `/CLAUDE.md` (ce fichier) | Contexte top-level, toujours en tête |
|
||
| `/landing/index.html` | Landing page brand-applied, déployée (waitlist V1) |
|
||
| `/landing/favicon.{svg,ico,png}` | Set complet de favicons + apple-touch-icon |
|
||
| `/landing/site.webmanifest` | Manifest PWA (theme `#9F1239`, background `#FAF7F2`) |
|
||
| `/landing/assets/logo.png` | Logo Rubis original (généré, source pour les favicons) |
|
||
| `/docs/produit.md` | Spec produit haut niveau (features, IN/OUT V1, pricing) |
|
||
| `/docs/flow.md` | **Comportement produit deep-dive** : cycle de vie d'une facture, statuts + transitions, surfaces UI, mécanique de confirmation (check-in), mode démo, edge cases |
|
||
| `/docs/marque.md` | Référence marque écrite (palette, typo, voix, do/don't) |
|
||
| `/docs/decisions.md` | Log de décisions avec rationale (format ADR-light) |
|
||
| `/docs/wireframes-mvp.html` | Wireframes low-fi des 13 écrans MVP |
|
||
| `/docs/brand-identity.html` | Présentation visuelle de la marque (4 logos, applications) |
|
||
| `/docs/munitions-marketing.md` | Stats marché, concurrents, positionnement, copy |
|
||
| `/docs/marketing/playbook.md` | Playbook acquisition premiers clients : ICP, Dream 100, channels, templates outreach |
|
||
| `/docs/tech/architecture.md` | Architecture technique : composants, flux, topologie, conventions |
|
||
| `/docs/tech/frontend.md` | Guide d'implémentation frontend (deps, Tailwind, TanStack, Tuyau) |
|
||
| `/Dockerfile` | Build nginx-alpine servant `/landing/` sur port 80 |
|
||
| `/k3s/` | Manifests Kubernetes (namespace, deployment, service) |
|
||
| `/.claude/deploy-memory.md` | Procédure de déploiement (Gitea CI ou manuel) |
|
||
|
||
## Déploiement
|
||
|
||
- **Domaine principal** : https://rubis.pro (landing) + https://app.rubis.pro (SaaS V1)
|
||
- **Image landing** : `git.arthurbarre.fr/ordinarthur/rubis:latest`
|
||
- **Build landing** : `COPY landing/` → nginx servi sur port 80
|
||
- **Compat** : `rubis.arthurbarre.fr` / `app.rubis.arthurbarre.fr` redirigent en 301 vers `rubis.pro` / `app.rubis.pro` (config Traefik dans repo proxmox)
|
||
- Voir `.claude/deploy-memory.md` pour la procédure complète.
|
||
|
||
## Email infrastructure (`rubis.pro`)
|
||
|
||
Deux flux distincts qui cohabitent sur le même domaine via des sous-domaines DNS séparés :
|
||
|
||
| Flux | Provider | Adresse | DNS clés |
|
||
|---|---|---|---|
|
||
| **Sortant** (relances, check-in, auth) | Resend | `relances@rubis.pro` | `send.rubis.pro` (MX + SPF), `resend._domainkey` (DKIM), `_dmarc` |
|
||
| **Entrant** (humain) | OVH MX Plan | `contact@rubis.pro` (général + RGPD), `dev@rubis.pro` (notifs tech) | MX `@` → `mx*.mail.ovh.net.` |
|
||
|
||
Détails dans `/docs/tech/backend.md` §12.5.
|
||
|
||
## Questions ouvertes
|
||
|
||
- **Conversion 1 rubis = 10 min** validée mais à confirmer en user testing après MVP
|
||
- **Wordmark "rubis" avec gem-i** (direction C) à monter en complément du logo A à un moment
|
||
- **Provider OCR** à benchmarker (Mindee, Document AI, Textract, Tesseract)
|
||
|
||
---
|
||
|
||
*Dernière mise à jour : 2026-05-07 · Maintenu par Arthur + Claude.*
|