ADR-0025 — Les écrans de file cassent la fenêtre kilométrique par l'arbre, pas par les cartes¶


Statut	🟡 Accepté — 2026-06-22 ; implémentation en cours (branche `topic/ui-cabinet-arbre`)
Portée	Layout des deux écrans de file du portail staff : Cabinet (`Cabinet.tsx`) et Pilotage / Portefeuille (`Portefeuille.tsx`). Réaménagement visuel + déclinaison persona ; aucune logique de workflow ni de garde backend touchée.
Décision	Le Cabinet sort ses sections administratives (Équipe, Clients) du scroll de travail derrière un segmented control senior-only, et rend sa file en arbre repliable par phase. Le Portefeuille garde sa table (refus assumé des cartes) et gagne des groupes repliables + pagination. La déclinaison persona existante (`estClient` / `estSenior` / `estJunior` / `estExterne`) est préservée par enveloppement, pas réécrite.
Réf.	ADR-0007 — Vues par persona & instigation ; ADR-0006 — Personas staff cross-tenant ; ADR-0014 — Cockpit de pilotage ; ADR-0023 — Taxonomie du journal (phases) ; ADR-0009 — Justification à deux niveaux & Atelier (Hicks)

🎯 À retenir

Le Cabinet du senior empile quatre sections verticales (file, détail d'une demande, Équipe, Clients) : une fenêtre kilométrique qui empire à chaque client et chaque collègue ajoutés. La tentation est « passer aux cartes ». On la refuse : sur un écran de triage comparatif, une carte par demande divise la densité par 3 à 4 et allonge donc la page que l'on veut raccourcir, en plus de heurter l'anti- référence maison (« grilles de cartes identiques », PRODUCT.md / DESIGN.md). Le bon levier est l'arbre (groupes repliables, façon colonne de gauche d'un client mail) et le segmented control qui sort l'administratif du scroll. La table dense du Portefeuille (registre Linear / Stripe) reste une table.

Contexte¶

Captures de QA prises en persona Senior. Deux écrans grandissent sans borne verticale :

Cabinet (Cabinet.tsx) empile dans la zone contenu : (1) la file de travail, (2) le détail de la demande sélectionnée (Progression + Synthèse + Revue contradictoire + Journal, déjà volumineux), (3) la carte Équipe du cabinet (estSenior, l.760), (4) la carte Clients du cabinet (estSenior, l.790). Quatre sections, dont deux purement administratives qui n'ont aucune raison d'être dans le scroll de travail. Croît avec l'équipe et le portefeuille clients.
Portefeuille (Portefeuille.tsx) est une table triée « le plus vieux en tête » (D-PILOT-3). Le group-by existe (Stade / Junior / Client / Secteur, l.81-87) mais les en-têtes de groupe sont plats, non repliables (l.334-344) ; et il n'y a pas de pagination alors que le composant Pagination existe (DESIGN.md). Croît ligne à ligne.

La direction initiale proposée était « système de cartes plutôt que listes ». Examinée à la source, elle est contre-productive sur le Portefeuille : les cartes baissent la densité (donc rallongent la page), cassent la comparaison verticale Âge / Séjour / Renvois / DBO qui est la raison d'être de l'écran, et tombent sur l'anti-référence explicite du produit. Elle ne traite pas non plus la vraie cause du Cabinet, qui n'est pas la forme des lignes mais l'empilement de sections hétérogènes.

Décision¶

D-UILAYOUT-1 — Le Cabinet sort l'administratif derrière un segmented control senior-only. Un sélecteur d'onglets File de travail · Équipe · Clients gouverne la zone contenu du senior. Les deux cartes administratives quittent le scroll de travail. Le contrôle n'est rendu que pour le senior : pour le junior et l'externe (qui n'ont ni Équipe ni Clients), un contrôle à un seul segment serait du bruit (loi de Hicks, ADR-0009) ; leur file de travail occupe tout le contenu, sans onglets. On réutilise la garde estSenior qui pilotait déjà l'affichage de ces cartes ; aucune nouvelle règle d'autorisation.
D-UILAYOUT-2 — La file de travail se lit en arbre par phase. Les demandes de la file sont groupées par phase selon ORDRE_PHASES / labelStatut de lib/statuts.ts (même vocabulaire partagé que le Journal qui groupe déjà par phase, ADR-0023, D-JOURNAL-4 — pas de libellé en dur). Chaque groupe est repliable. La phase terminale Livrée est repliée par défaut (écho du « masquer les livrées » du Portefeuille : ce qui est fini dort en bas). Le jeu de phases présentes diffère par persona (Senior : Soumis → Livrée ; Junior : Assignée · En étude · À revoir ; Externe : Audit externe), l'arbre s'y adapte sans code spécifique.
D-UILAYOUT-3 — Le Portefeuille reste une table ; on lui donne l'arbre et la pagination. Refus assumé des cartes (registre Linear / Stripe, anti-référence « grilles de cartes »). Les en-têtes de groupe deviennent repliables (l'arbre ne mord que lorsqu'un group-by est actif), et la pagination (Pagination, 25/page) borne la hauteur quand le tri est transverse (group-by « Aucun »). Le défaut de group-by reste « Aucun » : le tri par âge transverse est le cœur du triage (D-PILOT-3), on ne le sacrifie pas pour rendre l'arbre visible d'entrée.
D-UILAYOUT-4 — La déclinaison persona est préservée par enveloppement. On enveloppe le rendu existant (la table du Portefeuille, la liste de la file du Cabinet) dans l'arbre et les onglets ; on ne réécrit pas les branches estClient (colonnes Assigné/Renvois masquées, group-by restreint, drill vers /demandes — Portefeuille.tsx l.135-142) ni estSenior (cartes admin — Cabinet.tsx l.545-634, 760-826). Le bandeau « périmètre / filiales » du client reste intact. Invariant : un persona ne voit jamais, après redesign, une donnée ou une action que le code lui masquait avant.

Conséquences¶

Positif. La fenêtre du Cabinet senior cesse de croître avec l'équipe et les clients (administratif derrière onglet) ; la file se parcourt par phase et se replie ; la table du Portefeuille garde sa densité de triage tout en étant bornée en hauteur. Aucune régression de périmètre persona (invariant D-UILAYOUT-4, vérifiable à la source).
Coût / refus. On renonce au master-detail à deux volets (file à gauche, détail à droite, façon inbox) : il entrerait en concurrence avec le panneau d'actions déjà réservé à droite par PageShell (rail · contenu · panneau), ferait quatre colonnes sur écran étroit, et représente un saut de risque supérieur au gain. Écarté pour v1, pas interdit.
Pas de backend. Aucune route, aucun schéma, aucune garde modifiés ; le backend re-garde de toute façon (persona, statut). Donc pas de migration _COLONNES_AJOUTEES.

Déclencheur de réexamen (pré-enregistré)¶

Friction réelle du va-et-vient file ↔ détail (si le scroll entre la file en haut et le détail en bas devient pénible à l'usage senior sur grand écran) → reconsidérer le master-detail à deux volets écarté ici, en arbitrant explicitement avec le panneau d'actions de PageShell.
Arbre du Portefeuille jugé peu utile (si personne ne groupe et que seul le tri transverse sert) → se contenter de la pagination et retirer le repli des groupes.