236 lines
12 KiB
Markdown
236 lines
12 KiB
Markdown
# Log de décisions — Rubis Sur l'Ongle
|
|
|
|
> Format ADR-light. Chaque décision : contexte, décision, rationale, alternatives, statut. Append-only — on n'efface jamais une décision passée, on en ajoute une nouvelle qui l'annule si besoin.
|
|
|
|
---
|
|
|
|
## ADR-001 · Conversion 1 rubis = 10 minutes libérées
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : la gamification "rubis gagnés" a besoin d'une conversion défendable et tangible.
|
|
- **Décision** : 1 rubis = 10 minutes libérées (≈ une relance manuelle complète).
|
|
- **Rationale** :
|
|
- Cohérent avec le bench *5h gagnées par semaine* (8h → <3h après automatisation).
|
|
- 10 min est un chiffre rond mémorisable dans la copy.
|
|
- Borne basse défensible — beaucoup d'études parlent de 15-20 min, on est conservateur, donc incontestable.
|
|
- Permet ~30 rubis/mois pour une PME type, ~150 pour les power users — bon flywheel de gamification.
|
|
- **Alternatives écartées** :
|
|
- 1 rubis = 1 € de trésorerie débloquée → trop financier, rompt la promesse temps
|
|
- 1 rubis = 1 facture encaissée → trop discret pour les utilisateurs faible volume
|
|
- 1 rubis = 12 ou 15 minutes → moins mémorisable, pas plus défendable
|
|
- **À reconfirmer** : après MVP, via user testing — si les utilisateurs disent "10 min c'est trop" ou "trop peu", on ajustera.
|
|
|
|
---
|
|
|
|
## ADR-002 · Direction de logo : A (gem facetté)
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : 4 directions explorées (A gem facetté, B rubis brut, C wordmark, D ongle littéral).
|
|
- **Décision** : Direction A (gem facetté géométrique) en logo principal V1.
|
|
- **Rationale** :
|
|
- Iconique, scalable de 16 px à billboard
|
|
- Naturellement cohérent avec le ◆ utilisé dans les wireframes pour la gamification
|
|
- Marche en mono, knockout, filigrane
|
|
- Symbole autonome — fonctionne en favicon et app icon sans wordmark
|
|
- **Alternatives** :
|
|
- B (rubis brut) : trop joaillerie, risque Cartier
|
|
- D (ongle littéral) : polarisante, risque "manucure / cosmétique"
|
|
- C (wordmark) : retenue mais à monter en complément plus tard, pas en V1
|
|
- **Suivi** : à monter le wordmark direction C en V2 pour signature email, doc, contextes éditoriaux.
|
|
|
|
---
|
|
|
|
## ADR-003 · Couleur primaire #9F1239
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : choisir le rouge de la marque parmi plusieurs options.
|
|
- **Décision** : `#9F1239` — rubis profond légèrement violacé.
|
|
- **Rationale** : sophistiqué, distinctif, anti-Coca-Cola. Évoque le rubis "pigeon blood" (vivid red avec hints purple). Différencie radicalement des rouges tech génériques.
|
|
- **Alternatives** :
|
|
- `#B91C3C` (rose 700) : plus punchy, plus tech
|
|
- `#881337` : plus dark, plus austère
|
|
- `#BE123C` : Tailwind rose-700, plus standard
|
|
- **À surveiller** : le contraste sur blanc pur peut être limite pour texte <14 px → utiliser `#771328` (rubis profond) dans ces cas.
|
|
|
|
---
|
|
|
|
## ADR-004 · Pas d'or accent
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : la palette initiale incluait un or `#B89F6B` comme accent rare.
|
|
- **Décision** : abandon total de l'or dans la marque.
|
|
- **Rationale** : "fait très cheap" (Arthur). Risque d'évoquer banque ou bling-bling. La marque tient sans or — rubis + neutres chauds suffit.
|
|
- **Conséquence** : tout document antérieur mentionnant l'or est obsolète sur ce point. La règle devient *rubis + neutres chauds, point*.
|
|
|
|
---
|
|
|
|
## ADR-005 · Typographies Bricolage Grotesque + Inter
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : choisir une paire display + body, libre et accessible.
|
|
- **Décision** :
|
|
- **Display** : Bricolage Grotesque (500-800)
|
|
- **Body** : Inter (400-700)
|
|
- Les deux sur Google Fonts.
|
|
- **Rationale** :
|
|
- Bricolage apporte un caractère "français contemporain" qui différencie de la galaxie Stripe/Linear/Notion sans tomber dans le designer-flex
|
|
- Inter est le workhorse incontesté pour l'UI moderne, hyper-lisible, neutre
|
|
- Les deux sont gratuites, installables en 30 secondes
|
|
- **Alternatives** :
|
|
- General Sans : retenue mais plus neutre, moins ownable
|
|
- Söhne : payante, hors scope MVP
|
|
- Inter Display + Inter : trop monochrome, pas de personnalité
|
|
|
|
---
|
|
|
|
## ADR-006 · Iconographie : Lucide
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée (tranche-claude)
|
|
- **Contexte** : choisir un set d'icônes pour l'UI.
|
|
- **Décision** : Lucide en regular weight (1.5px stroke).
|
|
- **Rationale** :
|
|
- 1 400+ icônes, couvre tous les use cases
|
|
- Licence MIT, pas de dépendance commerciale
|
|
- Cohérent avec le ton "précis pas froid"
|
|
- Bien intégré dans l'écosystème JS (React, Vue, Svelte, Vanilla)
|
|
- **Alternatives** :
|
|
- Phosphor Icons : très joli mais moins universel
|
|
- Heroicons : trop associé Tailwind
|
|
- Custom set : hors scope MVP, retour sur investissement faible
|
|
- **Règle** : le ◆ (gem) reste un SVG custom, jamais une icône Lucide.
|
|
|
|
---
|
|
|
|
## ADR-007 · Mise en demeure : validation manuelle obligatoire
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : l'étape J+20 (ou équivalent) du plan ferme est une mise en demeure. Doit-elle être envoyée automatiquement comme les autres relances ?
|
|
- **Décision** : **non**. Toute mise en demeure passe par une **modale de confirmation** où l'utilisateur clique explicitement "Envoyer la mise en demeure".
|
|
- **Rationale** :
|
|
- Risque légal : la mise en demeure a des conséquences juridiques
|
|
- Risque relationnel : peut casser une relation client durablement
|
|
- Le moment où l'utilisateur veut reprendre le contrôle, c'est exactement à cette étape
|
|
- **UX** : la modale rappelle le contexte légal (loi LME), affiche le contenu de l'email, et propose deux boutons distincts ("Envoyer maintenant" / "Reporter à plus tard").
|
|
- **Anti-pattern à éviter** : checkbox d'auto-envoi, même opt-in. Pas négociable.
|
|
|
|
---
|
|
|
|
## ADR-008 · Banking V1 : check-in email à l'utilisateur
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : sans intégration bancaire en V1, comment éviter de relancer un client qui a déjà payé hors plateforme ?
|
|
- **Décision** : avant chaque envoi de relance, Rubis envoie un email **à l'utilisateur** (pas au client) demandant : "Avez-vous été payé pour la facture X ?" avec deux boutons (Oui / Non).
|
|
- L'utilisateur configure la cadence et le timing (ex. T-2 jours avant la relance suivante)
|
|
- "Oui" → facture marquée encaissée, plan stoppé
|
|
- "Non" ou pas de réponse → la relance part comme prévu
|
|
- **Rationale** :
|
|
- Évite les relances fantômes sur factures déjà payées
|
|
- Garde l'utilisateur informé sans le surcharger
|
|
- Architecture compatible V2 banking : le check-in V1 devient simplement un fallback quand on ajoutera Bridge / Tink / GoCardless
|
|
- **Contrainte architecturale** : modèle d'événement abstrait `payment_status_check` qui peut être déclenché par email-réponse OU webhook bancaire. L'app ne doit pas savoir d'où vient le signal.
|
|
|
|
---
|
|
|
|
## ADR-009 · SMS et multi-utilisateurs : V2, plans payants
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : décider du périmètre V1 vs V2 sur deux features demandées.
|
|
- **Décision** :
|
|
- **SMS** : V2 uniquement, **plan le plus cher seulement** (Business)
|
|
- **Multi-utilisateurs** : V2 uniquement, **plans payants seulement** (Pro et Business, pas Free)
|
|
- **Rationale** :
|
|
- SMS = coût marginal direct (Twilio/OVH/etc.) → doit être monétisé sur le palier le plus rentable
|
|
- Multi-utilisateurs ajoute de la complexité (rôles, invitations, audit) → out of MVP, et c'est un argument upgrade naturel pour les plans payants
|
|
- **Conséquence sur l'archi** :
|
|
- DB structurée multi-tenant dès V1 (`organization` → `users` → `invoices`) pour ne pas refactorer
|
|
- Modèle d'envoi message abstrait (un message peut être email V1, ou SMS/email V2)
|
|
|
|
---
|
|
|
|
## ADR-010 · Pas d'intégration banking en V1
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée
|
|
- **Contexte** : l'intégration banking (Bridge / Tink / Powens) automatiserait la réconciliation des paiements.
|
|
- **Décision** : pas en V1. Remplacée par check-in email (ADR-008).
|
|
- **Rationale** :
|
|
- Coût d'implémentation important (DSP2, agréments, gestion des erreurs banking)
|
|
- Impose de toucher aux données financières du client → friction RGPD/sécurité
|
|
- Le check-in email résout 80 % du problème pour 10 % du coût
|
|
- **À prévoir en V1** : architecture événementielle qui rendra l'intégration V2 mécanique (cf. ADR-008).
|
|
|
|
---
|
|
|
|
## ADR-011 · "3 clics maximum" est une règle de design, pas un compteur
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée (clarification)
|
|
- **Contexte** : la promesse "3 clics" est dans le pitch et la landing. Doit-on la respecter strictement à chaque parcours ?
|
|
- **Décision** : c'est une **règle de design** (l'utilisateur doit faire le minimum d'actions possible) plus qu'un compteur strict. Si le plan par défaut est bien configuré, 2 clics suffisent. Si le contexte demande plus, on peut aller à 4.
|
|
- **Rationale** : "3 clics" est une promesse marketing claire et mémorable. Le vrai principe sous-jacent est "minimum d'actions utilisateur".
|
|
- **Application** :
|
|
- Le storyboard hero (drop → valider → récompense) doit absolument tenir en 3 clics ou moins
|
|
- Les flows secondaires (changer un plan, archiver) peuvent dépasser sans casser la promesse
|
|
- On ne sacrifie pas la clarté pour économiser un clic
|
|
|
|
---
|
|
|
|
## Décisions à venir (en attente)
|
|
|
|
## ADR-013 · Tagline V1 « Vos factures relancées toutes seules pendant que vous travaillez »
|
|
|
|
- **Date** : 2026-05-05
|
|
- **Statut** : ✅ Validée pour la landing V1
|
|
- **Contexte** : 5 taglines candidates explorées dans `/docs/munitions-marketing.md` (douces vs polarisantes vs factuelles).
|
|
- **Décision** : retenir *« Vos factures relancées toutes seules pendant que vous travaillez. »*
|
|
- **Rationale** :
|
|
- Image concrète et duale : vous travaillez / l'app travaille — facile à se représenter
|
|
- Respecte les 4 principes de marque (chaleureuse, action, précise, rubis-centric implicite)
|
|
- Promet le bénéfice (libération de temps) plutôt que le problème (impayés) — différencie de tous les concurrents
|
|
- Tient en signature email, en hero de landing, en pitch oral
|
|
- **Alternatives écartées** :
|
|
- *« Ne mendiez plus jamais ce qu'on vous doit »* : trop polarisante pour la landing. Garde en réserve pour campagnes ads ciblées.
|
|
- *« 3 clics. Plus jamais de relance manuelle »* : trop factuelle, pas d'émotion.
|
|
- *« Arrêtez de courir après votre argent »* : impératif négatif, casse le ton chaleureux.
|
|
- *« L'argent, c'est sérieux. La relance, ça ne devrait plus l'être »* : trop intellectualisée.
|
|
- **À reconfirmer** : après MVP, A/B testable sur Google Ads contre la version polarisante.
|
|
|
|
---
|
|
|
|
## Décisions à venir (en attente)
|
|
|
|
| # | Sujet | Pourquoi en attente |
|
|
|---|---|---|
|
|
| 014 | Stack technique (framework, DB, OCR provider, email provider, hosting) | À formaliser avec Arthur |
|
|
| 015 | Structure DB / domain model | Dépend de 014 |
|
|
| 016 | Pricing exact (Free 5 factures ? Pro 19 € ?) | À tester avant figer |
|
|
| 017 | Provider OCR (Mindee, Document AI, Textract, open-source) | Dépend de coût/qualité — à benchmarker |
|
|
| 018 | Endpoint waitlist (Resend / Formspree / Tally / API perso) | Choix au déploiement de la landing |
|
|
|
|
---
|
|
|
|
## Comment ajouter une décision
|
|
|
|
```markdown
|
|
## ADR-XXX · Titre court
|
|
|
|
- **Date** : YYYY-MM-DD
|
|
- **Statut** : ✅ Validée | 🟡 En cours | ❌ Annulée par ADR-YYY
|
|
- **Contexte** : la situation qui appelle la décision
|
|
- **Décision** : ce qu'on fait
|
|
- **Rationale** : pourquoi (avec preuves/data si possible)
|
|
- **Alternatives écartées** : ce qu'on n'a pas fait, et pourquoi
|
|
- **Conséquences** : impact sur l'archi, le produit, la marque
|
|
```
|
|
|
|
Quand une décision est remise en cause, on **ajoute** un ADR qui annule l'ancien (jamais éditer rétroactivement). C'est ça qui rend le log fiable comme mémoire d'équipe.
|