TaxActes/DECISIONS.md

TaxActe — Registre des Décisions

Log des décisions importantes prises pendant le développement

---

Format

Chaque décision suit ce template :

## [DATE] Titre de la Décision

**Contexte** : [Pourquoi cette décision est nécessaire]

**Options Considérées** :
1. Option A : [Description]
2. Option B : [Description]
3. Option C : [Description]

**Décision** : [Option choisie]

**Rationale** : [Pourquoi cette option]

**Conséquences** :
- ✅ [Avantages]
- ⚠️ [Trade-offs]
- 🔴 [Risques]

**Acteurs** : [Qui a pris la décision]

---

Décisions Initiales (Avant Phase 0)

2026-05-15 — Architecture Monolithique

Contexte : Choix entre monolithe Next.js vs microservices

Options Considérées :

1. Monolithe Next.js (API Routes + SSR)
2. Backend séparé (Express/Fastify) + Frontend Next.js
3. Microservices (calculs, auth, PDF séparés)

Décision : Monolithe Next.js

Rationale :

• Simplicité : pas besoin de microservices pour un outil de calcul
• SSR disponible pour SEO futur (widget public)
• Déploiement simplifié
• Équipe réduite (pas besoin d'orchestration)

Conséquences :

• ✅ Développement plus rapide
• ✅ Déploiement simple
• ⚠️ Scaling futur nécessitera refactoring si volume > 1000 offices
• ✅ Serverless compatible (Scaleway)

---

2026-05-15 — Auth Custom (JWT + bcrypt)

Contexte : Choix de la solution d'authentification

Options Considérées :

1. NextAuth.js (Auth.js)
2. JWT custom (jose + bcryptjs)
3. Supabase Auth
4. Clerk

Décision : JWT custom

Rationale :

• NextAuth en beta pour App Router
• Contrôle total sur le flow
• Pas de dépendance externe
• Simple pour le cas d'usage (email/password)

Conséquences :

• ✅ Pas de dépendance beta
• ✅ Contrôle total
• ⚠️ Responsabilité sécurité sur nous
• ⚠️ À auditer attentivement (Phase 0)

---

2026-05-15 — IA = Extracteur, Pas Calculateur

Contexte : Rôle de l'IA dans l'application

Options Considérées :

1. IA fait tout (extraction + calcul)
2. IA extrait paramètres → fonction pure calcule
3. Pas d'IA du tout (formulaires seulement)

Décision : IA extrait → fonction pure calcule

Rationale :

• LLM peut halluciner ou mal formater du JSON
• Calculs doivent être 100% exacts (responsabilité professionnelle)
• Validation Zod entre IA et calcul = sécurité
• Fonctions pures = testables, auditables, déterministes

Conséquences :

• ✅ Garantie de conformité calculs
• ✅ IA comme différenciateur (UX) sans risque (précision)
• ✅ Testable séparément
• ⚠️ Validation Zod doit être stricte

---

2026-05-15 — Settings en BDD (pas localStorage)

Contexte : Où stocker les paramètres de l'étude (marge, couleurs, logo)

Options Considérées :

1. localStorage (côté client)
2. PostgreSQL (table Office)
3. Fichier de config (JSON)

Décision : PostgreSQL

Rationale :

• Un clerc se connectant depuis un autre poste doit retrouver les paramètres
• Données métier (marge de sécurité) doivent être persistées
• localStorage uniquement pour cache UI éphémère

Conséquences :

• ✅ Persistance multi-postes
• ✅ Backup automatique avec la BDD
• ⚠️ Latence initiale (fetch au login)
• ✅ Cohérence garantie

---

Décisions Phase 0

2026-05-15 — Stratégie B : MVP + RAG Intégré (12 semaines)

Contexte : Choix entre lancer MVP d'abord (10 semaines) puis RAG en v1.1 (+ 3 semaines) OU intégrer le RAG dans le MVP (12 semaines)

Options Considérées :

1. Stratégie A : MVP en 10 semaines → RAG en v1.1 (total 13 semaines)
2. Stratégie B : MVP + RAG intégré (12 semaines)

Décision : Stratégie B (MVP + RAG intégré)

Rationale :

• Différenciation immédiate : Le RAG (aide à la taxation + actes complexes) est l'argument de vente unique vs Notafrais
• Documents disponibles : Accès confirmé aux guides de taxation notariale CSN
• 1 seule phase de communication : Lancement avec le différenciateur dès le départ
• Feedback pilotes complet : Valider calculs standard ET complexes ensemble
• Gain de temps réel pour notaires : Actes complexes 30-60 min → 5-10 min (70-80% gain)

Conséquences :

• ✅ Différenciation maximale dès v1
• ✅ Validation complète avec pilotes (calculs + RAG)
• ⚠️ Planning serré : 12 semaines (14 avec buffer)
• ⚠️ Dépendance critique : documents RAG doivent être prêts à S4-S5
• ✅ Pivot possible : si retard > 1 semaine, basculer sur Stratégie A

Acteurs : Décision validée avec le client (accès documents confirmé)

Plan de mitigation :

• Démarrage préparation documents RAG dès S2 (parallèle sécurisation)
• Checkpoint S3 : validation 50%+ documents convertis
• Checkpoint S5 : validation 100% documents finalisés (CRITIQUE BLOQUANT)
• Plan B : Si documents non prêts à S5 → reporter RAG en v1.1

---

Décisions Phase 1+

À compléter au fur et à mesure