Contexte

Fintello permet actuellement de gérer les finances d'un foyer (Family), mais un seul utilisateur peut y accéder. Dans la réalité, un foyer est souvent composé de plusieurs personnes (couple, colocation, famille) qui souhaitent gérer leurs finances ensemble tout en conservant une certaine autonomie.

Besoin utilisateur

"Je veux inviter mon/ma conjoint(e) à rejoindre notre foyer Fintello pour qu'on puisse tous les deux suivre nos finances communes, tout en gardant certaines dépenses privées"

---

⚠️ Cette issue est une RÉFLEXION

Objectif : Définir le périmètre, les sous-issues à créer, et les décisions d'architecture à prendre AVANT de développer.

Cette feature est structurante et impacte :

• Le modèle de données (Family, User, permissions)
• La sécurité et la privacy
• L'UX globale de l'application
• Potentiellement le modèle économique (pricing par foyer vs par utilisateur)

---

🤔 Questions à trancher

1. Modèle de fusion des données

Quand un utilisateur B rejoint le foyer de A, que fait-on de ses données existantes ?

Option	Description	Avantages	Inconvénients
Fusion complète	Tous les comptes/transactions de B migrent vers le foyer A	Simple, tout est partagé	Pas de retour arrière, perte d'autonomie
Import sélectif	B choisit quels comptes importer dans le foyer	Flexibilité	Complexité UX, données dupliquées ?
Comptes liés	B garde son foyer mais peut voir/contribuer au foyer A	Autonomie préservée	2 foyers à gérer, confusion
Fusion + comptes privés	Tout migre mais certains comptes sont marqués "privés"	Bon compromis	Complexité modèle de données

Recommandation : Option 4 (Fusion + comptes privés)

2. Gestion de la privacy

Quelles données peuvent être privées ?

Donnée	Partageable ?	Privé possible ?
Comptes bancaires	✅ Oui	✅ Oui (compte perso)
Transactions	✅ Oui	✅ Oui (si compte privé)
Budgets	✅ Oui	❓ À définir
Abonnements	✅ Oui	❓ À définir
Catégories	✅ Partagées	❌ Non (communes au foyer)
Objectifs d'épargne	✅ Oui	✅ Oui (objectif perso)

3. Rôles et permissions

Rôle	Permissions
Propriétaire	Tout (inviter, exclure, supprimer foyer)
Membre	CRUD sur données partagées, voir ses données privées
Lecture seule	Consulter uniquement (pour un enfant, un comptable ?)

4. Processus d'invitation

┌─────────────┐    Invitation    ┌─────────────┐
│  User A     │ ──────────────▶  │  User B     │
│ (proprio)   │                  │ (invité)    │
└─────────────┘                  └─────────────┘
                                       │
                    ┌──────────────────┼──────────────────┐
                    ▼                  ▼                  ▼
              [Accepter]         [Refuser]          [Ignorer]
                    │
                    ▼
        ┌─────────────────────┐
        │ Choix des données   │
        │ à importer/garder   │
        │ privées             │
        └─────────────────────┘
                    │
                    ▼
        ┌─────────────────────┐
        │ Fusion effectuée    │
        │ B rejoint foyer A   │
        └─────────────────────┘

5. Cas de séparation (quitter le foyer)

Que se passe-t-il si B quitte le foyer ?

• Ses comptes privés repartent avec lui
• Les comptes partagés restent dans le foyer
• Les transactions qu'il a créées sur comptes partagés restent
• Option : exporter ses données avant de partir

---

📋 Sous-issues à créer (draft)

Phase 1 : Fondations

• DEF-XX : Ajouter le concept de "compte privé" (visible uniquement par son propriétaire)
• DEF-XX : Ajouter le champ ownerId sur les entités (qui a créé quoi)
• DEF-XX : Implémenter les rôles Propriétaire/Membre sur Family

Phase 2 : Invitation

• DEF-XX : Créer le système d'invitation par email
• DEF-XX : Page d'acceptation d'invitation avec choix des données
• DEF-XX : Migration des données de l'invité vers le nouveau foyer

Phase 3 : Privacy

• DEF-XX : Filtrer les données privées dans toutes les requêtes API
• DEF-XX : UI pour marquer un compte comme privé
• DEF-XX : Indicateur visuel "Privé" dans l'interface

Phase 4 : Gestion du foyer

• DEF-XX : Page "Gérer le foyer" (voir membres, rôles)
• DEF-XX : Exclure un membre du foyer
• DEF-XX : Quitter un foyer (avec export de données)

---

🔒 Considérations sécurité

1. RLS Supabase : Les policies doivent être revues pour gérer :

   • Données du foyer (tous les membres)
   • Données privées (owner uniquement)

2. Invitation sécurisée : Token unique, expiration, validation email

3. Audit trail : Qui a modifié quoi ? (important en cas de litige)

---

💰 Impact pricing

Modèle actuel	Modèle possible
1 user = 1 abo	1 foyer = 1 abo (jusqu'à X membres)
	ou : membre supplémentaire = +Y€/mois

---

📊 Estimation globale

Phase	Complexité	Estimation
Phase 1 : Fondations	Haute	20-30h
Phase 2 : Invitation	Moyenne	15-20h
Phase 3 : Privacy	Haute	15-25h
Phase 4 : Gestion	Moyenne	10-15h
TOTAL		60-90h

---

✅ Prochaines étapes

1. Valider les choix d'architecture (fusion + comptes privés ?)
2. Définir le MVP (quelles phases sont indispensables ?)
3. Créer les sous-issues avec specs détaillées
4. Prototyper l'UX (maquettes invitation, gestion foyer)

---

Critères d'acceptation (pour cette issue de réflexion)

• Décisions d'architecture documentées et validées
• Sous-issues créées avec périmètre clair
• Maquettes UX des parcours critiques
• Impact sur le modèle de données identifié
• Estimation affinée après découpage