---
issueRef: "#202"
version: 4
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
updatedAt: 1786750786970
---
2026-08-14 — Ouverture du chantier de refonte web UI/UX.

Demande utilisateur:
- Refonte totale de l’UI/UX de la version web d’IdeA.
- Desktop PC: viser une forte parité avec l’AppImage.
- Toutes les features actuelles doivent être exposées.
- Les fenêtres flottantes AppImage devraient idéalement devenir des onglets/fenêtres navigateur.
- Mobile téléphone: UX dédiée, pensée spécifiquement pour ce format.

Cadrage UX reçu:
- Ne pas faire un simple responsive du desktop vers mobile.
- Deux produits UX dans un même client web: `desktop-parity workspace` et `mobile task-flow`.
- Desktop: shell avec top bar, rail primaire, canevas central, rail secondaire, vues détachables, persistance par projet.
- Mobile: navigation focalisée, mono-tâche visible, priorisation des usages courts/décisionnels.
- Exposition des features par intention utilisateur, pas par module technique.

Cadrage architecture reçu:
- Introduire une abstraction de `surface adressable` au-dessus des composants.
- Conserver `LayoutTree` pour le canevas central uniquement; ne pas lui faire porter tabs/fenêtres/sheets du shell web.
- Ajouter un `SurfaceCatalog`, un `WorkspaceSession` desktop, un `TaskFlowSession` mobile et une synchro cross-window/tab.
- Chaque surface doit supporter une présentation parmi `inPlace | tab | window | sheet` selon son contrat.
- Conserver les gateways métier existants; ne pas dupliquer la logique par shell.

Découpage recommandé:
- A0 inventaire complet des features/surfaces.
- A1 noyau surfaces + routage/ouverture.
- A2 shell desktop web.
- A3 détachement onglet/fenêtre.
- A4 persistance/restauration/synchro.
- A5 migration progressive des features.
- A6 shell mobile dédié.
- A7 hardening QA.

Risque principal:
- Copier visuellement l’AppImage sans transposer correctement les contraintes du navigateur.
- Faire du mobile un desktop rétréci.
- Mélanger état de shell, état local de vue et données métier.

Décision Main:
- Traiter #202 comme un programme de refonte structuré, pas comme un ticket de skinning.
- Demander ensuite un éclatement en sous-tickets d’implémentation avant toute phase dev/QA massive.