Cartographie écrans · applications · acteurs¶
Mise à jour : 2026-05-21 · Méthode produit DYNORS (synthèse cahier Cartographie des écrans par application et acteur, alignée sur le workspace
docs/projet-nouveau/**).
Principe¶
Un produit peut comporter plusieurs surfaces frontend déployées (SPA, mobile, Electron) lorsque les acteurs, droits, contexte d’usage ou mode de déploiement diffèrent.
- Un parcours métier identifiable appartient à une seule application déployée — pas de méga-bundle partagé par des acteurs incompatibles.
- Une maquette HTML peut regrouper plusieurs rôles pour la démo : cela ne définit pas le découpage en artefacts de production.
Quand séparer ou regrouper¶
| Situation | Décision type |
|---|---|
| Rôles, permissions ou données exposées différentes | Apps / artefacts distincts |
| Contexte matériel ou réseau différent (mobile terrain, POS offline, bureau) | Surfaces distinctes si le périmètre produit l’exige |
| Déploiement indépendant (POS par magasin vs back-office central) | Cycles de vie distincts |
| Même acteur, mêmes droits, mêmes contextes — seules les vues métier diffèrent | Une app, modules / routes lazy internes |
Stack web et dérogations¶
| Surface | Stack DYNORS par défaut | Dérogation documentée |
|---|---|---|
| Back-office web, portails métier | Angular 17+ | — |
| Terminal POS desktop (offline, scan, impression) | — | Electron + React (ex. SuperGest) — journal d’archi AR-20260426-005 |
| Mobile client / livreur / élève | React Native ou Flutter | — |
Ne pas imposer une stack « par habitude » copiée d’un ancien cahier (ex. Vue 3 généralisé) : la vérité est dans les specs et repos du projet.
FISCAL¶
FISCAL est un service backend. Les écrans facturation / certification vivent dans l’application hôte (back-office boutique, médecin, auto-école, etc.). Pas d’app client dédiée « FISCAL » sans spec explicite.
SuperGest — exemple de découpage (2026-05-21)¶
| Surface | Acteur | Stack cible | Référence visuelle / comportement |
|---|---|---|---|
| Terminal POS | Caissier | Electron + React + PouchDB | Maquette SuperGest_Terminal_POS_v7.html · comportement CU-POS_Caisse.docx, supergest_pos.docx |
| Back-office gérant | Gérant / manager | Angular 17+ | SuperGest_BackOffice_Gerant.html |
| Admin produit DYNORS | Équipe DYNORS | Angular 17+ | SuperGest_DYNORS_Admin.html |
Démo maquette POS (Cloudflare Pages) : supergest.pages.dev/SuperGest_Terminal_POS — fichier déployé SuperGest_Terminal_POS.html (contenu = v7). Synchro depuis le workspace : scripts/sync_products_sites_maquettes.py → dépôt dynors-products-sites.
Historique maquettes POS v1–v4 : docs/projet-nouveau/SuperGEST/archive/ uniquement.
Sources de vérité (workspace agrégé)¶
| Besoin | Chemin |
|---|---|
| Specs produit à jour | docs/projet-nouveau/<Produit>/ |
| Index SuperGest | docs/projet-nouveau/SuperGEST/README.md |
| Méthode POS (maquette ↔ CU ↔ sécu) | docs/projet-nouveau/SuperGEST/SUPERGEST_POS_SYNTHESE_MAQUETTES_SPECS_UX_SECURITE.md |
| Point d’entrée workspace | docs/POINT_ENTREE_WORKSPACE_DYNORS.md (règle Cursor .cursor/rules/cartographie-ecrans-par-app-acteur-dynors.mdc) |
Checklist avant scaffolding UI¶
- [ ] Quel acteur exactement ?
- [ ] Dans quel artefact SPA / mobile / Electron déjà défini pour ce produit ?
- [ ] Aucune route critique d’un autre acteur dupliquée à tort (ex.
/pos/*dans le back-office gérant si le POS est une app séparée).