ordinarthur/rubis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
rubis/docs/decisions.md
ordinarthur 89ca81d839 init doc rubis
2026-05-05 15:29:20 +02:00

10 KiB
Raw Blame History

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)

# Sujet Pourquoi en attente
012 Stack technique (framework, DB, OCR provider, email provider, hosting) À formaliser avec Arthur
013 Tagline finale 5 candidates dans /munitions-marketing.md, pas tranchée
014 Structure DB / domain model Dépend de 012
015 Pricing exact (Free 5 factures ? Pro 19 € ?) À tester avant figer
016 Provider OCR (Mindee, Document AI, Textract, open-source) Dépend de coût/qualité — à benchmarker

Comment ajouter une décision

## 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.