1. Problème
Les utilisateurs disposant de plusieurs comptes (professionnel, personnel, épargne, joint, devises, courtage) ne voient pas dans l’application comment l’argent circule entre leurs comptes au cours d’un cycle donné. Le tableau de bord affiche les soldes et les catégories de dépenses, mais ne répond pas aux questions du type :
- « Combien de la dernière facture est réellement resté sur l’épargne, et combien est passé en transit ? »
- « Depuis quel compte les virements vers l’épargne ont-ils été effectués ? »
- « Qu’est-ce qui reste à payer dans ce cycle ? »
Actuellement, ces analyses sont créées ad hoc dans le chat avec l’IA sous forme de graphe textuel — sans accès aux données par compte, ce qui impose des heuristiques et des approximations (voir : bug de l’absence d’`account_id` et des soldes par compte dans le contexte analytique).
2. Proposition
Vue interactive native « Flux » (onglet à côté de Patrimoine / Dépenses), affichée pour un cycle financier ou un mois calendaire sélectionné :
2.1. Structure du graphe
- Nœuds d’entrée — sources de revenus (factures, salaire, intérêts) avec montants.
- Nœuds-comptes — chaque compte de l’utilisateur comme nœud distinct avec deux valeurs : entrée dans le cycle et solde après flux.
- Nœuds de sortie — dépenses regroupées par catégorie, avec montants.
- Arêtes — virements avec montants ; la couleur/type distingue les virements internes (transit) des dépenses réelles.
2.2. Fonctionnalités clés
- Palette sémantique : vert = épargne/investissements (l’argent reste dans le système de l’utilisateur), jaune = transit entre comptes, rouge = dépenses (l’argent sort).
- Résumé du cycle : combien est allé vers l’épargne vs. dépenses vs. transit — sous forme de barre/tableau sous le graphe.
- Perspective temporelle : bascule cycle financier ↔ mois calendaire ; curseur temporel pour animer les flux.
- « En attente de paiement » : section avec les engagements prévus mais non encore payés du cycle (impôts, échéances, charges fixes) — sur la base des schémas de paiement détectés.
- Interactivité : clic sur nœud/arête → drill-down vers la liste des transactions ; survol → détails du virement.
2.3. Données requises (dépendances)
Cette fonctionnalité nécessite d’abord de combler les lacunes dans les données :
- `account_id` par transaction — propagation de l’identifiant du compte source à la couche analytique (aujourd’hui les transactions sont agrégées par banque).
- Soldes par compte — depuis l’endpoint `GET /accounts/{id}/balances`, actualisés à chaque synchronisation.
- Mappage des comptes aux rôles — configurable par l’utilisateur (professionnel / personnel / épargne / joint / devises / courtage), enregistré dans le profil ; l’IA peut les suggérer automatiquement sur la base des schémas de transactions (ex. : entrée de factures + sécurité sociale → professionnel).
Sans les points 1 et 2, le graphe aura le même problème que la solution de chat actuelle : des directions supposées, non confirmées.
3. Valeur pour l’utilisateur
- Conscience, pas seulement enregistrement : l’utilisateur voit quelle part du revenu reste réellement (épargne) vs. sort — en un seul coup d’œil au lieu d’une reconstruction manuelle.
- Vérification des habitudes : par ex. « environ 17 % de chaque facture atterrit sur l’épargne » devient immédiatement visible.
- Contrôle des engagements : la section « en attente de paiement » prévient les mauvaises surprises en fin de cycle.
- Réduction des questions à l’IA : le graphe répond à la classe de requêtes « où est passé mon argent », qui génèrent aujourd’hui de longues analyses dans le chat.
4. Périmètre MVP vs. extensions
MVP
Graphe statique par cycle : comptes + flux + dépenses par catégorie, couleurs sémantiques, tableau récapitulatif
v1.1
Soldes après flux, drill-down vers les transactions, section « en attente de paiement »
v1.2
Animation temporelle, comparaison de cycles, suggestions de mappage automatique des rôles de comptes
- Risques
- Qualité des données : sans `account_id` par transaction, le graphe sera trompeur — la fonctionnalité ne devrait démarrer qu’après avoir comblé les lacunes de données (ou avec un marquage explicite des attributions heuristiques).
- Complexité visuelle : avec > 8 comptes, le graphe devient illisible — il faut un regroupement (ex. : repli des comptes devises) et des limites sur le nombre de nœuds de dépenses (top N + « autres »).
- Classification des virements internes : la détection des paires de virements internes (même montant, même jour, deux comptes) doit être robuste face aux données manquantes et aux conversions de devises.