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