IdeA/.ideai/tickets/202/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#202	4	kind agent_id agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d	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.