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>
9.5 KiB
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)
- 3 clics maximum pour lancer une relance sur une facture neuve. Idéalement 2 si bien configuré.
- Mobile et desktop — la photo de facture depuis le téléphone est un usage clé.
- Pure-player relance — on ne fait pas CRM, pas facturation, pas comptabilité. On fait une chose et on la fait bien.
- Respectueux du client final — le ton monte avec le retard, jamais avant. Pas d'agressivité par défaut.
- 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
uuidavec defaultgen_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.frredirigent en 301 versrubis.pro/app.rubis.pro(config Traefik dans repo proxmox) - Voir
.claude/deploy-memory.mdpour 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.