docs(collapse): ADR 0016 per-profile UI state + guide, architecture, i18n

Document the final multi-level category collapse behavior (shipped in #288/#289/#290) and the structural decision to persist per-profile UI state in user_preferences rather than localStorage. - ADR 0016 (accepted): profile-specific UI state (category collapse) lives in the profile's own SQLite user_preferences table, not localStorage. deleteProfile drops the .db but purges no localStorage, so a per-profile localStorage key would be a residue surviving profile deletion, leaking which categories a (possibly PIN-protected) profile explored. States the boundary: profile-specific -> user_preferences; machine-global (theme, subtotals position, Cartes period mode) -> localStorage. - guide-utilisateur.md sections 8 (Budget) + 9 (Reports): multi-level collapse, collapsed-by-default, "Expand all / Collapse all" button, memory per profile. - docs.* i18n keys (fr + en): mirror the guide additions in the in-app help page (docs.budget + docs.reports features/tips). - architecture.md: user_preferences line now names the 4 collapse keys, useCollapsibleGroups cross-cutting hook note, ADR index row. No DB migration, no behavior change (docs only). Build clean, 828 vitest. Resolves #291 Generated autonomously by /autopilot run of 2026-07-15 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-15 21:43:44 -04:00 · 2026-07-15 21:43:44 -04:00 · 5a3d87b31f
commit 5a3d87b31f
parent 9f628aa9f4
7 changed files with 486 additions and 8 deletions
--- a/docs/adr/0016-persistance-etat-ui-par-profil.md
+++ b/docs/adr/0016-persistance-etat-ui-par-profil.md
@ -0,0 +1,87 @@
+# ADR 0016 — Persistance de l'état UI par profil : le repli des catégories vit dans `user_preferences`
+
+- Status: **Accepted**
+- Date: 2026-07-15
+- Issues: #288 (socle multi-niveaux + 3 rapports + bascule vers `user_preferences`), #289 (grille budget), #290 (unification des deux arbres de catégories), #291 (cet ADR + doc)
+- Spec: [`spec-decisions-collapse-multi-niveaux.md`](../../spec-decisions-collapse-multi-niveaux.md), [`spec-plan-collapse-multi-niveaux.md`](../../spec-plan-collapse-multi-niveaux.md) (plan v2)
+- S'appuie sur [ADR 0005](0005-multi-profile-db.md) (bases SQLite séparées par profil) et [ADR 0002](0002-useReducer-vs-redux.md) (état local, pas de store global)
+
+## Contexte
+
+Le repli/dépli des catégories a d'abord été introduit sur les deux rapports comparables (issue #254/#265) : un `Set` d'ID de catégories par rapport, persisté en **`localStorage`**, replié par défaut. La généralisation (issues #288/#289/#290) a étendu ce mécanisme à **tous les niveaux** de la hiérarchie et à **six surfaces** : les trois tableaux de rapports hiérarchiques (comparable réel-vs-réel `ComparePeriodTable`, réel-vs-budget `BudgetVsActualTable`, tendance par catégorie `CategoryOverTimeTable`), la **grille budgétaire** (`BudgetTable`), et les **deux arbres de gestion des catégories** (`CategoryTree` de la page Catégories + `CategoryTaxonomyTree` du guide standard et de l'assistant de migration).
+
+Cette généralisation a forcé une question qui n'était pas tranchée en #254 : **où vit l'état de repli ?** Deux propriétés du produit rendent le choix structurant, pas cosmétique.
+
+1. **L'app est multi-profils à bases séparées** ([ADR 0005](0005-multi-profile-db.md)) : chaque profil a sa **propre base SQLite**, ses propres catégories, ses propres ID de catégories. Un profil peut être **protégé par un NIP** (Argon2). Supprimer un profil = **supprimer son fichier `.db`** (`deleteProfileDb` → commande Rust `delete_profile_db`) + retirer son entrée de `profiles.json`. Rien d'autre n'est nettoyé — `deleteProfile` (`ProfileContext`) ne touche **jamais** `localStorage`.
+
+2. **`localStorage` est machine-global**, partagé par tous les profils du poste. La clé de repli est un ensemble d'**ID de catégories** (`p:<categoryId>`), et ces ID n'ont de sens que **dans la base d'un profil donné** : le même ID numérique désigne des catégories différentes selon le profil. Une clé de repli en `localStorage` serait donc soit **en collision entre profils** (mêmes ID, catégories différentes), soit suffixée par `profileId` — et dans ce dernier cas, elle **survivrait à la suppression du profil**, devenant un **résidu**.
+
+Ce résidu n'est pas anodin : l'ensemble des catégories qu'un profil a **dépliées** révèle quelles postes de dépense l'utilisateur a explorés. Le laisser traîner en `localStorage` après la suppression d'un profil (potentiellement NIP-protégé) trahit une part de son comportement financier. C'est **incompatible avec le principe privacy-first** (non négociable) du projet.
+
+## Décision
+
+**L'état UI *spécifique à un profil* est persisté dans la table `user_preferences` de la base du profil ; l'état UI *machine-global* reste dans `localStorage`.** Le repli des catégories relève du premier cas.
+
+### 1. Frontière `user_preferences` vs `localStorage`
+
+| Nature de l'état | Support | Pourquoi | Exemples |
+|---|---|---|---|
+| **Spécifique au profil** (dépend des données du profil, ou révèle son usage) | `user_preferences` (base SQLite du profil) | Scoping par-profil **gratuit** (la clé vit dans la base du profil) ; **détruit avec le profil** (drop du `.db`) ⇒ zéro résidu | **Repli des catégories** des rapports + grille budget (clés `reports-compare-expanded`, `reports-bva-expanded`, `reports-trends-expanded`, `budget-grid-expanded`) ; `import_folder`, `balance_show_returns`, `balance_starter_proposed` (préexistants) |
+| **Machine-globale** (scalaire agnostique du profil, ne révèle rien de sensible) | `localStorage` | On *veut* la même valeur quel que soit le profil ouvert ; aucune fuite si elle survit à une suppression | Thème clair/sombre (`theme`), position des sous-totaux (`*-subtotals-position`), mode de période Cartes (`reports-cartes-period-mode`), bascule graphique/tableau par rapport |
+
+Le critère : une préférence est **machine-globale** quand sa valeur est un scalaire agnostique du profil (`"top"`/`"bottom"`, `"dark"`, `"chart"`) qu'on souhaite partager entre tous les profils du poste. Elle est **spécifique au profil** dès qu'elle est indexée par des identifiants propres à la base du profil (les ID de catégories du repli) **ou** qu'elle expose l'usage d'un profil donné.
+
+### 2. Mécanisme — `useCollapsibleGroups(storageKey: string | null)`
+
+Le hook `useCollapsibleGroups` porte cette décision via un unique paramètre `storageKey` :
+
+- **`storageKey` non nul** ⇒ persistance dans `user_preferences` via `userPreferenceService` (`getPreference`/`setPreference`, UPSERT sur `key`). Utilisé par les **quatre surfaces persistées** (3 rapports + budget). La valeur sérialisée est le `Set` des clés dont l'état **diffère du défaut** — ce qui permet un défaut « tout replié » sans graine (Set vide = tout replié pour `defaultExpanded: false`).
+- **`storageKey === null`** ⇒ **aucune persistance**, état purement en mémoire, réinitialisé au défaut à chaque montage. Utilisé par les **deux arbres de catégories** (page Catégories, guide standard, assistant de migration) : leur repli est un confort de navigation éphémère, sans intérêt à conserver ni à révéler.
+
+Le hook reste **sans contexte** — il n'appelle jamais `useProfile()` : la clé `user_preferences` est **déjà** par-profil, puisqu'elle vit dans la base du profil actif. Aucun `profileId` à faufiler.
+
+### 3. Rationale privacy — le résidu qui survit à la suppression
+
+C'est l'argument central. `deleteProfile` détruit la base (`.db`) mais **ne purge aucun `localStorage`**. Une clé de repli par-profil en `localStorage` (ex. `reports-compare-expanded:<profileId>`) survivrait donc à la suppression du profil, laissant deviner **quelles catégories** un profil désormais supprimé — et peut-être NIP-protégé — avait explorées. En logeant l'état dans `user_preferences`, il **disparaît avec le fichier `.db`** : la suppression du profil emporte automatiquement son état UI, sans code de nettoyage dédié et sans surface de fuite. La propriété « supprimer un profil = supprimer un fichier » ([ADR 0005](0005-multi-profile-db.md)) est préservée telle quelle.
+
+## Alternatives considérées
+
+### A. `localStorage` suffixé par `profileId` — **rejeté**
+
+Garder le repli en `localStorage` avec une clé `…:<profileId>` par profil. Rejeté : c'est précisément le **résidu** décrit ci-dessus (survit à `deleteProfile`, fuite privacy), et il faudrait ajouter un balayage de nettoyage dans `deleteProfile` — du code fragile qui doit connaître toutes les clés UI par-profil de l'app, à maintenir à chaque nouvelle surface repliable.
+
+### B. Table SQLite dédiée (`ui_collapse_state`) — rejeté
+
+Créer une table par-profil rien que pour le repli. Rejeté : sur-dimensionné. `user_preferences` est déjà une table clé-valeur par-profil faite pour ça (`import_folder`, `balance_show_returns`…) ; une clé par surface suffit, sans migration.
+
+### C. Tout en mémoire (aucune persistance) — rejeté pour les rapports/budget
+
+Simple, zéro résidu. Rejeté pour les **quatre** surfaces persistées : sur des tableaux profonds, re-replier à chaque visite est une friction réelle (finding remonté en #254). **Retenu en revanche pour les deux arbres de catégories** (`storageKey: null`) — d'où le paramètre nullable plutôt qu'un choix uniforme.
+
+## Consequences
+
+### Positives
+
+- **Zéro résidu, zéro fuite** : l'état de repli est détruit avec le `.db` du profil ; aucune trace machine-globale de l'usage d'un profil supprimé. Conforme privacy-first.
+- **Scoping par-profil gratuit** : la clé vit dans la base du profil ⇒ isolation automatique, hook sans contexte, pas de `profileId` à propager.
+- **Réutilise l'existant** : `user_preferences` + `userPreferenceService` déjà en place ⇒ **aucune migration, aucune table, aucun changement de schéma**.
+- **Frontière tracée** : la règle « profil-spécifique → `user_preferences` ; machine-globale → `localStorage` » est explicite (§1) ⇒ le prochain état UI par-profil ne repartira pas en `localStorage` par défaut (caveat de review levé).
+
+### Négatives / risques actés
+
+- **Hydratation asynchrone** : `getPreference`/`setPreference` sont `async` (passent par `getDb()`). L'état initial rendu est le **défaut** (tout replié pour les rapports/budget), puis un `useEffect` hydrate depuis `user_preferences`. **Pas de flash visible** : le défaut EST ce qui s'affiche en premier, et l'hydratation ne peut que **révéler** ce que l'utilisateur avait déplié (jamais masquer ce qui était visible). Acceptable — c'est la contrepartie assumée du choix.
+- **Best-effort** : une lecture/écriture en échec retombe silencieusement sur l'état par défaut (jamais de crash). Une écriture perdue = la session suivante rouvre au défaut.
+- **Frontière à faire respecter dans la durée** : rien dans le type ne force un futur état par-profil à choisir `user_preferences`. La règle est documentaire (cet ADR + `docs/architecture.md`) — d'où l'importance de l'avoir tracée.
+
+### Neutre
+
+- Les préférences machine-globales existantes (`theme`, `*-subtotals-position`, `reports-cartes-period-mode`, bascule graphique/tableau) **restent en `localStorage`** : elles sont volontairement partagées entre profils et ne révèlent rien de sensible en cas de suppression. Aucune migration de ces clés n'est entreprise.
+
+## Liens
+
+- [ADR 0005](0005-multi-profile-db.md) — bases SQLite séparées par profil ; « supprimer un profil = supprimer un fichier `.db` » (fondement de l'argument résidu)
+- [ADR 0002](0002-useReducer-vs-redux.md) — état local par domaine, pas de store global (le repli reste un état UI local persisté à la marge)
+- `src/hooks/useCollapsibleGroups.ts` — implémentation (`storageKey: string | null`, `defaultExpanded`, hydratation async)
+- `src/utils/collapsibleRows.ts` — helpers purs (marche des ancêtres, polarité du `Set`)
+- `src/services/userPreferenceService.ts` — `getPreference`/`setPreference` (UPSERT sur `user_preferences`)
+- Issues #254/#265 (repli d'origine, localStorage) → #288/#289/#290 (généralisation + bascule `user_preferences`) → #291 (cette doc)
--- a/docs/architecture.md
+++ b/docs/architecture.md
@ -89,7 +89,7 @@ simpl-resultat/
 | `budget_templates` | Modèles de budget réutilisables |
 | `budget_template_entries` | Catégories et montants dans les modèles |
 | `import_config_templates` | Modèles prédéfinis de config d'import |
-| `user_preferences` | Préférences applicatives (clé-valeur) |
+| `user_preferences` | Préférences applicatives (clé-valeur) — `import_folder`, `balance_show_returns`, `balance_starter_proposed`… **et l'état de repli des catégories** (clés `reports-compare-expanded`, `reports-bva-expanded`, `reports-trends-expanded`, `budget-grid-expanded`) : persisté ici **par profil** plutôt qu'en `localStorage`, pour être détruit avec le profil (pas de résidu machine-global survivant à la suppression) — voir [ADR 0016](adr/0016-persistance-etat-ui-par-profil.md) |
 | `balance_categories` | Taxonomie des **classes d'actif** (Liquidités, Fonds/FNB, Actions, Crypto, Autres) — `kind ∈ {simple, priced}` (défaut suggéré pour les nouveaux comptes), `custom_label` pour le renommage bilingue-safe (v12). Les ex-types véhicules (TFSA/RRSP) ont migré vers `balance_accounts.vehicle_type` (Étape 1, v12/v13, [ADR 0014](adr/0014-balance-vehicule-attribut.md)) |
 | `balance_accounts` | Comptes de bilan (rattachés à une catégorie). `currency` hardcodée à `CAD` au MVP via CHECK. `archived_at` pour soft-delete. `vehicle_type` (enveloppe fiscale nullable, v12, [ADR 0014](adr/0014-balance-vehicule-attribut.md)). `kind ∈ {simple, detailed}` + `detailed_since` (pivot faisant autorité, v15, [ADR 0015](adr/0015-balance-detail-par-titre.md)) — porte désormais l'axe simple/détaillé (auparavant dérivé de `category.kind`). **Issue #179** : 4 comptes de départ seedés (`consolidated_schema.sql`) + proposés aux profils existants via `StarterAccountsModal` |
 | `balance_snapshots` | Snapshots datés (`snapshot_date` UNIQUE) — éditer = mettre à jour les lignes, pas dupliquer |
@ -221,6 +221,13 @@ Chaque hook encapsule la logique d'état via `useReducer` :
 | `useLicense` | État de la licence et entitlements |
 | `useAuth` | Authentification Compte Maximus (OAuth2 PKCE, subscription status) |

+### Hook transverse — `useCollapsibleGroups`
+
+`useCollapsibleGroups<T>(storageKey: string | null, accessors, { defaultExpanded })` est un hook **utilitaire d'état UI** (basé `useState`, hors convention `useReducer` par domaine) partagé par toutes les surfaces à hiérarchie repliable : les 3 tableaux de rapports (`ComparePeriodTable`, `BudgetVsActualTable`, `CategoryOverTimeTable`), la grille budget (`BudgetTable`) et les 2 arbres de catégories (`CategoryTree`, `CategoryTaxonomyTree`). Les helpers purs (marche des ancêtres pour la visibilité, polarité du `Set` selon `defaultExpanded`) vivent dans `src/utils/collapsibleRows.ts`.
+
+- `storageKey` **non nul** → l'état de repli est **persisté par profil** dans `user_preferences` (via `userPreferenceService`), donc détruit avec le profil, sans résidu `localStorage` ([ADR 0016](adr/0016-persistance-etat-ui-par-profil.md)). Quatre surfaces persistées (les 3 rapports + budget). Hydratation **asynchrone** : le défaut (« tout replié » pour rapports/budget) est rendu d'abord, un `useEffect` hydrate ensuite → pas de flash visible.
+- `storageKey === null` → état **purement en mémoire**, réinitialisé à chaque montage (les 2 arbres de catégories : navigation éphémère, rien à conserver ni à révéler).
+
 ## Commandes Tauri (36)

 ### `fs_commands.rs` — Système de fichiers (6)
@ -429,3 +436,4 @@ Les ADRs documentent les décisions techniques structurantes. Ils vivent dans `d
 | [0013](adr/0013-stocks-provider-evaluation.md) | Évaluation provider stocks : Alpha Vantage retenu comme cible | 2026-05-09 | Accepted |
 | [0014](adr/0014-balance-vehicule-attribut.md) | Bilan : le véhicule fiscal est un attribut du compte (Étape 1) | 2026-06-01 | Accepted |
 | [0015](adr/0015-balance-detail-par-titre.md) | Bilan : détail par titre (holdings par snapshot, Étape 2) | 2026-06-06 | Accepted |
+| [0016](adr/0016-persistance-etat-ui-par-profil.md) | Persistance de l'état UI par profil : repli des catégories dans `user_preferences` | 2026-07-15 | Accepted |
--- a/docs/guide-utilisateur.md
+++ b/docs/guide-utilisateur.md
@ -226,6 +226,7 @@ Planifiez votre budget mensuel pour chaque catégorie et suivez le prévu par ra
 - Répartition égale du montant annuel sur 12 mois
 - Modèles de budget pour sauvegarder et appliquer des configurations
 - Sous-totaux par catégorie parente
+- Repli / dépli de la hiérarchie à **chaque niveau** : chaque catégorie parente a son chevron, la grille s'ouvre **entièrement repliée** (seules les catégories de premier niveau visibles), et un bouton **« Tout déplier / Tout replier »** ouvre ou ferme tous les niveaux d'un coup — votre choix est mémorisé **par profil**
 - En-têtes de colonnes fixes au défilement vertical

 ### Comment faire
@ -241,6 +242,7 @@ Planifiez votre budget mensuel pour chaque catégorie et suivez le prévu par ra
 - La colonne Annuel additionne automatiquement les 12 mois — un avertissement apparaît si les totaux mensuels ne correspondent pas
 - Les modèles peuvent être appliqués à des mois spécifiques ou aux 12 mois d'un coup
 - Les catégories parentes affichent les sous-totaux agrégés de leurs enfants
+- Replier une catégorie est **purement visuel** : les sous-totaux et les totaux annuels sont toujours calculés sur toutes les lignes, jamais seulement sur les lignes visibles — aucun montant saisi n'est perdu quand vous repliez

 ---

@ -319,7 +321,7 @@ Toujours mensuelle, indépendamment du toggle.
 ### Rapport Tendances (`/reports/trends`)

 - **Flux global** : revenus vs dépenses vs solde net sur la période, en graphique d'aires ou tableau
- **Par catégorie** : évolution de chaque catégorie, en lignes ou tableau pivot
+- **Par catégorie** : évolution de chaque catégorie, en lignes ou tableau. En mode tableau, la hiérarchie se **replie / déplie à chaque niveau** (voir ci-dessous)

 ### Rapport Comparables (`/reports/compare`)

@ -329,6 +331,10 @@ Trois modes accessibles via un tab bar :
 - **Année vs année précédente** — même logique sur 12 mois vs 12 mois
 - **Réel vs budget** — reprend la vue Budget vs Réel avec ses totaux mensuels et cumul annuel

+#### Repli de la hiérarchie
+
+Les trois modes ci-dessus, comme le tableau **Par catégorie** des Tendances, présentent les catégories en arbre repliable **à chaque niveau**. Chaque catégorie parente — y compris les niveaux intermédiaires — porte son propre chevron : le déplier révèle ses enfants directs (eux-mêmes repliés), de sorte que vous descendez d'un niveau à la fois. Le tableau s'ouvre **entièrement replié** (seules les catégories de premier niveau visibles) ; le bouton **« Tout déplier / Tout replier »** ouvre ou ferme tous les niveaux d'un coup. Replier une catégorie est **purement visuel** — les sous-totaux, totaux et lignes de résultat restent calculés sur l'ensemble des lignes, jamais sur les seules lignes visibles. Vos choix de repli sont **mémorisés par profil** (dans la base du profil, ils disparaissent donc avec lui).
+
 ### Rapport Zoom catégorie (`/reports/category`)

 Choisissez une catégorie dans la combobox en haut. Par défaut le rapport inclut automatiquement les sous-catégories (toggle *Directe seulement* pour les exclure). Vous voyez :
--- a/spec-decisions-collapse-multi-niveaux.md
+++ b/spec-decisions-collapse-multi-niveaux.md
@ -0,0 +1,72 @@
+# Spec Decisions — Repli/dépliage à chaque niveau de la hiérarchie
+
+> Date: 2026-07-13
+> Projet: simpl-resultat
+> Statut: Draft
+> Slug: collapse-multi-niveaux
+
+## Contexte
+
+Le repli des catégories a été livré en deux temps — #254 (les deux rapports comparables) puis #265 (la tendance par catégorie) — mais avec une limite qui n'avait pas été explicitée : **on ne peut replier que les catégories de premier niveau**.
+
+La taxonomie standard compte pourtant **trois niveaux** : 11 racines, **41 catégories intermédiaires**, 98 feuilles. Ces 41 catégories intermédiaires (par exemple `Alimentation > Épicerie`) sont aujourd'hui des culs-de-sac visuels : elles portent un sous-total, un style dédié et une indentation, mais **aucun chevron**. Déplier une racine révèle d'un coup tout son sous-arbre, feuilles comprises — impossible de s'arrêter au palier intermédiaire.
+
+La restriction n'est pas structurelle. Elle tient dans deux fonctions de `src/utils/collapsibleRows.ts` : `visibleRows` ne consulte l'état de repli qu'à `depth === 0`, et `collapsibleKeys` ne liste que les parents de premier niveau. Tout le reste de la chaîne est déjà prêt : le builder d'arbre (`buildLeafDrivenTree`) est récursif à profondeur arbitraire, chaque ligne porte sa propre `depth`, les sous-totaux sont exacts à chaque palier, et l'indentation gère déjà quatre niveaux.
+
+En parallèle, la **grille Budget** est hiérarchique (elle lit `depth` / `is_parent`, elle indente) mais a été **délibérément exclue du repli** par #278 : « elle demeure une surface d'édition, sans ligne masquée ni repliable ». Avec ~150 lignes affichées d'un bloc, cette décision est revue ici.
+
+## Objectif
+
+Rendre chaque catégorie parente repliable **à n'importe quel niveau de la hiérarchie**, sur les trois rapports hiérarchiques et sur la grille Budget. Tous les niveaux s'ouvrent **repliés** : déplier un parent révèle uniquement le palier suivant, lui-même replié, ce qui permet de forer par étapes au lieu de subir un mur de lignes.
+
+## Scope
+
+### IN
+
+- **Généralisation du socle** — `collapsibleRows.ts` : le repli devient valable à toute profondeur (aujourd'hui `depth === 0` en dur).
+- **Sémantique en cascade** — déplier un parent révèle ses enfants directs, eux-mêmes repliés. Un descendant n'est visible que si **tous** ses ancêtres sont dépliés.
+- **Les 3 rapports hiérarchiques** — `ComparePeriodTable` (réel-vs-réel), `BudgetVsActualTable` (réel-vs-budget), `CategoryOverTimeTable` (tendances par catégorie) : chevron sur les parents intermédiaires, qui n'ont aujourd'hui qu'un `<span>` muet.
+- **La grille Budget** (`BudgetTable`) — nouveau consommateur du repli : elle ne l'a jamais eu. Revient sur la décision de #278.
+- **Le bouton « Tout déplier / Tout replier »** — agit désormais sur tous les niveaux d'un coup.
+- **Correctifs d'hygiène** dans les fichiers touchés :
+  - collision de clé `localStorage` `subtotals-position`, partagée entre `BudgetVsActualTable.tsx:30` et `BudgetTable.tsx:21` ;
+  - état de repli non scopé par profil (l'app est multi-profils, les ids de catégories divergent d'un profil à l'autre) ;
+  - suppression de `src/components/reports/CategoryTable.tsx` (74 lignes, importé nulle part).
+- **`aria-level`** sur les lignes parentes : avec plusieurs niveaux imbriqués, la profondeur n'est plus déductible pour un lecteur d'écran (l'indentation est du padding CSS, invisible pour lui).
+
+### OUT (explicitement exclu)
+
+- **Dashboard, Cartes, Faits saillants, Par-catégorie** — aucun tableau hiérarchique de catégories à replier : ce sont des donuts, des top-N plats et des cartes de KPI. « Tous les rapports » ne s'y applique pas.
+- **Page Catégories (`/categories`) et guide de la taxonomie standard** — les deux ont déjà leur propre repli à N niveaux, avec leur code, non persisté, et des défauts opposés (Catégories = tout déplié ; guide = tout replié). Les unifier sur le hook partagé est un chantier distinct : la page Catégories est une surface CRUD avec drag-and-drop, où « tout replié par défaut » nuirait à l'usage.
+- **Page Bilan** — sa hiérarchie porte sur des **comptes**, pas des catégories, et son mécanisme d'expansion est entièrement distinct (drill-down des titres, colonnes de rendement persistées en DB).
+- **Migration vers `role="treegrid"`** — le pattern ARIA complet exigerait toute la navigation clavier bidirectionnelle (flèches, Home/End, Ctrl+Home…). Hors sujet ici ; `aria-expanded` sur le bouton de repli reste valide et conforme. À noter comme dette.
+- **Niveau 4 et au-delà** — l'UI l'interdit déjà à la création (`CategoryForm.tsx:44-63`) comme au drag-and-drop (`CategoryTree.tsx:283-287`). Le socle reste néanmoins agnostique de la profondeur (le garde anti-cycle `MAX_TREE_DEPTH = 5` est conservé).
+
+## Decisions prises
+
+| Question | Decision | Raison |
+|----------|----------|--------|
+| Quelles surfaces reçoivent le repli multi-niveaux ? | Les 3 rapports hiérarchiques **+ la grille Budget** | Ce sont les seules surfaces réellement hiérarchiques. Dashboard/Cartes/Faits saillants n'ont aucun tableau de catégories imbriqué — il n'y a rien à y replier. |
+| Que révèle le dépliage d'un parent ? | **Le palier suivant, replié** (cascade) | Fidèle à « chaque niveau est replié par défaut ». Permet de forer par étapes. Assume un changement de comportement : aujourd'hui, déplier une racine révèle tout son sous-arbre d'un coup. |
+| État par défaut de la grille Budget ? | **Replié, comme partout** | Uniformité. La page ouvre sur 11 lignes compactes au lieu de ~150. Coût assumé : à la première visite, aucun champ de saisie n'est visible (seules les feuilles sont éditables) — mais l'état étant persisté, ce coût n'est payé qu'une fois, et « Tout déplier » est à un clic. |
+| Portée du bouton « Tout déplier / Tout replier » ? | **Tous les niveaux d'un coup** | C'est l'échappatoire qui rend le défaut replié vivable, en particulier sur la grille de saisie. Sans lui, il faudrait ouvrir les 41 intermédiaires un par un. |
+| Corriger la collision `subtotals-position` ? | **Oui** | Bug préexistant : déplacer les sous-totaux dans la grille Budget les déplace aussi dans le rapport réel-vs-budget. Une ligne, dans un fichier qu'on ouvre de toute façon. |
+| Scoper l'état de repli par profil ? | **Oui** | Le repli multi-niveaux aggrave le défaut : on mémorise désormais des ids de catégories à tous les niveaux, et deux profils aux taxonomies divergentes se marchent dessus. |
+| Supprimer `reports/CategoryTable.tsx` ? | **Oui** | Code mort (0 import), vestige plat d'avant les tables hiérarchiques. Évite qu'on le confonde un jour avec une surface à replier. |
+| Découpage du travail ? | **Deux issues stackées** — A : socle + les 3 rapports ; B (dépend de A) : adoption sur la grille Budget | Sépare un changement de ~15 lignes bien testé de l'ajout du repli sur une surface d'édition, où la régression est plus plausible. A peut être mergée sans porter le risque de B. |
+
+## Contraintes techniques établies (vérifiées dans le code)
+
+- **La couche données est déjà prête.** `buildLeafDrivenTree` (`reportService.ts:561-686`) et `buildSubGroup` (`budgetService.ts:351-374`) sont récursifs à profondeur arbitraire ; chaque ligne porte `depth` / `is_parent` / `parent_id` ; les sous-totaux sont exacts à chaque palier. Le rendu indente déjà quatre niveaux (`px-3` / `pl-8` / `pl-14` / `pl-20`) et style déjà les parents intermédiaires. **Il ne leur manque que le chevron.**
+- **Le bouton bulk fonctionnera sans toucher aux appelants.** `expandAll` / `allExpanded` / `groupCount` reçoivent les lignes **complètes** (`rows` / `data.tree`), le filtre `visible()` étant appliqué séparément au rendu. Généraliser `collapsibleKeys` pour qu'il retourne tous les parents suffit donc à couvrir tous les niveaux.
+- **Le repli reste purement visuel.** Sous-totaux, « Résultat avant transferts » et « Résultat net » sont calculés sur les lignes brutes, jamais sur les lignes visibles — invariant vérifié en revue de #254 et couvert par les tests. Il doit le rester.
+- **Seules les feuilles sont éditables dans la grille Budget** (`BudgetTable.tsx:105`, `:175`) : les parents sont des sous-totaux en lecture seule. C'est ce qui fonde le compromis sur le défaut replié.
+- **Les tests actuels verrouillent la sémantique mono-niveau** (`collapsibleRows.test.ts:53-63` et `:82-84` affirment explicitement que déplier révèle tout le sous-arbre et que seuls les parents de niveau 1 sont repliables). **Ils devront être réécrits** — ce n'est pas une régression, c'est le changement demandé.
+- **Pas de harnais de rendu React** dans le repo (ni jsdom ni testing-library). Toute la logique doit rester dans des modules purs testables (`collapsibleRows.ts`, `overTimeTableModel.ts`), les composants restant de simples afficheurs.
+
+## References
+
+| Source | Pertinence |
+|--------|------------|
+| [Treegrid Pattern — WAI-ARIA APG](https://www.w3.org/WAI/ARIA/apg/patterns/treegrid/) | Confirme que les lignes parentes portent `aria-expanded`, et que les lignes **sans** enfants ne doivent **pas** porter l'attribut (l'inclure les définirait comme parentes). Notre gate actuel — bouton présent uniquement sur les parents — est conforme et le reste après généralisation. |
+| [ARIA: treegrid role — MDN](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/treegrid_role) | Un vrai `treegrid` impose la navigation clavier bidirectionnelle complète. Trop coûteux pour ce chantier → on conserve le disclosure par bouton et on ajoute `aria-level`, qui porte l'information de profondeur qu'un lecteur d'écran ne peut pas tirer du padding CSS. |
--- a/spec-plan-collapse-multi-niveaux.md
+++ b/spec-plan-collapse-multi-niveaux.md
@ -0,0 +1,297 @@
+# Spec Plan — Repli/dépliage à chaque niveau de la hiérarchie
+
+> Date: 2026-07-13 (révisé après `/review-spec`)
+> Projet: simpl-resultat
+> Statut: Gelé — décisions tranchées
+> Slug: collapse-multi-niveaux
+> Decisions: [spec-decisions-collapse-multi-niveaux.md](./spec-decisions-collapse-multi-niveaux.md)
+
+> **Ce plan est la v2.** La v1 reposait sur un algorithme « cascade » guidé par la profondeur, qui supposait que les lignes arrivent en ordre DFS. Les trois experts de `/review-spec` ont indépendamment démontré que **c'est faux** (la grille Budget émet un ordre par niveau). Voir la synthèse en fin de document.
+
+## Design
+
+### UX / Interface
+
+Inchangé par rapport à la v1 :
+
+- Tout est **replié** à l'ouverture : seules les 11 racines sont visibles.
+- Déplier une catégorie révèle **ses enfants directs, eux-mêmes repliés**.
+- **Chaque parent porte un chevron**, à n'importe quelle profondeur.
+- « Tout déplier » ouvre tous les niveaux d'un coup ; « Tout replier » ne laisse que les racines.
+- L'état est **persisté par rapport**, et naturellement isolé par profil (voir Données).
+
+### Données
+
+**Aucune migration. Aucun changement de schéma.** Mais — correction de la v1 — **deux modules de données sont bien touchés** : `useBudget.ts` (le 3ᵉ builder, que la v1 ignorait) est **lu** pour vérifier l'invariant d'ordre, et `userPreferenceService.ts` devient le support de persistance.
+
+**L'état de repli migre de `localStorage` vers `user_preferences`.** La table `user_preferences (key TEXT PRIMARY KEY, value TEXT NOT NULL)` vit **dans la base SQLite du profil** : elle est créée et détruite avec lui. La clé est donc **scopée par profil gratuitement** — pas de préfixe `${profileId}:`, pas de helper `scopedStorageKey`, pas de risque de ré-hydratation, et surtout **aucun résidu** après suppression d'un profil.
+
+C'est une exigence de principe : `deleteProfile` détruit le fichier SQLite mais ne purge **aucun** `localStorage` (aucun `removeItem` en production). Des clés de repli en `localStorage` auraient été le premier résidu par-profil survivant à la suppression, révélant quelles catégories un profil (potentiellement protégé par PIN) a explorées. Incompatible avec le principe privacy-first.
+
+L'hydratation devient **asynchrone** (`await getPreference(key)`). **Sans flash visible** : le défaut est « tout replié », donc l'état initial affiché *est* l'état par défaut — l'hydratation ne peut que déplier ce que l'utilisateur avait ouvert.
+
+Clés (dans `user_preferences`) : `reports-compare-expanded`, `reports-bva-expanded`, `reports-trends-expanded`, `budget-grid-expanded`.
+
+### Architecture
+
+#### Le cœur : visibilité par chaîne d'ancêtres (et non par adjacence)
+
+La v1 suivait un curseur de profondeur sur des lignes supposées adjacentes. **On remonte désormais `parent_id`** : une ligne est visible ⟺ **tous ses ancêtres sont dépliés**.
+
+```ts
+export interface CollapseAccessors<T> {
+  keyOf: (row: T) => string;              // 'p:<categoryId>' — seuls les parents sont keyés
+  parentKeyOf: (row: T) => string | null; // NOUVEAU — 'p:<parent_id>', ou null à la racine
+  isParent: (row: T) => boolean;
+  depthOf: (row: T) => number;            // CONSERVÉ, mais pour l'indentation + aria-level UNIQUEMENT
+}
+
+export function visibleRows<T>(rows, acc, isCollapsed): T[] {
+  // N'indexer QUE les parents : une feuille « (direct) » porte la clé de son parent.
+  const parents = new Map<string, T>();
+  for (const r of rows) if (acc.isParent(r)) parents.set(acc.keyOf(r), r);
+
+  const hiddenByAncestor = (row: T): boolean => {
+    let key = acc.parentKeyOf(row);
+    let hops = 0;
+    while (key !== null && hops++ < MAX_TREE_DEPTH) {   // garde anti-cycle (parent_id corrompu)
+      const parent = parents.get(key);
+      if (parent === undefined) return false;           // ancêtre hors de cette section → visible
+      if (isCollapsed(parent)) return true;
+      key = acc.parentKeyOf(parent);
+    }
+    return false;
+  };
+
+  return rows.filter((r) => !hiddenByAncestor(r));
+}
+
+export function collapsibleKeys<T>(rows, acc): string[] {
+  return rows.filter(acc.isParent).map(acc.keyOf);      // tous les parents, toute profondeur
+}
+```
+
+**Pourquoi c'est le bon choix — ça résout quatre problèmes d'un coup :**
+
+1. **L'ordre par niveau de la grille Budget** (`useBudget.ts:361` trie par `depth` croissant) — l'algorithme est désormais indépendant de l'ordre des lignes.
+2. **Le tri final par type de catégorie**, présent dans les trois builders, peut placer un enfant dans une *autre section* que son parent (`CategoryForm` autorise un type d'enfant différent de celui du parent) — l'ancêtre absent de la section rend simplement la ligne visible, sans orphelin masqué à tort.
+3. **La feuille « (direct) »** — elle porte `parent_id === son propre category_id`, donc sa chaîne remonte vers le sous-total de son parent : replier le parent la masque, **par construction**. Le garde `isParent` redevient **cosmétique** (« pas de chevron sur une feuille »), il n'est plus load-bearing.
+4. **La contrainte « `visible()` avant `reorderRows` »** disparaît — `reorderRows` peut déplacer les sous-totaux en bas d'un groupe sans rien casser.
+
+**`keyOf` devient injectif** : le préfixe `p:` marque que seuls les parents sont keyés (aujourd'hui, un sous-total parent et sa feuille « (direct) » partagent `String(categoryId)`). Coût de migration nul — le passage à `user_preferences` repart de toute façon d'un état vierge.
+
+#### Le hook : polarité + persistance optionnelle
+
+```ts
+useCollapsibleGroups<T>(
+  storageKey: string | null,        // null ⇒ aucune persistance (état React pur)
+  acc: CollapseAccessors<T>,
+  options?: { defaultExpanded?: boolean },  // défaut false
+): CollapsibleGroups<T>
+```
+
+**Le Set persisté stocke les clés dont l'état DIFFÈRE du défaut.** C'est ce qui permet de servir les deux polarités sans seed :
+
+```ts
+const isCollapsed = (row) => {
+  const flipped = flippedKeys.has(acc.keyOf(row));
+  return defaultExpanded ? flipped : !flipped;
+};
+```
+
+- `defaultExpanded: false` (rapports, budget) ⇒ le Set = les **dépliés**. Set vide = tout replié. **Strictement le comportement actuel.**
+- `defaultExpanded: true` (page Catégories) ⇒ le Set = les **repliés**. Set vide = tout déplié. Aucun seed nécessaire.
+
+Conséquence sur l'API : **`collapseAll` prend désormais `rows`** (`collapseAll(rows: T[])`), symétrique d'`expandAll`, puisqu'en polarité `defaultExpanded` il doit remplir le Set.
+
+**Le hook reste sans dépendance au contexte** : il n'appelle pas `useProfile()` (qui *throw* hors de son provider et coupleraient un util générique à `ProfileContext`). La clé `user_preferences` étant déjà propre au profil, il n'y a rien à injecter.
+
+#### Les 4 composants — deux gates, pas un
+
+La v1 ne voyait que le gate du bouton. Il y en a **deux** :
+
+```tsx
+const collapsed = isTopParent && groups.isCollapsed(row);   // (1) → isParent && ...
+...
+{isTopParent ? <button>{chevron}</button> : <span>}          // (2) → isParent ? ...
+```
+
+Sans corriger **(1)**, chaque parent intermédiaire afficherait un chevron *perpétuellement ouvert* et un `aria-expanded={true}` mensonger, alors que son sous-arbre est masqué.
+
+## Plan de travail
+
+### Issue A — Socle : repli à chaque niveau sur les 3 rapports hiérarchiques [type:feature] (#288)
+
+Dependances : aucune
+
+- [ ] `src/utils/collapsibleRows.ts` — réécrire `visibleRows` en **remontée d'ancêtres** (code ci-dessus) ; ajouter `parentKeyOf` à `CollapseAccessors` ; `collapsibleKeys` retourne tous les parents ; `keyOf` préfixé `p:`.
+- [ ] `src/utils/collapsibleRows.test.ts` — **réécrire** (les tests actuels verrouillent le mono-niveau : `:53-63`, `:70-73`, `:82-84`).
+- [ ] `src/hooks/useCollapsibleGroups.ts` — persistance via `user_preferences` (`getPreference`/`setPreference`, async) au lieu de `localStorage` ; `storageKey: string | null` ; `options.defaultExpanded` ; sémantique « Set = écarts au défaut » ; `collapseAll(rows)`. **Ne pas** appeler `useProfile()`.
+- [ ] Les 3 tables — corriger **les deux gates** (`collapsed` ET le bouton) : `isTopParent` → `isParent`.
+  - `ComparePeriodTable.tsx` (`:157` + `:184`), `BudgetVsActualTable.tsx` (`:119` + `:140`), `CategoryOverTimeTable.tsx` (`:96` + `:123`)
+  - Fournir `parentKeyOf` dans les 3 jeux d'accesseurs (`COMPARE_*:64`, `BVA_*:35`, `OVERTIME_*` dans `overTimeTableModel.ts:18`)
+- [ ] `aria-level={depth + 1}` sur les lignes parentes.
+- [ ] `overTimeTableModel.test.ts` — **ÉTENDRE la fixture à 3 niveaux** (racine > parent intermédiaire > feuilles) et ajouter des assertions de cascade. (La v1 disait « mettre à jour » : vérifié, la fixture actuelle `:57-68` n'a que 2 niveaux, donc ses tests passent identiquement sous le nouvel algo — la tâche n'avait pas de cible.)
+- [ ] Supprimer `src/components/reports/CategoryTable.tsx` (74 lignes, 0 import).
+- [ ] CHANGELOG (EN + FR).
+
+### Issue B — Adoption du repli sur la grille Budget [type:feature] (#289)
+
+Dependances : Issue A (#288)
+
+- [ ] `src/hooks/useBudget.ts` — **lire et documenter l'invariant d'ordre**. Le tri (`:345-365`) est par *niveau*, pas DFS. Avec la remontée d'ancêtres, **aucun changement de tri n'est requis** — mais il faut le vérifier et l'acter par un test, car la v1 s'y était trompée.
+- [ ] `BudgetTable.tsx` — brancher `useCollapsibleGroups` ; déclarer `BUDGET_COLLAPSE_ACCESSORS` + `BUDGET_EXPANDED_KEY` **inline au module scope**, comme `ComparePeriodTable:64` et `BudgetVsActualTable:35`. **Ne PAS créer `budgetTableModel.ts`** : `overTimeTableModel.ts` existe parce qu'il porte de la vraie logique (`groupOverTimeSections`), pas pour héberger trois lambdas.
+- [ ] Chevron + `aria-expanded` sur **toute** ligne parente dans `renderRow` (`:168-205`) — les parents y sont aujourd'hui du texte pur.
+- [ ] Bouton « Tout déplier / Tout replier » (réutiliser `reports.collapse.expandAll` / `.collapseAll`).
+- [ ] **Remplacer le sous-total de section fait main** (`:301-311`) par `sumLeavesForType` de `budgetTableResults.ts:42` — code déjà testé, et cela *prouve* le critère « sous-totaux sur lignes brutes » au lieu de le promettre.
+- [ ] **Corriger la collision `localStorage`** : `BudgetTable.tsx:21` et `BudgetVsActualTable.tsx:30` déclarent tous deux `STORAGE_KEY = "subtotals-position"`. Préfixer celle du budget → `budget-subtotals-position`.
+- [ ] CHANGELOG (EN + FR).
+
+### Issue C — Unifier la machine à états des 2 arbres de catégories [type:refactor] (#290)
+
+Dependances : Issue A (#288). Indépendante de B.
+
+Les trois implémentations de repli ont des **rendus** inconciliables (liste plate indentée vs récursion sur `children[]`) mais une **machine à états identique** (Set d'ids, toggle, expandAll, collapseAll, allExpanded, polarité, persistance). Après A, le hook est un **sur-ensemble strict** de ce que les deux arbres bricolent.
+
+- [ ] `CategoryTree.tsx` (page Catégories, CRUD) — adopter `useCollapsibleGroups` pour **l'état seul** (`storageKey: null`, `defaultExpanded: true`), en **gardant** son rendu récursif et son drag-and-drop. Supprimer `collectExpandable` (`:195-204`) et son `Set` local.
+- [ ] `CategoryTaxonomyTree.tsx` + `CategoriesStandardGuidePage.tsx` (guide read-only) — idem (`storageKey: null`, `defaultExpanded: false`).
+- [ ] **Corriger le bug avéré** : `CategoriesStandardGuidePage:79` calcule `allExpanded = expanded.size > 0` — un seul nœud déplié bascule le bouton en « Tout replier ». Le `allExpanded` du hook est correct.
+- [ ] Les deux arbres passent leurs nœuds **aplatis** à `expandAll` / `collapseAll` / `allExpanded` / `groupCount` (qui attendent un tableau).
+- [ ] CHANGELOG (EN + FR) — uniquement pour le bug du bouton (le reste est interne).
+
+### Ordre d'execution
+
+```
+Issue A (#288) → Issue B (#289)
+Issue A (#288) → Issue C (#290)
+```
+
+B et C sont indépendantes entre elles et parallélisables — **mais** elles touchent toutes deux les CHANGELOG et les locales : voir les conflits partagés connus du repo.
+
+## Fichiers concernes
+
+| Fichier | Action | Issue | Raison |
+|---------|--------|-------|--------|
+| `src/utils/collapsibleRows.ts` | Modifier | A | Remontée d'ancêtres, `parentKeyOf`, `keyOf` préfixé |
+| `src/utils/collapsibleRows.test.ts` | Réécrire | A | Les tests verrouillent le mono-niveau |
+| `src/hooks/useCollapsibleGroups.ts` | Modifier | A | `user_preferences`, polarité, `storageKey` nullable |
+| `src/services/userPreferenceService.ts` | Lire | A | `getPreference` / `setPreference` (déjà async, inchangés) |
+| `src/components/reports/ComparePeriodTable.tsx` | Modifier | A | 2 gates + `parentKeyOf` + `aria-level` |
+| `src/components/reports/BudgetVsActualTable.tsx` | Modifier | A | Idem |
+| `src/components/reports/CategoryOverTimeTable.tsx` | Modifier | A | Idem |
+| `src/components/reports/overTimeTableModel.ts` | Modifier | A | `parentKeyOf` dans les accesseurs |
+| `src/components/reports/overTimeTableModel.test.ts` | Modifier | A | Étendre la fixture à 3 niveaux |
+| `src/components/reports/CategoryTable.tsx` | **Supprimer** | A | Code mort (0 import) |
+| `src/hooks/useBudget.ts` | Lire + tester | B | 3ᵉ builder — ordre par niveau, à acter par un test |
+| `src/components/budget/BudgetTable.tsx` | Modifier | B | Repli + `sumLeavesForType` + clé `budget-subtotals-position` |
+| `src/components/budget/budgetTableResults.ts` | Lire | B | `sumLeavesForType:42` à réutiliser |
+| `src/components/categories/CategoryTree.tsx` | Modifier | C | Adopter le hook pour l'état |
+| `src/components/categories/CategoryTaxonomyTree.tsx` | Modifier | C | Idem |
+| `src/pages/CategoriesStandardGuidePage.tsx` | Modifier | C | Bug `allExpanded = expanded.size > 0` |
+| `src/i18n/locales/{fr,en}.json` | Modifier | A, B | Clés `reports.collapse.*` existent déjà ; éventuel aria-label |
+| `CHANGELOG.md`, `CHANGELOG.fr.md` | Modifier | A, B, C | Une entrée par issue |
+
+## Plan de tests
+
+Le repo n'a **ni jsdom ni testing-library** : aucun composant React n'est rendable. La logique vit dans les modules purs.
+
+### Tests unitaires — `collapsibleRows.test.ts` (réécrit)
+
+- Set vide ⇒ seules les racines sont visibles (défaut replié, tous niveaux).
+- Déplier une racine révèle **uniquement ses enfants directs**, pas ses petits-enfants.
+- Déplier racine **et** intermédiaire révèle les feuilles.
+- Déplier un intermédiaire dont la racine est repliée ne révèle **rien** (un ancêtre replié gagne toujours).
+- **Ordre par niveau** (fixture BFS, celle de la grille Budget) : le masquage est **identique** à celui d'une fixture DFS. *C'est le test qui aurait tué la v1.*
+- **Sous-totaux en bas** (`reorderRows`) : masquage inchangé.
+- **Feuille « (direct) »** : parent replié ⇒ elle est masquée ; parent déplié ⇒ visible ; elle ne porte jamais de chevron.
+- **`parent_id` corrompu (cycle)** : le garde `MAX_TREE_DEPTH` empêche la boucle infinie.
+- **Ancêtre absent de la section** (enfant de type différent du parent) : la ligne reste visible, pas d'orphelin masqué.
+- `collapsibleKeys` liste **tous** les parents, intermédiaires compris.
+
+### Tests unitaires — polarité du hook
+
+La logique de polarité (`Set = écarts au défaut`) doit être extraite en helper **pur** pour être testable (le hook lui-même ne l'est pas) : `isCollapsedFor(flipped, key, defaultExpanded)`.
+
+### Tests d'integration
+
+- `overTimeTableModel.test.ts` — fixture **étendue à 3 niveaux** + assertions de cascade. **Conserver** l'assertion « le repli est purement visuel ».
+- `budgetTableResults` — `sumLeavesForType` couvre déjà les sous-totaux de section : le brancher *prouve* l'invariant.
+
+### Tests de regression (à figer AVANT modification)
+
+- **Le repli est purement visuel** : sous-totaux, « Résultat avant transferts » et « Résultat net » se calculent sur les lignes **brutes**, jamais sur les visibles — sur les 3 rapports **et** sur la grille Budget.
+- **Grille Budget** : replier un parent n'altère aucune valeur saisie ; les totaux de section sont identiques, repliés ou non.
+- **Ordre des lignes de `useBudget`** : test actant que l'ordre est par niveau (documente l'invariant que la v1 avait supposé à tort).
+
+## Criteres d'acceptation
+
+### Issue A (socle + 3 rapports)
+
+- [ ] Toute catégorie parente est repliable à n'importe quel niveau (les 41 intermédiaires incluses)
+- [ ] À l'ouverture, seules les racines sont visibles
+- [ ] Déplier un parent révèle ses enfants directs, eux-mêmes repliés
+- [ ] Un descendant n'est visible que si **tous** ses ancêtres sont dépliés
+- [ ] Le masquage est **identique** que les lignes soient en DFS ou par niveau
+- [ ] Un parent intermédiaire replié affiche un chevron **fermé** et `aria-expanded={false}`
+- [ ] « Tout déplier » ouvre tous les niveaux d'un coup
+- [ ] L'état est persisté dans `user_preferences` (donc isolé par profil, et détruit avec lui)
+- [ ] Sous-totaux et lignes de résultat rigoureusement inchangés, replié ou déplié
+- [ ] Les lignes parentes portent `aria-level`
+
+### Issue B (grille Budget)
+
+- [ ] Toute catégorie parente de la grille est repliable, à n'importe quel niveau
+- [ ] La grille s'ouvre entièrement repliée ; « Tout déplier » est visible d'emblée
+- [ ] Aucune valeur de budget n'est altérée par un repli ; totaux de section et lignes de résultat inchangés
+- [ ] Les sous-totaux de section passent par `sumLeavesForType` (plus de calcul fait main)
+- [ ] La position des sous-totaux de la grille est **indépendante** de celle du rapport réel-vs-budget
+
+### Issue C (unification)
+
+- [ ] `CategoryTree` et `CategoryTaxonomyTree` ne portent plus leur propre `Set` d'état
+- [ ] La page Catégories s'ouvre toujours **dépliée** ; le guide toujours **replié** (comportements préservés)
+- [ ] Le drag-and-drop de la page Catégories fonctionne comme avant
+- [ ] Sur le guide, déplier **un** nœud ne bascule plus le bouton en « Tout replier »
+
+## Edge cases et risques
+
+| Cas | Mitigation |
+|-----|------------|
+| **Chaîne `parent_id` cyclique** (corruption DB) | Garde `hops < MAX_TREE_DEPTH` dans la remontée. Test dédié. |
+| **Ancêtre absent du tableau de lignes** (enfant d'un type différent de son parent ⇒ autre section) | `parents.get(key) === undefined` ⇒ la ligne est **visible**. Choix explicite : mieux vaut une ligne orpheline visible qu'une ligne masquée par un ancêtre introuvable. Test dédié. |
+| **Hydratation asynchrone** depuis `user_preferences` | Sans flash : le défaut « tout replié » *est* l'état initial. L'hydratation ne peut que déplier. Sur la page Catégories (Issue C, défaut déplié), `storageKey: null` ⇒ aucune hydratation, donc aucun flash. |
+| **Changement de profil** | La clé vit dans la base du profil : après bascule, `getPreference` lit la nouvelle base. Vérifier que les composants de rapport se remontent (ou se ré-hydratent) au switch. |
+| **Grille Budget : 1re ouverture sans champ de saisie** | Décision assumée et tracée. « Tout déplier » doit être visible d'emblée. À réévaluer si l'usage la contredit. |
+| **`depth` optionnel** sur `BudgetYearRow` / `BudgetVsActualRow` avec des fallbacks dérivés (`row.depth ?? (…? 1 : 0)`) | **Neutralisé** : `depth` ne pilote plus la visibilité, seulement l'indentation et `aria-level`. Une valeur fausse dégrade l'affichage, elle ne masque plus les mauvaises lignes. |
+| **Perf** | ~150 lignes × profondeur ≤ 3 ⇒ ~450 remontées par rendu. Négligeable ; mémoïsation inutile. |
+
+## Revision — Synthese
+
+> Date: 2026-07-13 | Experts: Securite, Architecture, Technique
+
+### Verdict
+
+🟡 **AMELIORATIONS INTEGREES** — la v1 portait un défaut fatal (algorithme adjacency-dépendant sur des lignes qui ne sont pas ordonnées comme supposé). Les trois critiques ont été résolues **dans le plan**, pas annotées : le design a changé.
+
+### Resume
+
+| Expert | 🔴 | 🟡 | 🟢 | Points cles |
+|--------|-----|-----|-----|-------------|
+| Securite | 1 | 1 | 1 | Grille Budget en ordre par niveau ; résidu `localStorage` survivant à `deleteProfile` ; `depth` optionnel |
+| Architecture | 1 | 5 | 1 | Même défaut d'ordre ; remontée d'ancêtres ; triplication ; `keyOf` non injectif ; `budgetTableModel` inutile |
+| Technique | 2 | 3 | 2 | Même défaut d'ordre ; **3ᵉ builder (`useBudget`) absent du plan** ; flag `collapsed` gaté sur `isTopParent` ; fixture overTime ne verrouille rien |
+
+### Decisions tranchees (2026-07-13)
+
+1. **Visibilité par remontée de `parent_id`**, et non par adjacence — résout d'un coup l'ordre par niveau de la grille, le tri par type qui sépare parent et enfant, la feuille « (direct) », et la contrainte `visible()`-avant-`reorderRows`.
+2. **Persistance dans `user_preferences`** (base du profil) et non `localStorage` — zéro résidu après suppression d'un profil, scoping gratuit, aucun helper de préfixe. Motivé par le principe privacy-first.
+3. **Unification de la machine à états** des deux arbres de catégories (Issue C) — les rendus restent distincts, l'état est partagé ; corrige au passage le bug `allExpanded = expanded.size > 0` du guide.
+
+### Corrections factuelles apportees a la v1
+
+- `useBudget.ts` (3ᵉ builder) était **absent** du plan et des fichiers concernés → ajouté.
+- « Aucun service touché » était **faux** → corrigé.
+- Le flag `collapsed = isTopParent && …` (3 tables) était **oublié** → tâche explicite.
+- « `overTimeTableModel.test.ts` verrouille le mono-niveau » était **faux** (fixture à 2 niveaux) → la tâche devient *étendre* la fixture, pas la mettre à jour.
+- `budgetTableModel.ts` : abandonné (les 2 autres tables déclarent leurs accesseurs inline ; la vraie logique extractible — `sumLeavesForType` — existait déjà).
+- Le garde `isParent`, décrit comme « structurel », redevient **cosmétique** grâce à `keyOf` injectif (`p:`).
--- a/src/i18n/locales/en.json
+++ b/src/i18n/locales/en.json
@ -914,6 +914,7 @@
        "Split annual amount evenly across 12 months",
        "Budget templates to save and apply configurations",
        "Parent category subtotals",
+        "Collapse/expand the hierarchy at every level: each parent category has its own chevron, the grid opens fully collapsed, and an \"Expand all / Collapse all\" button opens or closes every level at once — remembered per profile",
        "Column headers stay fixed when scrolling vertically"
      ],
      "steps": [
@ -926,7 +927,8 @@
      "tips": [
        "The Annual column auto-sums all 12 months — a warning appears if monthly totals don't match",
        "Templates can be applied to specific months or all 12 at once",
-        "Parent categories show subtotals aggregated from their children"
+        "Parent categories show subtotals aggregated from their children",
+        "Collapsing a category is purely visual: subtotals and annual totals are always computed over all rows, never just the visible ones — no amount you typed is ever lost"
      ]
    },
    "reports": {
@ -941,7 +943,8 @@
        "Category Zoom: single-category drill-down with donut, monthly evolution, and filterable transaction table; auto-rollup of subcategories",
        "Contextual keyword editing: right-click a transaction row to add its description as a keyword with a live preview of the matches",
        "SVG patterns (lines, dots, crosshatch) to distinguish categories",
-        "View mode preference (chart vs. table) persisted per report section"
+        "View mode preference (chart vs. table) persisted per report section",
+        "Collapse the category hierarchy at every level on the Compare reports and the by-category Trends table: a chevron per parent category, opens fully collapsed, an \"Expand all / Collapse all\" button; purely visual (subtotals and results unchanged), remembered per profile"
      ],
      "steps": [
        "Open /reports to see the highlights panel and four navigation cards",
@ -957,7 +960,8 @@
        "Keywords must be 2–64 characters long",
        "The Category Zoom is protected against malformed category trees: a parent_id cycle cannot freeze the app",
        "On /reports/cartes in YTD mode, the MoM delta for January is always \"—\" (no prior YTD window inside the same year), and the savings rate stays \"—\" when YTD income is zero",
-        "Seasonality, top movers, and budget adherence stay monthly even when the toggle is set to YTD — only the 4 KPI numbers change"
+        "Seasonality, top movers, and budget adherence stay monthly even when the toggle is set to YTD — only the 4 KPI numbers change",
+        "Your category collapse choices (Compare, Trends, Budget) are remembered per profile: stored in the profile's own database, they are destroyed with it"
      ]
    },
    "balance": {
--- a/src/i18n/locales/fr.json
+++ b/src/i18n/locales/fr.json
@ -914,6 +914,7 @@
        "Répartition égale du montant annuel sur 12 mois",
        "Modèles de budget pour sauvegarder et appliquer des configurations",
        "Sous-totaux par catégorie parente",
+        "Repli / dépli de la hiérarchie à chaque niveau : chaque catégorie parente a son chevron, la grille s'ouvre entièrement repliée, et un bouton « Tout déplier / Tout replier » ouvre ou ferme tous les niveaux d'un coup — mémorisé par profil",
        "En-têtes de colonnes fixes au défilement vertical"
      ],
      "steps": [
@ -926,7 +927,8 @@
      "tips": [
        "La colonne Annuel additionne automatiquement les 12 mois — un avertissement apparaît si les totaux mensuels ne correspondent pas",
        "Les modèles peuvent être appliqués à des mois spécifiques ou aux 12 mois d'un coup",
-        "Les catégories parentes affichent les sous-totaux agrégés de leurs enfants"
+        "Les catégories parentes affichent les sous-totaux agrégés de leurs enfants",
+        "Replier une catégorie est purement visuel : les sous-totaux et les totaux annuels sont toujours calculés sur toutes les lignes, jamais sur les seules lignes visibles — aucun montant saisi n'est perdu"
      ]
    },
    "reports": {
@ -941,7 +943,8 @@
        "Zoom catégorie : analyse d'une seule catégorie avec donut, évolution mensuelle et tableau de transactions filtrable ; rollup automatique des sous-catégories",
        "Édition contextuelle des mots-clés : clic droit sur une ligne de transaction pour ajouter sa description comme mot-clé avec prévisualisation en direct des matches",
        "Motifs SVG (lignes, points, hachures) pour distinguer les catégories",
-        "Préférence chart/table mémorisée par section de rapport"
+        "Préférence chart/table mémorisée par section de rapport",
+        "Repli de la hiérarchie à chaque niveau sur les Comparables et la tendance Par catégorie : chevron par catégorie parente, ouverture entièrement repliée, bouton « Tout déplier / Tout replier » ; purement visuel (sous-totaux et résultats inchangés), mémorisé par profil"
      ],
      "steps": [
        "Ouvrez /reports pour voir le panneau de faits saillants et les quatre cartes de navigation",
@ -957,7 +960,8 @@
        "Les mots-clés doivent faire entre 2 et 64 caractères",
        "Le Zoom catégorie est protégé contre les arborescences malformées : un cycle parent_id ne peut pas figer l'app",
        "Sur /reports/cartes en mode YTD, le delta MoM du mois de janvier est toujours « — » (pas de fenêtre YTD antérieure dans la même année), et le taux d'épargne reste « — » quand les revenus YTD sont à zéro",
-        "La saisonnalité, les top mouvements et l'adhésion budgétaire restent mensuels même quand le toggle est sur YTD — seuls les 4 chiffres KPI changent"
+        "La saisonnalité, les top mouvements et l'adhésion budgétaire restent mensuels même quand le toggle est sur YTD — seuls les 4 chiffres KPI changent",
+        "Vos choix de repli des catégories (Comparables, Tendances, Budget) sont mémorisés par profil : stockés dans la base du profil, ils disparaissent avec lui"
      ]
    },
    "balance": {