4nk/smart_ide
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add enso docs mirror under services/docv/enso-docs; docv integration docs

Browse Source 
- Copy enso/docs tree to services/docv/enso-docs (refresh via cp -a from enso repo)
- Document mirror and refresh command in services/docv/README.md
- Ignore services/docv/target for local Rust workspace
- Track docv-service-integration, API docv.md, and related doc index updates
This commit is contained in:
Nicolas Cantu 2026-04-03 17:26:35 +02:00
parent 1fcf057ce7
commit bc3c75e15f
82 changed files with 7494 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -2,3 +2,6 @@
core_ide/
# Clones applicatifs : hors de ce dépôt (ex. répertoire frère ../projects/). Les confs ia_dev sont dans ./projects/<id>/ (versionnées).
*node_modules/
# Rust build output if docv workspace is present under services/docv/
services/docv/target/

4
README.md
View File

@ -35,13 +35,13 @@ Le dépôt [**ia_dev**](https://git.4nkweb.com/4nk/ia_dev.git) est intégré com
|----------|---------|
| [docs/README.md](./docs/README.md) | Index de la documentation technique (`docs/`, `docs/features/`, `docs/API/`) |
| [docs/platform-target.md](./docs/platform-target.md) | Plateforme en ligne : envs test/pprod/prod, IA same-host, SSO docv, API IA docv |
| [docs/API/README.md](./docs/API/README.md) | Référence HTTP des services sous `services/` (endpoints, auth, ports) |
| [docs/API/README.md](./docs/API/README.md) | Référence HTTP des services sous `services/` + docv externe (endpoints, auth, ports) |
| [docs/infrastructure.md](./docs/infrastructure.md) | LAN, SSH, scripts d’accès hôte |
| [docs/services.md](./docs/services.md) | Ollama, AnythingLLM Docker, intégration |
| [docs/anythingllm-workspaces.md](./docs/anythingllm-workspaces.md) | Workspaces par projet, synchronisation |
| [docs/ux-navigation-model.md](./docs/ux-navigation-model.md) | Remplacer l’explorer : intentions, risques, vues, graphe, mode expert |
| [docs/system-architecture.md](./docs/system-architecture.md) | Couches, modules, agents, gateway, OpenShell, événements |
| [docs/ecosystem-architecture-and-sync.md](./docs/ecosystem-architecture-and-sync.md) | smart_ide, clones projet, API IA, Git / Ollama / AnythingLLM ; automation synchro |
| [docs/ecosystem-architecture-and-sync.md](./docs/ecosystem-architecture-and-sync.md) | smart_ide, clones projet, API IA, docv / données `../projects/<id>/data`, Git / Ollama / AnythingLLM |
| [docs/deployment-target.md](./docs/deployment-target.md) | Client Linux + SSH : serveur = socle IA + repos |
| [projects/README.md](./projects/README.md) | Confs `ia_dev` (`conf.json` seuls) — distinct des clones sous `../projects/` |
| [docs/ia_dev-submodule.md](./docs/ia_dev-submodule.md) | Sous-module Git `ia_dev`, clone / mise à jour |

3
docs/API/README.md
View File

@ -11,11 +11,14 @@ Documentation des **API HTTP** exposées par les services sous [`services/`](../
| **local-office** | `X-API-Key` | `8000` (exemple run) | [local-office.md](./local-office.md) |
| **ia-dev-gateway** | Bearer | `37144` (spécification) | [ia-dev-gateway.md](./ia-dev-gateway.md) |
| **smart_ide-orchestrator** | Bearer (spécification) | `37145` (spécification) | [orchestrator.md](./orchestrator.md) |
| **docv** (externe) | selon dépôt Enso | selon déploiement | [docv.md](./docv.md) |
**OpenAPI** : FastAPI expose une spec interactive pour **langextract-api** (`/docs`) et **local-office** (`/docs`) une fois le service démarré.
**Amont claw-code** : le binaire / serveur HTTP réel est hors de ce dépôt ; seul le **proxy** documenté ici fait partie du monorepo.
**docv** : serveur HTTP et OpenAPI dans le dépôt **docv** ; smart_ide ne les duplique pas — voir [docv.md](./docv.md).
**Implémentation minimale** : **ia-dev-gateway** et **smart_ide-orchestrator** ont un serveur Node/TS dans le monorepo (`npm run build` dans chaque dossier). Le branchement runner `ia_dev` et le proxy HTTP complet de l’orchestrateur restent à étendre.
Voir aussi : [services.md](../services.md), [system-architecture.md](../system-architecture.md), README de chaque dossier sous `services/`.

15
docs/API/docv.md Normal file
View File

@ -0,0 +1,15 @@
# docv (service externe)
**docv** n’est **pas** implémenté dans le monorepo `smart_ide`. Les endpoints HTTP, schémas et ports sont définis dans le **dépôt docv** (filière Enso).
## Consommation depuis smart_ide
- **Base URL** : variable d’environnement du type `DOCV_BASE_URL` (valeur par environnement, hors dépôt).
- **Auth** : selon le contrat docv (ex. Bearer `DOCV_API_TOKEN`) ; définir côté hôte sans commiter les secrets.
- **Données projet** : docv lit les fichiers sous **`${DOCV_PROJECTS_ROOT}/<projet>/data/`** — voir [features/docv-service-integration.md](../features/docv-service-integration.md).
## Documentation dans smart_ide
- Gestion documentaire, chemins, multi-hôte : [features/docv-service-integration.md](../features/docv-service-integration.md)
- Intégration IA : [features/docv-ai-integration.md](../features/docv-ai-integration.md)
- Contrat emplacement `services/docv/` : [services/docv/README.md](../../services/docv/README.md)

1
docs/README.md
View File

@ -56,6 +56,7 @@ Index des documents à la racine de `docs/`. Les **fonctionnalités** détaillé
| [features/lapce-porting-roadmap.md](./features/lapce-porting-roadmap.md) | Phases portage extension AnythingLLM → Lapce |
| [features/sso-docv-enso.md](./features/sso-docv-enso.md) | OIDC front ↔ docv (Enso) |
| [features/docv-ai-integration.md](./features/docv-ai-integration.md) | Backend docv : API IA smart_ide, clones `../projects/`, AnythingLLM |
| [features/docv-service-integration.md](./features/docv-service-integration.md) | docv gestion documentaire, `../projects/<id>/data`, `DOCV_PROJECTS_ROOT`, multi-hôte |
| [features/browser-automation-criteria.md](./features/browser-automation-criteria.md) | Critères service navigateur optionnel |
## Arborescence hors `docs/`

20
docs/ecosystem-architecture-and-sync.md
View File

@ -2,7 +2,7 @@
Ce document fixe la **répartition souhaitée** entre le monorepo **smart_ide**, les **dépôts applicatifs** développés ailleurs, la **couche API IA** (orchestrateur, gateway, micro-services HTTP), et les **services d’hôte** (**Git**, **Ollama**, **AnythingLLM**). Il décrit ensuite une **stratégie d’automatisation et de synchronisation** cohérente, centrée sur **Git** et des **scripts** du dépôt smart_ide.
Références complémentaires : [system-architecture.md](./system-architecture.md), [platform-target.md](./platform-target.md), [anythingllm-workspaces.md](./anythingllm-workspaces.md), [features/orchestrator-api.md](./features/orchestrator-api.md), [features/ia-dev-service.md](./features/ia-dev-service.md), [API/README.md](./API/README.md), [projects/README.md](../projects/README.md), [features/docv-ai-integration.md](./features/docv-ai-integration.md).
Références complémentaires : [system-architecture.md](./system-architecture.md), [platform-target.md](./platform-target.md), [anythingllm-workspaces.md](./anythingllm-workspaces.md), [features/orchestrator-api.md](./features/orchestrator-api.md), [features/ia-dev-service.md](./features/ia-dev-service.md), [API/README.md](./API/README.md), [projects/README.md](../projects/README.md), [features/docv-ai-integration.md](./features/docv-ai-integration.md), [features/docv-service-integration.md](./features/docv-service-integration.md).
## 1. Périmètres et référentiels
@ -36,13 +36,23 @@ flowchart TB
GW[ia_dev_gateway]
MS[micro_services]
end
subgraph docv_layer [docv_externe]
Docv[docv_HTTP]
DataA["projects_A_data"]
DataB["projects_B_data"]
end
SI --> Git
P1 --> Git
P2 --> Git
P1 --> DataA
P2 --> DataB
Docv --> DataA
Docv --> DataB
Orch --> Oll
Orch --> ALLM
Orch --> GW
Orch --> MS
Orch --> Docv
GW --> SI
Clients[IDE_docv_autres] --> Orch
```
@ -113,9 +123,13 @@ Objectif : après un changement **tracé dans Git**, les systèmes en aval (Anyt
| Workspace désynchronisé | `git pull` sur le clone concerné pour déclencher le hook ; ou exécuter manuellement `sync.mjs` avec les bons répertoires / variables. |
| Nouveau fichier sensible dans le dépôt | Vérifier **`.4nkaiignore`** avant le prochain upload ; ne pas indexer de secrets. |
## 5. Intégrations tierces (ex. docv)
## 5. Intégrations tierces (docv)
Le backend **docv** consomme la **même couche API IA** et les mêmes principes de **projet = clone Git + workspace** : [features/docv-ai-integration.md](./features/docv-ai-integration.md). L’**OIDC** (SSO) est orthogonal aux flux de synchro fichier : [features/sso-docv-enso.md](./features/sso-docv-enso.md).
- **Gestion documentaire** et données sous **`PROJECTS_CLONE_ROOT/<projet>/data/`** (souvent **`../projects/<projet>/data`** relatif à smart_ide) : [features/docv-service-integration.md](./features/docv-service-integration.md).
- **API IA** consommées par le backend docv (orchestrateur, Ollama, AnythingLLM, etc.) : [features/docv-ai-integration.md](./features/docv-ai-integration.md).
- **SSO OIDC** : orthogonal aux flux fichiers et aux appels serveur à serveur : [features/sso-docv-enso.md](./features/sso-docv-enso.md).
Sur un **hôte distinct**, docv résout `DOCV_PROJECTS_ROOT` localement ; smart_ide atteint docv via **`DOCV_BASE_URL`** — sans stockage partagé, les répertoires `data/` ne sont pas les mêmes sur les deux machines.
## 6. Non-objectifs explicites dans cette stratégie

2
docs/features/docv-ai-integration.md
View File

@ -1,5 +1,7 @@
# docv — intégrations IA via la plateforme smart_ide
**Gestion documentaire**, chemins **`../projects/<projet>/data`**, adaptation du dépôt docv et multi-hôte : [docv-service-integration.md](./docv-service-integration.md).
## Rôle de smart_ide
Le monorepo **smart_ide** sert aussi de **socle technique** pour les intégrations IA consommées par le **backend docv** (filière Enso). Le principe : exposer, parmi les services locaux, des **API HTTP génériques** (orchestrateur, gateway agents, Ollama, AnythingLLM, micro-services sous `services/`) que le back **docv** peut appeler pour offrir les fonctionnalités IA **par projet**.

61
docs/features/docv-service-integration.md Normal file
View File

@ -0,0 +1,61 @@
# docv — service de gestion documentaire et données projet
## Objectif
**docv** fournit la **gestion documentaire** aux projets de la filière Enso (workflows, API et stockage métier documents). Ce document fixe comment **smart_ide** référence docv comme **service externe** au monorepo, où placer les **données projet** (`../projects/<projet>/data`), et comment **adapter** le dépôt docv pour ne plus dépendre de chemins machine figés.
Les **intégrations IA** (orchestrateur, Ollama, AnythingLLM, etc.) sont décrites séparément : [docv-ai-integration.md](./docv-ai-integration.md).
## Emplacement du code docv
Le dépôt applicatif **docv** n’est **pas** copié dans smart_ide. Référence type sur une machine de développement : **`…/enso/docv`** (ex. `/home/desk/code/enso/docv`). Le dossier [services/docv/](../../services/docv/) dans smart_ide contient uniquement le **contrat** (README, exemple de noms de variables).
## Convention disque : clones et `data/`
```mermaid
flowchart TB
subgraph parent [Parent_commun_exemple_code]
SI[smart_ide]
PR[projects]
EN[enso_ou_autre]
SI --> SI
PR --> P1["projects_projA_data"]
PR --> P2["projects_projB_data"]
EN --> DV[docv_repo]
end
```
- **`PROJECTS_CLONE_ROOT`** : répertoire absolu qui contient un sous-dossier par **identifiant de projet** (`<projet>/`), avec le code ou la racine métier du clone. Convention alignée avec [projects/README.md](../../projects/README.md) : souvent le répertoire **frère** de `smart_ide` nommé **`projects`**, donc **`../projects`** relatif à la racine de smart_ide.
- **Données documentaires pour docv** : **`${PROJECTS_CLONE_ROOT}/<projet>/data/`**. Le contenu de `data/` est **synchronisé** par les mécanismes du projet (contrôle de version partiel, pipelines, rsync, stockage partagé) ; smart_ide ne prescrit pas un seul outil de synchro, mais impose la **structure** pour que docv résolve un chemin stable par projet.
## Adaptations attendues dans le dépôt docv (amont)
À réaliser dans le clone **docv** (hors ce monorepo) :
1. Variable d’environnement **`DOCV_PROJECTS_ROOT`** (ou nom équivalent documenté en équipe) : chemin absolu vers **`PROJECTS_CLONE_ROOT`** (parent des répertoires `<projet>/`).
2. Résolution du répertoire de données :
**`path.join(DOCV_PROJECTS_ROOT, projectId, 'data')`** (ou équivalent selon le langage), avec règles métier pour existence / création contrôlée.
3. Suppression des chemins **en dur** du type `/home/desk/code/enso/...` dans la logique runtime ; conserver de tels chemins uniquement comme **exemples** dans la documentation.
4. Par **environnement** (test, pprod, prod), utiliser des fichiers d’environnement **hors Git** avec des valeurs distinctes pour `DOCV_PROJECTS_ROOT` et URLs, alignés sur [platform-target.md](../platform-target.md).
## Multi-hôte : poste local docv vs serveur SSH smart_ide
**docv** peut tourner sur un **hôte différent** de celui où s’exécutent l’orchestrateur et les services smart_ide (ex. docv sur poste desk, smart_ide via SSH sur serveur distant).
- Les appels HTTP de smart_ide vers docv utilisent une **URL réseau** (`DOCV_BASE_URL`, TLS, allowlist) — voir [services/docv/.env.example](../../services/docv/.env.example).
- Le répertoire **`../projects/<projet>/data`** sur la machine **docv** n’est **pas** automatiquement le même que sur le serveur smart_ide : il faut un **stockage partagé** (NFS, montage), une **réplication**, ou une autre stratégie explicite. Sans cela, docv et smart_ide ne voient pas les mêmes fichiers.
## Orchestrateur et routage
Lorsque le routage « intentions » doit déléguer à docv (création de document, recherche catalogue métier, etc.), l’orchestrateur utilise la **base URL** et l’**auth** documentées pour l’environnement ; le détail des endpoints reste la responsabilité du dépôt docv. Index des services : [API/README.md](../API/README.md).
## SSO
L’authentification utilisateur (OIDC) entre front et docv : [sso-docv-enso.md](./sso-docv-enso.md). Elle ne remplace pas l’auth **serveur à serveur** entre composants smart_ide et docv.
## Liens
- Contrat dans le monorepo : [services/docv/README.md](../../services/docv/README.md)
- Copie de la doc **enso** (`docs/`) sous [services/docv/enso-docs/](../../services/docv/enso-docs/) (architecture docv, plans, etc.)
- IA : [docv-ai-integration.md](./docv-ai-integration.md)
- Écosystème et synchro Git : [ecosystem-architecture-and-sync.md](../ecosystem-architecture-and-sync.md)

2
docs/features/sso-docv-enso.md
View File

@ -33,6 +33,8 @@ sequenceDiagram
Intégrations **IA** côté backend docv (services smart_ide, clones, AnythingLLM) : [docv-ai-integration.md](./docv-ai-integration.md).
Gestion documentaire, chemins **`../projects/<projet>/data`**, **`DOCV_PROJECTS_ROOT`** : [docv-service-integration.md](./docv-service-integration.md).
## Paramètres à fixer avec le dépôt Enso
- `issuer` (URL stable par env)

9
docs/services.md
View File

@ -26,6 +26,12 @@ Ce document décrit les **services logiciels** typiques sur l’**hôte** (serve
- **Sécurité** : définir `API_KEYS` via variables d’environnement ou fichiers hors dépôt (voir `.env.example` dans `services/local-office/`). En production, préférer **bind `127.0.0.1`** derrière un reverse proxy TLS plutôt que `0.0.0.0` exposé.
- **Périmètre fonctionnel** : édition par commandes **docx** ; xlsx/pptx peuvent être stockés mais les commandes d’édition peuvent renvoyer **400** selon l’implémentation actuelle.
## docv (hors monorepo, contrat sous `services/docv/`)
- **Rôle** : gestion documentaire métier pour les projets Enso ; processus HTTP dans le **dépôt docv**, pas dans smart_ide.
- **Données** : convention **`${PROJECTS_CLONE_ROOT}/<projet>/data/`** (souvent **`../projects/<projet>/data`** relatif à smart_ide) ; variable **`DOCV_PROJECTS_ROOT`** côté docv.
- **Documentation** : [features/docv-service-integration.md](./features/docv-service-integration.md), [services/docv/README.md](../services/docv/README.md), [API/docv.md](./API/docv.md).
## Micro-services HTTP sous `services/`
Services d’appoint sur **`127.0.0.1`** (souvent auth **Bearer**) : Git devtools, LangExtract, recherche regex, proxy claw, **`ia-dev-gateway`** (agents / runs stub), **`smart-ide-orchestrator`** (routage intentions) — voir tableau dans [system-architecture.md](./system-architecture.md), la **référence API** dans [`API/README.md`](./API/README.md), et README de chaque sous-dossier de [`../services/`](../services/).
@ -36,4 +42,5 @@ Services d’appoint sur **`127.0.0.1`** (souvent auth **Bearer**) : Git devtool
- [features/local-office.md](./features/local-office.md)
- [system-architecture.md](./system-architecture.md)
- [anythingllm-workspaces.md](./anythingllm-workspaces.md)
- [API/README.md](./API/README.md)
- [API/README.md](./API/README.md)
- [features/docv-service-integration.md](./features/docv-service-integration.md)

3
docs/system-architecture.md
View File

@ -35,6 +35,7 @@ Conséquences :
| `extensions/anythingllm-workspaces/` | Outils / modèles alignés AnythingLLM et workspaces par projet |
| `scripts/` , `setup/` , `systemd/` | Installation hôte, scripts d’exploitation, unités utilisateur pour services |
| `services/local-office/` | **API REST** Office (upload, commandes docx, stockage SQLite + fichiers) ; complément programmatique à ONLYOFFICE |
| `services/docv/` | **Contrat d’intégration** docv (hors monorepo) ; données projet sous `../projects/<id>/data/` ; pas de code applicatif docv ici — [features/docv-service-integration.md](./features/docv-service-integration.md) |
| `projects/<id>/` (racine monorepo) | **Confs seules** pour `ia_dev` (`conf.json`) — **pas** les clones Git ; clones typiquement sous `../projects/` ou autre racine ; voir [projects/README.md](../projects/README.md) |
| `ia_dev/` | Agents, déploiements — exécution sous policy ; `projects/<id>/` du sous-module peut pointer vers `../../projects/<id>` (lien) ; voir sous-module |
| `services/ia-dev-gateway/` | Gateway HTTP (stub runner) : registre agents `.md`, runs, SSE — [features/ia-dev-service.md](./features/ia-dev-service.md) |
@ -69,7 +70,7 @@ L’**éditeur** et une partie de l’UX peuvent rester sur le client ; le **gat
| **AnythingLLM** | **Mémoire documentaire** et RAG ; **un workspace par projet** ([anythingllm-workspaces.md](./anythingllm-workspaces.md)) |
| **ONLYOFFICE** | Backend **documentaire métier** (documents, feuilles, présentations) |
Flux type : demande utilisateur → orchestrateur → préparation (scripts / tools génériques) → agents → besoin LLM → Ollama ; besoin doc / RAG → AnythingLLM ; besoin bureautique riche → ONLYOFFICE ; besoin **fichier Office manipulé par API** (tiers, scripts, agents) → **`services/local-office/`** (Local Office). Le **backend docv** peut s’appuyer sur les mêmes services pour des parcours IA **par projet** ([features/docv-ai-integration.md](./features/docv-ai-integration.md)).
Flux type : demande utilisateur → orchestrateur → préparation (scripts / tools génériques) → agents → besoin LLM → Ollama ; besoin doc / RAG → AnythingLLM ; besoin bureautique riche → ONLYOFFICE ; besoin **fichier Office manipulé par API** (tiers, scripts, agents) → **`services/local-office/`** (Local Office) ; besoin **gestion documentaire métier docv** → service **docv** (HTTP externe, données sous `../projects/<id>/data/` — [features/docv-service-integration.md](./features/docv-service-integration.md)). Le **backend docv** peut s’appuyer sur les mêmes services pour des parcours IA **par projet** ([features/docv-ai-integration.md](./features/docv-ai-integration.md)).
Enrichissement possible du routage (sans changer le principe « orchestrateur = logique de flux, pas LLM ») :

13
services/docv/README.md
View File

@ -2,6 +2,15 @@
Ce répertoire ne contient **pas** le code du produit **docv** (gestion documentaire pour les projets Enso). Il documente le **contrat d’intégration** entre le monorepo **smart_ide** et le dépôt **docv**, attendu sous un chemin du type **`…/enso/docv`** sur la machine qui exécute docv (ex. poste local `/home/desk/code/enso/docv`).
## Documentation Enso (`enso-docs/`)
Une **copie** de l’arborescence **`docs/`** du dépôt **enso** (source typique : `/home/ncantu/code/enso/docs`) est conservée sous **[`enso-docs/`](./enso-docs/)** pour consultation dans le monorepo **sans dépendre du clone enso** sur la machine. Point d’entrée : [`enso-docs/README.md`](./enso-docs/README.md). Après évolution majeure de la doc enso, **recopier** depuis le dépôt enso :
```bash
rm -rf services/docv/enso-docs
cp -a /chemin/vers/enso/docs services/docv/enso-docs
```
## Rôle de docv
**docv** apporte les **services de gestion documentaire** aux projets : stockage, workflows et API métier documents côté filière Enso. Les **données projet** ne sont pas dans le dépôt **smart_ide** : elles résident sous les clones applicatifs, selon la convention ci-dessous.
@ -13,8 +22,8 @@ Ce répertoire ne contient **pas** le code du produit **docv** (gestion document
| **`PROJECTS_CLONE_ROOT`** | Répertoire absolu parent des dossiers **`<projet>/`** (un clone ou racine métier par identifiant de projet). En pratique, aligné sur **`../projects`** relatif à la racine du clone **smart_ide** (voir [projects/README.md](../../projects/README.md)). |
| **Données documentaires docv** | Répertoire **`${PROJECTS_CLONE_ROOT}/<projet>/data/`** — contenu synchronisé selon la politique du projet (Git, jobs, rsync, montage NFS, etc.). |
Sur le **même hôte** que smart_ide, une valeur typique est :
`PROJECTS_CLONE_ROOT=/home/…/code/projects`
Sur le **même hôte** que smart_ide, une valeur typique est :
`PROJECTS_CLONE_ROOT=/home/…/code/projects`
si `smart_ide` est dans `/home/…/code/smart_ide`.
## Côté dépôt docv (amont)

104
services/docv/enso-docs/AI_DEV_INTEGRATION.md Normal file
View File

@ -0,0 +1,104 @@
# ai_dev — intégration déploiement et secrets (Enso)
Référence unique pour brancher **enso** sur l’outillage partagé (**`dev_ai` / `ai_dev`**) : variables d’environnement, secrets, scripts bash et agents Cursor. La section **7** résume les artefacts sous **`deploy/`** et renvoie aux fichiers versionnés dans le dépôt.
## 1. Racine outillage (`ai_dev` / `dev_ai`)
Ordre de résolution (identique dans **`deploy-env.sh`**, **`ssh.sh`**, **`sync-secrets-to-ai_dev.sh`**, **`deploy/deploy.sh`**) :
1. `AI_DEV_ROOT`
2. `DEV_AI_ROOT` (clone **dev_ai** côte à côte du monorepo, ex. `~/code/dev_ai`)
3. `IA_DEV_ROOT` (compatibilité)
4. `~/code/dev_ai`
5. `~/code/ai_dev`
6. `~/code/ia_dev`
Fichiers attendus : **`${ROOT}/deploy/lib/ssh.sh`**, et côté secrets : **`${ROOT}/.secrets/enso/<env>/enso-deploy.env`**.
## 2. Secrets canoniques
Arborescence cible dans **ai_dev** (versionnée ou non selon politique du dépôt ai_dev) :
```text
$TOOLING_ROOT/.secrets/enso/<test|pprod|prod>/enso-deploy.env
```
(`$TOOLING_ROOT` = première racine résolue selon la liste §1.)
Les scripts **enso** doivent **préférer** ce fichier s’il existe, sinon :
```text
<monorepo-enso>/.secrets/<env>/enso-deploy.env
```
## 3. Script de synchronisation
Fichier à ajouter : `deploy/scripts_v2/sync-secrets-to-ai_dev.sh`
(merge depuis `.secrets/<env>/enso-deploy.env` du monorepo vers `.secrets/enso/<env>/enso-deploy.env` dans ai_dev.)
## 4. Bibliothèque `_lib/deploy-env.sh`
Fonction `enso_resolve_deploy_env_file repo_root env` — à sourcer depuis `deploy.sh`, `bootstrap-from-local.sh`, `install-rust-on-local.sh`, `install-systemd-on-local.sh`.
## 5. Wrapper `deploy/deploy.sh`
Exécute **`$TOOLING_ROOT/deploy/deploy.sh enso "$@"`** avec la résolution §1 (`$TOOLING_ROOT` = première racine trouvée).
## 6. Agents Cursor
Ajoutés sous **`.cursor/agents/`** :
- **`ai-dev-secrets-merge.md`** (`/ai-dev-secrets-merge`) — exécute le script de fusion des secrets vers ai_dev.
- **`ai-dev-deploy.md`** (`/ai-dev-deploy`) — vérifie ai_dev, rappelle **ai-dev-secrets-merge** si besoin, puis applique intégralement **`deploy-by-script.md`**.
- **`fix.md`** et **`evol.md`** — après un **`/push-by-script`** réussi (code de sortie **0**), enchaînent **`/ai-dev-deploy`** pour publier sur **test** la révision distante correspondant à la branche, sauf demande explicite de ne pas déployer.
L’agent **`deploy-by-script.md`** référence ai_dev et la résolution des secrets (section *ai_dev*).
**Après déploiement réussi** (**branche** **`test`**, **`pprod`** ou **`prod`**, log avec **`[enso-health] all checks passed`**) : **`deploy-by-script.md` §6** impose un appel **`call_mcp_tool`** : serveur **`cursor-ide-browser`**, outil **`browser_navigate`**, arguments **`url`** = **`ENSO_PUBLIC_ORIGIN`** (lue dans le **`enso-deploy.env`** résolu) ou repli `https://{env}.enso.4nkweb.com`, et **`newTab`**: **`true`**. Option : second **`browser_navigate`** pour `https://{env}.docv.4nkweb.com` (**docv**). Même consigne depuis le monorepo **enso** ou **dev_ai** (**`deploy/deploy.sh enso`**).
---
## 7. Fichiers à créer / remplacer dans le dépôt (contenu de référence)
### 7.1 `deploy/scripts_v2/_lib/deploy-env.sh`
Voir le fichier dans le dépôt (boucle **`AI_DEV_ROOT`**, **`DEV_AI_ROOT`**, **`IA_DEV_ROOT`**, **`~/code/dev_ai`**, **`~/code/ai_dev`**, **`~/code/ia_dev`**).
### 7.2 `deploy/scripts_v2/_lib/ssh.sh`
Même ordre de candidats que §7.1 ; source **`${cand}/deploy/lib/ssh.sh`** au premier trouvé.
### 7.3 `deploy/scripts_v2/sync-secrets-to-ai_dev.sh`
Copie **`.secrets/<env>/enso-deploy.env`** du monorepo vers **`<outil>/.secrets/enso/<env>/enso-deploy.env`**, avec la même découverte de racine que §7.1. Voir le fichier versionné dans le dépôt.
Puis : `chmod +x deploy/scripts_v2/sync-secrets-to-ai_dev.sh`.
### 7.4 Modifier `deploy/scripts_v2/deploy.sh`
Après `SCRIPT_DIR` / `REPO_ROOT` et le parsing `ENV`, **remplacer** l’affectation directe de `DEPLOY_ENV_FILE` par :
```bash
# shellcheck source=deploy-env.sh
source "$SCRIPT_DIR/_lib/deploy-env.sh"
enso_resolve_deploy_env_file "$REPO_ROOT" "$ENV"
echo "[enso-deploy] enso-deploy.env source=${ENSO_DEPLOY_ENV_SOURCE} file=${DEPLOY_ENV_FILE}"
```
Conserver **`source "$SCRIPT_DIR/_lib/ssh.sh"`** **après** la résolution du fichier env (comme aujourd’hui), ou **avant** si l’ordre actuel est conservé — l’important est d’avoir **`DEPLOY_ENV_FILE`** défini avant `source "$DEPLOY_ENV_FILE"`.
### 7.5 Idem pour `bootstrap-from-local.sh`, `install-rust-on-local.sh`, `install-systemd-on-local.sh`
Même bloc `source deploy-env.sh` + `enso_resolve_deploy_env_file "$REPO_ROOT" "$ENV"` à la place de `DEPLOY_ENV_FILE="${REPO_ROOT}/.secrets/..."`.
### 7.6 `deploy/deploy.sh` (racine du dossier `deploy/` dans enso)
**`exec`** le premier **`${C}/deploy/deploy.sh enso "$@"`** trouvé avec la même liste de candidats que §1. Voir le fichier versionné ; **`chmod +x`** appliqué dans le dépôt.
### 7.7 `deploy/enso-deploy.env.example`
En-tête : copie canonique sous l’outil partagé, repli monorepo, commande **`sync-secrets-to-ai_dev.sh`** (déjà présent dans le dépôt).
### 7.8 `deploy/README.md` et `docs/INSTALLATION_ENVIRONNEMENT.md` §7.15
**`dev_ai` / `ai_dev`** en premier, variables **`DEV_AI_ROOT`**, repli **`ia_dev`** et **`~/code/ia_dev`** ; secrets **`.secrets/enso/<env>/`** et script **`sync-secrets-to-ai_dev.sh`** (voir fichiers à jour dans le dépôt).

250
services/docv/enso-docs/ARCHITECTURE_DOCV_DETAILLEE.md Normal file
View File

@ -0,0 +1,250 @@
# Architecture logicielle détaillée — docv
Proposition d’architecture logicielle détaillée pour le socle **docv** (agnostique métier), consommée par **enso**. Ce document complète `docs/ARCHITECTURE_DOCV_ENSO.md` en se limitant au périmètre docv.
---
## 1. Rôle et périmètre de docv
- **Rôle** : socle commun contenant tout le **code** applicatif (back et front) agnostique du métier côté périmètre avocat. Le projet **enso** **configure** ce socle et n’ajoute que des **spécifiques** validés.
- **Périmètre** : authentification, offices, utilisateurs, rôles et permissions, dossiers (folders), documents, types de documents et de dossiers, partage et invitations, notes et rappels, textes i18n, configuration système (écrans, actions, options), ancrage et IA consommés côté back uniquement.
- **Hors périmètre docv** : IdNot, API notaire, Mailchimp, OVH, Stripe, écrans et flux métier spécifiques avocat ou notaire (listés dans `docs/features/SPECIFIQUES_PROJETS.md`).
---
## 2. Vue d’ensemble des couches
```
┌─────────────────────────────────────────────────────────────────────────┐
│ docv-front (Next.js / React, TypeScript) │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ Pages/App │ │ Components │ │ API client │ │ Design system │ │
│ │ (routes) │ │ (UI, layout) │ │ (backend) │ │ + i18n │ │
│ └──────┬──────┘ └──────┬───────┘ └──────┬──────┘ └────────┬────────┘ │
│ │ │ │ │ │
│ └───────────────┴────────────────┴──────────────────┘ │
│ │ HTTP (JSON) │
└────────────────────────────────────┼────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ docv-back (Rust: Axum ou Actix) │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ Handlers │→│ Services │→│ Repositories│→│ DB + clients │ │
│ │ (HTTP) │ │ (métier) │ │ (accès BDD)│ │ (ancrage, IA) │ │
│ └─────────────┘ └──────────────┘ └─────────────┘ └─────────────────────┘ │
│ │ │ │ │ │
│ ┌──────┴────────────────┴────────────────┴────────────────────┐ │
│ │ Middleware: auth, logging, CORS, rate limit, erreurs │ │
│ └───────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌─────────────────┐ ┌────────────────────────────────────────────────────┐
│ PostgreSQL │ │ API externes (back uniquement): ancrage, IA │
│ (docv BDD) │ │ (serveur services / api-anchorage ; sous-module ai) │
└─────────────────┘ └────────────────────────────────────────────────────┘
```
- **Front** : ne parle qu’au backend docv ; pas d’appel direct aux API externes.
- **Back** : orchestre la logique métier, la BDD et les clients HTTP vers l’ancrage et l’IA.
- **Partagé** : `docv-shared` (Rust, natif + WASM) pour validation, formatage, constantes ; optionnellement `docv-core` (TS) pour types et contrats API.
---
## 3. Backend (docv-back)
### 3.1 Structure des répertoires
```text
docv-back/
├── Cargo.toml
├── .env.example
├── migrations/
├── seeds/
└── src/
├── main.rs # Bootstrap, routes, middleware
├── config/ # Chargement env, config app et DB
├── db/ # Pool connexions, run migrations
├── error/ # Types erreur, impl IntoResponse / From
├── handlers/ # Contrôleurs HTTP (entrée/sortie uniquement)
├── services/ # Logique métier (orchestration)
├── repositories/ # Accès données (requêtes SQL / ORM)
├── models/ # Entités et DTOs (sérialisation)
├── middleware/ # Auth, logging, CORS, rate limit
├── clients/ # Clients HTTP externes (anchoring, ia)
└── routes.rs # Agrégation des routes
```
### 3.2 Responsabilités par couche
| Couche | Rôle | Exemples |
|--------|------|----------|
| **handlers** | Recevoir la requête HTTP, valider les entrées (form/body), appeler le service, renvoyer la réponse (JSON ou erreur). Pas de logique métier ni de SQL. | `auth.rs` (login, logout), `folders.rs` (CRUD), `documents.rs`, `system_configuration.rs`, `screen_config.rs`, `action_config.rs` |
| **services** | Logique métier : règles, orchestration, appels aux repositories et aux clients externes (ancrage, IA). Pas d’accès direct à la requête HTTP. | `auth_service`, `folder_service`, `document_service`, `parametrage_service` (résolution écrans/actions/options), `anchoring`, `ia` |
| **repositories** | Requêtes SQL (ou ORM) et mapping vers les modèles. Pas de règles métier. | `user_repository`, `folder_repository`, `document_repository`, `screen_config_repository` |
| **models** | Structures de données (entités BDD, DTOs requête/réponse). Sérialisation / désérialisation (serde). | `User`, `Folder`, `Document`, `ScreenConfig`, `ActionConfig` |
| **clients** | Appels HTTP sortants vers l’API d’ancrage (serveur services, api-anchorage) et l’API IA (sous-module ai). Erreurs typées, pas de fallback silencieux. | `anchoring_client`, `ia_client` |
| **middleware** | Auth (JWT ou session), logging structuré, CORS, rate limit, centralisation des erreurs. | `auth_middleware`, `logging_middleware`, `error_handler` |
| **config** | Lecture des variables d’environnement et construction de la config (DB URL, secret JWT, URLs ancrage/IA, feature flags). | `Config`, `load_from_env` |
| **error** | Types d’erreur métier et techniques ; impl `From` et `IntoResponse` pour un retour HTTP cohérent. | `AppError`, `AuthError`, `NotFoundError` |
### 3.3 Ressources API (principales)
- **Auth** : `POST /auth/login`, `POST /auth/logout`, `GET /auth/me`, éventuellement refresh.
- **Offices** : `GET /offices`, `GET /offices/:id`, `PUT /offices/:id` (selon droits).
- **Users** : `GET /users`, `GET /users/:id`, `PUT /users/:id` (selon droits).
- **Roles** : `GET /roles`, `GET /roles/:id`, `POST /roles`, `PUT /roles/:id` (admin).
- **Folders** : `GET /folders`, `GET /folders/:id`, `POST /folders`, `PUT /folders/:id`, `DELETE /folders/:id`, `GET /folders/archived`, `GET /folders/deleted`.
- **Documents** : `GET /folders/:folderId/documents`, `POST /folders/:folderId/documents`, `GET /documents/:id`, `PUT /documents/:id`, `DELETE /documents/:id`, upload/download.
- **Document types** : `GET /document-types`, `POST /document-types`, `GET /document-types/:id`, `PUT /document-types/:id`.
- **Folder types (case types)** : `GET /folder-types`, `POST /folder-types`, `GET /folder-types/:id`, `PUT /folder-types/:id`.
- **Site texts (i18n)** : `GET /site-texts` (filtré par clé, locale), `PUT /site-texts` (admin).
- **System configuration** : `GET /system-configuration`, `PUT /system-configuration` (admin), clés masquées pour les valeurs sensibles.
- **Paramétrage écrans/actions** : `GET /screen-config`, `GET /action-config` (résolus par office/rôle/type de dossier) ; `PUT /screen-config`, `PUT /action-config` (admin).
- **Ancrage** : pas d’endpoint direct front ; le back appelle l’API ancrage dans les services (ex. à la validation d’un document).
- **IA** : pas d’endpoint direct front ; le back appelle l’API IA dans les services (ex. extraction, chat, synthèse). Référence : `docs/features/IA_GRANDS_PRINCIPES.md`.
### 3.4 Base de données (PostgreSQL)
- **Migrations** : versionnées (ex. SQLx ou Diesel), appliquées au démarrage ou via une commande dédiée.
- **Seeds** : rôles par défaut, matrice de permissions, types de documents/dossiers, textes site, configuration système (écrans, actions, options), données de démo optionnelles.
- **Entités principales** (agnostiques) : `users`, `contacts`, `addresses`, `offices`, `office_members`, `roles`, `role_permissions`, `folders`, `folder_types`, `documents`, `document_types`, `site_texts`, `system_configuration`, `screen_config`, `action_config`, `folder_share`, `invitations`, `notes`, `reminders`. Pas de champs IdNot ou notaire dans le noyau docv.
### 3.5 Clients externes (back uniquement)
- **Ancrage** : client HTTP vers le serveur **services** (infra 4NK), projet **api-anchorage**. Appel depuis un service (ex. après validation d’un document) ; résultat stocké ou renvoyé dans la réponse métier.
- **IA** : client HTTP vers l’API du sous-module **ai** (TypeScript, socle Ollama/AnythingLLM). Appel depuis un service (extraction, chat, synthèse) ; jamais exposé directement au front. Référence : `docs/features/IA_GRANDS_PRINCIPES.md`.
---
## 4. Frontend (docv-front)
### 4.1 Structure des répertoires
```text
docv-front/
├── package.json
├── tsconfig.json
├── next.config.* (ou équivalent)
├── .env.example
├── public/
└── src/
├── app/ # App Router (Next.js) ou pages/
│ ├── layout.tsx
│ ├── page.tsx
│ ├── (auth)/
│ ├── folders/
│ ├── documents/
│ ├── offices/
│ ├── users/
│ ├── roles/
│ ├── admin/
│ ├── my-account/
│ └── ...
├── components/
│ ├── layout/ # Header, sidebar, breadcrumb
│ ├── ui/ # Design system (Button, Input, Table, Modal…)
│ └── domain/ # Composants métier (FolderCard, DocumentList…)
├── design-system/ # Tokens, thème par défaut
│ ├── tokens/
│ ├── theme.ts
│ └── index.ts
├── api/ # Client API (appels backend docv)
│ ├── client.ts # Instance HTTP, intercepteurs, erreurs
│ ├── auth.ts
│ ├── folders.ts
│ ├── documents.ts
│ ├── screen-config.ts # Chargement config écrans/actions
│ └── ...
├── i18n/ # Structure + textes par défaut (fr, en)
│ ├── keys.ts
│ ├── fr.json
│ └── en.json
├── stores/ # État global (context ou store)
├── hooks/ # useAuth, useFolders, useScreenConfig…
├── utils/ # Helpers (format, validation si pas WASM)
└── types/ # Types TS alignés contrats back
```
### 4.2 Règles front
- **Un seul client API** : tous les appels passent par le client docv-back (pas d’URL ancrage ni IA côté front).
- **Paramétrage** : chargement de la config écrans/actions (et options) au login ou au changement d’office ; affichage des menus et boutons selon cette config ; pas de listes d’écrans/actions en dur.
- **i18n** : clés structurées ; textes par défaut dans docv ; pas de texte en dur dans l’UI.
- **Design system** : tokens (couleurs, typo, espacements) et thème par défaut ; composants réutilisables pour **enso** (surcharges possibles).
- **Accessibilité** : ARIA, contraste, clavier (référence `docs/SCREENS_AND_FUNCTIONS_MAP.md` et règles projet).
---
## 5. Code partagé (docv-shared, docv-core)
### 5.1 docv-shared (Rust, natif + WASM)
- **Contenu** : validation de champs (email, longueur, format), formatage (dates, montants), constantes métier (codes erreur, limites), règles métier pures sans I/O.
- **Usage back** : dépendance Rust classique (natif).
- **Usage front** : build WASM (wasm-pack), import depuis le front pour réutiliser la même logique (validation formulaire, formatage affichage).
- **Place** : `docv/docv-shared/` ; consommée par docv-back et docv-front (et éventuellement enso-back, enso-front).
### 5.2 docv-core (TypeScript, optionnel)
- **Contenu** : types et contrats API (DTOs, réponses paginées), constantes partagées (codes erreur, clés i18n de base). Peut être généré depuis OpenAPI (docv-back) pour garder les contrats alignés.
- **Usage** : importé par docv-front et enso-front pour typage et appels API.
- **Place** : `docv/docv-core/` ; pas de logique métier lourde (celle-ci reste dans docv-shared/WASM ou dans les services back).
---
## 6. Paramétrage (écrans, actions, options)
- **Stockage** : tables (ou entités) `screen_config`, `action_config` et tables dédiées pour les options (workflow, types de documents, etc.) + `system_configuration` pour les feature flags et options globales. Référence : `docs/features/PARAMETRAGE_ECRANS_ACTIONS.md`.
- **Résolution** : service dédié (ex. `parametrage_service`) qui fusionne plateforme → office → type de dossier → rôle → préférence utilisateur ; exposé au front via des endpoints du type `GET /screen-config`, `GET /action-config` (et éventuellement `GET /me/preferences`).
- **Back** : les handlers qui renvoient des listes d’écrans ou d’actions (pour le menu, les boutons) s’appuient sur ce service ; les middlewares d’auth peuvent enrichir le contexte avec les permissions résolues.
- **Front** : chargement de la config au démarrage ou au changement d’office ; rendu conditionnel des routes et des boutons selon la config ; pas de liste en dur.
---
## 7. Sécurité
- **Authentification** : session ou JWT ; renouvellement et déconnexion gérés par le back.
- **Login par défaut docv** : docv fournit un **système de login par défaut** (identifiant / mot de passe, session ou JWT, choix d’office actif) pour **tous les types de membres** : rôles des offices, membres des dossiers, droits par ressource. **enso** utilise ce login docv tel quel (aucune implémentation auth spécifique requise dans le périmètre actuel).
- **Autorisation** : matrice rôle × ressource × action ; vérification dans les services ou middleware avant toute opération sensible.
- **CSRF** : token CSRF sur les requêtes mutantes (formulaires, POST/PUT/DELETE) ; middleware back pour vérification.
- **Secrets** : aucun secret en front ; URLs et clés API (ancrage, IA) uniquement en back (variables d’environnement ou config serveur).
- **Entrées** : validation côté back (et optionnellement côté front via docv-shared WASM) ; pas de confiance aveugle au client.
---
## 8. Gestion des erreurs et logging
- **Back** : types d’erreur typés (`AppError`, `AuthError`, `NotFound`, `ValidationError`) ; impl `IntoResponse` pour un format JSON cohérent ; logging structuré (niveau, contexte, pas de données sensibles).
- **Front** : le client API transforme les réponses d’erreur en erreurs typées ; affichage utilisateur via i18n (messages génériques ou clés d’erreur) ; pas de fallback silencieux.
- **Clients externes** : erreurs ancrage/IA remontées avec contexte ; journalisées ; pas de continuation silencieuse.
---
## 9. Build et exécution
- **docv-back** : `cargo build`, `cargo run` ; migrations au démarrage ou `cargo run -- migrate` ; variables d’environnement via `.env` ou env.
- **docv-front** : `npm run build`, `npm run dev` ; variables d’environnement pour l’URL du backend (ex. `NEXT_PUBLIC_API_URL`).
- **docv-shared** : `cargo build` (natif) et `wasm-pack build --target web` (ou équivalent) pour le front ; le front importe le `pkg/` généré.
- **Ordre de build** : docv-shared (natif + WASM) → docv-back (dépend docv-shared) ; docv-front (dépend docv-shared pkg si WASM, et docv-core si présent).
---
## 10. Dépendances et flux de données
- **docv** ne dépend pas d’**enso**.
- **Données** : le front envoie des requêtes au back ; le back lit/écrit la BDD et appelle les API ancrage/IA ; les réponses repassent par le back vers le front.
- **Paramétrage** : la config (écrans, actions, options) est lue depuis la BDD par le back et servie au front ; les mises à jour se font via les endpoints admin (back uniquement).
---
## 11. Références
- **Architecture globale** : `docs/ARCHITECTURE_DOCV_ENSO.md`
- **Plan de réalisation** : `docs/PLAN_REALISATION_DOCV_ENSO.md`
- **Cartographie écrans et actions** : `docs/SCREENS_AND_FUNCTIONS_MAP.md`
- **Paramétrage** : `docs/features/PARAMETRAGE_ECRANS_ACTIONS.md`
- **Référentiel écrans et actions** : `docs/features/REFERENTIEL_ECRANS_ACTIONS.md`
- **Description technique d’implémentation (par zone)** : `docs/features/implementation/README.md`
- **Spécifiques enso** : `docs/features/SPECIFIQUES_PROJETS.md`
- **Grands principes IA** : `docs/features/IA_GRANDS_PRINCIPES.md`

438
services/docv/enso-docs/ARCHITECTURE_DOCV_ENSO.md Normal file
View File

@ -0,0 +1,438 @@
# Proposition de découpage et organisation — docv / enso
Ce document décrit une organisation possible du dépôt **enso** pour héberger le socle commun **docv** (agnostique métier) et la déclinaison **enso** (avocats). **Périmètre actuel du dépôt :** implementation et documentation centrées sur docv et enso ; les sections historiques mentionnant d’autres dépôts ou produits restent comme référence sans livraison dans ce clone.
---
## 1. Objectif
- **docv** : partie rendue commune et agnostique (types, contrats, i18n de base, utilitaires, éventuellement composants UI de base). Pour la logique partagée entre back et front, utiliser **WebAssembly (WASM)** si c’est plus pratique (crate Rust compilée en natif + WASM).
- **enso** : déclinaison pour les avocats (front + back consommant docv).
**Consommation prioritaire des API docv (docv-back) par les fronts produits pour le périmètre métier commun.** Détail d’implémentation (zones, stack, surface API) : [docs/docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) (entête) ; déclinaison **enso** : [docs/enso/README.md](enso/README.md) §4.1.
### 1bis. Paramétrabilité des écrans, actions et options
Chaque **écran**, chaque **action** (fonctionnalité) et chaque **option d’implémentation** doit être **paramétrable** (activation, visibilité, droits, libellés, choix techniques ou métier) sans modification de code. Les niveaux de paramétrage sont : plateforme, office, type de dossier, rôle, préférence utilisateur. Référence : `docs/SCREENS_AND_FUNCTIONS_MAP.md` (principe de paramétrabilité) et `docs/features/PARAMETRAGE_ECRANS_ACTIONS.md`.
### 1ter. Code dans docv, configuration et spécifiques dans enso
- **Code** : le code applicatif (back et front) est développé dans **docv**. docv porte la structure, les composants, les services, les écrans et les actions génériques (agnostiques métier).
- **Configuration** : le projet **enso** **configure** ce qu’il utilise (paramétrage des écrans, des actions, des options d’implémentation, des données par défaut : rôles, types de documents, types de dossiers, textes, thème). Pas de duplication de code : il hérite docv et surcharge par configuration (BDD, seeds, system_configuration, paramétrage par office).
- **Spécifiques uniques** : **enso** peut avoir des **spécifiques uniques** (écrans, actions, services métier, intégrations API ou libellés non présents dans docv). Chaque spécifique doit être **listé et confirmé** avant implémentation. Aucun spécifique ne doit être codé sans avoir été validé et documenté. Référence : `docs/features/SPECIFIQUES_PROJETS.md`.
- **Authentification** : docv fournit un **login par défaut** (identifiant / mot de passe, session, choix d’office) pour tous les types de membres (rôles, dossiers, offices). **enso** l’utilise par défaut.
---
## 2. Référence fonctionnelle (sans dépôt applicatif externe obligatoire)
La cartographie des écrans et des règles attendues est tenue dans `docs/SCREENS_AND_FUNCTIONS_MAP.md`, les specs par zone dans `docs/features/specs/`, et les spécifiques enso dans `docs/features/SPECIFIQUES_PROJETS.md`. Aucun autre dépôt n’est requis dans ce clone pour décrire ou implémenter docv / enso.
---
## 2bis. API externes et consommation côté back uniquement
- **API d’ancrage** : c’est celle du serveur **services** (infrastructure 4NK), dans son projet Bitcoin **api-anchorage**. Service externe ; les backends **docv** et **enso** la **consomment** (aucune implémentation de l’API d’ancrage dans le dépôt enso).
- **Consommation des API** : **toutes les API externes** (ancrage, IA, etc., selon le périmètre déployé) sont **consommées par les backends exclusivement**. Les frontends n’appellent que leur propre backend ; ils ne parlent jamais directement aux API tierces.
- **API IA** : développée dans un **sous-module Git** `ai` (dépôt https://git.4nkweb.com/4nk/ai.git), en **TypeScript**, pour interagir avec le socle IA de la machine (voir section 2ter).
---
## 2ter. Environnement de développement et socle IA
La machine de développement dispose de :
- **Ollama**, **AnythingLLM**, **Obsidian**
- **Node.js**, **PostgreSQL**
- **Modèles préinstallés** pour Ollama et AnythingLLM
L’**API IA** consommée par les backends (**docv**, **enso**) est développée dans un **sous-module Git** :
- **URL** : https://git.4nkweb.com/4nk/ai.git
- **Rôle** : développer l’API IA en **TypeScript** et faire le lien avec ce socle IA (Ollama, AnythingLLM, modèles préinstallés).
- **Intégration** : le dépôt enso doit importer ce dépôt en **sous-module Git** (ex. `ai/` à la racine ou dans un répertoire dédié). Les backends appellent cette API IA (ex. service local ou déployé) ; ils ne parlent pas directement à Ollama ou AnythingLLM.
- **Grands principes IA** : dossier synchronisé sur un workspace AnythingLLM ; pré-traitement par librairies (traductions vers anglais uniquement, extractions vers JSON uniquement, vérification de vraisemblance des codes/IDs/clés en amont, prétraitement images/formats non convertibles) ; IA pour les opérations demandées ; workflow optionnel (anonymisation, décontextualisation, appel IA cloud, recontextualisation) ; déclenchement des fonctionnalités IA via un Cursor instrumenté pour l’API, avec utilisation systématique des agents, subagents, commandes, skills et plans par le code et les hooks. Détail : `docs/features/IA_GRANDS_PRINCIPES.md`.
Commande pour ajouter le sous-module (à exécuter depuis la racine du dépôt enso, après validation) :
```bash
git submodule add https://git.4nkweb.com/4nk/ai.git ai
```
---
## 3. Structure détaillée de chaque sous-projet
### 3.0 Code partagé back/front et WebAssembly
Lorsque du **code doit être partagé entre backends (Rust) et frontends** (ex. validation, formatage, constantes, règles métier pures), **utiliser WebAssembly (WASM) si c’est plus pratique** que de dupliquer la logique (ex. en TypeScript côté front et Rust côté back) ou que de maintenir deux implémentations.
- **Principe** : une **crate Rust partagée** (ex. `docv-shared`) est compilée :
- en **natif** pour les backends (docv-back, enso-back), qui l’utilisent comme dépendance Rust classique ;
- en **WASM** (`target wasm32-unknown-unknown` ou `wasm32-wasi`) pour les frontends, qui l’importent via `wasm-bindgen` / `wasm-pack` (ou équivalent) et l’appellent depuis le JavaScript/TypeScript.
- **Contenu typique** : validation de champs, formatage dates/montants, constantes métier, codes erreur, règles de calcul ou de cohérence sans I/O. Tout ce qui est pure logique et doit être identique back et front.
- **Quand privilégier WASM** : logique partagée non triviale, besoin de garantir la même implémentation partout, réutilisation déjà en Rust côté back. **Quand ne pas forcer WASM** : simple partage de types/contrats (garder docv-core en TS ou génération depuis OpenAPI), ou logique très légère où le coût d’intégration WASM (build, chargement) l’emporte.
- **Place dans l’arborescence** : la crate partagée vit sous docv (ex. `docv/docv-shared/`) et est consommée par docv-back, docv-front (en WASM), et éventuellement par enso-back, enso-front si la logique est commune.
Les arborescences ci-dessous décrivent la structure cible de chaque sous-projet. **Les backends** (**docv**, **enso**) utilisent **le même langage et les mêmes frameworks** (Rust, même stack HTTP et PostgreSQL). **Les frontends** (**docv**, **enso**) utilisent **le même langage et les mêmes frameworks** (ex. Next.js, TypeScript). docv inclut un backend Rust et un frontend ; **enso** a un front et un back sur cette même base technique, qui consomment ou héritent de docv.
### 3.1 docv
**Documentation dédiée docv :** point d’entrée `docs/docv/README.md` (périmètre zones 1–15, ordre de réalisation Phase 1, liens vers specs et implémentation).
docv est le socle commun : backend Rust, frontend moderne, BDD PostgreSQL dédiée. Il porte les structures et données par défaut (BDD, textes, design, rôles, documents, dossiers, membres). Pour l’ancrage et l’IA : les backends **consomment** l’API d’ancrage (serveur services, projet Bitcoin api-anchorage) et les API IA ; ces API ne sont jamais appelées depuis les fronts (voir section 2bis).
```text
docv/
├── package.json # Workspace root docv (scripts build/lint pour front + back)
├── Cargo.toml # Workspace Rust (docv-shared, docv-back)
│
├── docv-shared/ # Crate Rust partagée back/front (optionnel WASM)
│ ├── Cargo.toml # lib, target natif + [target.'cfg(target_arch = "wasm32")'].dependencies (wasm-bindgen)
│ ├── src/
│ │ ├── lib.rs
│ │ ├── validation/ # Règles de validation (réutilisées back + front via WASM)
│ │ ├── format/ # Formatage dates, montants, etc.
│ │ ├── constants/ # Codes erreur, limites, paramètres métier
│ │ └── rules/ # Règles métier pures (sans I/O)
│ └── pkg/ # Sortie wasm-pack (si WASM) pour import front
│
├── docv-back/ # Backend Rust
│ ├── Cargo.toml
│ ├── .env.example
│ ├── migrations/ # Migrations SQL versionnées
│ │ └── *.sql
│ ├── seeds/ # Données par défaut (rôles, permissions, document_types, site_texts, etc.)
│ │ └── *.sql
│ ├── src/
│ │ ├── main.rs # Point d’entrée
│ │ ├── config/ # Configuration (env, db, app)
│ │ ├── db/ # Connexion pool, migrations
│ │ ├── error/ # Types d’erreur, mapping HTTP
│ │ ├── handlers/ # Handlers HTTP par ressource
│ │ │ ├── auth.rs
│ │ │ ├── folders.rs
│ │ │ ├── documents.rs
│ │ │ ├── offices.rs
│ │ │ ├── users.rs
│ │ │ ├── roles.rs
│ │ │ ├── site_texts.rs
│ │ │ ├── system_configuration.rs
│ │ │ └── ...
│ │ ├── services/ # Logique métier
│ │ │ ├── folder_service.rs
│ │ │ ├── document_service.rs
│ │ │ ├── auth_service.rs
│ │ │ ├── anchoring/ # Client vers API ancrage (serveur services, projet api-anchorage)
│ │ │ └── ia/ # Client vers API IA (sous-module ai, TypeScript, socle Ollama/AnythingLLM)
│ │ ├── models/ # Entités / DTOs (sérialisation)
│ │ ├── repositories/ # Accès BDD (requêtes)
│ │ ├── middleware/ # Auth, logging, rate limit, CORS
│ │ └── routes.rs # Agrégation des routes
│ └── logs/ # Logs applicatifs (hors dépôt ou .gitignore)
│
├── docv-front/ # Frontend (Next.js ou équivalent)
│ ├── package.json
│ ├── tsconfig.json
│ ├── next.config.* (ou équivalent)
│ ├── .env.example
│ ├── public/
│ │ └── ...
│ ├── src/
│ │ ├── app/ # App router (si Next.js App Router) ou pages/
│ │ │ └── ...
│ │ ├── pages/ # Pages (si Next.js Pages Router)
│ │ │ ├── folders/
│ │ │ ├── documents/
│ │ │ ├── offices/
│ │ │ ├── users/
│ │ │ ├── roles/
│ │ │ ├── admin/
│ │ │ └── ...
│ │ ├── components/ # Composants réutilisables
│ │ │ ├── layout/
│ │ │ ├── ui/ # Design system (boutons, inputs, etc.)
│ │ │ └── ...
│ │ ├── design-system/ # Tokens, thème par défaut (structure pour enso)
│ │ │ ├── tokens/ # Couleurs, typo, espacements
│ │ │ ├── theme.ts
│ │ │ └── index.ts
│ │ ├── api/ # Client API (appels backend docv)
│ │ │ ├── client.ts
│ │ │ ├── folders.ts
│ │ │ ├── documents.ts
│ │ │ └── ...
│ │ ├── i18n/ # Structure textes + textes par défaut (fr, en)
│ │ │ ├── keys.ts
│ │ │ ├── fr.json
│ │ │ └── en.json
│ │ ├── stores/ # État global (context, store)
│ │ ├── hooks/
│ │ ├── utils/ # Helpers partagés
│ │ └── types/ # Types TS (alignés contrats back)
│ └── dist/ ou .next/
│
└── docv-core/ # Optionnel : package partagé TS (types, contrats, constantes)
├── package.json # @enso/docv-core
├── tsconfig.json
├── src/
│ ├── types/ # Entités métier agnostiques
│ ├── contracts/ # DTOs, réponses API
│ ├── constants/
│ └── index.ts
└── dist/
```
- **docv-back** : service HTTP Rust (Axum/Actix), connexion PostgreSQL, migrations + seeds pour structure et données par défaut. Dépend de `docv-shared` (natif). Handlers et services pour auth, dossiers, documents, offices, users, rôles, site_texts, system_configuration ; sous-dossiers `anchoring` et `ia` pour les **clients** HTTP vers l’API d’ancrage (serveur services, projet api-anchorage) et vers l’**API IA** (sous-module `ai`, TypeScript, qui s’appuie sur le socle Ollama/AnythingLLM). Ces API externes sont consommées par le back uniquement (voir sections 2bis et 2ter).
- **docv-front** : application front complète ; design-system avec tokens et thème par défaut ; i18n avec structure et textes par défaut ; pages et composants pour toutes les fonctionnalités docv. Si WASM utilisé : importe le build `docv-shared` (pkg wasm-pack) pour validation, formatage, constantes partagés.
- **docv-core** : optionnel ; package partagé TS exposant types, contrats et constantes pour **docv-front** et **enso-front**. Peut coexister avec docv-shared (WASM) : docv-core pour types/contrats API, docv-shared pour logique partagée en Rust/WASM.
Architecture logicielle détaillée (couches, modules, API, paramétrage, sécurité) : `docs/ARCHITECTURE_DOCV_DETAILLEE.md`.
---
### 3.2 enso (avocats)
**Documentation dédiée enso :** point d’entrée `docs/enso/README.md` (périmètre, spécifiques E1–E31, liens vers specs, implémentation, référentiel).
enso a sa propre BDD, ses textes, son design, ses paramétrages (rôles, documents, dossiers, membres) et ses API tiers ; il hérite de la structure et des défauts de docv. Les API externes (ancrage, IA) sont **consommées par le backend uniquement** ; le front n’appelle que enso-back (voir section 2bis). Backend et frontend utilisent les mêmes langages et frameworks que docv (Rust côté back, même stack front que docv-front).
```text
enso/
├── package.json # Scripts qui délèguent à enso-front et enso-back
│
├── enso-front/ # Même stack que docv-front (ex. Next.js, TypeScript)
│ ├── package.json # dependency: docv-front ou @enso/docv-core (types/contrats)
│ ├── tsconfig.json
│ ├── next.config.* (ou équivalent)
│ ├── .env.example
│ ├── public/
│ ├── src/
│ │ ├── app/ ou pages/
│ │ │ └── ... # Pages spécifiques avocat (dossiers, mandats, etc.)
│ │ ├── components/ # Composants spécifiques enso (surcharges ou nouveaux)
│ │ ├── theme/ # Surcharges du design system docv (couleurs, marque enso)
│ │ │ └── overrides.ts
│ │ ├── api/ # Client API enso uniquement (pas d’appel direct aux API externes)
│ │ ├── i18n/ # Textes enso (structure héritée, clés spécifiques ou surcharges)
│ │ │ ├── fr.json
│ │ │ └── en.json
│ │ ├── stores/
│ │ ├── hooks/
│ │ └── types/
│ └── dist/ ou .next/
│
└── enso-back/ # Même stack que docv-back (Rust)
├── Cargo.toml
├── .env.example
├── migrations/ # Migrations SQL (structure dérivée docv)
│ └── *.sql
├── seeds/ # Données spécifiques avocat
│ └── *.sql
├── src/
│ ├── main.rs
│ ├── config/
│ ├── db/
│ ├── error/
│ ├── handlers/ # Handlers HTTP par ressource
│ │ ├── auth.rs
│ │ ├── folders.rs
│ │ ├── documents.rs
│ │ └── ...
│ ├── services/
│ │ ├── common/ # Auth, logging, erreurs (mêmes patterns que docv)
│ │ ├── lawyer/ # Dossiers avocat, mandats, etc.
│ │ └── docv/ # Optionnel : client vers backend docv si délégation ; sinon client direct API ancrage (services, api-anchorage) et API IA
│ ├── models/
│ ├── repositories/
│ ├── middleware/
│ └── routes.rs
└── logs/
```
- **enso-front** : même langage et framework que docv-front ; hérite du design system docv (structure + défauts), surcharge le thème (couleurs, marque) ; textes et paramétrages spécifiques avocat ; pas d’IdNot, Mailchimp, OVH, Stripe.
- **enso-back** : même langage et framework que docv-back (Rust) ; BDD enso (PostgreSQL), schéma aligné sur la structure docv ; services `lawyer/` pour la logique avocat ; **consomme** les API externes (ancrage : serveur services, api-anchorage ; IA) côté back uniquement. Le front n’appelle que enso-back.
---
### 3.3 Périmètre notaire (hors dépôt actuel)
Un produit dédié au secteur notarial n’est pas arborescé ici pour l’instant. Orientation : [`docs/HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md).
---
### 3.4 Racine du monorepo (rappel)
```text
enso/ # Dépôt (workspace root)
├── package.json # workspaces: docv, docv/docv-front, ...
├── .gitmodules # Déclaration du sous-module ai (après git submodule add)
├── .cursor/
│ └── rules/ # Règles Cursor (qualité, lint, clôture)
├── docs/
│ ├── features/
│ ├── fixKnowledge/
│ ├── ARCHITECTURE_DOCV_ENSO.md
│ └── PLAN_REALISATION_DOCV_ENSO.md
├── deploy/ # Scripts et configs déploiement (docv, enso)
├── .secrets/ # Secrets par env (hors dépôt ou ignorés)
├── ai/ # Sous-module Git → https://git.4nkweb.com/4nk/ai.git (API IA TypeScript, socle Ollama/AnythingLLM)
├── docv/
│ ├── docv-shared/ # Crate Rust partagée (natif + WASM pour fronts)
│ ├── docv-back/ # Rust
│ ├── docv-front/ # Next.js ou équivalent
│ └── docv-core/ # Optionnel (TS partagé)
├── enso/
│ ├── enso-front/
│ └── enso-back/
```
Les workspaces npm à la racine incluent les frontends déclarés dans le `package.json` racine (ex. `docv/docv-front`, `docv/docv-core`, `enso/enso-front` selon évolution du dépôt). Les backends Rust (**docv-back**, **enso-back**) sont gérés par Cargo ; la racine peut appeler `cargo build` dans chaque répertoire back ou via un workspace Cargo commun. Le répertoire **`ai/`** est un **sous-module Git** (https://git.4nkweb.com/4nk/ai.git) : API IA en TypeScript, développée pour interagir avec le socle IA (Ollama, AnythingLLM, modèles préinstallés) ; les backends consomment cette API (voir section 2ter).
---
## 4. Proposition d’arborescence pour enso (vue globale)
Monorepo avec **workspaces npm** à la racine. Deux produits suivis dans ce dépôt : **docv** (commun) et **enso** (avocats). Chacun peut avoir un front et un back, dépendants de docv pour le partagé.
```text
enso/ # Dépôt (workspace root)
├── package.json # workspaces, scripts globaux (lint, typecheck, build)
├── docs/ # Documentation technique
│ ├── features/
│ ├── fixKnowledge/
│ └── ARCHITECTURE_DOCV_ENSO.md
├── deploy/ # Déploiement (scripts, configs, hooks)
├── .secrets/ # Secrets par environnement (hors dépôt ou ignorés)
│
├── docv/ # Commun agnostique
│ ├── package.json # @enso/docv ou docv-core
│ ├── src/
│ │ ├── types/ # Entités métier agnostiques
│ │ │ ├── document.ts
│ │ │ ├── folder.ts
│ │ │ ├── office.ts
│ │ │ ├── user.ts
│ │ │ └── index.ts
│ │ ├── contracts/ # DTOs, contrats API partagés
│ │ ├── i18n/ # Clés et traductions de base (fr, en)
│ │ ├── utils/ # Helpers partagés (validation, format, etc.)
│ │ └── constants/
│ ├── tsconfig.json
│ └── dist/
│
├── enso/ # Déclinaison avocats
│ ├── package.json # scripts qui délèguent aux sous-packages
│ ├── enso-front/ # Même stack que docv-front (ex. Next.js)
│ │ ├── package.json # dependency: "@enso/docv" ou "docv-core"
│ │ ├── src/
│ │ │ ├── pages/
│ │ │ ├── components/ # Spécifique avocat
│ │ │ ├── api/
│ │ │ └── ...
│ │ └── public/
│ └── enso-back/ # Même stack que docv-back (Rust)
│ ├── Cargo.toml
│ ├── migrations/
│ ├── src/
│ │ ├── handlers/
│ │ ├── services/ # common/, lawyer/, docv/
│ │ └── ...
│ └── logs/
```
---
## 5. Découpage fonctionnel
### 5.1 docv (commun)
- **Responsabilité** : tout ce qui est indépendant du métier notaire vs avocat.
- **Contenu proposé** :
- **types** : Document, Folder, Office, User, Contact, Address, File, etc. (noms et champs agnostiques).
- **contracts** : DTOs et interfaces d’API réutilisables (création document, pagination, réponses standard).
- **i18n** : clés et fichiers de traduction communs (erreurs, libellés génériques, formats).
- **utils** : validation, formatage dates/montants, helpers de transformation.
- **constants** : codes erreur, limites, paramètres par défaut.
- **Pas dans docv** : logique métier spécifique notaire (ancrage, actes, IdNot, etc.) ou avocat (mandats, dossiers avocat), ni couche d’accès données (Prisma, repositories).
### 5.2 enso (avocats)
- **enso-front** : même langage et framework que docv-front ; application dédiée aux avocats ; importe docv pour types, i18n, design system ; pages et composants spécifiques avocat.
- **enso-back** : même langage et framework que docv-back (Rust) ; BDD enso (PostgreSQL), schéma aligné sur docv ; services `common/` (auth, logging, erreurs) et `lawyer/` (dossiers, mandats) ; consomme les API externes (ancrage : serveur services, api-anchorage ; IA) côté back uniquement.
### 5.3 Périmètre notaire (hors dépôt actuel)
Voir [`docs/HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md).
---
## 6. Workspaces npm (racine)
Exemple de `package.json` à la racine de enso :
```json
{
"name": "enso-monorepo",
"private": true,
"workspaces": [
"docv/docv-front",
"docv/docv-core",
"enso/enso-front"
],
"scripts": {
"build": "npm run build --workspaces --if-present",
"build:back": "cargo build --manifest-path docv/docv-back/Cargo.toml && cargo build --manifest-path enso/enso-back/Cargo.toml",
"lint": "npm run lint --workspaces --if-present",
"typecheck": "npm run typecheck --workspaces --if-present"
}
}
```
Les packages **docv-front**, **docv-core** (si présent) et **enso-front** sont référencés par leur chemin. Les backends Rust sont buildés via Cargo (voir script `build:back` ou workspace Cargo à la racine).
---
## 7. Dépendances entre packages
- **docv** : aucune dépendance vers **enso**.
- **enso-front**, **enso-back** : dépendent de **docv** uniquement pour le partagé.
---
## 8. Nommage des packages
- **docv** : `@enso/docv` ou `docv-core` (à aligner avec la convention du dépôt).
- **enso** : `@enso/enso-front`, `@enso/enso-back` (ou `enso-front`, `enso-back`).
Les noms ci-dessus sont des propositions ; à valider selon les usages (npm privé, `file:../docv`, etc.).
---
## 9. Déploiement et environnements
- **deploy/** à la racine : scripts et configs communs (build, déploiement, hooks).
- Le sous-projet **enso** peut avoir ses propres cibles (test, pprod, prod) et variables d’environnement ; les scripts dans `deploy/` peuvent appeler les builds des workspaces concernés (par exemple build docv puis enso-front et enso-back pour la cible « enso »).
---
## 10. Documentation
- **docs/features/** : évolutions (objectif, impacts, déploiement, analyse).
- **docs/fixKnowledge/** : correctifs (problème, cause, corrections, déploiement, analyse).
- **docs/SCREENS_AND_FUNCTIONS_MAP.md** : cartographie des écrans et des fonctions attendues (wording générique).
- **docs/features/specs/README.md** : référentiel des spécifications par fonctionnalité (une spec par zone, détail objectif, écrans, actions, règles métier, API, déploiement, analyse).
- Ce fichier reste la référence pour le découpage **docv / enso** et l’architecture du monorepo.
---
## 11. Résumé
| Sous-projet | Rôle | Contenu principal |
|-------------|------|--------------------|
| **docv** | Commun agnostique | docv-shared (Rust, natif + WASM si partage back/front), docv-back (Rust), docv-front (ex. Next.js), docv-core (TS partagé) ; structure et défauts pour tous |
| **enso** | Avocats | enso-front (même stack que docv-front) + enso-back (Rust, même stack que docv-back), consomment docv |
Un périmètre notaire distinct est documenté hors arborescence applicative actuelle : [`docs/HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md).
Cette proposition concerne l’organisation du dépôt **enso** et l’intégration de **docv** et **enso**.

5
services/docv/enso-docs/HORS_PERIMETRE_NOTAIRE.md Normal file
View File

@ -0,0 +1,5 @@
# Périmètre notaire — hors dépôt actuel
Un déploiement dédié au secteur notarial (intégrations réglementaires ou métier spécifiques) n’est pas suivi dans ce dépôt pour l’instant.
Pour l’architecture et le plan **docv / enso** : [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md), [PLAN_REALISATION_DOCV_ENSO.md](PLAN_REALISATION_DOCV_ENSO.md).

388
services/docv/enso-docs/INSTALLATION_ENVIRONNEMENT.md Normal file
View File

@ -0,0 +1,388 @@
# Installation de l'environnement — enso (docv / enso)
Ce document décrit l’installation de l’environnement du projet **sans Docker** : prérequis, clone, build, et déploiement sur les machines **test**, **pprod** et **prod**. La configuration du **proxy** et des **certificats** sur la machine proxy est prévue ultérieurement.
**Références :** [README.md](README.md), [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md), [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md).
---
## 1. Vue d’ensemble
| Élément | Description |
|--------|-------------|
| **Pas de Docker** | Les applications sont installées et exécutées directement sur l’OS (binaires Rust, build Next.js, processus Node). |
| **Machines cibles** | **test** (192.168.1.101), **pprod** (192.168.1.102), **prod** (192.168.1.103). Chaque environnement est déployé sur sa machine dédiée. |
| **Domaines DNS** | **enso :** `test.enso.4nkweb.com`, `pprod.enso.4nkweb.com`, `prod.enso.4nkweb.com`. **docv :** `test.docv.4nkweb.com`, `pprod.docv.4nkweb.com`, `prod.docv.4nkweb.com` (configurés). |
| **Proxy** | La machine **proxy** (192.168.1.100) assure le reverse proxy et les certificats SSL. La configuration détaillée pour **enso** et **docv** est **à faire plus tard** (voir `deploy/nginx/`). |
| **Ports** | Mêmes ports en développement, test, pprod et prod ; aucun port déjà utilisé par d’autres services. Détail : [PORTS_ENSO.md](PORTS_ENSO.md). |
| **Accès** | Accès SSH aux machines via le proxy (ProxyJump). Utilisateur : `ncantu`. |
| **smart_ide** | Dépôt outillage ([smart_ide](https://git.4nkweb.com/4nk/smart_ide)) : socle dev orienté IA (Ollama, AnythingLLM, etc.). **Accès SSH sur le LAN : 192.168.1.164** (même mode d’accès que les autres hôtes internes : bastion / proxy selon votre `~/.ssh/config`). |
---
## 2. Prérequis
À installer sur chaque machine cible (test, pprod, prod) et sur la machine de développement.
| Logiciel | Version minimale | Usage |
|----------|------------------|--------|
| **Node.js** | 18+ | Build des fronts (Next.js), scripts npm. |
| **npm** | 9+ | Workspaces, install, build. |
| **Rust** (cargo, rustc) | **1.78+** (lock **Cargo.lock** version 4), toolchain **épinglée 1.88.0** (fichier `rust-toolchain.toml` à la racine du dépôt) | Compilation des backends **docv-back** et **enso-back** ; **rustup** obligatoire — éviter le seul paquet `cargo`/`rustc` du système si votre `PATH` pointe encore vers `/usr/bin/cargo` (souvent trop ancien). |
| **PostgreSQL** | 14+ | BDD par environnement (une instance par machine ou une BDD par projet selon choix). |
| **Git** | 2+ | Clone du dépôt et du sous-module `ai`. |
Sous Debian/Ubuntu (à adapter selon l’OS) :
```bash
# Node.js (via NodeSource ou nvm selon politique)
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libssl-dev
# Rust (rustup — après install, ~/.cargo/bin doit précéder /usr/bin dans PATH)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain 1.88.0
source "$HOME/.cargo/env"
# Depuis la racine du dépôt cloné : prise en compte de rust-toolchain.toml (ex. 1.88.0)
# rustup show && cargo --version
# PostgreSQL client et serveur
sudo apt-get install -y postgresql postgresql-client
# Git
sudo apt-get install -y git
```
---
## 3. Clone du dépôt et sous-modules
### 3.1 Dépôt canonique et fork (`4nk/enso` vs `nicolas.cantu/enso`)
| Rôle | URL typique |
|------|-------------|
| **Canonique (organisation)** | `https://git.4nkweb.com/4nk/enso.git` — SSH : `git@git.4nkweb.com:4nk/enso.git` |
| **Fork / miroir personnel** | `https://git.4nkweb.com/nicolas.cantu/enso.git` (exemple) |
Les deux peuvent coexister : un poste de développement peut avoir **`origin`** sur le fork tandis que les **serveurs** (test, pprod, prod) clonent le dépôt que le compte de déploiement peut lire — en pratique souvent **`4nk/enso`** (variable **`ENSO_GIT_CLONE_URL`** dans **`.secrets/<env>/enso-deploy.env`**, voir **`deploy/enso-deploy.env.example`**). L’historique Git attendu reste aligné entre fork et canonique.
### 3.2 Clone
Sur la machine de développement ou sur chaque machine cible (si build sur la cible) :
```bash
git clone https://git.4nkweb.com/4nk/enso.git
cd enso
git submodule update --init --recursive
```
Le sous-module **ai** (API IA) est référencé dans `.gitmodules`. Si le dépôt `ai` est vide ou indisponible, le clone du sous-module peut échouer ; dans ce cas, poursuivre sans `ai` ou initialiser le sous-module lorsque le dépôt est prêt.
### 3.3 Branche `test` (et équivalent) sur le dépôt distant
Le script **`deploy/scripts_v2/deploy.sh`** fait un **`git pull origin <env>`** sur la cible (ex. **`test`**). Il faut que la branche distante existe (ex. **`git push origin master:test`** depuis la branche contenant le code à déployer) ou que la phase distante retombe sur **`master`** tant que **`origin/test`** n’existe pas (message d’avertissement dans les logs).
Sur **Gitea**, si le message **« Push to create is not enabled for users »** apparaît, la création de branche à la volée est désactivée : un administrateur peut activer l’option correspondante ou créer la branche **`test`** sur le dépôt, puis vous pousser dessus avec les droits habituels.
---
## 4. Variables d’environnement
Chaque environnement (test, pprod, prod) utilise ses propres variables. Aucun secret ne doit être commité : utiliser `.env` (ignoré par Git) ou un mécanisme de déploiement (fichiers dans `.secrets/<env>/` copiés à la main ou par script).
### 4.1 Backends
**enso-back (Rust)** : binaire **`enso-back`**, variables **`HOST`**, **`PORT`** (**3040** derrière le proxy — voir [PORTS_ENSO.md](PORTS_ENSO.md)), `enso/enso-back/.env.example`. Build : `cargo build --release --manifest-path enso/enso-back/Cargo.toml` ; exécution : `enso/enso-back/target/release/enso-back`. Déploiement sur **192.168.1.164** : section **7.5** (adapter le chemin si besoin).
**docv-back (Rust)** — variables attendues (documentées dans le code et dans [docs/docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) §5.4) :
| Variable | Description | Exemple |
|----------|-------------|---------|
| `DATABASE_URL` | URL de connexion PostgreSQL | `postgres://user:password@localhost:5432/docv_test` |
| `JWT_SECRET` | Secret pour la signature des JWT | Chaîne longue et aléatoire |
| `OAUTH_CLIENT_ID` | Identifiant(s) client OAuth2 publics (virgule = plusieurs applis) | `enso-web` ou `enso-web,autre-id` |
| `OAUTH_CLIENT_SECRET` | Secret confidentiel pour `/oauth/token` | Aligné avec le front / enso-back |
| `OAUTH_REDIRECT_URIS` | URIs de callback autorisées (séparées par des virgules) | `https://test.enso.4nkweb.com/auth/docv-callback` |
| `OAUTH_BROWSER_PATH_PREFIX` | Préfixe public devant `/oauth/…` (reverse proxy, ex. `/docv-api`) | `/docv-api` ; vide seulement si OAuth est à la racine du site |
| `DOCV_USERS_PK_COLUMN` | Colonne PK sur `users` pour le login OAuth : `id` (défaut) ou `uid` (schéma existant type IMPL) | `uid` si la table utilise `uid` au lieu de `id` |
| `DOCV_OAUTH_ACCESS_TOKEN_TTL_SEC` | Durée **unique** (secondes) pour : jeton **Bearer** (`JWT` `exp`, `expires_in`), JWT dans le cookie **`docv_oauth_session`** et **`Max-Age`** du cookie après **`POST /oauth/sign-in`**. | Défaut **900** (15 min) ; plage **60**–**86400**. Détail : [docv/AUTH_SESSION.md](docv/AUTH_SESSION.md). |
| `DOCV_DEMO_MEMBER_EMAILS` | (optionnel) **Contournement test / BDD incomplete** : emails séparés par des **virgules** ; au **démarrage** de docv-back, chaque utilisateur listé **sans** ligne `office_members` reçoit un lien sur le **plus ancien** office en rôle **`client`** (champ technique). Ne remplace pas le rattachement métier cabinet / client ni le choix d’espace au login (docv). | Ex. `client@example.com` |
| `DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE` | (optionnel) **`1`** / **`true`** / **`yes`** / **`on`** : au **démarrage**, **tout** utilisateur **sans** `office_members` est lié au **plus ancien** office uniquement. **Test** : avec plusieurs offices démo, un compte « orphelin » ne verra qu’**une** société ; memberships explicites requis pour le périmètre réel. **Déconseillé en prod**. Voir [AUTH_SESSION.md](docv/AUTH_SESSION.md) § modèle produit. | `1` sur **test** par défaut via deploy (surcharge possible) |
| `OAUTH_TENANTS_JSON` | (optionnel) JSON de branding par `client_id` | Voir `docv/docv-back/tenants.default.json` |
| `OAUTH_TENANTS_PATH` | (optionnel) chemin fichier JSON de branding | `/chemin/vers/tenants.json` |
| `HOST` | Adresse d’écoute du serveur HTTP | `0.0.0.0` |
| `PORT` | Port d’écoute | `3038` (docv-back), **3040** (enso-back). Fronts : `3032` (enso-front), **3005** (docv-front prévu). Voir [PORTS_ENSO.md](PORTS_ENSO.md). |
| `ANCHORING_URL` | URL de l’API d’ancrage (serveur services) | À définir selon l’infra |
| `IA_API_URL` | URL de l’API IA (sous-module ai) | **Nominal :** `http://192.168.1.164:3022` (API IA sur le serveur smart_ide / LAN). **Poste client** : utiliser cette URL si l’API ne tourne pas localement ; sinon `http://localhost:3022`. **test, pprod, prod** : `http://192.168.1.164:3022`. Voir [PORTS_ENSO.md](PORTS_ENSO.md). |
| `DOCV_FILE_STORAGE_DIR` | (optionnel) Répertoire des octets pour `POST .../documents/binary` | Ex. `/var/lib/docv/uploads` ; sans cette variable, pas de téléchargement binaire (`503`). |
| `DOCV_UPLOAD_MAX_BYTES` | (optionnel) Taille max du corps d’upload binaire | Défaut `10485760`. |
| `DOCV_DP_GIT_SYNC` | (optionnel) `1` / `true` : après miroir sous `data/dossiers-permanents/`, enchaîne `git add` / `commit` / `push` | Nécessite un clone « writable » avec remote configuré ; voir [features/DOSSIERS_PERMANENTS_DATA_GIT.md](features/DOSSIERS_PERMANENTS_DATA_GIT.md). |
| `DOCV_DP_GIT_REPO_ROOT` | Racine du dépôt Git (monorepo enso ou copie miroir) | Ex. `/srv/4NK/enso-test/repo` |
| `DOCV_DP_GIT_DATA_SUBPATH` | Sous-chemin des DP versionnés depuis la racine | Défaut `data/dossiers-permanents` |
| `DOCV_DP_GIT_REMOTE` | Nom du remote pour `git push` | Défaut `origin` |
| `DOCV_DP_GIT_BRANCH` | Branche distante ciblée (`git push HEAD:refs/heads/…`) | Ex. `test` ; si vide, `git push` sans refspec explicite |
**Note `JWT_SECRET` :** le changer sur docv-back **invalide** les access tokens déjà émis. Les utilisateurs connectés doivent se **reconnecter**. Côté **enso-front**, une réponse **401** sur les appels **docv** (`docvFetch`, upload binaire, etc.) déclenche la même séquence que la **déconnexion menu** : effacement jeton / état OAuth dans le **sessionStorage**, puis **`GET /oauth/sign-out`** docv avec **`return_url`** = **`/?signed_out=1`** (accueil ; enchaînement vers **`/login?signed_out=1`** — voir `invalidateLocalSessionAndGoHome`, `ensoSignedOutHomeReturnUrl`).
Fichier d’exemple (à copier et renseigner, ne pas commiter les valeurs réelles) :
```bash
# .env.example (à copier en .env)
DATABASE_URL=postgres://user:password@localhost:5432/docv_test
JWT_SECRET=your-jwt-secret
HOST=0.0.0.0
PORT=3038
ANCHORING_URL=
IA_API_URL=
```
### 4.2 Fronts (enso-front)
**enso-front (Next.js)** : copier `enso/enso-front/.env.example` vers `.env.local` (dev) ou `.env.production.local` (serveur, non versionné). Le script **`deploy/scripts_v2/remote/bootstrap-enso-remote.sh`** écrit un fichier **`enso/enso-front/.env.production.local`** aligné sur **`ENSO_PUBLIC_ORIGIN`** (mêmes clés que l’exemple, secret OAuth docv partagé avec la valeur générée pour `docv-back`).
| Variable | Portée | Description |
|----------|--------|-------------|
| `NEXT_PUBLIC_ENSO_PUBLIC_ORIGIN` | client | Origine publique du site enso (ex. `https://test.enso.4nkweb.com`). |
| `NEXT_PUBLIC_DOCV_OAUTH_CLIENT_ID` | client | Identifiant client OAuth (ex. `enso-web`, aligné sur docv-back). |
| `NEXT_PUBLIC_DOCV_OAUTH_AUTHORIZE_BASE` | client | URL de base du endpoint authorize docv (ex. `…/docv-api/oauth/authorize`). |
| `NEXT_PUBLIC_DOCV_API_BASE` | client | Optionnel : base URL des appels API métier avec Bearer (`/api/v1/…`). Défaut navigateur : origine du site + `/docv-api`. Écrit par **`deploy/scripts_v2/remote/bootstrap-enso-remote.sh`** sur les déploiements bootstrap. |
| `DOCV_OAUTH_TOKEN_URL` | serveur Next | URL du endpoint token docv (sur la machine : en général `http://127.0.0.1:3038/oauth/token`). |
| `DOCV_OAUTH_CLIENT_ID` | serveur Next | Même id que côté public. |
| `DOCV_OAUTH_CLIENT_SECRET` | serveur Next | Secret partagé avec **docv-back** (`OAUTH_CLIENT_SECRET`). |
Si la route **`/api/auth/docv-token`** renvoie *Configuration serveur incomplète (secret OAuth)*, **`DOCV_OAUTH_CLIENT_SECRET`** est absent ou vide dans **`.env.production.local`** côté Next : il doit être **identique** à **`OAUTH_CLIENT_SECRET`** dans **`docv/docv-back/.env`**. Le script **`bootstrap-enso-remote.sh`** synchronise ce secret vers **`enso-front`** et **`enso-back`** même lorsqu’il ne réécrit pas **`docv-back/.env`** (fichier déjà présent). L’unité **`deploy/systemd/enso-enso-front.service`** charge ce fichier via **`EnvironmentFile`** (comme **`enso-back`** avec **`.env`**) : après modification des secrets, **`systemctl --user daemon-reload`** puis **`systemctl --user restart enso-enso-front`**, ou relancer **`deploy/systemd/install-user-units.sh`** si le modèle d’unité a changé.
Chaque déploiement distant (**`deploy/scripts_v2/remote/enso-remote-phase.sh`**) exécute **`sync-docv-oauth-secret-to-enso.sh`** : copie **`OAUTH_CLIENT_SECRET`** depuis **`docv/docv-back/.env`** vers **`DOCV_OAUTH_CLIENT_SECRET`** dans **`enso-front/.env.production.local`** et **`enso/enso-back/.env`**, afin d’éviter un front déployé sans secret alors que docv en dispose déjà.
**HTTP 500** sur cette route avec un corps JSON : en pratique, le cas le plus fréquent est le secret manquant ci‑dessus (**Next** ne voit pas **`DOCV_OAUTH_CLIENT_SECRET`**). Après correction des fichiers, **`systemctl --user restart enso-enso-front`** (ou un nouveau déploiement) recharge l’**`EnvironmentFile`**. Sinon, lire le corps de la réponse dans les outils réseau du navigateur : une clé **`detail`** (renvoyée par docv) indique le rejet côté **`/oauth/token`** (code invalide, redirect_uri, etc.). Vérifier aussi que nginx envoie **`location /api/`** vers **enso-front (3032)** et non vers **enso-back (3040)** (voir **`docs/operations/NGINX_ENSO_API_ROUTING.md`**).
En développement : `npm run dev` (port **3032**). Sur les machines test/pprod/prod : **`npm run start`** après `next build` (unit **systemd** : `deploy/systemd/enso-enso-front.service`).
Les anciennes variables **Vite** `VITE_DOCV_*` ne sont plus utilisées ; tout l’OAuth / callback passe par les clés ci-dessus et la route handler **`/api/auth/docv-token`**.
Le tableau de bord et la barre latérale appellent **docv-back** en HTTPS sur **`{origine publique}/docv-api/api/v1/…`** avec l’en-tête **`Authorization: Bearer`** (token d’accès OAuth). Nginx route le préfixe **`/docv-api/`** vers docv-back (port **3038** sur l’infra de référence). Liste des routes HTTP et câblage front : [features/DOCV_API_ENSO_FRONT_MAP.md](features/DOCV_API_ENSO_FRONT_MAP.md) §1 ; socle, migrations et narrative : [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) §3.1. Le front agrège les requêtes stubs (notifications, pending-documents, conversations) dans **`DocvStubListsProvider`** via **`Promise.all`**.
### 4.3 Par environnement
- **test** : BDD dédiée (ex. `docv_test`, `enso_test`), secrets de test, URLs pointant vers les domaines de test.
- **pprod** : BDD et secrets de préproduction ; URLs de préproduction.
- **prod** : BDD et secrets de production ; URLs de production.
Les fichiers `.secrets/<env>/` (ex. `.secrets/test/`, `.secrets/pprod/`, `.secrets/prod/`) peuvent contenir les `.env` ou fichiers équivalents par projet ; à déployer manuellement ou via script (hors dépôt).
---
## 5. Build
### 5.1 Fronts
Depuis la racine du monorepo :
```bash
npm install
npm run build
```
Cela build les workspaces configurés (`enso/enso-front`). **enso-front** produit le build Next.js (`.next/`, `next start`) sur le port **3032** ; le reverse proxy doit router **`/api/`** vers **enso-front (3032)** pour les Route Handlers Next (ex. **`/api/auth/docv-token`**), pas vers **enso-back (3040)**.
Pour un seul front enso :
```bash
cd enso/enso-front
npm install
npm run build
```
### 5.2 Backends (Rust)
Depuis la racine :
```bash
# docv (workspace : docv-shared + docv-back)
cargo build --release --manifest-path docv/Cargo.toml --workspace
# enso-back
cargo build --release --manifest-path enso/enso-back/Cargo.toml
```
Binaires produits (à déployer sur la machine cible) :
- `docv/target/release/docv-back`
- `enso/enso-back/target/release/enso-back`
**enso-back** : `enso/enso-back/target/release/enso-back` après `cargo build --release --manifest-path enso/enso-back/Cargo.toml`, avec `.env` (**PORT=3040** typiquement).
---
## 6. Base de données PostgreSQL
Sur chaque machine (test, pprod, prod), créer les bases et utilisateurs nécessaires. Exemple pour l’environnement **test** :
```bash
sudo -u postgres psql -c "CREATE USER enso_test WITH PASSWORD '...';"
sudo -u postgres psql -c "CREATE DATABASE docv_test OWNER enso_test;"
sudo -u postgres psql -c "CREATE DATABASE enso_test OWNER enso_test;"
```
Exécuter les **migrations** (SQL ou outil utilisé par le projet — SQLx migrate, Diesel, etc.) avant le premier démarrage des backends. Les migrations sont dans le dépôt (ex. `docv/docv-back/migrations/` ou équivalent) et doivent être appliquées avec les bons droits.
---
## 7. Déploiement sur chaque machine
### 7.1 Répertoire cible
Convention courante sur l’infra 4NK : `/srv/4NK/<domaine ou projet>/`. Pour enso, exemples possibles :
- **test** : `/srv/4NK/enso-test/` (ou un répertoire par produit : `docv-test`, `enso-test`).
- **pprod** : `/srv/4NK/enso-pprod/`
- **prod** : `/srv/4NK/enso-prod/`
À aligner avec la convention réelle des autres projets sur les machines.
### 7.15 Chaîne `deploy/scripts_v2` et outillage partagé (`dev_ai` / `ai_dev`)
Le dépôt inclut **`deploy/scripts_v2/deploy.sh`** : synchronisation Git optionnelle en local, puis **SSH** vers la cible (**ProxyJump** via **`deploy/lib/ssh.sh`** dans l'outillage partagé, résolu par **`AI_DEV_ROOT`**, **`DEV_AI_ROOT`**, **`IA_DEV_ROOT`**, ou chemins **`~/code/dev_ai`**, **`~/code/ai_dev`**, repli **`~/code/ia_dev`**) pour `git pull`, builds Rust/npm et **restart** des unités **systemd --user** `enso-*` si installées.
- Documentation opérationnelle : **[deploy/README.md](../deploy/README.md)** ; intégration détaillée : **[AI_DEV_INTEGRATION.md](AI_DEV_INTEGRATION.md)**.
- Fichier **`enso-deploy.env`** : de préférence **`<outil>/.secrets/enso/<env>/enso-deploy.env`** ; repli **`.secrets/<env>/enso-deploy.env`** dans le monorepo (voir **`deploy/enso-deploy.env.example`**). Synchronisation : **`deploy/scripts_v2/sync-secrets-to-ai_dev.sh`**.
- Depuis le monorepo : **`./deploy/deploy.sh <test|pprod|prod> [options]`** (wrapper vers **`deploy/deploy.sh enso`** de l'outil) ou **`~/code/dev_ai/deploy/deploy.sh enso <env> [options]`** selon l'emplacement du clone (voir configuration projet côté tooling, ex. **`deploy.repository_root`** vers le clone **enso**).
### 7.2 Contenu à déployer
Pour chaque machine et chaque environnement :
1. **Backends** : copier les binaires release **docv-back** et **`enso/enso-back/target/release/enso-back`** (avec `.env`, **PORT=3040** selon [PORTS_ENSO.md](PORTS_ENSO.md)).
2. **Fronts** : pour **enso-front**, déployer le build (`.next/` ou `dist/` selon la stack) et exécuter le serveur de prod sur **3032** ; proxy `/api` vers enso-back côté nginx si nécessaire.
3. **Config** : copier le fichier `.env` (ou équivalent) pour chaque processus, avec les variables correspondant à l’environnement (test, pprod, prod).
4. **Migrations** : déjà appliquées (voir section 6).
### 7.3 Démarrage des services
Sans Docker, les processus peuvent être gérés par **systemd** (recommandé) ou par un gestionnaire de processus (supervisor, etc.). Exemple de unit systemd pour un backend :
```ini
[Unit]
Description=docv-back (enso test)
After=network.target postgresql.service
[Service]
Type=simple
User=ncantu
WorkingDirectory=/srv/4NK/enso-test
EnvironmentFile=/srv/4NK/enso-test/docv-back.env
ExecStart=/srv/4NK/enso-test/bin/docv-back
Restart=on-failure
[Install]
WantedBy=multi-user.target
```
Adapter pour enso-back (**3040**) et **enso-front** sur **3032**. Les ports sont fixés dans [PORTS_ENSO.md](PORTS_ENSO.md) et doivent correspondre à la configuration du proxy (voir section 8).
### 7.4 Résumé par machine
| Machine | Rôle | Déploiement |
|---------|------|-------------|
| **test** (192.168.1.101) | Environnement de test | docv-back, enso-back, enso-front ; BDD test ; config test. |
| **pprod** (192.168.1.102) | Préproduction | Idem avec BDD et config pprod. |
| **prod** (192.168.1.103) | Production | Idem avec BDD et config prod. |
### 7.5 Machine LAN **192.168.1.164** (smart_ide) — **enso-back** dans `~/code/enso`
Pour déployer uniquement **enso-back** (Node) sur l’hôte **192.168.1.164**, avec le code sous **`~/code/enso/enso-back`** (créé si absent) :
1. Cloner ou disposer du dépôt **enso** sur la machine **d’où vous lancez le script** (poste de dev ou autre).
2. Depuis la racine du clone (répertoire qui contient **`enso/`**), exécuter :
```bash
bash enso/scripts/deploy-enso-back-remote.sh
```
Variables optionnelles : **`TARGET_HOST`** (défaut `192.168.1.164`), **`DEPLOY_USER`** (défaut `ncantu`), **`REMOTE_PROJECT`** (défaut `enso` → chemin `~/code/enso/enso-back`), **`SSH_OPTS`** (ex. `'-J ncantu@4nk.myftp.biz'` si accès via bastion), **`SKIP_INSTALL=1`** pour ne pas lancer `npm install` sur la cible.
Le script : **SSH** + **rsync** (`--delete`, exclusion de **`node_modules/`** et **`data/`** pour ne pas effacer la persistance distante), **`mkdir -p …/data/uploads`**, **`chmod 750`** sur **`data/`** et **`data/uploads/`**, puis **`npm install --omit=dev`** dans **`enso-back`**.
Démarrage sur la cible (exemple) : `cd ~/code/enso/enso-back && HOST=0.0.0.0 PORT=3040 ./target/release/enso-back` (ou `cargo run --manifest-path enso/enso-back/Cargo.toml`). Chiffrement au repos, sauvegardes dédiées, antivirus sur **`uploads/`**, quotas et réplication ne sont pas couverts par ce script.
---
## 8. Proxy et certificats
La machine **proxy** (192.168.1.100) assure :
- Le reverse proxy HTTP/HTTPS (Nginx ou équivalent) vers les backends et fronts déployés sur test, pprod, prod.
- La terminaison SSL (certificats Let’s Encrypt ou existants).
- **enso :** `test.enso.4nkweb.com` → **192.168.1.101** ; `pprod.enso.4nkweb.com` → **192.168.1.102** ; `prod.enso.4nkweb.com` → **192.168.1.103** (nginx : `/` → **3032**, `/api/` → **3040**, `/docv-api/` → **3038**).
- **docv :** `test.docv.4nkweb.com` → **101** ; `pprod.docv.4nkweb.com` → **102** ; `prod.docv.4nkweb.com` → **103** — API **docv-back** **3038** (**3038** / **3040** enso sont réservés au produit enso) ; **docv-front** prévu sur **3005** (voir [PORTS_ENSO.md](PORTS_ENSO.md)).
- Snippets nginx de référence : `deploy/nginx/*.locations.snippet` (`*.enso.*` et `*.docv.*`). Chaque snippet **docv** rappelle l’inclusion dans un bloc `server { listen 443 ssl; server_name … }` avec chemins `ssl_certificate` / `ssl_certificate_key` (ou équivalent).
### 8.1 Certificats TLS des vhosts **docv**
Exigences :
- **SNI / SAN** : le certificat présenté sur le **443** du proxy pour chaque FQDN doit inclure ce nom en **Subject Alternative Name** (un certificat par vhost ou SAN multi-noms selon politique infra).
- **Chaîne** : confiance publique (ex. **Let’s Encrypt**) ou certificat d’entreprise explicitement approuvé ; **pas** de certificat auto-signé en production (règles projet).
Contrôle depuis un poste ayant accès au **443** public des FQDN (remplacer le nom de domaine) :
```bash
openssl s_client -connect test.docv.4nkweb.com:443 -servername test.docv.4nkweb.com </dev/null 2>&1 \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
```
Répéter pour `pprod.docv.4nkweb.com` et `prod.docv.4nkweb.com`. Points à valider sur la sortie : **`subject` / SAN** = FQDN attendu, **`issuer`** cohérent (ex. Let’s Encrypt), **`notAfter`** dans le futur.
La configuration détaillée du proxy (fichiers nginx complets, renouvellement **certbot**, alignement avec l’infra 4NK) reste à consolider côté exploitation. Référence : documentation infrastructure Cloud 4NK (règles utilisateur).
---
### 8.2 Front **enso** : message Vite « This host is not allowed » derrière le proxy
Symptôme (navigateur) : *Blocked request. This host ("…") is not allowed. To allow this host, add "…" to `preview.allowedHosts` in vite.config.*
**Cause :** l'instance sert le build avec **`vite preview`** (recommandation actuelle du dépôt : **`next build`** puis **`npm run start`** sans Vite). À partir de Vite 5, le serveur de **preview** restreint l'en-tête **`Host`** sauf configuration explicite.
**Correctif si l'hôte utilise encore Vite :** dans `enso/enso-front/vite.config.ts` (ou `.js`), ajouter les FQDN attendus derrière le proxy. Section **`preview`** (mode `vite preview`) **et**, en développement (`vite`), section **`server`**, même tableau **`allowedHosts`** :
```ts
const allowedHosts = [
"test.enso.4nkweb.com",
"pprod.enso.4nkweb.com",
"prod.enso.4nkweb.com",
"test.docv.4nkweb.com",
"pprod.docv.4nkweb.com",
"prod.docv.4nkweb.com",
] as const;
// server: { … allowedHosts, … }
// preview: { … allowedHosts, … }
```
Si un **docv-front** distinct (ex. port **3005**) utilise Vite, lister les mêmes noms (ou équivalent) dans **son** `vite.config`.
Puis redémarrer le service (ex. `systemctl --user restart enso-enso-front`).
**Pérenne :** aligner l'arbre sur le front **Next.js** du dépôt et l'unité **systemd** `deploy/systemd/enso-enso-front.service` (`npm run start` après `next build`).
---
## 9. Checklist d’installation (par environnement)
- [ ] Prérequis installés (Node, Rust, PostgreSQL, Git).
- [ ] Dépôt cloné et sous-modules initialisés.
- [ ] Variables d’environnement définies (`.env` ou `.secrets/<env>/`).
- [ ] BDD créées et migrations appliquées.
- [ ] Build des fronts et des backends effectué.
- [ ] Fichiers déployés sur la machine cible (binaires, build Next.js, config).
- [ ] Services configurés (systemd ou équivalent) et démarrés.
- [ ] Proxy : vhosts HTTPS et certificats (contrôle §8.1 pour **docv** ; idem **enso** selon mêmes principes).
---
## 10. Références
- [README.md](README.md) — index de la documentation.
- [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md) — découpage des projets et infra.
- [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) — stack, config back (DATABASE_URL, JWT_SECRET, etc.).
- [PLAN_DEVELOPPEMENT.md](PLAN_DEVELOPPEMENT.md) — jalons et scripts deploy.
- [PORTS_ENSO.md](PORTS_ENSO.md) — cartographie des ports (déjà utilisés, ports attribués enso, identiques en dev/test/pprod/prod).
- Infrastructure Cloud 4NK — adresses des machines (proxy, test, pprod, prod), accès SSH, conventions de déploiement.

155
services/docv/enso-docs/PLAN_DEVELOPPEMENT.md Normal file
View File

@ -0,0 +1,155 @@
# Plan de développement — docv / enso
Plan de développement actionnable du monorepo enso. Il détaille les phases, les jalons et l’ordre des travaux en s’appuyant sur le [plan de réalisation](PLAN_REALISATION_DOCV_ENSO.md), l’[implémentation docv](docv/IMPLEMENTATION.md) et l’[ordre d’intégration enso](enso/ORDRE_INTEGRATION_ZONE_17.md).
---
## 1. Vue d’ensemble des phases
| Phase | Objectif | Dépendance | Livrable clé |
|-------|----------|------------|---------------|
| **0** | Cadrage et règles | Aucune | Monorepo structuré, règles Cursor/lint, sous-module ai, docs à jour. |
| **1** | docv (socle commun) | Phase 0 | Back docv (Rust), front docv (Next.js), BDD + seeds, login par défaut, zones 1–15. |
| **2** | enso (avocats) | Phase 1 suffisamment avancée | Back enso, front enso, BDD enso, zone 17 (ia_local) selon ordre d’intégration. |
| **3** | — | — | Hors périmètre actuel du dépôt (voir [HORS_PERIMETRE_NOTAIRE.md](HORS_PERIMETRE_NOTAIRE.md)). |
| **4** | Convergence et qualité | Phases 1–2 | Lint/conformité, scripts deploy/, clôture évolutions, documentation à jour. |
Les phases 1 et 2 se succèdent ; la phase 4 clôt une fois docv et enso stabilisés pour le périmètre visé.
---
## 2. Phase 0 — Cadrage et règles
**Référence :** [PLAN_REALISATION_DOCV_ENSO.md](PLAN_REALISATION_DOCV_ENSO.md) (Phase 0).
### 2.1 Jalons
| Jalon | Contenu | Critère de complétion |
|-------|---------|------------------------|
| 0.1 | Structure du monorepo | Dossiers `docv/`, `enso/`, `deploy/`, `.secrets/`, `docs/` ; `package.json` racine (workspaces) ; `.gitignore` (secrets, node_modules, target, .env). |
| 0.2 | Sous-module API IA | `.gitmodules` avec `ai` → https://git.4nkweb.com/4nk/ai.git ; dépôt `ai` cloné (ou prêt dès premier commit distant). |
| 0.3 | Règles Cursor | Fichiers dans `.cursor/rules/` : qualité, lint, clôture évolution, correction d’erreurs (référence section 10 du plan de réalisation). |
| 0.4 | Règles de lint | Config ESLint (front) et Clippy / rustfmt (back) ; max-lines, max-lines-per-function, max-params, complexity alignés sur les règles Cursor. |
| 0.5 | Documentation cadrage | Architecture, plan de réalisation, plan de développement (ce document) à jour et accessibles depuis [docs/README.md](README.md). |
### 2.2 Livrable Phase 0
- Repo structuré, règles Cursor et lint définies et applicables, pas de code métier obligatoire au-delà des squelettes existants.
---
## 3. Phase 1 — docv (socle commun)
**Référence :** [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md), [docv/README.md](docv/README.md), [PLAN_REALISATION](PLAN_REALISATION_DOCV_ENSO.md) (Phase 1).
### 3.1 Ordre d’implémentation par zone
Les zones sont implémentées dans l’ordre des dépendances. Détail : [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) section 1.
| Ordre | Zone | IMPL | Livrable zone |
|-------|------|------|----------------|
| 1 | 1 — Auth et compte | IMPL_01 | Login par défaut (identifiant/mot de passe, session ou JWT, choix d’office) pour tous les types de membres. |
| 2 | 5 — Offices et membres | IMPL_05 | CRUD offices, collaborateurs, utilisateurs, RIB ; contexte office actif. |
| 3 | 6 — Rôles et permissions | IMPL_06 | Matrice rôle × ressource × action ; screen_config / action_config (paramétrage). |
| 4 | 4 — Types de dossiers | IMPL_04 | Référentiel types de dossiers par office. |
| 5 | 3 — Documents et types | IMPL_03 | Types de documents, upload/download. |
| 6 | 2 — Dossiers | IMPL_02 | CRUD dossiers, liste, archivés, supprimés. |
| 7 | 7 — Parties et partage | IMPL_07 | Parties au dossier, partage, invitations. |
| 8 | 8 — Notes et rappels | IMPL_08 | Notes et rappels liés dossiers/documents. |
| 9 | 14 — Contenus et paramètres | IMPL_14 | Textes légaux, config publique. |
| 10 | 13 — Admin plateforme | IMPL_13 | Super-admin : rôles plateforme, plans, textes, system_configuration. |
| 11 | 9 — Abonnement et facturation | IMPL_09 | Abonnement par office, plans, prestataire paiement (back). |
| 12 | 10, 11 — Espace client / invité | IMPL_10 | Portail client, accès invité. |
| 13 | 12 — Admin d’office | IMPL_12 | Portail admin office, métriques. |
| 14 | 15 — Technique et design | IMPL_15 | Vérification ancrage, design system, paramétrage écrans/actions. |
### 3.2 Sous-phases Phase 1
| Sous-phase | Contenu | Livrable |
|------------|---------|----------|
| **1.1 Backend docv** | Stack Rust (Axum/Actix), PostgreSQL (SQLx/Diesel), migrations BDD (ordre §3.1), handlers/services/repositories pour chaque zone, clients anchoring + IA (back uniquement), erreurs typées, logging. | Service docv-back démarre, expose les endpoints zones 1–15, lit/écrit BDD, consomme ancrage et IA côté back. |
| **1.2 Frontend docv** | Stack Next.js (ou équivalent), client API unique vers docv-back, pages et composants pour chaque écran (référentiel zones 1–15), design system (tokens, thème), i18n (structure + défauts fr/en), chargement screen_config/action_config. | Front docv utilisable en autonomie sur BDD et back docv. |
| **1.3 Données et paramétrage** | Seeds : rôles, permissions, types documents/dossiers, textes site, system_configuration ; seeds screen_config/action_config (identifiants stables). | Instance docv déployée avec structures et données par défaut réutilisables par enso. |
### 3.3 Critères de passage à la Phase 2
- Back docv opérationnel (auth, offices, rôles, dossiers, documents, partage, admin, paramétrage).
- Front docv opérationnel (écrans zones 1–15, design system, i18n).
- Migrations et seeds appliqués ; login par défaut fonctionnel pour tous les types de membres.
- API ancrage et API IA (sous-module ai) consommables par le back (contrats stables ou stubs documentés).
---
## 4. Phase 2 — enso (avocats)
**Référence :** [enso/README.md](enso/README.md), [enso/ORDRE_INTEGRATION_ZONE_17.md](enso/ORDRE_INTEGRATION_ZONE_17.md), [SPECIFIQUES_PROJETS.md](features/SPECIFIQUES_PROJETS.md) (E1–E31).
### 4.1 Jalons
| Jalon | Contenu | Critère de complétion |
|-------|---------|------------------------|
| 2.1 | Héritage docv dans enso | BDD enso (schéma docv + migrations), enso-back et enso-front structure alignée docv ; config (seeds, thème, i18n) spécifique avocat. |
| 2.2 | Zones 1–15 opérationnelles dans enso | Même fonctionnalités que docv (auth par défaut, offices, rôles, dossiers, documents, partage, etc.) avec paramétrage enso. |
| 2.3 | Zone 17 — Config et navigation | Établissements (18.68), admin-types (18.69), Explorer (18.81), recherche (18.82), dashboard minimal (18.53). |
| 2.4 | Zone 17 — CRM, tâches, débours | CRM (18.54), tâches (18.64), planning (18.75), débours (18.65), facturation débours (18.70). |
| 2.5 | Zone 17 — Partage, dataroom, alertes, workflow | Renvoi (18.58), data room (18.61), extraction dataroom (18.59), alertes (18.60), workflow (18.63). |
| 2.6 | Zone 17 — Communication et actes | Messages (18.66), notifications (18.67), courriers IFU (18.62), mails semi-auto (18.72) ; actes et juridique (18.55–18.58, 18.71–18.74, 18.77–18.78). |
| 2.7 | Zone 17 — IA et compte | Outlook (18.79), organigramme (18.76), Chat IA (18.80), appareils (18.83). |
Ordre détaillé des sous-blocs zone 17 : [enso/ORDRE_INTEGRATION_ZONE_17.md](enso/ORDRE_INTEGRATION_ZONE_17.md). Spécifiques E1–E31 à confirmer avant implémentation ([SPECIFIQUES_PROJETS.md](features/SPECIFIQUES_PROJETS.md)).
### 4.2 Livrable Phase 2
- Application enso déployable avec BDD enso, back enso (consommation ancrage + IA côté back uniquement), front enso (design et textes avocat), zones 1–15 + zone 17 selon ordre d’intégration.
---
## 5. Phase 3 — hors périmètre actuel
La phase « troisième produit » n’est pas suivie dans ce dépôt pour l’instant. Référence : [HORS_PERIMETRE_NOTAIRE.md](HORS_PERIMETRE_NOTAIRE.md).
---
## 6. Phase 4 — Convergence et qualité
**Référence :** [PLAN_REALISATION](PLAN_REALISATION_DOCV_ENSO.md) (Phase 4), section 5 (règles Cursor et lint).
### 6.1 Jalons
| Jalon | Contenu | Critère de complétion |
|-------|---------|------------------------|
| 4.1 | Documentation à jour | Architecture, plan de réalisation, plan de développement, docs docv/enso et implémentation reflètent l’état réel (stack, schémas BDD, endpoints). |
| 4.2 | Conformité Cursor et lint | Règles appliquées sur tout le code (docv, enso) ; pas de contournement ; Clippy / ESLint / type-check OK. |
| 4.3 | Scripts de déploiement | Scripts dans `deploy/` pour build et déploiement de docv et enso (BDD respectives). |
| 4.4 | Clôture des évolutions | Pour chaque livrable, workflow de clôture appliqué (helpers, i18n, fallback, modifications similaires, optimisation, sécurité, code mort, lint, types, compilation, documentation). |
### 6.2 Livrable Phase 4
- Documentation à jour ; conformité Cursor/lint ; scripts deploy/ opérationnels ; clôture des évolutions effectuée.
---
## 7. Dépendances et ordre de lecture
```
Phase 0 (Cadrage)
│
▼
Phase 1 (docv) ──► 1.1 Backend → 1.2 Frontend → 1.3 Données (zones 1–15 dans l’ordre §3.1)
│
▼
Phase 2 (enso) — zones 1–15 puis 17
│
▼
Phase 4 (Convergence)
```
### 7.1 Références croisées
| Document | Usage |
|----------|--------|
| [PLAN_REALISATION_DOCV_ENSO.md](PLAN_REALISATION_DOCV_ENSO.md) | Phases et livrables globaux, règles Cursor, références. |
| [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) | Ordre des zones docv, stack, schéma BDD, surface API, checklist Phase 1. |
| [enso/ORDRE_INTEGRATION_ZONE_17.md](enso/ORDRE_INTEGRATION_ZONE_17.md) | Phases d’intégration zone 17 (enso). |
| [features/SPECIFIQUES_PROJETS.md](features/SPECIFIQUES_PROJETS.md) | Liste et statut de confirmation des spécifiques enso (E1–E31). |
| [features/implementation/README.md](features/implementation/README.md) | IMPL_xx par zone (détail technique). |

165
services/docv/enso-docs/PLAN_REALISATION_DOCV_ENSO.md Normal file
View File

@ -0,0 +1,165 @@
# Plan de réalisation — docv / enso
Ce document décrit le plan de réalisation du monorepo enso pour **docv** (socle commun, backend Rust, front moderne, PostgreSQL dédiée) et **enso** (avocats). docv est hérité par enso pour les structures et données par défaut. Le projet reprend les règles de lint et les règles Cursor du projet (voir section 10).
---
## 1. Modèle d’héritage (récap)
| Dimension | docv | enso |
|-----------|------|------|
| **Base de données** | Sa BDD ; porte la **structure** et les **données par défaut** pour tous | Sa BDD (hérite structure/défauts docv) |
| **Textes (i18n)** | Ses textes ; porte la **structure des textes** et **textes par défaut** pour tous | Ses textes (hérite structure/défauts docv) |
| **Design / front** | Son design ; porte la **structure des fronts** et le **design par défaut** pour tous | Son design (hérite structure/défauts docv) |
| **Rôles** | Son paramétrage ; porte la **structure des rôles** et **rôles par défaut** pour tous | Son paramétrage rôles (hérite docv) |
| **Documents** | Son paramétrage ; porte la **structure des documents** et **paramétrage par défaut** pour tous | Son paramétrage documents (hérite docv) |
| **Dossiers** | Son paramétrage ; porte la **structure des dossiers** et **paramétrage par défaut** pour tous | Son paramétrage dossiers (hérite docv) |
| **Membres des rôles** | Son paramétrage ; porte la **structure des membres** et **membres par défaut** pour tous | Son paramétrage membres (hérite docv) |
| **API tiers** | Consomme **API IA** et **API d’ancrage** (serveur services, projet Bitcoin api-anchorage) | Consomme API IA + ancrage **côté back uniquement** |
- **docv** : socle commun avec backend **Rust**, front **moderne/propre**, et **PostgreSQL dédiée**. Pour le **code partagé back/front** (validation, formatage, constantes, règles métier pures), utiliser **WebAssembly (WASM)** si c’est plus pratique : une crate Rust partagée (ex. `docv-shared`) compilée en natif pour les backs et en WASM pour les fronts.
- **enso** : hérite docv (structure + défauts) ; données, textes, design et paramétrages propres au périmètre avocat. **Les API externes** (ancrage, IA) sont **consommées par les backends exclusivement** ; les fronts n’appellent que **enso-back**. L’**API d’ancrage** est celle du serveur **services** (infra 4NK), projet Bitcoin **api-anchorage**. L’**API IA** est développée dans le **sous-module Git** `ai` (https://git.4nkweb.com/4nk/ai.git), en TypeScript ; voir section 2ter du document d’architecture.
---
## 2. Phases et ordre de réalisation
### Phase 0 — Cadrage et règles (préalable à tout code)
- **Environnement de développement** : la machine dispose d’**Ollama**, **Obsidian**, **AnythingLLM**, **Node.js**, **PostgreSQL**, et de **modèles préinstallés** pour Ollama et AnythingLLM. L’API IA consommée par les backends s’appuie sur ce socle et est développée dans le sous-module `ai`.
- **Sous-module Git `ai`** : importer le dépôt https://git.4nkweb.com/4nk/ai.git en sous-module (ex. `git submodule add https://git.4nkweb.com/4nk/ai.git ai` depuis la racine enso, après validation). Ce sous-module sert à développer l’**API IA en TypeScript** et à interagir avec le socle IA (Ollama, AnythingLLM). Les backends **docv** et **enso** consomment cette API ; ils n’appellent pas directement Ollama ou AnythingLLM.
- Définir et versionner les **règles Cursor** du projet (`.cursor/rules/`) : reprise des règles qualité, lint, clôture évolution, correction d’erreurs (cf. section 10).
- Créer la **structure du monorepo** (workspaces, `docs/`, `deploy/`, `.secrets/`) et le **fichier de règles de lint** (ESLint / équivalent Rust) aligné sur les règles Cursor (max-lines, max-lines-per-function, max-params, complexity, etc.).
- Documenter dans `docs/` : architecture (déjà en place), plan de réalisation (ce document), conventions de code et lint (référence aux règles Cursor).
- **Livrable** : repo enso structuré, règles Cursor et lint appliquables, pas encore de code métier.
---
### Phase 1 — docv (socle commun)
Objectif : application docv autonome, parité fonctionnelle avec la cartographie des écrans (`docs/SCREENS_AND_FUNCTIONS_MAP.md`) mais réécrite, avec backend Rust, front moderne, PostgreSQL dédiée, et portage des structures + données par défaut pour tous.
#### 1.1 Backend docv (Rust)
- Choix du stack Rust : framework HTTP (Axum / Actix), connexion PostgreSQL (SQLx ou Diesel), migrations, logging structuré, gestion d’erreurs typées.
- **Code partagé back/front** : si plus pratique, introduire une crate Rust partagée (ex. `docv-shared`) compilable en **natif** (pour docv-back et enso-back) et en **WASM** (pour les frontends via wasm-bindgen / wasm-pack). Y mettre validation, formatage, constantes, règles métier pures ; utiliser WASM dès que cela évite la duplication et garantit la même logique partout.
- Schéma **BDD docv** : reprendre les entités métier attendues (users, contacts, addresses, offices, office_folders, document_types, roles, office_roles, role_permissions_matrix, site_texts, system_configuration, etc.) en une **structure agnostique** (sans champs réservés à un métier notaire dans le noyau).
- Migrations SQL versionnées ; **données de référence par défaut** : rôles, permissions, types de documents, structure des dossiers, textes site, configuration système (clés communes).
- API REST (ou équivalent) : auth (agnostique, sans IdNot), CRUD dossiers, documents, membres, rôles, paramétrage documents/dossiers, textes (i18n), configuration.
- **API IA** et **API d’ancrage** : les backends **consomment** l’API d’ancrage (serveur **services**, projet Bitcoin **api-anchorage**) et l’**API IA** (développée dans le sous-module `ai`, TypeScript, qui s’appuie sur Ollama, AnythingLLM et les modèles préinstallés). Aucune de ces API n’est appelée par les frontends (consommation back exclusivement).
- Logging, validation des entrées, pas de secrets en dur, respect des règles Cursor (pas de fallback, erreurs remontées, pas de contournement).
- **Livrable** : service Rust docv qui démarre, expose les endpoints, lit/écrit la BDD docv, et consomme les API ancrage (services, api-anchorage) et IA depuis le back uniquement.
#### 1.2 Frontend docv (moderne / propre)
- Stack front : choix (ex. Next.js ou autre) aligné avec « moderne et propre » ; pas de reprise à l’identique d’une base front historique externe.
- **Code partagé avec le back** : si une crate Rust partagée est compilée en WASM (ex. `docv-shared`), l’importer dans le front (wasm-pack `pkg/`) pour validation, formatage, constantes ; utiliser WASM lorsque c’est plus pratique que de dupliquer la logique en TypeScript.
- Structure des écrans et fonctionnalités : couvrir **toutes les fonctionnalités** décrites dans la cartographie (dossiers, documents, rôles, membres, paramétrage, textes, etc.) mais réécrites (composants, hooks, appels API).
- **Design system docv** : structure des thèmes, composants de base, tokens (couleurs, typo, espacements) ; design par défaut utilisable comme base par enso.
- Consommation de l’API docv ; gestion d’état, erreurs, chargements ; textes via structure i18n (clés + défauts docv).
- Respect des règles Cursor : helpers centralisés, pas de code mort, max-lines / max-lines-per-function, typecheck, lint.
- **Livrable** : front docv utilisable en autonome sur la BDD et le back docv.
#### 1.3 Données et paramétrage par défaut (docv)
- **BDD** : seeds / migrations pour rôles par défaut, matrice de permissions par défaut, types de documents par défaut, structure dossiers par défaut, membres/rôles par défaut.
- **Textes** : structure des clés (scope, locale, version) + jeu de textes par défaut (fr, en).
- **Configuration** : clés `system_configuration` (ou équivalent) par défaut pour toute l’app.
- **Livrable** : une instance docv déployée contient toutes les structures et données par défaut réutilisables pour enso.
---
### Phase 2 — enso (avocats)
- Création des répertoires **enso-front** et **enso-back** (mêmes langages et frameworks que docv : Rust pour le back, même stack front que docv-front).
- **Code** : héritage de docv ; pas de duplication. **Configuration** : BDD enso, seeds, paramétrage (écrans, actions, options, rôles, types de documents/dossiers, textes, thème). **Spécifiques** : tout spécifique enso (écrans, actions, services, intégrations) doit être **listé et confirmé** avant implémentation ; voir `docs/features/SPECIFIQUES_PROJETS.md`.
- **BDD enso** : schéma dérivé de la structure docv (migrations SQL, même modèle logique) ; données spécifiques avocat (pas de données notaire).
- **Backend enso** (Rust) : même stack que docv-back ; **consomme** les API externes (ancrage : serveur services, api-anchorage ; IA) côté back uniquement ; logique métier avocat (dossiers, mandats, etc.) dans `services/lawyer/` ; pas d’IdNot, pas de Mailchimp/OVH/Stripe/API notaire.
- **Front enso** : même stack que docv-front ; héritage du design system docv (structure + défauts) ; surcharges thème/couleurs/texte pour « enso » ; textes et paramétrages spécifiques avocat.
- **Textes, rôles, documents, dossiers, membres** : structure identique à docv ; données et paramétrages spécifiques enso (avec possibilité d’importer les défauts docv en amont).
- **Livrable** : application enso déployable avec sa BDD, ses textes, son design, ses paramétrages ; les API (ancrage, IA) sont consommées par enso-back uniquement.
---
### Phase 3 — hors périmètre actuel du dépôt
Produit métier notaire : non suivi dans ce clone pour l’instant. Orientation : [`docs/HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md).
---
### Phase 4 — Convergence et qualité
- **Documentation** : mettre à jour `docs/ARCHITECTURE_DOCV_ENSO.md` et `docs/PLAN_REALISATION_DOCV_ENSO.md` avec l’état réel (Rust, stack front, schémas BDD).
- **Règles Cursor et lint** : vérifier que tout le code **docv** et **enso** respecte les règles ; corriger les écarts ; pas de contournement de lint.
- **Déploiement** : scripts dans `deploy/` pour build et déploiement de docv et enso (avec leurs BDD respectives).
- **Clôture** : pour chaque livrable, appliquer le workflow de clôture (helpers, i18n, fallback, modifications similaires, optimisation, sécurité, code mort, lint, types, compilation, documentation).
---
## 3. Dépendances entre phases
```text
Phase 0 (Cadrage) ──────────────────────────────────────────────────────────┐
│ │
▼ │
Phase 1 (docv) ───► Backend Rust + BDD + consommation API ancrage (services, api-anchorage) + API IA │
│ Front moderne + design system + structure textes/rôles/… │
│ │
├────────────────────────────────────────────────────────────────────┤
▼ │
Phase 2 (enso) ───► BDD enso, back enso, front enso (héritent docv) │
│ │
▼ │
Phase 4 (Convergence) ──► Doc, lint, déploiement, clôture │
```
- Phase 1 doit être suffisamment avancée (structure BDD + API + design system) pour qu’**enso** puisse « hériter » (structure + défauts).
- Les backends **docv** et **enso** consomment l’API d’ancrage (serveur services, projet api-anchorage) et l’API IA (sous-module `ai`, TypeScript, socle Ollama/AnythingLLM) ; ces API doivent être accessibles et contrats stables avant intégration.
---
## 4. Récapitulatif des livrables par phase
| Phase | Livrables principaux |
|-------|----------------------|
| **0** | Monorepo structuré ; règles Cursor et lint définies et appliquées ; docs d’architecture et plan à jour. |
| **1** | Backend docv (Rust), crate docv-shared (natif + WASM si pertinent), BDD docv (structure + données par défaut), consommation API ancrage (services, api-anchorage) + API IA (sous-module ai, TypeScript, socle Ollama/AnythingLLM ; back uniquement) ; front docv (écrans complets, design system, textes/rôles/documents/dossiers/membres par défaut ; pas d’appel direct aux API externes). |
| **2** | BDD enso ; backend enso (Rust, consomme API ancrage + IA côté back uniquement) ; front enso (même stack que docv-front, hérite design/textes/paramétrages docv, surcharges avocat). |
| **3** | — hors périmètre actuel du dépôt — voir [`HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md). |
| **4** | Documentation à jour ; conformité Cursor/lint ; scripts de déploiement ; clôture des évolutions. |
---
## 5. Règles Cursor et lint à respecter
Le projet doit reprendre les **règles de lint** et les **règles Cursor** du projet. À intégrer dans `.cursor/rules/` et dans la config lint (ESLint pour le front/TypeScript, Clippy / format pour Rust) :
- **Général** : répondre en français ; code, documentation et commits en anglais ; ne pas écrire en base (scripts dédiés) ; ne pas masquer les sorties ; pas de certificats auto-signés ; pas de modification des variables d’environnement ; pas d’alternative HTTP à HTTPS ; validation avant déploiement/certificats ; pas d’exécution en arrière-plan.
- **Processus** : priorité aux questions posées ; validation avant implémentation ; identifier et corriger la root cause avant de corriger les bugs ; pas de contournement.
- **Qualité** : clôture systématique (helpers, i18n, fallback, modifications similaires, optimisation, sécurité, code mort, lint, types, compilation, documentation) ; vérification des fichiers (logs, code mort, commentaires) ; pas de bypass lint par commentaires.
- **Code** : factorisation et réutilisation ; pas de code mort ; max 250 lignes/fichier, 40 lignes/fonction ; max-params 4, max-depth 4, complexity 10, max-nested-callbacks 3 ; pas de lazy imports ; imports par défaut nommés ; types de retour explicites ; pas de `any` ; gestion d’erreurs explicite, pas de fallback implicite.
- **Sécurité** : validation des entrées ; pas de secrets en dur ; pas de log de données sensibles ; soft-delete pris en compte.
- **Documentation** : mise à jour de `docs/` (features, fixKnowledge, architecture) ; rationalisation ; pas de doublons.
- **Commits** : format avec **Motivations**, **Root causes**, **Correctifs**, **Evolutions**, **Pages affectées** ; auteur 4NK ou Nicolas Cantu uniquement (pas de Co-authored-by Cursor).
Pour le **backend Rust** : définir des règles équivalentes (format, Clippy, pas de `unwrap` en production, erreurs typées, logging structuré) et les documenter dans `docs/`.
**Règles de coding spécifiques au projet** (placement du code, API, auth, paramétrage, conventions, interdictions) : `docs/REGLES_CODING_PROJET.md`.
---
## 6. Références
- **Plan de développement** (jalons et ordre des travaux) : `docs/PLAN_DEVELOPPEMENT.md`
- Architecture, **structure détaillée de chaque sous-projet** et **API externes / socle IA** : `docs/ARCHITECTURE_DOCV_ENSO.md` (sections 2bis, 2ter, 3 et 3.1 à 3.4)
- **Point d’entrée documentation docv** : `docs/docv/README.md` (périmètre docv, zones 1–15, ordre de réalisation Phase 1)
- **Point d’entrée documentation enso** : `docs/enso/README.md` (périmètre enso, zones 1–15 + 17, correspondance spécifiques E1–E31, liens specs/IMPL/référentiel)
- **Périmètre notaire (hors dépôt actuel)** : `docs/HORS_PERIMETRE_NOTAIRE.md`
- **Cartographie écrans et fonctions** : `docs/SCREENS_AND_FUNCTIONS_MAP.md` (wording générique, référence pour docv et enso)
- **Spécifications par fonctionnalité** : `docs/features/specs/README.md` (référentiel des specs par zone : objectif, écrans, actions, règles métier, API, déploiement, analyse)
- **Référentiel écrans et actions** : `docs/features/REFERENTIEL_ECRANS_ACTIONS.md` (identifiants stables, routes, actions 18.x)
- **Description technique d’implémentation** : `docs/features/implementation/README.md` (IMPL_xx par zone : routes, front, back, BDD)
- Règles Cursor : à créer dans `.cursor/rules/` en reprenant les modèles qualité / lint / clôture / correction d’erreurs déjà utilisés sur les dépôts 4NK.
- Référence fonctionnelle : cartographie et specs dans `docs/` (sans dépendre d’un dépôt applicatif externe dans ce clone).
- Sous-module API IA : https://git.4nkweb.com/4nk/ai.git (TypeScript, interaction avec Ollama, AnythingLLM)
- Grands principes IA (dossier ↔ workspace AnythingLLM, librairies, workflow cloud optionnel, Cursor instrumenté) : `docs/features/IA_GRANDS_PRINCIPES.md`

197
services/docv/enso-docs/PORTS_ENSO.md Normal file
View File

@ -0,0 +1,197 @@
# Cartographie des ports — enso (docv / enso)
Ce document fixe les **ports utilisés** par le projet enso sur les machines **test**, **pprod**, **prod** et sur le **poste de développement**. Les ports listés comme déjà utilisés ci‑dessous ont été vérifiés par connexion aux machines (`ss -tlnp`).
**Proxy nginx (192.168.1.100)** : pour les **seuls** vhosts `*.enso.4nkweb.com` et `*.docv.4nkweb.com`, les upstreams vers **101 / 102 / 103** sont **3032** (enso-front), **3038** (docv-back), **3040** (enso-back). Les fichiers `deploy/nginx/*.enso.*.locations.snippet` et `deploy/nginx/*.docv.*.locations.snippet` reprennent ce câblage. **Ne pas modifier** les autres vhosts du proxy (autres produits / domaines).
**Domaines DNS (enso) :** `test.enso.4nkweb.com`, `pprod.enso.4nkweb.com`, `prod.enso.4nkweb.com`.
**Domaines DNS (docv) :** `test.docv.4nkweb.com`, `pprod.docv.4nkweb.com`, `prod.docv.4nkweb.com` (TLS et DNS configurés). Même plan d’adressage machine que les domaines **enso** correspondants (101 / 102 / 103).
**Règles de ports pour le produit docv (vhosts `*.docv.*`) :**
- Ne pas binder de service docv sur les ports déjà utilisés sur les machines cibles (**§1** : 22, 25, 631, 3009, 3100, 3101, 80, 443, 3000, 3004, 3310, 9050, 9051, 18443, 29000, 38333, 38334, 5432, etc. — revérifier après chaque audit `ss`).
- Ne pas réutiliser les ports **réservés** du déploiement **docv / enso** pour d’autres rôles : **3032** (enso-front), **3038** (docv-back), **3040** (enso-back), **3005** (docv-front prévu), **3022** (API IA dédiée).
- **docv-back** (API socle) : **3038** (distinct de **3032** / **3040**).
- **docv-front** (prévu) : **3005** — ne pas utiliser **3032** (réservé enso-front).
**Référence :** [INSTALLATION_ENVIRONNEMENT.md](INSTALLATION_ENVIRONNEMENT.md).
---
## 1. Ports déjà utilisés sur les machines test / pprod / prod (vérifiés)
Connexion SSH aux trois machines et exécution de `ss -tlnp`. Ports en écoute (hors localhost sauf si exposé) :
### test (192.168.1.101)
| Port | Processus / usage |
|------|-------------------|
| 22 | sshd |
| 25 | (mail) |
| 631 | cups |
| 3009 | node (LeCoffreIO ou équivalent) |
| 3100 | next-server |
| 3101 | node |
| 5432 | PostgreSQL (localhost) |
### pprod (192.168.1.102)
| Port | Processus / usage |
|------|-------------------|
| 22 | sshd |
| 25 | (mail) |
| 631 | cups |
| 3009 | node |
| 3100 | next-server |
| 3101 | node |
| 5432 | PostgreSQL (localhost) |
### prod (192.168.1.103)
| Port | Processus / usage |
|------|-------------------|
| 22 | sshd |
| 25 | (mail) |
| 631 | cups |
| 80 | HTTP |
| 443 | HTTPS |
| 3000 | node |
| **3004** | **MainThread (déjà utilisé)** |
| 3009 | node |
| 3100 | next-server |
| 3101 | node |
| 3310 | (autre service) |
| 5432 | PostgreSQL (localhost) |
| 9050, 9051 | (Tor) |
| 18443, 29000, 38333, 38334 | bitcoind |
**Conclusion :** les ports **3032**, **3038**, **3040** (stack **enso** + **docv-back** derrière le proxy), **3005** (docv-front), **3022** sont **retenus pour le périmètre actuel du monorepo** et doivent rester **libres** sur les machines applicatives **par rapport à la liste §1 au moment du dernier audit** — revérifier avec `ss` avant toute mise en service. Le port **3004** est occupé sur prod (service existant). Le port **3000** est occupé sur prod ; l’API IA (`ai`) utilise **3022** lorsqu’elle tourne sur une machine dédiée (ex. poste de dev, 192.168.1.173).
---
## 2. Briques logicielles ouvrant des ports
Toutes les briques du projet enso qui ouvrent un port TCP :
| Brique | Type | Consommée par |
|--------|------|----------------|
| docv-back | Backend Rust | Proxy, fronts (via API) |
| enso-back | Backend Rust | Proxy, enso-front |
| enso-front | Front Next.js | Proxy, navigateur |
| docv-front | Front Next.js (vhost ***.docv.***) | Proxy, navigateur ; port **3005**, distinct d’enso-front (**3032**) |
| **API IA** (sous-module `ai`) | API TypeScript (Ollama, AnythingLLM) | docv-back, enso-back (variable `IA_API_URL`) |
L’API IA est une brique à part. **Pour l’instant les services IA ne tournent que sur le poste de développement et sur la machine 192.168.1.173** (ce poste / machine ia). Sur test, pprod et prod, l’API IA n’est pas déployée : les backends de ces environnements pointent `IA_API_URL` vers 192.168.1.173:3022. Lorsqu’elle tourne (dev ou 173), elle écoute sur le port 3022.
### 2bis. Logiciels IA du socle (en plus de l’API IA)
L’**API IA** (sous-module `ai`, port 3022) s’appuie sur le **socle IA** : Ollama et AnythingLLM. Ces logiciels ouvrent eux‑mêmes des ports. Ils sont installés sur le **poste de développement** et sur **192.168.1.173** (pas sur test/pprod/prod pour l’instant). Les backends n’appellent pas directement ces logiciels, uniquement l’API IA.
| Logiciel | Port par défaut | Variable / config | Consommée par |
|----------|-----------------|-------------------|---------------|
| **Ollama** | 11434 | `OLLAMA_HOST` (ex. `0.0.0.0:11434`) | API IA (sous-module `ai`) |
| **AnythingLLM** | 3001 | `SERVER_PORT` (dans `.env` AnythingLLM) | API IA (sous-module `ai`) |
| **API IA** (`ai/`) | 3022 | `PORT` ou config du serveur API IA | docv-back, enso-back (`IA_API_URL`) |
**Note :** Si le port 3001 est déjà utilisé sur la machine (poste de dev ou 173), configurer AnythingLLM sur un autre port (ex. 3019 ou 3021) via `SERVER_PORT`. L’API IA (`ai`) doit être configurée pour pointer vers les URLs réelles d’Ollama et d’AnythingLLM (ex. `http://localhost:11434` pour Ollama, `http://localhost:3001` ou le port choisi pour AnythingLLM).
## 3. APIs, BDD et services par environnement
Sur **chaque** environnement (développement, test, pprod, prod) on a des **APIs** (backends), une **BDD** (PostgreSQL) et des **services** (fronts). Chaque type utilise des ports distincts ; il y a donc **plusieurs ports par environnement**, pas un seul.
| Type | Port(s) | Rôle |
|------|---------|------|
| **APIs** (backends) | **3038**, **3040** | docv-back, enso-back |
| **BDD** | 5432 (localhost) | PostgreSQL (docv, enso par BDD ou schémas) |
| **Services** (fronts) | **3032**, **3005** | enso-front ; **docv-front** (vhost docv uniquement) |
| **API IA** (sous-module `ai`) | 3022 | Uniquement sur **poste de dev** et **192.168.1.173** pour l’instant ; test/pprod/prod appellent 192.168.1.173:3022 |
| **Ollama** (socle IA) | 11434 | Sur poste de dev et 173 ; consommée par l’API IA |
| **AnythingLLM** (socle IA) | 3001 (ou autre si `SERVER_PORT` défini) | Sur poste de dev et 173 ; consommée par l’API IA |
Sur test, pprod et prod : mêmes ports pour APIs et fronts (**3038**, **3040**, **3032**, **3005** lorsque docv-front est déployé) ; BDD locale (5432). L’API IA et le socle IA (Ollama, AnythingLLM) n’écoutent pas sur ces machines.
## 4. Ports nécessaires pour enso
Le monorepo enso expose **quatre** briques applicatives principales côté produit (deux backends, deux fronts) plus l'**API IA** à part :
| Service | Rôle |
|-----------------|-------------------------------|
| docv-back | Backend API socle commun |
| enso-back | Backend API enso (avocats) |
| enso-front | Front Next.js enso |
| docv-front | Front docv (vhost ***.docv.***) — port **3005** |
| **API IA** (`ai/`) | API IA TypeScript (Ollama, AnythingLLM) ; consommée par les backends |
Chaque processus écoute sur un port dédié. Les mêmes numéros pour APIs et fronts en **développement**, **test**, **pprod** et **prod** (sauf **API IA** : uniquement dev + 173). L’API IA (3022) n’écoute que sur le **poste de développement** et sur **192.168.1.173** pour l’instant.
---
## 5. Attribution des ports (libres, identiques partout)
Ports **retenus** sur test, pprod, prod et en développement local (alignés **proxy nginx** + applications) :
| Port | Service | Fichier / variable concerné |
|------|------------------|-----------------------------|
| **3032** | enso-front | `enso/enso-front/package.json` (dev, start) |
| **3005** | docv-front (vhost ***.docv.***) | `docv/docv-front/package.json` lorsque le front existe |
| **3038** | docv-back | `docv/docv-back/.env` → `PORT=3038` |
| **3040** | enso-back | `enso/enso-back/.env` → `PORT=3040` |
| **3022** | API IA (`ai/`) | Config du serveur API IA ; `IA_API_URL` dans les backends. **Pour l’instant : API IA uniquement sur le poste de dev et sur 192.168.1.173.** Sur test/pprod/prod, `IA_API_URL` = `http://192.168.1.173:3022`. |
Règle : **les mêmes numéros** en local, test, pprod et prod. L’API IA (3022) ne tourne que sur le poste de dev et la machine 173 ; les autres environnements l’appellent à distance.
---
## 6. Résumé par environnement
Sur chaque environnement : **APIs** (backends), **BDD** (PostgreSQL), **services** (fronts). Plusieurs ports par machine.
| Environnement | Machine / poste | APIs (**3038**, **3040**) | BDD (5432) | Fronts (**3032**, docv **3005**) | API IA (3022) |
|---------------|----------------------|--------------------------|------------|---------------------|---------------|
| Développement | Poste local | oui | oui | oui | **oui** (locale) |
| test | 192.168.1.101 | oui | oui | oui | non → appelle 192.168.1.173:3022 |
| pprod | 192.168.1.102 | oui | oui | oui | non → appelle 192.168.1.173:3022 |
| prod | 192.168.1.103 | oui | oui | oui | non → appelle 192.168.1.173:3022 |
| Services IA | 192.168.1.173 (ce poste) | — | — | — | **oui** (3022) ; consommée par test/pprod/prod et par le poste de dev |
Détail des ports par machine :
| Machine / poste | docv-back | docv-front | enso-back | enso-front | API IA |
|-----------------|-----------|------------|-----------|------------|--------|
| Poste de dev | 3038 | 3005 | 3040 | 3032 | 3022 |
| test 192.168.1.101 | 3038 | 3005 | 3040 | 3032 | — |
| pprod 192.168.1.102 | 3038 | 3005 | 3040 | 3032 | — |
| prod 192.168.1.103 | 3038 | 3005 | 3040 | 3032 | — |
| 192.168.1.173 | — | — | — | — | 3022 |
Sur le **poste de dev** et **192.168.1.173**, en plus des ports ci‑dessus (pour le poste de dev : **3038**, **3005**, **3040**, **3032**, **3022** ; pour 173 : 3022 uniquement), les **logiciels du socle IA** écoutent : **Ollama** sur **11434**, **AnythingLLM** sur **3001** (ou le port défini par `SERVER_PORT`). L’API IA (3022) appelle Ollama et AnythingLLM en local sur ces machines.
Routage côté **proxy 192.168.1.100** :
**enso :** `test.enso.4nkweb.com` → 192.168.1.101 ; `pprod.enso.4nkweb.com` → 192.168.1.102 ; `prod.enso.4nkweb.com` → 192.168.1.103 — préfixes **location** : `/` → **3032**, `/api/` → **3040**, `/docv-api/` → **3038**.
**docv :** `test|pprod|prod.docv.4nkweb.com` → même IP ; **3038** (API) ; **3005** lorsque **docv-front** sera déployé. Fichiers : `deploy/nginx/*.docv.*.locations.snippet`, `deploy/nginx/*.enso.*.locations.snippet`. Les backends test/pprod/prod utilisent `IA_API_URL=http://192.168.1.173:3022` pour l’API IA.
---
## 7. Vérification des ports sur une machine
Avant déploiement ou au diagnostic, lister les ports en écoute :
```bash
ss -tlnp | grep -E '3032|3038|3040|3005|3022'
# ou
sudo lsof -i -P -n | grep LISTEN | grep -E '3032|3038|3040|3005|3022'
```
S’assurer qu’aucun autre service n’utilise déjà ces ports sur la machine cible. Sur le **poste de dev** et **192.168.1.173**, inclure aussi les ports du socle IA :
```bash
ss -tlnp | grep -E '3032|3038|3040|3003|3005|3010|3022|11434|3001'
```
---
## 8. Références
- [INSTALLATION_ENVIRONNEMENT.md](INSTALLATION_ENVIRONNEMENT.md) — installation et déploiement.
- [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md) — section 2ter (API IA, sous-module ai).
- Infrastructure Cloud 4NK — liste des services et ports par machine (règles projet / documentation infra).

64
services/docv/enso-docs/README.md Normal file
View File

@ -0,0 +1,64 @@
# Documentation — enso (docv / enso)
Index de la documentation du monorepo **enso**, qui regroupe **docv** (socle commun) et **enso** (avocats).
---
## 1. Documents de cadrage
| Document | Description |
|----------|-------------|
| [PLAN_DEVELOPPEMENT.md](PLAN_DEVELOPPEMENT.md) | Plan de développement actionnable : phases, jalons, ordre des zones docv, ordre d’intégration enso (zone 17). |
| [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md) | Découpage docv / enso, API externes, structure des projets. |
| [PLAN_REALISATION_DOCV_ENSO.md](PLAN_REALISATION_DOCV_ENSO.md) | Phases de réalisation (Phase 0 à 4), héritage, livrables, références. |
| [ARCHITECTURE_DOCV_DETAILLEE.md](ARCHITECTURE_DOCV_DETAILLEE.md) | Architecture détaillée du socle docv (couches, BDD, API). |
| [REGLES_CODING_PROJET.md](REGLES_CODING_PROJET.md) | Règles de coding spécifiques au projet : placement du code, API/couches, auth, paramétrage, erreurs, front, conventions, commits, interdictions. |
| [INSTALLATION_ENVIRONNEMENT.md](INSTALLATION_ENVIRONNEMENT.md) | Installation de l’environnement sans Docker : prérequis, clone, build, déploiement sur test / pprod / prod ; proxy ; certificats TLS docv documentés (§8.1), consolidation nginx/certbot côté infra à poursuivre. |
| [PORTS_ENSO.md](PORTS_ENSO.md) | Cartographie des ports : déjà utilisés sur test/pprod/prod, ports attribués au projet enso (identiques en dev, test, pprod, prod). |
---
## 2. Points d’entrée par projet
Chaque sous-projet dispose d’un point d’entrée qui décrit son périmètre, ses références et l’ordre de lecture pour l’implémentation :
| Projet | Point d’entrée | Périmètre |
|--------|----------------|-----------|
| **docv** | [docv/README.md](docv/README.md) | Socle commun ; zones 1–15 ; pas de zone 17 ni de spécifiques. |
| **enso** | [enso/README.md](enso/README.md) | Avocats ; zones 1–15 + zone 17 (ia_local) ; spécifiques E1–E31. |
---
## 3. Référentiels et spécifications
| Document | Description |
|----------|-------------|
| [SCREENS_AND_FUNCTIONS_MAP.md](SCREENS_AND_FUNCTIONS_MAP.md) | Cartographie écrans et fonctions (zones 1–17, actions 18.1–18.83). |
| [features/REFERENTIEL_ECRANS_ACTIONS.md](features/REFERENTIEL_ECRANS_ACTIONS.md) | Liste exhaustive des écrans et actions avec identifiants stables (paramétrage, implémentation). |
| [features/specs/README.md](features/specs/README.md) | Spécifications fonctionnelles par zone (SPEC_01 à SPEC_17). |
| [features/implementation/README.md](features/implementation/README.md) | Description technique d’implémentation par zone (IMPL_01 à IMPL_17). |
| [features/PARAMETRAGE_ECRANS_ACTIONS.md](features/PARAMETRAGE_ECRANS_ACTIONS.md) | Modèle de paramétrage (écrans, actions, options). |
| [features/SPECIFIQUES_PROJETS.md](features/SPECIFIQUES_PROJETS.md) | Spécifiques enso (E1–E31) ; statuts de confirmation. |
| [features/DOCV_API_ENSO_FRONT_MAP.md](features/DOCV_API_ENSO_FRONT_MAP.md) | Liaison docv-back (`/api/v1/*`, OAuth) ↔ modules et routes **enso-front** ; point d’entrée **enso-back** (`/api/v1/enso/status`). |
| [features/ENSO_FRONT_BACKEND_CONTRACT.md](features/ENSO_FRONT_BACKEND_CONTRACT.md) | Audit des appels **enso-front** (`docvFetch`, types JSON) et **enso-back** (zone 17). |
| [features/DOSSIERS_PERMANENTS_DATA_GIT.md](features/DOSSIERS_PERMANENTS_DATA_GIT.md) | Dossiers permanents types : `data/dossiers-permanents/`, BDD (`dp_*`), sync Git optionnelle après upload. |
| [features/ANYTHINGLLM_DATAROOM_SYNC.md](features/ANYTHINGLLM_DATAROOM_SYNC.md) | Clone, `git pull` périodique, workspace AnythingLLM ↔ arborescence DP. |
---
## 4. Ordres d’intégration
| Projet | Document | Contenu |
|--------|----------|---------|
| enso | [enso/ORDRE_INTEGRATION_ZONE_17.md](enso/ORDRE_INTEGRATION_ZONE_17.md) | Phases d’intégration de la zone 17 (ia_local) ; dépendances entre sous-blocs. |
docv n’a pas de document d’ordre d’intégration spécifique : l’ordre est décrit dans le plan de réalisation (Phase 1 : 1.1 Backend, 1.2 Frontend, 1.3 Données et paramétrage).
---
## 5. Autres références
- **Périmètre notaire** (hors dépôt actuel) : [HORS_PERIMETRE_NOTAIRE.md](HORS_PERIMETRE_NOTAIRE.md).
- **Fonctionnalités ia_local** (enso) : [features/FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md](features/FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md).
- **IA — grands principes** : [features/IA_GRANDS_PRINCIPES.md](features/IA_GRANDS_PRINCIPES.md) (si présent).
- **Corrections et évolutions** : `fixKnowledge/` (corrections), `features/` (évolutions), selon les conventions du projet.

259
services/docv/enso-docs/REGLES_CODING_PROJET.md Normal file
View File

@ -0,0 +1,259 @@
# Règles de coding spécifiques au projet — docv / enso
Ce document consolide les **règles de développement spécifiques** au monorepo enso (docv, enso). Les règles Cursor et lint générales (max-lines, complexity, etc.) sont détaillées en section 9 ; la config détaillée reste dans `.cursor/rules/` et les fichiers ESLint/Clippy.
**Références :** [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md), [ARCHITECTURE_DOCV_DETAILLEE.md](ARCHITECTURE_DOCV_DETAILLEE.md), [PLAN_REALISATION_DOCV_ENSO.md](PLAN_REALISATION_DOCV_ENSO.md) (section 5).
---
## 1. Placement du code et héritage
| Règle | Description |
|-------|-------------|
| **Code dans docv** | Tout le code applicatif commun (back et front) est dans **docv**. **enso** **ne duplique pas** ce code ; il hérite (structure, design system, types) et **configure** (BDD, seeds, paramétrage, thème, i18n). |
| **Spécifiques listés et confirmés** | Tout spécifique enso (E1–E31) doit être **listé** dans [SPECIFIQUES_PROJETS.md](features/SPECIFIQUES_PROJETS.md) et passé en statut **Confirmé** avant toute implémentation. Aucun code spécifique (écran, action, service, intégration API) sans confirmation. |
| **Pas de dépendance croisée** | docv ne dépend pas d’enso. **enso** dépend de docv pour le socle commun ; aucune autre déclinaison produit n’est suivie dans ce dépôt. |
### 1.1 Où va le code par projet
- **docv-back** : `handlers/` (auth, folders, documents, offices, users, roles, site_texts, system_configuration, screen_config, action_config), `services/`, `repositories/`, `clients/` (anchoring_client, ia_client). Aucune référence à « lawyer » ou « notary ».
- **enso-back** : mêmes modules que docv pour les zones 1–15 (ou réutilisation via dépendance docv) ; **en plus** `handlers/ia/*`, `services/lawyer/`, `services/ia/` (ou équivalent) pour la zone 17. Pas de `handlers/idnot` ni de clients Mailchimp/OVH/Stripe côté périmètre avocat.
- **Fronts** : docv-front contient tous les écrans zones 1–15 ; **enso-front** hérite de la structure (composants, design-system, i18n) et ajoute ou surcharge (routes `/ia/*`, thème/i18n avocat).
---
## 2. API externes et couches back
| Règle | Description |
|-------|-------------|
| **API externes côté back uniquement** | Les API externes pertinentes du périmètre (ancrage, IA) sont **consommées par le backend uniquement**. Les fronts n’appellent **jamais** directement ces API ; ils appellent **docv-back** ou **enso-back**. |
| **Handlers** | Réception HTTP, extraction params/body, **appel au service**, retour JSON ou erreur. **Pas de logique métier** ni de SQL dans les handlers. |
| **Services** | Logique métier, orchestration, appels aux repositories et aux clients externes (anchoring, ia). **Pas d’accès direct** à la requête HTTP. |
| **Repositories** | Requêtes SQL (ou ORM) et mapping vers les modèles. **Pas de règles métier**. |
| **Clients externes** | Erreurs typées ; **pas de fallback silencieux** ; erreurs remontées avec contexte et journalisées. |
### 2.1 Handlers — contenu autorisé et interdit
**Autorisé :** extraction des entrées (Path, Query, Json, State), appel à une fonction de service (ex. `folder_service::get_by_id(uid)`), mapping du résultat en réponse HTTP (status + JSON), mapping des erreurs en réponse HTTP (ex. `AppError::into_response()`). Une seule responsabilité par handler (une route = un cas d’usage).
**Interdit :** requêtes SQL ou accès direct au repository depuis le handler ; conditions métier (ex. « si l’utilisateur est admin alors… ») ; calculs, validations métier complexes ; appels directs aux API externes. En cas de besoin de logique, déplacer dans le service.
**Exemple de structure (Rust) :**
`handler : extract Path(id), State(state) → service::get(state.db(), id) → map Ok to 200 Json, Err to IntoResponse`.
### 2.2 Services — signature et responsabilités
**Signature :** les services reçoivent des types métier (identifiants, DTOs, options) et des références au pool BDD ou aux repositories ; ils ne reçoivent pas la requête HTTP (Request/Response). Retour : `Result<T, E>` ou type métier ; les erreurs sont typées (ex. `AuthError`, `NotFoundError`).
**Responsabilités :** appliquer les règles métier, orchestrer les appels aux repositories et aux clients externes (anchoring, ia), vérifier les permissions (ou déléguer au middleware après résolution du contexte). Pas d’écriture SQL : passer par les repositories.
### 2.3 Repositories — périmètre
Un repository par entité principale (ex. `user_repository`, `folder_repository`, `document_repository`). Méthodes typiques : `find_by_id`, `list` (avec filtres/pagination), `create`, `update`, `delete`. Retour : modèles ou `Option<T>` / `Result`. **Aucune règle métier** (pas de « si rôle alors requête différente » ; la condition est gérée par le service qui choisit quelle méthode du repository appeler).
---
## 3. Authentification
| Règle | Description |
|-------|-------------|
| **Login par défaut docv** | docv fournit un **système de login par défaut** (identifiant / mot de passe, session ou JWT, choix d’office) pour **tous les types de membres** (rôles des offices, membres des dossiers). |
| **enso** | Utilise ce login docv **par défaut** ; pas d’implémentation auth spécifique. |
Référence : [SPEC_01_auth_compte.md](features/specs/SPEC_01_auth_compte.md), [ARCHITECTURE_DOCV_DETAILLEE.md](ARCHITECTURE_DOCV_DETAILLEE.md) (section 7).
---
## 4. Paramétrage (écrans, actions, options)
| Règle | Description |
|-------|-------------|
| **Paramétrable sans changement de code** | Chaque écran, chaque action et chaque option d’implémentation doit être **paramétrable** (activation, visibilité, droits, libellés) via BDD / config (screen_config, action_config, system_configuration). |
| **Pas de listes en dur** | Pas de listes d’écrans ou d’actions en dur dans le front ; chargement de la config (GET /screen-config, GET /action-config ou équivalent) au login ou au changement d’office ; rendu conditionnel des menus et boutons selon cette config. |
| **Résolution** | Service dédié (parametrage_service) qui fusionne plateforme → office → type de dossier → rôle → préférence utilisateur. Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](features/PARAMETRAGE_ECRANS_ACTIONS.md). |
### 4.1 Identifiants stables
Utiliser les **identifiants stables** du [référentiel écrans et actions](features/REFERENTIEL_ECRANS_ACTIONS.md) pour screen_config et action_config (ex. `auth.login`, `folders.list`, `folders.detail`, `ia.crm`, `ia.dashboard`). Pas d’invention de clés en dehors du référentiel sans l’y ajouter.
---
## 5. Code partagé (docv-shared, docv-core)
| Règle | Description |
|-------|-------------|
| **docv-shared (Rust)** | Validation (email, mot de passe, longueurs), formatage (dates, montants), constantes, **règles métier pures sans I/O**. Compilable en **natif** (backs) et en **WASM** (fronts) pour réutiliser la même logique. Place : `docv/docv-shared/`. |
| **docv-core (TypeScript, optionnel)** | Types et contrats API (DTOs), constantes partagées. Pas de logique métier lourde. Peut être généré depuis OpenAPI (docv-back). Place : `docv/docv-core/`. |
| **Pas de duplication** | Éviter de dupliquer la logique back/front ; privilégier docv-shared (WASM) ou docv-core pour garder les contrats alignés. |
### 5.1 Quand utiliser docv-shared
Règles de validation (longueur mot de passe, format email, plages de dates), formatage affichage (montants, dates), constantes métier (codes statut, libellés techniques). Tout ce qui doit être identique côté back (vérification) et front (feedback immédiat) sans appel réseau. Ne pas y mettre de requêtes BDD ni d’appels HTTP.
---
## 6. Erreurs et logging
| Règle | Description |
|-------|-------------|
| **Erreurs typées** | Back : types dédiés (AppError, AuthError, NotFound, ValidationError) ; impl `From` et `IntoResponse` ; format JSON cohérent. Front : client API transforme les réponses en erreurs typées ; affichage via i18n. |
| **Pas de fallback implicite** | Aucun fallback silencieux ; aucune continuation après erreur sans comportement explicite et documenté. En cas d’erreur, remonter et journaliser. |
| **Logging structuré** | Niveau, contexte (request_id, user_uid, office_uid), **pas de données sensibles**. Pas de `console.log` / `println!` pour le métier ; utiliser le logger centralisé. |
| **Clients externes** | Erreurs ancrage/IA remontées avec contexte ; journalisées ; pas de continuation silencieuse. |
### 6.1 Format des erreurs API (back)
Réponse JSON d’erreur recommandée : un corps structuré (ex. `{ "error": { "code": "VALIDATION_ERROR" | "UNAUTHORIZED" | "FORBIDDEN" | "NOT_FOUND" | "INTERNAL", "message": "..." } }`). Le `message` est destiné au client ; ne pas y mettre de stack ni de chemins internes en production. Mapping HTTP cohérent : 400 (validation), 401 (non authentifié), 403 (non autorisé), 404 (ressource absente), 409 (conflit si pertinent), 500 (erreur interne ; message générique).
### 6.2 Logging — champs et exclusions
**Inclure :** niveau (info, warn, error), message, request_id (ou trace_id), user_uid et office_uid quand disponibles, duration_ms pour les requêtes, code erreur métier. **Exclure :** mots de passe, tokens, secrets, données personnelles non nécessaires au diagnostic (email peut être masqué partiellement si requis par la politique). Utiliser le logger structuré (ex. tracing avec champs) ; pas de concaténation de chaînes pour des données non contrôlées (risque d’injection dans les agrégateurs de logs).
---
## 7. Frontend
| Règle | Description |
|-------|-------------|
| **Un seul client API** | Tous les appels passent par un client unique vers **docv-back** ou **enso-back**. Pas d’URL ancrage ni IA côté front. |
| **i18n** | Clés structurées (auth.*, folders.*, …) ; textes par défaut dans docv ; **pas de texte en dur** dans l’UI. |
| **Design system** | Tokens (couleurs, typo, espacements), thème par défaut ; composants réutilisables ; **enso** surcharge (thème, couleurs) sans dupliquer la structure. |
| **Accessibilité** | ARIA, contraste, clavier (référence [SCREENS_AND_FUNCTIONS_MAP.md](SCREENS_AND_FUNCTIONS_MAP.md) et règles projet). |
### 7.1 Client API — contrat
Un seul module client (ex. `api/client.ts`) : création d’instance avec base URL lue depuis une variable d’environnement (ex. `NEXT_PUBLIC_API_URL`), intercepteur qui ajoute le header `Authorization: Bearer <token>` (token lu depuis le store auth ou cookie), gestion des réponses (200 → body, 401 → invalidation session + redirection vers login, 4xx/5xx → conversion en erreur typée). Toutes les routes métier passent par ce client ; pas de `fetch` ou `axios` direct ailleurs dans le code métier.
### 7.2 i18n — structure des clés
Préfixe par zone puis par écran/action : `auth.login.title`, `auth.login.error`, `auth.logout`, `auth.my-account.title`, `folders.list.title`, `folders.detail.actions.archive`, etc. Fichiers par locale : `fr.json`, `en.json` (et autres si besoin). Clés de validation : `validation.required`, `validation.email_invalid`, etc. Pas de chaîne en dur dans les composants (boutons, labels, messages d’erreur, titres de page).
---
## 8. Sécurité et données
| Règle | Description |
|-------|-------------|
| **Secrets** | Aucun secret en front. URLs et clés API (ancrage, IA, IdNot, etc.) uniquement en back (variables d’environnement ou config serveur). |
| **Validation des entrées** | Validation côté back obligatoire ; optionnellement côté front via docv-shared (WASM) ; pas de confiance aveugle au client. |
| **Autorisation** | Matrice rôle × ressource × action ; vérification dans les services ou middleware avant toute opération sensible. |
| **BDD docv** | Pas de champs IdNot ou notaire dans le noyau docv (structure agnostique). |
### 8.1 Variables d’environnement — back
Documenter dans `.env.example` ; ne jamais commiter de valeurs réelles. Noms attendus (ex.) : `DATABASE_URL`, `JWT_SECRET`, `ANCHORING_URL`, `IA_API_URL`, `HOST`, `PORT`. Lecture dans un module `config` (ex. `Config::load_from_env()`) ; pas de lecture dispersée de `env::var` dans les services.
---
## 9. Conventions de code (résumé)
À appliquer sur tout le code (docv, enso). Détail dans `.cursor/rules/` et config lint.
| Domaine | Règle |
|---------|--------|
| **Langues** | Répondre en français ; **code, documentation du code et commits en anglais**. |
| **Taille et complexité** | Max 250 lignes/fichier, 40 lignes/fonction ; max 4 paramètres ; profondeur d’imbrication max 4 ; complexité cyclomatique max 10. |
| **Factorisation** | Réutilisation systématique ; pas de code mort ; helpers centralisés. |
| **TypeScript** | Types de retour explicites ; pas de `any` ; pas de lazy imports ; imports nommés selon convention du projet. |
| **Rust** | Pas de `unwrap` en production ; erreurs typées, propagation `?` ; format (rustfmt), Clippy. |
| **Lint** | Pas de contournement (pas de disable de règle sans justification documentée) ; pas de bypass par commentaires. |
Référence : [PLAN_REALISATION_DOCV_ENSO.md](PLAN_REALISATION_DOCV_ENSO.md) (section 5).
### 9.1 Seuils numériques (à faire respecter par la config)
- **Fichier :** 250 lignes maximum (lignes vides et commentaires exclus).
- **Fonction :** 40 lignes maximum (lignes vides et commentaires exclus).
- **Paramètres :** 4 maximum par fonction ; au-delà, regrouper dans un objet options typé.
- **Imbrication :** profondeur max 4 (blocs if/for/match imbriqués).
- **Complexité cyclomatique :** max 10 par fonction.
- **Callbacks imbriqués :** max 3 (ex. then/then/catch ; au-delà, décomposer ou async/await).
### 9.2 Nommage
- **Rust :** snake_case pour modules, fonctions, variables, champs ; PascalCase pour types, enum variants. Fichiers : snake_case (ex. `auth_service.rs`, `folder_repository.rs`).
- **TypeScript/React :** camelCase pour fonctions et variables ; PascalCase pour composants et types. Fichiers composants : PascalCase ou kebab-case selon convention du projet (ex. `LoginForm.tsx`, `folder-list.tsx`).
- **Routes front :** alignées sur le référentiel (ex. `/login`, `/my-account`, `/folders`, `/folders/[id]`, `/ia/dashboard` pour enso).
### 9.3 Variables inutilisées
Supprimer les variables inutilisées plutôt que de les préfixer par `_`. Les paramètres de fonction non utilisés peuvent être omis ou nommés explicitement si la signature doit rester stable (ex. callback avec signature imposée).
### 9.4 Fichiers de configuration lint
- **ESLint (fronts)** : config partagée à la racine `eslint.config.base.mjs` (règles fix-lint) ; **enso-front** étend cette base via `enso/enso-front/eslint.config.mjs`. Lint des fronts : `npm run lint` (racine) ou `npm run lint` dans chaque workspace ; lint Rust : `npm run lint:rust` (docv workspace + enso-back). Référence : `.cursor/agents/fix-lint.md`.
- **Clippy (Rust)** : config partagée dans `docv/Cargo.toml` ([workspace.lints.clippy]) ; les crates docv-back et docv-shared héritent via `[lints] workspace = true` ; **enso-back** suit la même logique (voir `Cargo.toml`).
---
## 10. Documentation
| Règle | Description |
|-------|-------------|
| **Mise à jour** | Toute modification de code ou d’architecture entraîne la mise à jour de la documentation concernée dans `docs/`. |
| **Emplacement** | Évolutions : `docs/features/` ; corrections : `docs/fixKnowledge/` ; architecture et plans : `docs/`. Rationalisation : pas de doublons ; centralisation dans `docs/`. |
| **Commentaires** | Commentaires pour invariants, hypothèses, contrats, cas limites ; pas de commentaires qui répètent le code. |
---
## 11. Commits
| Règle | Description |
|-------|-------------|
| **Format** | Message structuré avec : **Motivations**, **Root causes**, **Correctifs**, **Evolutions**, **Pages affectées** (en bullets). |
| **Auteur** | 4NK ou Nicolas Cantu uniquement ; **pas de Co-authored-by: Cursor** ni d’auteur autre que 4NK ou Nicolas Cantu. |
| **Atomicité** | Commits atomiques et logiques ; pas de modifications non commitées durablement. |
Référence : CONTRIBUTING.md ou conventions du dépôt.
### 11.1 Exemple de message de commit
```text
Add folder archive endpoint and front action
**Motivations:**
- Allow users to archive folders from the detail screen.
**Root causes:**
- N/A (evolution).
**Correctifs:**
- N/A.
**Evolutions:**
- POST /folders/:id/archive in docv-back (handler + folder_service).
- Archive button on folder detail page (docv-front), gated by action_config.
**Pages affectées:**
- docv/docv-back/src/handlers/folders.rs
- docv/docv-back/src/services/folder_service.rs
- docv/docv-front/src/app/(dashboard)/folders/[id]/page.tsx
- docs/features/implementation/IMPL_02_dossiers.md (reference)
```
---
## 12. Interdictions (rappel)
| Interdit | Description |
|----------|-------------|
| Appels directs aux API externes depuis le front | Ancrage, IA, IdNot, etc. : back uniquement. |
| Logique métier ou SQL dans les handlers | Handlers : extraction + appel service + retour. |
| Fallback silencieux | Pas de continuation après erreur sans comportement explicite. |
| Textes en dur dans l’UI | Utiliser i18n (clés structurées). |
| Listes d’écrans/actions en dur | Utiliser screen_config / action_config. |
| Secrets en dur | Variables d’environnement ou config serveur. |
| Code spécifique non confirmé | Spécifiques enso listés et confirmés dans SPECIFIQUES_PROJETS avant implémentation. |
---
## 13. Références
- **Architecture** : [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md), [ARCHITECTURE_DOCV_DETAILLEE.md](ARCHITECTURE_DOCV_DETAILLEE.md)
- **Plan et règles globales** : [PLAN_REALISATION_DOCV_ENSO.md](PLAN_REALISATION_DOCV_ENSO.md) (section 5)
- **Implémentation docv** : [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) — ordre des zones, stack, BDD, API
- **Spécifiques** : [SPECIFIQUES_PROJETS.md](features/SPECIFIQUES_PROJETS.md)
- **Paramétrage** : [PARAMETRAGE_ECRANS_ACTIONS.md](features/PARAMETRAGE_ECRANS_ACTIONS.md)
- **Référentiel écrans/actions** : [REFERENTIEL_ECRANS_ACTIONS.md](features/REFERENTIEL_ECRANS_ACTIONS.md)
- **Auth** : [SPEC_01_auth_compte.md](features/specs/SPEC_01_auth_compte.md)
- **IMPL_xx** : [features/implementation/README.md](features/implementation/README.md) — index des fiches d’implémentation par zone

901
services/docv/enso-docs/SCREENS_AND_FUNCTIONS_MAP.md Normal file
View File

@ -0,0 +1,901 @@
# Cartographie des écrans et des fonctions attendues
Ce document décrit les écrans (pages) et les fonctions attendues pour docv / enso, en wording **générique** (agnostique du métier). Il sert de référence pour la réécriture dans docv et la déclinaison enso (avocats).
---
## Principe de paramétrabilité
**Règle :** Chaque écran, chaque action (fonctionnalité) et chaque option d’implémentation doit être **paramétrable**.
| Élément | Paramétrable | Niveaux possibles |
|--------|--------------|--------------------|
| **Écran** | Visibilité, ordre, libellé, accès par rôle | Plateforme, office, type de dossier, rôle |
| **Action (fonctionnalité)** | Activation, droits requis, conditions d’affichage | Plateforme, office, rôle, type de dossier |
| **Option d’implémentation** | Choix technique ou métier (workflow, intégration, comportement) | Plateforme, office, type de dossier, préférence utilisateur |
- **Écrans :** activation/désactivation par office ou par projet (docv / enso), ordre dans les menus, libellés, restriction par rôle ou par type de dossier.
- **Actions :** activation/désactivation par office ou par contexte (ex. « Télécharger » activé seulement si ancrage activé), droits requis (matrice permissions), conditions d’affichage (ex. bouton « Inviter » visible seulement si partage activé pour le dossier).
- **Options d’implémentation :** choix paramétrables (ex. workflow documentaire à 4 ou 5 statuts, intégration Outlook activée ou non, mode Chat IA activé ou non, type d’éditeur pour rédaction d’actes, seuils d’alertes, durée de conservation).
Détail du modèle de paramétrage : `docs/features/PARAMETRAGE_ECRANS_ACTIONS.md`.
---
**Conventions de libellés génériques :**
| Wording métier notaire (référence) | Wording générique |
|------------------------------------|-------------------|
| Acte / deed | Type de dossier (case type / folder type) |
| Étude | Office |
| Notaire (rôle) | Membre de l’office / professionnel |
| Client (dossier) | Partie au dossier / client |
| Tiers (courtier, agent…) | Partie externe / invité |
| Collaborateur | Collaborateur (conservé) |
| RIB | Coordonnées bancaires |
| Ancrage | Ancrage (conservé) |
| Super-admin | Admin plateforme |
| Admin (office) | Admin d’office |
---
## 1. Authentification et compte
| Écran / route | Fonctions attendues |
|--------------------------|---------------------|
| **Connexion** (auth) | Connexion par identifiant / mot de passe ou SSO selon le projet ; choix d’office actif pour les utilisateurs multi-offices. |
| **Déconnexion** (`/logout-callback`) | Déconnexion sécurisée, redirection, nettoyage de session. |
| **Mon compte** (`/my-account`) | Consultation et mise à jour du profil utilisateur (nom, email, téléphone, préférences) ; changement de mot de passe si applicable. |
---
## 2. Dossiers (folders / cases)
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Liste des dossiers** (`/folders`) | Liste paginée des dossiers de l’office actif ; filtres (statut, type de dossier, recherche) ; tri ; accès aux dossiers archivés et supprimés. |
| **Sélection de dossier** (`/folders/select`) | Choix d’un dossier (ex. pour une action contextuelle). |
| **Détail d’un dossier** (`/folders/[folderUid]`) | Fiche dossier : en-tête (nom, type de dossier, statut, dates), parties au dossier, documents, notes, partages, historique ; actions : modifier, archiver, supprimer, ancrage si applicable. |
| **Dossiers archivés** (`/folders/archived`) | Liste des dossiers archivés ; restauration ou consultation. |
| **Dossiers supprimés** (`/folders/deleted`) | Liste des dossiers en corbeille ; restauration ou suppression définitive. |
| **Création / édition de dossier** | Formulaire création ou édition : nom, type de dossier, description, parties liées ; validation et contraintes métier. |
---
## 3. Documents et types de documents
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Types de documents** (`/document-types`) | Liste des types de documents paramétrés pour l’office (libellé, description, obligatoire optionnel, etc.). |
| **Création type de document** (`/document-types/create`) | Création d’un nouveau type de document pour l’office. |
| **Détail type de document** (`/document-types/[documentTypeUid]`) | Consultation et édition d’un type de document. |
| **Documents d’un dossier** (dans `/folders/[folderUid]`) | Liste des documents du dossier ; téléversement, téléchargement, suppression, validation ; filigrane et ancrage si applicable. |
| **Téléversement / détail document** | Upload de fichiers, métadonnées, statut de validation, preuve d’ancrage si disponible. |
---
## 4. Types de dossiers (case types / deed types → générique)
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Types de dossiers** (`/deed-types` → `/case-types` ou `/folder-types`) | Liste des types de dossiers (ex. « Vente », « Prêt ») paramétrés pour l’office ; association aux types de documents. |
| **Création type de dossier** (`/deed-types/create`) | Création d’un type de dossier et liaison aux types de documents requis. |
| **Détail type de dossier** (`/deed-types/[deedTypeUid]`) | Consultation et édition d’un type de dossier. |
---
## 5. Offices et membres
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Liste des offices** (`/offices`) | Liste des offices accessibles à l’utilisateur ; sélection de l’office actif. |
| **Détail d’un office** (`/offices/[officeUid]`) | Fiche office : nom, adresse, paramètres ; gestion des rôles office et des membres. |
| **Coordonnées bancaires** (`/offices/rib`) | Saisie et mise à jour des coordonnées bancaires de l’office (selon périmètre métier). |
| **Collaborateurs** (`/collaborators`) | Liste des collaborateurs (membres) de l’office ; rôles, droits. |
| **Détail collaborateur** (`/collaborators/[collaboratorUid]`) | Fiche collaborateur : contact, rôle dans l’office, dossiers partagés ; édition des droits. |
| **Utilisateurs** (`/users`) | Liste des utilisateurs (selon rôle : même office ou tous) ; consultation, édition, désactivation. |
| **Détail utilisateur** (`/users/[userUid]`) | Fiche utilisateur : profil, offices, rôles, affiliations. |
---
## 6. Rôles et permissions
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Rôles** (`/roles`) | Liste des rôles (globaux et/ou par office) ; création, édition, suppression. |
| **Création rôle** (`/roles/create`) | Création d’un rôle ; attribution des permissions. |
| **Détail rôle** (`/roles/[roleUid]`) | Consultation et édition d’un rôle ; matrice des permissions (ressources × actions). |
---
## 7. Parties au dossier et partage
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Parties au dossier** (clients, `/customers`) | Liste des parties (clients) liées aux dossiers ; création, édition, suppression ; liaison à un dossier. |
| **Partage de dossier** (dans détail dossier) | Partage d’un dossier avec d’autres offices ou avec des parties externes ; gestion des invitations, rôles (lecture / écriture), révocation. |
| **Parties externes / invités** (third-party) | Gestion des invités d’un dossier : ajout, rôle (ex. lecteur, contributeur), renvoi d’invitation, suppression. |
---
## 8. Notes et rappels
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Notes** (`/notes`) | Liste des notes (par dossier ou globale selon droits). |
| **Notes d’un dossier** (`/notes/folder`, `/notes/[noteUid]`) | Création, édition, suppression de notes liées à un dossier. |
| **Rappels** (`/reminders`) | Liste des rappels (documents à fournir, échéances) ; configuration des rappels par type de document et par office. |
---
## 9. Abonnement et facturation
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Abonnement** (`/subscription`) | Vue d’ensemble de l’abonnement de l’office ; plan, nombre de collaborateurs, renouvellement. |
| **Souscrire** (`/subscription/subscribe`, `/subscription/new`) | Choix d’un plan, souscription, paiement (si intégré). |
| **Gérer l’abonnement** (`/subscription/manage`) | Modification de plan, mise à jour des moyens de paiement. |
| **Gérer les collaborateurs** (`/subscription/manage-collaborators`) | Gestion des sièges / licences liés à l’abonnement. |
| **Invitation** (`/subscription/invite`) | Envoi d’invitations à rejoindre l’office (sous réserve des places). |
| **Succès / erreur** (`/subscription/success`, `/subscription/error`) | Pages de retour après paiement ou erreur. |
---
## 10. Espace client (partie au dossier)
| Écran / route | Fonctions attendues |
| ------------------------------------------ | ------------------------------------------------------------------- |
| **Tableau de bord client** (`/client-dashboard`) | Vue des dossiers partagés ; accès aux documents et téléchargements. |
| **Détail dossier client** (`/client-dashboard/[folderUid]`) | Fiche dossier côté client ; téléchargement, dépôt si autorisé. |
---
## 11. Espace partie externe (invité)
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Connexion invité** (auth tiers) | Connexion par lien d’invitation ou code ; 2FA si applicable. |
| **Tableau de bord invité** (`/third-party`, `/third-party/dashboard`) | Vue des dossiers partagés avec l’invité ; accès aux documents selon rôle (lecture / contribution). |
---
## 12. Admin d’office
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Admin** (`/admin`) | Portail d’administration de l’office : métriques, paramètres, liens vers gestion des rôles, utilisateurs, types de documents, types de dossiers. |
| **Helpers admin** (`/admin/helpers`) | Outils ou aides techniques pour l’admin (selon implémentation). |
---
## 13. Admin plateforme (super-admin)
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Super-admin** (`/super-admin`) | Vue d’ensemble plateforme : offices, utilisateurs, santé des services, configuration globale. |
| **Gestion des rôles plateforme** (`/super-admin/roles-management`) | Rôles et permissions au niveau plateforme. |
| **Plans d’abonnement** (`/super-admin/subscription-plans`) | Création et édition des offres d’abonnement. |
---
## 14. Contenus et paramètres globaux
| Écran / route | Fonctions attendues |
| -------------------------------- | ---------------------------------------------------------------------------- |
| **Textes du site** (super-admin) | Gestion des textes éditoriaux (i18n) : clés, locales, versions, publication. |
| **Configuration système** | Clés de configuration (feature flags, limites, URLs) ; valeurs masquées. |
| **Mentions légales** (`/legal`) | Consultation mentions légales, CGU, politique de confidentialité. |
---
## 15. Technique et design
| Écran / route | Fonctions attendues |
|----------------|--------------------|
| **Design system** (`/design-system`) | Documentation des composants et tokens pour les développeurs (pas un écran métier). |
| **Vérification d’ancrage** (public) | Page publique de vérification d’un certificat d’ancrage (lien depuis un document ancré). |
---
## 16. Synthèse des zones fonctionnelles
| Zone | Écrans principaux | Fonctions clés |
|------|-------------------|----------------|
| **Auth & compte** | Connexion, déconnexion, mon compte | Authentification, profil, choix d’office |
| **Dossiers** | Liste, détail, archivés, supprimés, création/édition | CRUD dossiers, filtres, statuts, ancrage |
| **Documents** | Types de documents, documents d’un dossier, upload | CRUD documents, types, validation, filigrane, ancrage |
| **Types de dossiers** | Liste, création, détail | CRUD types de dossiers, lien types de documents |
| **Offices & membres** | Offices, détail office, RIB, collaborateurs, utilisateurs | Gestion offices, membres, rôles office, coordonnées bancaires |
| **Rôles & permissions** | Rôles, création, détail (matrice) | CRUD rôles, matrice permissions |
| **Parties & partage** | Parties au dossier, partage, invités | CRUD parties, partage inter-offices, invités externes |
| **Notes & rappels** | Notes, rappels | CRUD notes, config rappels |
| **Abonnement** | Souscription, gestion, collaborateurs, invitations | Plans, paiement, sièges, invitations |
| **Espace client** | Dashboard client, détail dossier | Consultation dossiers partagés, téléchargements |
| **Espace invité** | Connexion invité, dashboard invité | Accès limité aux dossiers partagés |
| **Admin office** | Portail admin | Paramétrage office, métriques |
| **Admin plateforme** | Super-admin, rôles, plans | Config globale, textes, configuration système |
| **Legal** | Mentions légales, CGU | Contenus juridiques |
| **Technique** | Design system, vérification ancrage | Doc composants, preuve ancrage |
| **Opération** | Liste opérations, détail, création, édition, entreprise, contacts, documents | CRUD opérations, extraction KBIS, répartition IA ZIP, workflow documents |
Cette cartographie peut être utilisée telle quelle pour docv (wording générique) ; enso peut réutiliser la même structure avec les libellés et le périmètre métier avocat (ex. ancrage, RIB, abonnement).
---
## 17. Fonctionnalités et écrans issus du projet ia_local (à intégrer)
Les fonctionnalités et écrans listés ci-dessous proviennent du projet **ia_local** (arrêté) ; elles sont à intégrer dans enso. Détail : `docs/features/FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md`.
| Écran / route (référence ia_local) | Fonctions attendues |
|------------------------------------|---------------------|
| **Tableau de bord métier** (`dashboard`) | Vue d’ensemble : tâches en cours, débours sur les projets ; accès rapide aux écrans métier. |
| **CRM (Clients, DP, Dossiers)** (`crm`) | Liste des clients et dossiers permanents ; recherche CRM ; navigation vers un dossier ou une grande activité. |
| **Composition d’actes** (`composition-actes`) | Rédaction d’actes à partir de données extraites (Excel, PDF, JPG) ; listes salariés, contrats, baux, KBIS, conventions intragroupe. |
| **Mise à jour DP** (`mise-a-jour-dp`) | Mise à jour du dossier permanent à partir de KBIS, PV AG, baux, conventions, pactes Dutreil, statuts, etc. |
| **Secrétariat juridique** (`secretariat-juridique`) | Prérédaction AG, PV, résolutions ; données comptables ; alertes (réserve légale, seuils CAC, etc.) ; convocations et publipostage. |
| **Renvoi de dossier (partage)** (`renvoi-dossier`) | Partage de documents avec clients, comptabilité, CAC ; gestion des destinataires et des accès. |
| **Extraction données dataroom** (`extraction-dataroom`) | Synthèse des pièces de la dataroom ; rapport d’audit (baux, emprunts, CRD, etc.). |
| **Alertes fins de dossiers** (`alertes`) | Liste des alertes par type et échéance (baux, marques, pactes Dutreil, mandats, rapports d’imposition) ; notifications associé / collaborateur. |
| **Data room** (`data-room`) | Espace partagé ; droits (consultation / édition) ; invitations ; date de fin d’accès ; notifications à chaque dépôt. |
| **Courriers renvois IFU / RDPD DVD** (`courriers-ifu`) | Intégration des données RDPD DVD, publipostage des courriers de renvoi ; ou classement automatique par IFU (SIRET). |
| **Workflow documentaire** (`workflow`) | Documents par statut (à demander, demandé, reçu, validé, refusé) ; filtres établissement / dossier / workflow ; actions par ligne (Voir, Télécharger, Analyse IA, Archiver, Supprimer, Inviter). |
| **Tâches** (`taches`) | Liste des tâches ; filtre par dossier, type, statut, assigné ; prochaines échéances ; ajout, modification, clôture. |
| **Débours** (`debours`) | Liste des débours par dossier ; statuts (en attente, validé, refusé, payé) ; ajout, modification, validation ; synthèse. |
| **Messages / Tchat** (`messages`) | Fil de discussion par contexte (dossier, établissement) ; envoi de messages ; pièces jointes ; lien avec l’IA. |
| **Notifications** (`notifications`) | Liste des notifications ; filtre type, période, lu / non lu ; marquer comme lu. |
| **Configuration établissements** (`configuration-etablissements`) | Liste des établissements ; ajout, modification, suppression (rôle associé). |
| **Types et configuration** (`admin-types`) | Gestion des types : documents, dossiers, tâches, alertes, débours, grandes activités, rôles, établissements, clients, contrats, salariés, membres. |
| **Facturation débours** (`facturation-debours`) | Workflow de facturation des débours ; transmission dématérialisée ; comparaison provision / débours ; validation en fin de dossier. |
| **Courriers annexes aux cessions** (`courriers-annexes`) | Génération de courriers types (salariés, urbanisme, bailleur, séquestre, etc.). |
| **Mails ou courrier semi-auto** (`mails-semi-auto`) | Envoi semi-automatique de mails pour alertes (plus-value, report d’imposition, baux, marques) avec texte pré-rédigé. |
| **Édition des pièces de formalités** (`edition-formalites`) | Génération de pièces (pouvoir, déclaration non-condamnation, 2759, LAB, extrait PV, domiciliation, statuts, cession de fonds). |
| **Fiche prépa AG groupe** (`fiche-prepa-ag`) | Données N à N-3 (dividendes, résultats), conventions intragroupe, rémunération dirigeants, fin de mandat CAC / dirigeant. |
| **Planning des charges** (`planning-charges`) | Affectation des tâches aux collaborateurs ; liste des tâches avec échéances et état d’avancement. |
| **Organigramme** (`organigramme`) | Visualisation de l’organigramme (actionnariat, structure) à partir des feuilles de présence ou statuts. |
| **Listing annexes et intercalaires** (`listing-annexes`) | Liste des annexes d’un acte ; génération d’intercalaires ; compilation PDF des annexes. |
| **Devis / lettre de mission** (`devis-lettre-mission`) | Création automatique de devis ou lettre de mission. |
| **Interfaçage Outlook** (`outlook`) | Lien des mails Outlook avec le dossier client concerné. |
| **Chat IA** (panneau) | Chat avec l’IA ; contexte de l’arborescence Explorer ; envoi « Montre-moi [rubrique] » depuis l’Explorer. |
| **Explorer (Commun / Datarooms)** | Arborescence des dossiers ; sélection d’un dossier pour afficher le contenu ; Datarooms pour le rôle client, Commun pour les rôles internes. |
| **Recherche globale** | Recherche texte libre et par tags (#tag) ; filtres établissement, dossier, client, dates. |
| **Mon compte (appareils)** | Gestion des appareils enregistrés (en plus du profil et du mot de passe). |
---
## 18. Opération (cabinet/office)
Périmètre cloisonné au cabinet/office. Référence : [SPEC_18_operation.md](features/specs/SPEC_18_operation.md).
| Écran / route | Fonctions attendues |
|---------------|---------------------|
| **Liste des opérations** (`/operations`) | Opérations où la personne connectée a un rôle ; filtres ; tri ; création (peut créer une société). |
| **Détail opération** (`/operations/[operationUid]`) | Fiche complète ; **onglets rôle → sous-rôle → membres** (selects/cases à cocher) ; tableau documents ; actions selon droits ; seuls cabinets/offices ont onglets complets ; autres : vue documents les concernant. |
| **Validation/correction post-création** (`/operations/[operationUid]/validate`) | Ordre fixe : infos → contacts → affectations ZIP → fichiers de synthèse ; pas de retour sur étape validée. |
| **Création / édition opération** | Formulaire opération ; section société(s) liée(s) (KBIS, SIRET, etc.) ; section contacts (rôles/sous-rôles cumulatifs) ; section documents ; une opération peut créer une société. |
| **Types d’opération** (`/settings/operation-types`) | Liste paramétrable ; création, édition, suppression ; définition des étapes par type. |
| **Étapes par type d’opération** (`/settings/operation-types/[typeUid]/steps`) | Liste des étapes ; création, édition, ordre ; paramétrage droits/types documents/workflow par étape. |
| **Types d’activité** (`/settings/activity-types`) | Liste paramétrable ; création, édition, suppression. |
---
## 19. Liste des actions par écran
Pour chaque écran, les actions utilisateur possibles sont listées explicitement.
### 18.1 Connexion (auth)
- Saisir identifiant et mot de passe (ou déclencher SSO).
- Valider la connexion.
- Choisir l’office actif (si multi-offices).
- Afficher un message d’erreur en cas d’échec.
### 18.2 Déconnexion (`/logout-callback`)
- Déclencher la déconnexion.
- Nettoyer la session côté client.
- Rediriger vers la page de connexion ou la page publique.
### 18.3 Mon compte (`/my-account`)
- Consulter le profil (nom, email, téléphone, préférences).
- Modifier le profil (nom, email, téléphone, préférences).
- Changer le mot de passe (si applicable).
- Enregistrer les modifications.
### 18.4 Liste des dossiers (`/folders`)
- Afficher la liste paginée des dossiers de l’office actif.
- Filtrer par statut, type de dossier, recherche textuelle.
- Trier les colonnes.
- Ouvrir un dossier (navigation vers le détail).
- Accéder à la liste des dossiers archivés.
- Accéder à la liste des dossiers supprimés.
- Créer un nouveau dossier (si droit).
### 18.5 Sélection de dossier (`/folders/select`)
- Afficher une liste ou un champ de recherche pour choisir un dossier.
- Sélectionner un dossier et valider (retour au contexte appelant).
- Annuler la sélection.
### 18.6 Détail d’un dossier (`/folders/[folderUid]`)
- Consulter l’en-tête du dossier (nom, type, statut, dates).
- Consulter les parties au dossier.
- Consulter la liste des documents du dossier.
- Consulter les notes du dossier.
- Consulter les partages et invités.
- Consulter l’historique si disponible.
- Modifier le dossier (nom, type, description, parties).
- Archiver le dossier (si droit).
- Supprimer le dossier (corbeille, si droit).
- Lancer ou consulter l’ancrage du dossier (si applicable).
- Téléverser un document.
- Ajouter une note.
- Gérer le partage du dossier.
- Gérer les parties externes / invités.
### 18.7 Dossiers archivés (`/folders/archived`)
- Afficher la liste des dossiers archivés.
- Restaurer un dossier (si droit).
- Consulter le détail d’un dossier archivé.
### 18.8 Dossiers supprimés (`/folders/deleted`)
- Afficher la liste des dossiers en corbeille.
- Restaurer un dossier (si droit).
- Supprimer définitivement un dossier (si droit).
### 18.9 Création / édition de dossier
- Saisir le nom, le type de dossier, la description, les parties liées.
- Valider le formulaire (création ou mise à jour).
- Annuler et revenir à la liste ou au détail.
### 18.10 Types de documents (`/document-types`)
- Afficher la liste des types de documents de l’office.
- Créer un nouveau type de document (si droit).
- Ouvrir le détail d’un type de document (consultation ou édition).
### 18.11 Création type de document (`/document-types/create`)
- Saisir le libellé, la description, les options (obligatoire, etc.).
- Enregistrer le type de document.
- Annuler et revenir à la liste.
### 18.12 Détail type de document (`/document-types/[documentTypeUid]`)
- Consulter les propriétés du type de document.
- Modifier le type de document (si droit).
- Supprimer le type de document (si droit et non utilisé).
### 18.13 Documents d’un dossier (dans le détail dossier)
- Afficher la liste des documents du dossier.
- Téléverser un ou plusieurs fichiers.
- Télécharger un document (original ou filigrané selon droit).
- Supprimer un document (si droit).
- Valider un document (si droit et workflow activé).
- Consulter la preuve d’ancrage d’un document (si applicable).
- Ouvrir le détail d’un document.
### 18.14 Téléversement / détail document
- Sélectionner un ou plusieurs fichiers à envoyer.
- Saisir les métadonnées éventuelles.
- Envoyer le(s) fichier(s).
- Consulter le statut de validation du document.
- Consulter ou télécharger la preuve d’ancrage (si disponible).
- Annuler l’upload ou fermer le détail.
### 18.15 Types de dossiers (`/case-types` ou `/folder-types`)
- Afficher la liste des types de dossiers de l’office.
- Créer un nouveau type de dossier (si droit).
- Ouvrir le détail d’un type de dossier.
### 18.16 Création type de dossier (`/case-types/create`)
- Saisir le libellé du type de dossier.
- Associer les types de documents requis ou optionnels.
- Enregistrer le type de dossier.
- Annuler et revenir à la liste.
### 18.17 Détail type de dossier (`/case-types/[caseTypeUid]`)
- Consulter les propriétés du type de dossier et les types de documents liés.
- Modifier le type de dossier (si droit).
- Supprimer le type de dossier (si droit et non utilisé).
### 18.18 Liste des offices (`/offices`)
- Afficher la liste des offices accessibles à l’utilisateur.
- Sélectionner l’office actif (changement de contexte).
- Ouvrir le détail d’un office (si droit).
### 18.19 Détail d’un office (`/offices/[officeUid]`)
- Consulter les informations de l’office (nom, adresse, paramètres).
- Modifier les informations de l’office (si droit).
- Accéder à la gestion des rôles office et des membres.
- Accéder aux coordonnées bancaires (si applicable).
### 18.20 Coordonnées bancaires (`/offices/rib`)
- Consulter les coordonnées bancaires enregistrées.
- Saisir ou modifier les coordonnées bancaires (si droit).
- Enregistrer les modifications.
### 18.21 Collaborateurs (`/collaborators`)
- Afficher la liste des collaborateurs de l’office.
- Créer ou inviter un collaborateur (si droit).
- Ouvrir le détail d’un collaborateur.
### 18.22 Détail collaborateur (`/collaborators/[collaboratorUid]`)
- Consulter le profil et le rôle du collaborateur.
- Consulter les dossiers partagés avec le collaborateur.
- Modifier le rôle ou les droits du collaborateur (si droit).
- Désactiver ou retirer le collaborateur (si droit).
### 18.23 Utilisateurs (`/users`)
- Afficher la liste des utilisateurs (selon périmètre : office ou plateforme).
- Filtrer ou rechercher un utilisateur.
- Ouvrir le détail d’un utilisateur.
- Créer un utilisateur (si admin plateforme).
### 18.24 Détail utilisateur (`/users/[userUid]`)
- Consulter le profil, les offices, les rôles et affiliations.
- Modifier le profil ou les rôles (si droit).
- Désactiver l’utilisateur (si droit).
### 18.25 Rôles (`/roles`)
- Afficher la liste des rôles (globaux et/ou par office).
- Créer un nouveau rôle (si droit).
- Ouvrir le détail d’un rôle.
- Supprimer un rôle (si droit et non utilisé).
### 18.26 Création rôle (`/roles/create`)
- Saisir le nom du rôle.
- Attribuer les permissions (matrice ou choix par ressource/action).
- Enregistrer le rôle.
- Annuler et revenir à la liste.
### 18.27 Détail rôle (`/roles/[roleUid]`)
- Consulter le rôle et la matrice des permissions.
- Modifier le nom ou les permissions du rôle (si droit).
- Supprimer le rôle (si droit).
### 18.28 Parties au dossier (`/customers`)
- Afficher la liste des parties (clients) liées aux dossiers.
- Créer une nouvelle partie (si droit).
- Modifier une partie existante (si droit).
- Supprimer une partie (si droit).
- Lier une partie à un dossier.
### 18.29 Partage de dossier (dans détail dossier)
- Consulter la liste des partages actifs (offices et parties externes).
- Créer un partage (inviter un office ou une partie externe).
- Modifier le rôle d’un partage (lecture / écriture).
- Révoker un partage.
- Renvoyer une invitation en attente.
### 18.30 Parties externes / invités (dans détail dossier)
- Afficher la liste des invités du dossier.
- Ajouter un invité (email, rôle : lecteur ou contributeur).
- Modifier le rôle d’un invité.
- Renvoyer l’invitation par email.
- Retirer un invité du dossier.
### 18.31 Notes (`/notes`)
- Afficher la liste des notes (par dossier ou globale selon droits).
- Filtrer par dossier ou par date.
- Ouvrir une note (détail ou édition).
### 18.32 Notes d’un dossier (`/notes/folder`, `/notes/[noteUid]`)
- Créer une nouvelle note liée au dossier.
- Consulter une note.
- Modifier une note (si droit).
- Supprimer une note (si droit).
### 18.33 Rappels (`/reminders`)
- Afficher la liste des rappels (documents à fournir, échéances).
- Consulter le détail d’un rappel.
- Configurer les rappels par type de document et par office (si droit).
### 18.34 Abonnement (`/subscription`)
- Consulter le plan actuel et le nombre de collaborateurs.
- Consulter la date de renouvellement.
- Accéder à la gestion de l’abonnement ou à la souscription (selon état).
### 18.35 Souscrire (`/subscription/subscribe`, `/subscription/new`)
- Choisir un plan d’abonnement.
- Saisir les informations de paiement (si intégré).
- Valider la souscription.
- Annuler et revenir.
### 18.36 Gérer l’abonnement (`/subscription/manage`)
- Consulter le plan et les moyens de paiement.
- Modifier le plan (upgrade / downgrade).
- Mettre à jour les moyens de paiement.
- Annuler l’abonnement (si prévu).
### 18.37 Gérer les collaborateurs (`/subscription/manage-collaborators`)
- Consulter le nombre de sièges utilisés et disponibles.
- Activer ou désactiver des sièges (selon offre).
- Lier les sièges aux collaborateurs.
### 18.38 Invitation (`/subscription/invite`)
- Saisir l’email (et éventuellement le rôle) du futur collaborateur.
- Envoyer l’invitation.
- Consulter les invitations en attente et renvoyer ou annuler.
### 18.39 Succès / erreur abonnement (`/subscription/success`, `/subscription/error`)
- Afficher le résultat du paiement (succès ou message d’erreur).
- Revenir au tableau de bord ou à la gestion de l’abonnement.
### 18.40 Tableau de bord client (`/client-dashboard`)
- Afficher la liste des dossiers partagés avec le client.
- Ouvrir un dossier pour consulter les documents.
- Télécharger les documents visibles.
### 18.41 Détail dossier client (`/client-dashboard/[folderUid]`)
- Consulter les informations du dossier et la liste des documents.
- Télécharger un document.
- Déposer un document (si rôle contributeur et autorisé).
### 18.42 Connexion invité (auth tiers)
- Saisir le code d’invitation ou suivre le lien reçu par email.
- Compléter la vérification 2FA si applicable.
- Valider la connexion et accéder au tableau de bord invité.
### 18.43 Tableau de bord invité (`/third-party/dashboard`)
- Afficher la liste des dossiers partagés avec l’invité.
- Ouvrir un dossier.
- Consulter et télécharger les documents (selon rôle).
- Déposer des documents (si rôle contributeur).
### 18.44 Admin (`/admin`)
- Consulter les métriques de l’office.
- Accéder aux paramètres et aux liens de gestion (rôles, utilisateurs, types de documents, types de dossiers).
- Consulter les aides ou outils techniques (`/admin/helpers` si présent).
### 18.45 Super-admin (`/super-admin`)
- Consulter la vue d’ensemble plateforme (offices, utilisateurs, santé des services).
- Accéder à la gestion des rôles plateforme.
- Accéder aux plans d’abonnement.
- Accéder à la configuration système et aux textes du site.
### 18.46 Gestion des rôles plateforme (`/super-admin/roles-management`)
- Afficher et modifier les rôles au niveau plateforme.
- Gérer la matrice des permissions plateforme.
### 18.47 Plans d’abonnement (`/super-admin/subscription-plans`)
- Afficher la liste des offres d’abonnement.
- Créer une nouvelle offre (si droit).
- Modifier ou désactiver une offre (si droit).
### 18.48 Textes du site (super-admin)
- Afficher la liste des textes (i18n) par clé, locale, version.
- Créer ou modifier un texte.
- Publier ou dépublier une version de texte.
### 18.49 Configuration système (super-admin)
- Afficher les clés de configuration par catégorie.
- Créer ou modifier une clé (feature flags, limites, URLs).
- Masquer ou révéler les valeurs sensibles (avec contrôle d’accès).
### 18.50 Mentions légales (`/legal`)
- Consulter les mentions légales, CGU, politique de confidentialité (lecture seule).
### 18.51 Design system (`/design-system`)
- Consulter la documentation des composants et des tokens (lecture seule, usage développeur).
### 18.52 Vérification d’ancrage (public)
- Saisir ou suivre un lien vers un certificat d’ancrage.
- Afficher le résultat de la vérification (validité, date, hash, etc.) (lecture seule).
### 18.53 Tableau de bord métier (dashboard, ia_local)
- Afficher les tâches en cours et les débours sur les projets.
- Accéder aux écrans métier (tâches, débours, workflow, CRM, etc.) via liens ou sélecteur.
### 18.54 CRM – Clients, DP, Dossiers (ia_local)
- Afficher la liste des clients et dossiers permanents (selon périmètre membre).
- Rechercher par nom client, référence, notes.
- Ouvrir un client ou un dossier permanent pour afficher le contenu.
- Filtrer par établissement ou grande activité si applicable.
### 18.55 Composition d’actes (ia_local)
- Sélectionner une source de données (Excel, PDF, JPG) pour extraction.
- Lancer l’extraction (salariés, contrats, baux, KBIS, conventions intragroupe).
- Consulter les données extraites et les utiliser pour la rédaction d’actes.
- Enregistrer ou exporter l’acte rédigé.
### 18.56 Mise à jour DP – Dossier permanent (ia_local)
- Sélectionner un dossier permanent et les documents sources (KBIS, PV AG, baux, statuts, etc.).
- Lancer la mise à jour automatique du dossier permanent.
- Consulter les données mises à jour et valider ou corriger.
### 18.57 Secrétariat juridique (ia_local)
- Consulter les événements AG et les statuts (à_venir, envoyé, tenu).
- Prérédaction des AG à partir du dossier N-1 ou trame vierge.
- Saisir ou importer les données comptables ; affecter le résultat.
- Consulter les alertes (réserve légale, seuils CAC, fin de mandat CAC).
- Prioriser rapport de gestion et résolutions / PV ; gérer les convocations et le publipostage.
### 18.58 Renvoi de dossier – partage (ia_local)
- Consulter les partages actifs (destinataires, cible dossier ou dataroom).
- Ajouter un destinataire (client, comptabilité, CAC) et définir le périmètre partagé.
- Modifier ou révoquer un partage.
### 18.59 Extraction données dataroom (ia_local)
- Sélectionner une dataroom ou un périmètre.
- Lancer la synthèse des pièces (baux, emprunts, CRD, etc.).
- Consulter ou exporter le rapport d’audit.
### 18.60 Alertes fins de dossiers (ia_local)
- Afficher la liste des alertes (baux, marques, pactes Dutreil, mandats, rapports d’imposition).
- Filtrer par dossier, type, période (30 j, 90 j, toutes).
- Consulter le bloc « À venir (30 jours) ».
- Marquer une alerte comme notifiée ; supprimer (selon droits).
- Ajouter une alerte (type, libellé, date d’échéance, dossier).
### 18.61 Data room (ia_local)
- Afficher les datarooms accessibles ; ouvrir une dataroom.
- Consulter les documents et les droits (consultation / édition).
- Inviter un membre ou un externe avec rôle (viewer / editor) et date de fin d’accès optionnelle.
- Déposer, modifier, supprimer ou télécharger des documents (selon droits).
- Consulter les notifications de dépôt.
### 18.62 Courriers renvois IFU / RDPD DVD (ia_local)
- Importer ou extraire un fichier RDPD DVD (distributions de l’année).
- Intégrer les sociétés dans la base du cabinet.
- Lancer le publipostage des courriers de renvoi ; ou configurer le classement automatique par IFU (SIRET).
### 18.63 Workflow documentaire (ia_local)
- Afficher les documents par statut (à demander, demandé, reçu, validé, refusé).
- Filtrer par établissement, dossier, workflow, statut.
- Consulter les vues par établissement, par dossier, par workflow, par statut.
- Par ligne : Voir, Télécharger, Analyse IA, Archiver, Supprimer, Inviter (selon droits).
- Changer le statut d’un document (demander, relancer, réceptionner, valider, refuser) selon le rôle.
### 18.64 Tâches métier (ia_local)
- Afficher la liste des tâches ; bloc « Prochaines échéances » (30 jours).
- Filtrer par dossier, type, statut, assigné à.
- Ajouter une tâche (titre, type, échéance, dossier, assigné à).
- Modifier, terminer ou supprimer une tâche (selon droits).
### 18.65 Débours (ia_local)
- Afficher la liste des débours ; filtrer par dossier, statut, période.
- Ajouter un débours (libellé, montant, dossier, tâche liée, statut).
- Modifier, supprimer ou valider un débours (selon droits).
- Consulter la synthèse (nombre, total par statut).
### 18.66 Messages / Tchat (ia_local)
- Afficher le fil de discussion du contexte (dossier, établissement).
- Envoyer un message ; joindre un document.
- Consulter l’historique des messages (auteur, date, contenu).
- Choisir le dossier ou le thread si plusieurs conversations.
### 18.67 Notifications (ia_local)
- Afficher la liste des notifications (titre, corps, envoyé, lu).
- Filtrer par type (info, alerte, demande), période (7 j, 30 j, 90 j), lu / non lu.
- Ouvrir le détail d’une notification ; marquer comme lu.
### 18.68 Configuration établissements (ia_local)
- Afficher la liste des établissements (nom, adresse, référence, dernière MAJ).
- Ajouter un établissement (nom, adresse, référence, email, téléphone).
- Modifier ou supprimer un établissement (avec confirmation) ; accéder au détail (informations, dossiers, membres, paramètres).
### 18.69 Types et configuration (ia_local)
- Afficher les catégories de types (documents, dossiers, tâches, alertes, débours, grandes activités, rôles, établissements, clients, contrats, salariés, membres).
- Consulter et modifier les types d’une catégorie (selon droits).
### 18.70 Facturation débours (ia_local)
- Consulter le workflow de facturation des débours.
- Transmettre les débours par voie dématérialisée ; affecter une facture à un dossier.
- Consulter la comparaison provision / débours engagés ; alerte en cas de dépassement.
- Valider la facture en fin de dossier (collaborateur).
### 18.71 Courriers annexes aux cessions (ia_local)
- Sélectionner un type de courrier (salariés, urbanisme, bailleur, fin de séquestre, renvoi chèque séquestre).
- Générer le courrier à partir des données du dossier ; prévisualiser, modifier, exporter ou envoyer.
### 18.72 Mails ou courrier semi-auto (ia_local)
- Consulter les alertes éligibles à un envoi semi-automatique (plus-value, report d’imposition, baux, marques).
- Choisir une alerte et afficher le mail pré-rédigé ; modifier si besoin ; envoyer.
### 18.73 Édition des pièces de formalités (ia_local)
- Sélectionner un type de pièce (pouvoir, déclaration non-condamnation, 2759, LAB, extrait PV, domiciliation, statuts, cession de fonds).
- Saisir les données nécessaires ; générer la pièce ; prévisualiser, modifier, exporter.
### 18.74 Fiche prépa AG groupe (ia_local)
- Consulter ou saisir les données N à N-3 (dividendes, résultats) et N (résultats).
- Saisir les conventions intragroupe et la rémunération des dirigeants ; dates de fin de mandat CAC et dirigeant.
- Générer ou exporter la fiche de préparation.
### 18.75 Planning des charges (ia_local)
- Afficher la liste des tâches par collaborateur avec échéances et état d’avancement.
- Affecter une tâche à un collaborateur ; modifier l’affectation.
- Filtrer par collaborateur, période, statut.
### 18.76 Organigramme (ia_local)
- Afficher l’organigramme (actionnariat ou structure) à partir des données sélectionnées (feuille de présence, statuts).
- Sélectionner le périmètre (dossier, société) ; exporter ou imprimer si prévu.
### 18.77 Listing annexes et intercalaires (ia_local)
- Sélectionner un acte ; lancer l’extraction des annexes citées.
- Consulter la liste des annexes ; générer les intercalaires.
- Lancer la compilation PDF des annexes (liste + pièces).
### 18.78 Devis / lettre de mission (ia_local)
- Créer un devis ou une lettre de mission à partir d’un modèle et des données du dossier.
- Prévisualiser, modifier, enregistrer ou envoyer.
### 18.79 Interfaçage Outlook (ia_local)
- Associer un mail Outlook au dossier client concerné (sélection ou suggestion).
- Consulter les mails liés à un dossier depuis l’application.
### 18.80 Chat IA (panneau, ia_local)
- Saisir un message dans le champ du chat.
- Envoyer le message ; consulter la réponse de l’IA (contexte Explorer).
- Depuis l’Explorer : cliquer sur une rubrique pour envoyer « Montre-moi [rubrique] » au chat et éventuellement basculer sur la vue Chat.
- Choisir un rôle ou un assistant IA si proposé.
### 18.81 Explorer – Commun / Datarooms (ia_local)
- Afficher l’arborescence Datarooms (rôle client) ou Commun (rôles internes).
- Déplier ou replier un dossier ; sélectionner un dossier pour afficher son contenu au centre.
- Navigation clavier (Entrée, Espace) sur les nœuds de l’arbre.
- Selon sélecteur : basculer entre Datarooms et Commun.
### 18.82 Recherche globale (ia_local)
- Saisir un texte libre ou des tags (#tag) dans la barre de recherche.
- Optionnel : ouvrir les filtres (établissement, dossier, client, dates).
- Lancer la recherche ; consulter les résultats (sections, liste CRM, etc.) ; naviguer vers un élément.
### 18.83 Mon compte – appareils (ia_local)
- Consulter la liste des appareils enregistrés pour le compte.
- Révoquer un appareil (selon droits).
- Enregistrer un nouvel appareil (flux d’enregistrement si prévu).
### 18.84 Liste des opérations (`/operations`)
- Afficher la liste paginée des opérations de l’office actif.
- Filtrer par date, type d’opération, recherche textuelle.
- Trier les colonnes.
- Ouvrir une opération (navigation vers le détail).
- Créer une nouvelle opération.
### 18.85 Détail opération (`/operations/[operationUid]`)
- Consulter l’en-tête (titre, date, numéro dossier, numéro comptable, type, entreprise).
- Consulter et gérer les sections entreprise, contacts, documents.
- Modifier l’opération (selon droits).
### 18.86 Création opération (`/operations/create`)
- Saisir titre, date (par défaut jour), numéro dossier, numéro comptable, type d’opération.
- Ajouter entreprise(s), contacts, documents.
- Valider ; annuler.
### 18.87 Édition opération (`/operations/[operationUid]/edit`)
- Modifier les champs de l’opération.
- Modifier les sections entreprise, contacts, documents.
- Enregistrer ; annuler.
### 18.88 Entreprise (dans opération)
- Saisir type (Groupe/Entreprise), imposition (IS/IR), SCI, SIRET, type d’activité.
- Uploader KBIS ; lancer l’extraction des données.
- Ajouter/modifier/supprimer des commentaires (niveau d’accès : interne, restreint au dossier, secret).
### 18.89 Contacts (dans opération)
- Ajouter un contact (nom, prénom, email, tel, rôle principal, rôle secondaire, actionnaire, parts).
- Recevoir une alerte si le contact existe déjà dans le cabinet ; charger automatiquement les données.
- Modifier ou supprimer un contact.
### 18.90 Documents (dans opération)
- Ajouter des documents par type (liste paramétrable).
- Uploader des fichiers ; associer à un type de document.
- Gérer le workflow (à envoyer, envoyé, téléchargé, validé, refusé) ; archiver, signer.
### 18.91 Upload ZIP et répartition IA
- Uploader un ZIP de dossiers et fichiers.
- Lancer l’analyse IA pour affecter chaque fichier au type de document approprié.
- Consulter et modifier la proposition avant validation.
### 18.92 Types d’opération (paramétrage)
- Afficher la liste des types d’opération (cession, approbation des comptes, autres, etc.).
- Créer, modifier ou supprimer un type (si non utilisé).
### 18.93 Types d’activité (paramétrage)
- Afficher la liste des types d’activité (particulier, boulangerie, etc.).
- Créer, modifier ou supprimer un type (si non utilisé).
### 18.96 Étapes par type d’opération (paramétrage)
- Afficher la liste des étapes d’un type d’opération.
- Créer, modifier, réordonner les étapes.
- Les paramétrages (droits, types de documents, workflow) dépendent des étapes.
### 18.94 Validation/correction post-création (`/operations/[operationUid]/validate`)
- Valider et corriger les informations complétées automatiquement.
- Valider et corriger les contacts complétés automatiquement.
- Valider et corriger les affectations automatiques des documents du ZIP.
- Valider les fichiers de synthèse générés/complétés : Fiche entreprise, liste des mouvements du capital, liste des associés, liste des salariés, liste des baux, liste des contrats.
### 18.95 Actions sur les documents (onglets par rôle/sous-rôle)
- Dans chaque onglet (rôle/sous-rôle) : tableau des documents avec états et actions possibles selon droits.
- Actions : demande, relance, exclusion du document, modification, suppression, visualisation (avec vignette preview), téléchargement, validation, refus.

72
services/docv/enso-docs/docv/AUTH_SESSION.md Normal file
View File

@ -0,0 +1,72 @@
# docv-back — Sessions OAuth, cookies et durées (référence unique)
Ce document centralise les **durées** et le **contrôle d’accès via `office_members`** (quels **`offices`** la métier `GET /api/v1/offices` retourne pour un jeton), ainsi que les **variables de contournement** pour bases de test.
## Modèle produit : espaces, rôles et sociétés
- **Sociétés (`offices` côté API)** : ce sont les **sociétés clientes du cabinet**, pas des « rattachements personnels » au sens où un même déploiement docv peut servir **plusieurs espaces** (applications / contextes) selon le **rôle** porté par la session.
- **Premier espace (périmètre cabinet actuel)** : l’utilisateur connecté est un **acteur du cabinet** (collaborateur, stagiaire, comptable, expert-comptable, associé, administrateur, etc.). Il accède aux dossiers des **sociétés clientes** que le produit lui expose pour ce rôle — **pas** comme un utilisateur final « membre client » rattaché à sa société au même titre que dans l’espace dédié clients.
- **Autres espaces (clients)** : réservés aux **utilisateurs clients**, **rattachés aux sociétés** avec **rôles et sous-rôles** métier ; la charge utile et les écrans suivent ce modèle.
- **Même e-mail, plusieurs rôles** : le **choix d’espace / de rôle au login** est **géré par docv** (sélection lorsque plusieurs contextes s’appliquent).
La table **`office_members`** reste le **mécanisme d’implémentation** qui lie un `user_uid` à des `office_uid` pour qu’un jeton voie des sociétés ; elle **ne documente pas à elle seule** la sémantique métier « cabinet vs client » — celle-ci vient du **contexte de session / de rôle** docv. Les variables ci-dessous ne remplacent **ni** ce modèle **ni** le choix au login.
## Variables d’environnement (docv-back)
| Variable | Rôle | Défaut / valeurs |
|----------|------|------------------|
| **`DOCV_OAUTH_ACCESS_TOKEN_TTL_SEC`** | Durée unique pour : (1) claims JWT **`exp`** et champ **`expires_in`** du **`POST /oauth/token`** ; (2) claims `exp` du JWT embarqué dans le cookie **`docv_oauth_session`** ; (3) attribut **`Max-Age`** de ce cookie après **`POST /oauth/sign-in`**. | **900** (15 min). Plage **60**–**86400**. |
| **`DOCV_DEMO_MEMBER_EMAILS`** | **Contournement test / données incomplete** : au **démarrage**, pour chaque **email** listé (virgules), si l’utilisateur n’a **aucune** ligne **`office_members`**, insertion sur le **plus ancien** office (`ORDER BY created_at ASC`) en rôle **`client`** (libellé technique BDD). | Vide = désactivé. |
| **`DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE`** | **Contournement test uniquement** : si **`1`**, **`true`**, **`yes`** ou **`on`** (insensible à la casse), **tous** les utilisateurs sans **`office_members`** sont liés au plus ancien office en **`client`**. **Ne représente pas** le rattachement métier cabinet ↔ sociétés ni client ↔ sociétés ; à n’utiliser que pour aligner une BDD de test (ex. liste Sociétés vide alors que des `offices` existent). | Désactivé si absent. |
## Cohérence Bearer ↔ cookie navigateur
- Avant correction **0.0.87**, le cookie `docv_oauth_session` utilisait **86400 s** alors que le Bearer suivait **`DOCV_OAUTH_ACCESS_TOKEN_TTL_SEC`** : une session navigateur OAuth pouvait rester valable alors que le jeton API était expiré (ou l’inverse selon le scénario).
- Désormais **un seul réglage** pilote les deux : **`DOCV_OAUTH_ACCESS_TOKEN_TTL_SEC`**.
## Schéma `office_members` avec `role_uid` (environnements IMPL / données réelles)
Certaines bases ont des tables **`folders`** sans colonne **`status`** (schéma IMPL). Au démarrage, **`ensure_folders_status_column`** exécute **`ADD COLUMN IF NOT EXISTS status … DEFAULT 'open'`** pour aligner les **`GET/POST /api/v1/folders`**.
Certaines bases ont **`office_members.role_uid`** (NOT NULL, FK vers **`roles`**) et **`joined_at`**. Au démarrage, docv-back applique une table **`roles`** minimale si besoin, assure **au moins une ligne `roles` par `office`** via **`ensure_impl_role_rows_for_all_offices`** (également après création des offices démo) et **`ensure_one_office_scoped_role_row_if_impl`** sur chaque **`INSERT INTO offices`** des chemins seed/migration. **`insert_office_member`** exige une ligne **`roles`** pour **`office_uid`** (**`require_office_scoped_role_uid`**) ; en cas d’absence, l’erreur remonte (pas de repli sur un rôle global ni succès feint). **`DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE`** interrompt le lot si l’office cible n’a pas de rôle d’office. Un schéma **`roles`** tiers (colonnes incompatibles) peut imposer une migration manuelle.
## Liste « Sociétés » vide (`GET /api/v1/offices`)
L’API ne renvoie que les offices pour lesquels une ligne **`office_members`** existe pour le **`sub`** du JWT (UUID utilisateur), dans le **contexte de session** courant.
Causes fréquentes en **test / données incomplètes** :
1. **Offices déjà présents** en base alors que **`seed_demo_office_if_needed`** ne s’exécute que lorsque **`COUNT(offices) = 0`**. Les comptes utilisés pour la recette n’ont alors **pas** de ligne **`office_members`** (alors que le modèle métier cible suppose des rattachements gérés par le produit ou par des scripts d’administration).
2. Le compte de test **n’est pas** celui couvert par le seed démo (`client@example.com`, etc.).
**Pistes de correction (uniquement alignement technique BDD / recette)** :
- **Liste d’emails** : **`DOCV_DEMO_MEMBER_EMAILS`** (ciblage fin ; reste un contournement).
- **Test** : **`DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE=1`** pour créer des **`office_members`** sur le **plus ancien** office **uniquement** — avec **multi-offices** démo, un compte ainsi « orphelin » ne verra **pas** les neuf sociétés ; il faut des **memberships explicites** par société ou un jeu de données cohérent avec le périmètre du rôle. **Ne pas activer en production** sans validation.
Après modification du `.env` sur la machine cible : **`systemctl --user restart enso-docv-back`** (ou équivalent).
## Déconnexion navigateur (`docv_oauth_session`)
Le jeton **Bearer** et le **sessionStorage** enso-front peuvent être effacés côté client, mais le cookie **HttpOnly** `docv_oauth_session` restait valide : une visite sur **`/oauth/authorize`** pouvait délivrer un **code** sans re-saisie du mot de passe.
- **`GET /oauth/sign-out?return_url=…`** : pose un **`Set-Cookie`** qui expire `docv_oauth_session`, puis **redirige** vers `return_url`.
- **`return_url`** doit avoir la **même origine** (`scheme://host[:port]`) qu’au moins une entrée de **`OAUTH_REDIRECT_URIS`** — en pratique **`/?signed_out=1`** sur le même hôte (redirection vers **`/dashboard?signed_out=1`** puis **`/login?signed_out=1`**).
- **enso-front** : après `logout`, redirection vers **`…/docv-api/oauth/sign-out?return_url=…`** (voir `docvOAuthSignOutUrl`).
## Déploiement **`test`** et **`DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE`**
Le script **`deploy/scripts_v2/deploy.sh`** exporte **`DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE=1`** par défaut pour l’environnement **`test`** (sauf si la clé est déjà définie dans `enso-deploy.env`, y compris à **`0`** pour désactiver). Le script distant **`sync-docv-deploy-opts-to-docv-env.sh`** recopie cette valeur dans **`docv/docv-back/.env`** avant le **restart** de **docv-back**. Sur **pprod** / **prod**, aucune valeur par défaut : la clé n’est écrite que si elle est **non vide** dans `enso-deploy.env`.
Ce défaut **test** reste un **raccourci technique** ; il **ne substitute pas** le rattachement métier (cabinet vs clients, plusieurs sociétés visibles pour un rôle cabinet) ni la **sélection de rôle / d’espace au login** (docv).
## Front enso (hors docv-back)
- Le délai d’affichage avant relance SSO lorsque **`signed_out=1`** arrive sur **`/login`** est **uniquement côté client** (`LoginPageInner`, constante **`SIGNED_OUT_AUTO_SSO_MS`**). Il n’est **pas** lié aux TTL ci-dessus ; son rôle est l’UX (laisser lire le message, puis enchaîner).
- Voir aussi **[ENSO_FRONT_BACKEND_CONTRACT.md](../features/ENSO_FRONT_BACKEND_CONTRACT.md)** (flux OAuth / déconnexion).
## Références croisées
- **`docv/docv-back/.env.example`**
- **[INSTALLATION_ENVIRONNEMENT.md](../INSTALLATION_ENVIRONNEMENT.md)** — tableau des variables docv-back
- **[IMPLEMENTATION.md](IMPLEMENTATION.md)** §5.4 OAuth2

220
services/docv/enso-docs/docv/IMPLEMENTATION.md Normal file
View File

@ -0,0 +1,220 @@
# Implémentation détaillée — docv
Document de référence pour l’implémentation concrète du socle docv (zones 1 à 15). Il complète [ARCHITECTURE_DOCV_DETAILLEE.md](../ARCHITECTURE_DOCV_DETAILLEE.md) et les [IMPL_xx](../features/implementation/README.md) en précisant l’ordre des zones, le schéma BDD, la surface API et les livrables par phase.
**Plan de réalisation :** [PLAN_REALISATION_DOCV_ENSO.md](../PLAN_REALISATION_DOCV_ENSO.md) (Phase 1).
**Point d’entrée docv :** [README.md](README.md).
**Consommation prioritaire des API docv (docv-back) par les fronts produits pour le périmètre métier commun** — alignement architectural : [ARCHITECTURE_DOCV_ENSO.md](../ARCHITECTURE_DOCV_ENSO.md) §1 (même énoncé).
---
## 1. Ordre d’implémentation par zone
Les zones doivent être implémentées dans un ordre respectant les dépendances (auth et offices d’abord, puis rôles et types, puis dossiers et documents, puis partage et abonnement). Ordre recommandé :
| Ordre | Zone | IMPL | Dépendances | Objectif |
|-------|------|------|-------------|----------|
| 1 | 1 — Auth et compte | [IMPL_01](../features/implementation/IMPL_01_auth_compte.md) | Aucune | Login, logout, mon compte ; base pour tout le reste. |
| 2 | 5 — Offices et membres | [IMPL_05](../features/implementation/IMPL_05_offices_membres.md) | Zone 1 | Offices, collaborateurs, utilisateurs, RIB ; contexte office actif. |
| 3 | 6 — Rôles et permissions | [IMPL_06](../features/implementation/IMPL_06_roles_permissions.md) | 1, 5 | Matrice rôle × ressource × action ; utilisé par toutes les zones protégées. |
| 4 | 4 — Types de dossiers | [IMPL_04](../features/implementation/IMPL_04_types_dossiers.md) | 5 | Référentiel des types de dossiers (par office). |
| 5 | 3 — Documents et types | [IMPL_03](../features/implementation/IMPL_03_documents_types.md) | 5 | Types de documents, upload/download ; prérequis pour les dossiers (documents liés). |
| 6 | 2 — Dossiers | [IMPL_02](../features/implementation/IMPL_02_dossiers.md) | 4, 5, 6, 3 | CRUD dossiers, liste, archivés, supprimés ; cœur métier. |
| 7 | 7 — Parties et partage | [IMPL_07](../features/implementation/IMPL_07_parties_partage.md) | 2, 5, 6 | Parties au dossier, partage dossiers, invitations. |
| 8 | 8 — Notes et rappels | [IMPL_08](../features/implementation/IMPL_08_notes_rappels.md) | 2, 3 | Notes et rappels liés aux dossiers/documents. |
| 9 | 14 — Contenus et paramètres | [IMPL_14](../features/implementation/IMPL_14_contenus_parametres.md) | — | Textes légaux, config publique ; utilisé par 13 et par le front. |
| 10 | 13 — Admin plateforme | [IMPL_13](../features/implementation/IMPL_13_admin_plateforme.md) | 5, 6, 14 | Super-admin : rôles plateforme, plans, textes, configuration système. |
| 11 | 9 — Abonnement et facturation | [IMPL_09](../features/implementation/IMPL_09_abonnement_facturation.md) | 5, 13 | Abonnement par office, plans, prestataire paiement (back). |
| 12 | 10, 11 — Espace client / invité | [IMPL_10](../features/implementation/IMPL_10_espace_client_invite.md) | 2, 7 | Portail client, accès invité par lien/code. |
| 13 | 12 — Admin d’office | [IMPL_12](../features/implementation/IMPL_12_admin_office.md) | 5, 6, 2, 3 | Portail admin office, métriques, liens vers rôles, users, types. |
| 14 | 15 — Technique et design | [IMPL_15](../features/implementation/IMPL_15_technique_design.md) | 2, 3 | Vérification ancrage, design system, paramétrage écrans/actions. |
Les tables `screen_config` et `action_config` (paramétrage écrans/actions) peuvent être introduites avec la zone 6 ou 15 ; les seeds de paramétrage par défaut sont à prévoir en phase 1.3.
---
## 2. Stack technique et conventions
### 2.1 Backend (docv-back)
| Élément | Choix recommandé | Convention |
|--------|-------------------|------------|
| Langage | Rust | Pas de `unwrap` en production ; erreurs typées, propagation `?`. |
| Framework HTTP | Axum ou Actix-web | Handlers async ; extraction (State, Json, Path). |
| BDD | PostgreSQL | Pool (ex. deadpool, SQLx) ; migrations versionnées (SQLx migrate ou Diesel). |
| ORM / requêtes | SQLx (compil-time) ou Diesel | Repositories par entité ; pas de SQL dans les handlers. |
| Logging | tracing / tracing-subscriber | Structuré (request_id, user_uid, office_uid) ; pas de `println!`. |
| Erreurs | Types dédiés (error/) | `AppError`, `AuthError`, `NotFoundError` ; impl `From` + `IntoResponse` ; messages non sensibles. |
| Config | Variables d’environnement | `.env.example` documenté ; `config::Config` (DATABASE_URL, JWT_SECRET, ANCHORING_URL, IA_API_URL). |
| Clients externes | reqwest ou équivalent | `clients/anchoring_client.rs`, `clients/ia_client.rs` ; timeouts, erreurs typées. |
**Impl. enso (tests)** : depuis **`docv/docv-back`**, **`cargo test`** inclut les tests du module **`dp_layout_fs`** (routes **`dp-layout-entries`** / **`dp-layout-file`** : base canonique partagée **`dp_layout_base_canonical`**, tri dossiers/fichiers, lecture texte, rejet d’extension et d’échappement de chemin). Les routes **`instance-layout-entries`** / **`instance-layout-file`** sur **`/api/v1/offices/:officeUid/...`** réutilisent la **même** lecture disque ; la racine est résolue pour tout membre de l’office (**`dp_layout_root`** sous **`instances`**, sinon **`instances/<dp_archetype>`**, sinon **`instances`**). Routage **`api_v1`** : chemin relatif en **suffixe d’URL** après **`dp-layout-entries/`**, **`dp-layout-file/`**, **`instance-layout-entries/`** ou **`instance-layout-file/`** (segments encodés séparément), avec repli **`?path=`** — voir **`docs/features/DOCV_API_ENSO_FRONT_MAP.md`**.
### 2.2 Frontend (docv-front)
| Élément | Choix recommandé | Convention |
|--------|-------------------|------------|
| Framework | Next.js (App Router) ou équivalent | Routes sous `app/(auth)/`, `app/(dashboard)/` ; layout commun dashboard. |
| Langage | TypeScript | Types stricts ; types API alignés sur le back (ou docv-core / OpenAPI). |
| Client API | fetch ou axios | Un seul client (api/client.ts) ; base URL depuis env ; intercepteur auth (Bearer) ; gestion 401 → redirect login. |
| État global | Context ou Zustand | Auth (user, office actif, token) ; chargement screen_config/action_config au login. |
| i18n | Clés structurées (fr.json, en.json) | Pas de texte en dur ; clés par zone (auth.*, folders.*, …). |
| Design system | Tokens + composants | design-system/tokens, theme ; composants ui/ (Button, Input, Table, Modal). |
### 2.3 Code partagé
- **docv-shared** (Rust, optionnel) : validation (email, mot de passe, longueurs), formatage (dates, montants), constantes ; compilable en natif (back) et en WASM (front). Référence : ARCHITECTURE_DOCV_DETAILLEE section 5.
- **docv-core** (TypeScript, optionnel) : types et DTOs API, constantes ; peut être généré depuis OpenAPI (back) pour garder les contrats alignés.
---
## 3. Schéma BDD synthétique (zones 1–15)
Tables principales et lien avec les zones. Les migrations sont à ordonner selon l’ordre des zones ci-dessus (ex. users/sessions avant offices, offices avant office_members, etc.).
| Table | Colonnes clés | Zones utilisatrices |
|-------|----------------|----------------------|
| **users** | uid, email, password_hash, name, phone, preferences, created_at | 1, 5, 6, 12, 13 |
| **sessions** | id, user_uid, token_hash ou jti, expires_at | 1 (ou JWT stateless) |
| **offices** | uid, name, address, created_at | 5, 12, 13 |
| **office_members** | user_uid, office_uid, role_uid (ou lien rôle) | 5, 6, 12 |
| **office_rib** | office_uid, iban_encrypted, bic, … | 5 |
| **roles** | uid, name, scope (office \| platform), … | 6, 13 |
| **role_permissions** | role_uid, resource, action (ou matrice) | 6, 13 |
| **folder_types** | uid, office_uid, name, … | 2, 4 |
| **document_types** | uid, office_uid, name, … | 3, 12 |
| **folders** | uid, office_uid, name, folder_type_uid, status, description, archived_at, deleted_at | 2, 7, 8, 10, 12 |
| **folder_parties** | folder_uid, party_uid ou customer_uid, role | 2, 7 |
| **folder_shares** | folder_uid, sharee_uid ou email, role, token, expires_at | 7, 10, 11 |
| **documents** | uid, folder_uid, document_type_uid, name, file_path ou storage_key, created_at | 2, 3, 7, 8, 10, 15 |
| **notes** | uid, folder_uid ou document_uid, content, author_uid, created_at | 8 |
| **reminders** | uid, folder_uid ou document_uid, due_at, notified, … | 8 |
| **site_texts** | key, locale, version, content, published_at | 13, 14 |
| **system_configuration** | key, value, sensitive, category | 13, 14 |
| **screen_config** | identifiant, office_uid, scope, config (JSON) | 15, paramétrage |
| **action_config** | identifiant, office_uid, scope, config (JSON) | 15, paramétrage |
| **plans** | uid, name, features, price, seats, active | 9, 13 |
| **subscriptions** | office_uid, plan_uid, status, current_period_end, … | 9 |
| **subscription_invites** | office_uid, email, role_uid, token, status | 9 |
| **invitations** | token, folder_uid, email, role, expires_at, status | 7, 11 |
Entités optionnelles : **contacts**, **addresses** (liés à offices ou users selon modèle). Pas de champs IdNot ou notaire dans le noyau docv.
### 3.1 Socle actuel (implémenté dans docv-back + enso-front)
**Toolchain Rust** : le dépôt **enso** fixe **1.88.0** via **`rust-toolchain.toml`** à la racine du monorepo ( **`docv-back`** et **`enso-back`** ) ; utiliser **rustup** et un **`PATH`** où **`~/.cargo/bin`** précède le **`cargo`** système.
Migrations `20260330140000_offices_folders.sql` : tables `offices`, `office_members`, `folders`. Au démarrage, `ensure_offices_folders_schema` applique la migration ; `ensure_folders_purpose_operation_type` ajoute **`folder_purpose`** / **`operation_type`** et renomme l’office démo legacy « Cabinet démo » en **« Entreprise démo (fictive) »**. **`20260403140000_roles_minimal.sql`** : table **`roles`** minimale si absente (support **`office_members.role_uid`**). **`ensure_impl_role_rows_for_all_offices`** (avant et après le seed des offices démo) et la partie **`roles`** de **`ensure_auxiliary_rows_for_new_office_if_impl`** après chaque création d’office en seed/migration assurent une ligne **`roles`** d’office (« Membre ») lorsque le schéma IMPL impose **`office_members.role_uid`**. **`ensure_impl_folder_type_rows_for_all_offices`** (même rythme) et la partie **`folder_types`** du même helper assurent **« Dossier standard »** par office lorsque **`folders.folder_type_uid`** et la table **`folder_types`** existent. Les insertions **`office_members`** utilisent **`require_office_scoped_role_uid`** (**`roles.office_uid`** uniquement — pas de rôle « global », pas d’échec ignoré) ; les insertions de dossiers IMPL utilisent **`require_office_scoped_folder_type_uid`** sans création implicite ; **`repair_seed_demo_user_office_memberships_if_needed`** rattrape **`client@example.com`** sans membre. `migrate_legacy_demo_single_office_to_demo_and_type_offices_if_needed` (dans `db/mod.rs`) convertit une base **un office démo + 8 dossiers structures** en **9 offices** (8 types + démo). `seed_demo_office_if_needed` : si `offices` est vide, crée les **9** offices (libellés types + `DEMO_OFFICE_DISPLAY_NAME`) et rattache `client@example.com` à chacun. **`seed_demo_dp_folders_for_cabinet_demo_if_needed`** : pour chaque office type, un dossier **`dp_structure_demo`** (`instances/<archetype>/`) ; pour l’office démo, un dossier avec **`instances/entreprise_demo/`** (schéma IMPL : la ligne **`folder_types`** doit déjà exister pour l’office via le bootstrap ci-dessus).
Migration `20260401160000_user_stub_lists.sql` : tables `user_notifications`, `user_pending_documents`, `user_conversations`, `conversation_messages`. `ensure_user_stub_lists_schema` au démarrage ; `seed_stub_lists_demo_if_needed` insère un exemple de notification, document en attente et conversation (utilisateur `client@example.com`) lorsque les tables sont vides **et** qu’au moins un dossier existe. **`PATCH /api/v1/notifications/:id`** met à jour `is_read` pour la ligne appartenant au porteur du jeton.
**Placeholder migration démo** : pendant `migrate_legacy_demo_single_office_to_demo_and_type_offices_if_needed`, un office peut être renommé temporairement en `__docv_migrating_legacy_demo__`. Ce nom est **exclu** des listes `GET /api/v1/offices` et du détail office ; les requêtes « premier office » (liaison e-mails démo / utilisateurs orphelins) **l’ignorent** également. Au démarrage, `remove_stale_legacy_demo_migration_placeholder_office_if_needed` supprime cet office s’il n’a **aucune** ligne dans `folders` ; sinon un **warn** est journalisé (migration interrompue — intervention manuelle possible).
Migration `20260401170000_folder_documents.sql` : table `folder_documents` (pièces rattachées à un dossier). Les **événements** de création / mise à jour de dossier et d’ajout de document **alimentent** `user_notifications` pour les autres membres de l’office (voir handlers dans `api_v1.rs`).
Migration `20260402100000_folder_documents_storage_pending_idx.sql` : colonnes **`storage_url`** et **`mime_type`** sur **`folder_documents`** ; index sur `user_pending_documents` selon le fichier de migration. `ensure_folder_documents_storage_columns` au démarrage (voir `db/mod.rs`).
Migration `20260402110000_folders_title_legacy_compat.sql` : si la table **`folders`** existe sans colonne **`title`** mais avec **`name`**, renomme en **`title`** ; sinon ajoute **`title`** avec défaut vide. Évite l’échec du seed stub et des requêtes API sur des BDD de test héritées. `ensure_folders_title_legacy_compat` au démarrage (`db/mod.rs`, enchaînée dans `main.rs` après `ensure_offices_folders_schema`).
**Préfixe public (navigateur) :** `{origin}/docv-api` — nginx retire `/docv-api/` et propage `/api/v1/...` au backend docv-back.
**Authentification API métier :** en-tête `Authorization: Bearer <access_token>` (même JWT que celui émis par `POST /oauth/token`, claims avec `iss: "docv-back"`).
**Liste des routes HTTP et câblage handlers ↔ enso-front :** [features/DOCV_API_ENSO_FRONT_MAP.md](../features/DOCV_API_ENSO_FRONT_MAP.md) §1 — **référence unique** (ne pas dupliquer ce tableau ici).
**`POST /api/v1/folders`** : si la colonne **`folders.folder_type_uid`** est présente (IMPL), **`handle_create_folder`** appelle **`db::ensure_folder_type_uid_for_api_create`** puis insère avec **`folder_type_uid`**, **`folder_purpose = client_operation`**, champs DP nuls et **`description`** vide ; sinon insert minimal inchangé.
**Fichiers pièces (optionnel) :** variable **`DOCV_FILE_STORAGE_DIR`** sur docv-back : **`POST /api/v1/folders/:uid/documents/binary`** enregistre les octets et expose **`GET /api/v1/files/:docUid`** (Bearer) ; `storage_url` relative au site (`/docv-api/api/v1/files/...`). Sans répertoire, le front conserve le flux JSON métadonnées uniquement.
**Dossiers permanents types (données versionnées) :** arborescence `data/dossiers-permanents/` dans le monorepo ; colonnes BDD `folders.dp_archetype`, `folders.dp_layout_root`, `folder_documents.dp_mirror_path` ; sync Git optionnelle après upload (`DOCV_DP_GIT_*`). Voir [features/DOSSIERS_PERMANENTS_DATA_GIT.md](../features/DOSSIERS_PERMANENTS_DATA_GIT.md). Côté **enso-front**, la **fiche société** affiche un explorateur du gabarit **`instances/…`** via les routes **`office`** **`instance-layout-*`** (toujours visible pour les membres de l’office) ; la **fiche dossier** continue d’utiliser **`dp-layout-*`** par UID de dossier — distinction produit : [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](../features/MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md) § « Arborescence disque dans l’UI ».
**enso-front** : client `docvFetch` (`src/lib/docv/client.ts`) avec `NEXT_PUBLIC_DOCV_API_BASE` optionnelle (sinon `{origin}/docv-api`). Toute réponse **401** sur ce client (et sur l’upload binaire qui partage `assertDocvResponseOk`) enchaîne comme **`logout`** : effacement jeton + état OAuth, puis **`GET /oauth/sign-out`** avec **`return_url`** = **`/?signed_out=1`** (`invalidateLocalSessionAndGoHome`, `ensoSignedOutHomeReturnUrl`). Types domaine dans `src/lib/domain/types.ts`. Après lecture du JWT session, `enrichUserFromDocv` appelle **`GET /api/v1/me`** pour aligner nom, `id` et `email` sur la BDD. Les offices et dossiers affichés viennent de **`GET /api/v1/offices`** et **`GET /api/v1/folders`** via `fetchUserCompanies` / écrans (un seul enchaînement `GET /offices` côté catalogue). La fiche dossier (`/company/[id]/case/[caseId]`) enchaîne en parallèle **`GET /api/v1/offices/:uid`** et **`GET /api/v1/folders/:uid`** (`loadCasePage`) ; la demande de pièce côté cabinet utilise **`GET /api/v1/offices/:uid/members`** pour lister les clients (`role` métier). La liste complète des dossiers d’un office reste sur **`GET /api/v1/folders?office_uid=`** pour la page société et le catalogue ; la page société expose aussi **`POST /api/v1/folders`** (nouveau dossier). Sur la fiche dossier : **`PATCH /api/v1/folders/:uid`**, **`DELETE`** pièce, **`POST /api/v1/pending-documents`** / **`DELETE /api/v1/pending-documents/:id`** ; la messagerie appelle **`POST /api/v1/conversations/:id/messages`** puis refetch des listes. Le **`DocvStubListsProvider`** regroupe en un lot parallèle **`GET /api/v1/notifications`**, **`GET /api/v1/pending-documents`** et **`GET /api/v1/conversations`** pour dashboard, sidebar et messagerie (données persistées ; jeux démo optionnels via seed au démarrage).
**Checklists « documents attendus » (par `operation_type` slug)** : JSON statique dans **`enso/enso-front/src/lib/operationChecklists/`**, sans endpoint docv ; i18n sous **`case.operationChecklist.<slug>`**. Détail : [OPERATION_CHECKLISTS.md](../features/OPERATION_CHECKLISTS.md).
**Alignement doc installation :** contenu à reporter dans [INSTALLATION_ENVIRONNEMENT.md](../INSTALLATION_ENVIRONNEMENT.md) §4.2 (tableau + paragraphe Bearer / nginx) — voir le supplément consolidé [installation-docv-enso-front-supplement.md](../installation-docv-enso-front-supplement.md) et l’échantillon [patches/INSTALLATION_4.2_DOCV_FRAGMENT.md](patches/INSTALLATION_4.2_DOCV_FRAGMENT.md). **`enso/enso-front/.env.example`** documente `NEXT_PUBLIC_DOCV_API_BASE`.
**Cartographie fichier à fichier (handlers Rust ↔ modules Next) :** [features/DOCV_API_ENSO_FRONT_MAP.md](../features/DOCV_API_ENSO_FRONT_MAP.md) §1 — à mettre à jour lors de l’évolution de `api_v1.rs` ou des appels `docvFetch` (sans recréer de second tableau dans ce fichier).
---
## 4. Surface API par zone (synthèse)
Cette section est une **vision synthétique par zones** du socle générique docv ; elle **n’est pas** équivalente route par route à l’implémentation actuelle de **docv-back** dans ce dépôt. Pour les chemins réellement exposés et câblés avec enso-front, utiliser [DOCV_API_ENSO_FRONT_MAP.md](../features/DOCV_API_ENSO_FRONT_MAP.md) §1.
Endpoints principaux exposés par docv-back, regroupés par zone. Préfixe commun (ex. `/api/v1`) et authentification (Bearer ou session) à appliquer selon la config.
| Zone | Méthodes et chemins (synthèse) |
|------|--------------------------------|
| 1 — Auth | POST /auth/login, POST /auth/logout, GET /auth/me, PATCH /users/me, POST /auth/change-password |
| 5 — Offices | GET/POST/PUT /offices, GET /offices/:id, GET/PUT /offices/:id/rib, GET /collaborators, GET/PATCH /collaborators/:id, GET /users (scope office) |
| 6 — Rôles | GET/POST/PUT /roles, GET /roles/:id, GET/PUT (matrice permissions) |
| 4 — Types dossiers | GET/POST/PUT /folder-types, GET /folder-types/:id |
| 3 — Documents | GET/POST /folders/:folderId/documents, GET/PUT/DELETE /documents/:id, upload/download |
| 2 — Dossiers | GET/POST/PUT /folders, GET /folders/:id, POST /folders/:id/archive|restore, DELETE /folders/:id, GET /folders/archived, GET /folders/deleted |
| 7 — Partage | GET/POST/PATCH/DELETE /folders/:id/shares, POST /invitations, GET /invitations/:token |
| 8 — Notes / rappels | GET/POST/PATCH/DELETE /folders/:id/notes, GET/POST/PATCH/DELETE /reminders |
| 14 — Contenus | GET /site-texts/public?key=... |
| 13 — Admin plateforme | GET /super-admin/overview, GET/PATCH /super-admin/roles, GET/POST/PATCH /super-admin/plans, GET/POST/PATCH /super-admin/texts, GET/PATCH /super-admin/config |
| 9 — Abonnement | GET /subscription, POST /subscription/subscribe, PATCH /subscription, GET/PATCH /subscription/collaborators, POST /subscription/invites |
| 10, 11 — Client / invité | GET /client-dashboard/folders, GET /client-dashboard/folders/:id, POST /auth/invitee, GET /third-party/folders |
| 12 — Admin office | GET /admin/metrics (ou agrégation de endpoints existants) |
| 15 — Technique | GET/POST /anchor/verify (optionnel), GET /config/public (feature flags, config publique) |
Détail complet des paramètres, body et réponses : voir les [IMPL_xx](../features/implementation/README.md) correspondants.
---
## 5. Checklist Phase 1 (livrables)
### 5.1 Phase 1.1 — Backend docv (Rust)
- [ ] Projet Cargo docv-back avec structure (handlers, services, repositories, models, middleware, config, error, clients).
- [ ] Config : chargement DATABASE_URL, JWT_SECRET, ANCHORING_URL, IA_API_URL depuis l’env ; `.env.example` documenté.
- [ ] BDD : migrations pour toutes les tables zones 1–15 (ordre cohérent avec la section 3) ; pool de connexions au démarrage.
- [ ] Auth : POST /auth/login, POST /auth/logout, GET /auth/me ; génération et validation JWT (ou sessions) ; middleware auth sur routes protégées.
- [ ] Zones 1, 5, 6, 4, 3, 2, 7, 8, 14, 13, 9, 10, 12, 15 : handlers et services implémentés selon IMPL_01 à IMPL_15 ; endpoints documentés ou cohérents avec la section 4.
- [ ] Clients externes : anchoring_client et ia_client (stubs ou réels) ; appel uniquement depuis les services ; pas d’exposition au front.
- [ ] Erreurs : types typés, impl IntoResponse ; logging structuré (tracing) ; pas de fallback silencieux.
- [ ] Livrable : le service démarre, répond aux endpoints listés, lit/écrit la BDD, et consomme (ou stub) ancrage et IA côté back.
### 5.2 Phase 1.2 — Frontend docv
- [ ] Projet Next.js (ou équivalent) avec structure app/, components/, api/, i18n/, design-system/, stores/, hooks/, types/.
- [ ] Client API unique : base URL depuis env, header Authorization (Bearer), gestion 401 → redirect login ; pas d’appel direct ancrage/IA.
- [ ] Auth : pages login, logout-callback, my-account ; formulaire profil et changement mot de passe ; chargement user et office actif (context/store).
- [ ] Zones 2 à 15 : pages et composants pour chaque écran du [référentiel](../features/REFERENTIEL_ECRANS_ACTIONS.md) (zones 1–15) ; appels API vers docv-back uniquement.
- [ ] Design system : tokens (couleurs, typo, espacements), thème par défaut, composants de base (Button, Input, Table, Modal, etc.).
- [ ] i18n : clés structurées (auth.*, folders.*, …) ; fr.json et en.json avec textes par défaut.
- [ ] Paramétrage : chargement screen_config / action_config (GET /screen-config, /action-config ou équivalent) au login ; affichage conditionnel des menus et boutons selon la config.
- [ ] Livrable : front utilisable en autonomie sur la BDD et le back docv ; toutes les fonctionnalités des écrans zones 1–15 accessibles selon paramétrage.
### 5.3 Phase 1.3 — Données et paramétrage par défaut
- [ ] Seeds : rôles par défaut, matrice de permissions par défaut, types de documents et types de dossiers par défaut, textes site (clés legal.*, auth.*, …), configuration système (clés feature flags, options).
- [ ] Paramétrage : seeds ou migrations pour screen_config et action_config (identifiants stables des écrans et actions zones 1–15) ; résolution par office et rôle opérationnelle.
- [ ] Livrable : une instance docv déployée contient toutes les structures et données par défaut réutilisables pour enso.
---
## 5.4 OAuth2 — plusieurs clients et branding (docv-back)
Le binaire **docv-back** expose `/oauth/authorize`, `/oauth/sign-in` (formulaire HTML), **`/oauth/sign-out`** (effacement cookie session navigateur) et `/oauth/token`. Comportement actuel :
- **`OAUTH_CLIENT_ID`** : une liste d’identifiants clients séparés par des virgules (ex. `enso-web,autre-client`). Chaque valeur doit correspondre au `client_id` transmis par les applications (ex. enso-front). Le secret **`OAUTH_CLIENT_SECRET`** reste unique pour l’instant (tous ces clients partagent le même secret côté échange de code).
- **Branding de la page de connexion HTML** : fichier JSON versionné `docv/docv-back/tenants.default.json` (clé `default` + objet `clients` indexé par `client_id`). Les champs optionnels par client fusionnent avec `default`. Champs : `page_title`, `heading`, `subtitle`, `primary_color`, `accent_color`, `surface_color`, `text_color`, `submit_label`, `font_family` (couleurs en `#RRGGBB`, polices sans `<` `>` `;` pour limiter les injections CSS).
- Surcharge runtime : variable **`OAUTH_TENANTS_JSON`** (contenu JSON complet) ou **`OAUTH_TENANTS_PATH`** (chemin vers un fichier JSON). Si absent ou invalide, repli sur `tenants.default.json` embarqué.
- Le `client_id` est lu depuis le `return_url` interne (`/oauth/authorize?...&client_id=...`, y compris avec préfixe `/docv-api/...`) pour choisir le bloc `clients.<id>`.
- **`OAUTH_BROWSER_PATH_PREFIX`** (défaut **`/docv-api`**) : préfixe ajouté aux `Location` et au `action` du formulaire HTML pour `/oauth/sign-in` et au `return_url` stocké ; sans cela le navigateur résout `/oauth/…` sur l’hôte du front (404). Laisser vide uniquement si l’API OAuth est publiée à la racine du nom d’hôte.
- **`DOCV_USERS_PK_COLUMN`** : `id` (défaut, migrations `docv-back` actuelles) ou **`uid`** si la table `users` existante utilise `uid` comme clé primaire (schémas plus anciens / alignés IMPL).
- **Durées JWT / cookie et rattachement offices** : voir **[AUTH_SESSION.md](AUTH_SESSION.md)** (variable unique **`DOCV_OAUTH_ACCESS_TOKEN_TTL_SEC`**, options **`DOCV_DEMO_MEMBER_EMAILS`** et **`DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE`**).
---
## 6. Références
- [ARCHITECTURE_DOCV_DETAILLEE.md](../ARCHITECTURE_DOCV_DETAILLEE.md) — couches, responsabilités, structure back/front.
- [features/implementation/README.md](../features/implementation/README.md) — index des IMPL_01 à IMPL_15.
- [features/REFERENTIEL_ECRANS_ACTIONS.md](../features/REFERENTIEL_ECRANS_ACTIONS.md) — identifiants stables écrans et actions.
- [features/PARAMETRAGE_ECRANS_ACTIONS.md](../features/PARAMETRAGE_ECRANS_ACTIONS.md) — modèle de paramétrage.

72
services/docv/enso-docs/docv/README.md Normal file
View File

@ -0,0 +1,72 @@
# docv — Documentation projet (socle commun)
Point d’entrée de la documentation pour le projet **docv** (socle commun agnostique métier). docv porte les **zones 1 à 15** (authentification, offices, dossiers, documents, partage, abonnement, admin, contenus, technique et design) ; il n’a **pas** de zone 17 ni de spécifiques métier dédiés. **enso** hérite de docv.
**Architecture globale :** [ARCHITECTURE_DOCV_ENSO.md](../ARCHITECTURE_DOCV_ENSO.md) (section 3.1 docv).
**Plan de réalisation :** [PLAN_REALISATION_DOCV_ENSO.md](../PLAN_REALISATION_DOCV_ENSO.md) (Phase 1 — docv).
---
## 1. Périmètre docv
| Élément | Contenu |
|--------|---------|
| **Zones** | 1 à 15 uniquement (pas de zone 17). |
| **Fonctionnalités** | Auth et compte, dossiers, documents et types, types de dossiers, offices et membres, rôles et permissions, parties et partage, notes et rappels, abonnement et facturation, espaces client/invité, admin office, admin plateforme, contenus et paramètres, technique et design. |
| **API externes** | Consommées par **docv-back uniquement** : API ancrage (serveur services, api-anchorage), API IA (sous-module `ai`). Pas d’IdNot, API notaire, Mailchimp, OVH, Stripe. |
| **Spécifiques** | Aucun ; docv reste agnostique. Les spécifiques **enso** sont listés sous E1–E31. |
---
## 2. Documentation de référence pour docv
| Document | Usage |
|----------|--------|
| [AUTH_SESSION.md](AUTH_SESSION.md) | **Durées OAuth** (Bearer + cookie `docv_oauth_session`), **`office_members`** (filtre API des sociétés visibles), **espaces cabinet vs clients** et variables **`DOCV_*`** de test. |
| [IMPLEMENTATION.md](IMPLEMENTATION.md) | Détail d’implémentation : ordre des zones, stack, schéma BDD, surface API, checklist Phase 1. |
| [SCREENS_AND_FUNCTIONS_MAP.md](../SCREENS_AND_FUNCTIONS_MAP.md) | Cartographie écrans et actions (sections 1–15, 18.1–18.52). |
| [REFERENTIEL_ECRANS_ACTIONS.md](../features/REFERENTIEL_ECRANS_ACTIONS.md) | Liste exhaustive écrans et actions zones 1–15 (identifiants stables). |
| [specs/README.md](../features/specs/README.md) | Spécifications fonctionnelles par zone (SPEC_01 à SPEC_15). |
| [implementation/README.md](../features/implementation/README.md) | Implémentation technique par zone (IMPL_01 à IMPL_15). |
| [PARAMETRAGE_ECRANS_ACTIONS.md](../features/PARAMETRAGE_ECRANS_ACTIONS.md) | Modèle de paramétrage (écrans, actions, options). |
| [ARCHITECTURE_DOCV_DETAILLEE.md](../ARCHITECTURE_DOCV_DETAILLEE.md) | Architecture détaillée du socle docv (couches, BDD, API). |
---
## 3. Ordre de réalisation docv (Phase 1)
D’après le [plan de réalisation](../PLAN_REALISATION_DOCV_ENSO.md) (Phase 1) :
| Étape | Contenu | Livrable |
|-------|---------|----------|
| **1.1 Backend docv (Rust)** | Stack HTTP, PostgreSQL, migrations, schéma BDD agnostique, API REST (auth, CRUD dossiers/documents/membres/rôles, paramétrage, textes) ; consommation API ancrage et API IA côté back. | Service docv-back opérationnel. |
| **1.2 Frontend docv** | Stack front moderne (ex. Next.js), écrans zones 1–15, design system (tokens, thème, composants de base), appels API docv-back uniquement. | Front docv utilisable sur BDD et back docv. |
| **1.3 Données et paramétrage par défaut** | Seeds/migrations (rôles, permissions, types documents/dossiers, textes, system_configuration). | Instance docv déployée avec structures et données par défaut réutilisables par enso. |
Phase 0 (cadrage, règles Cursor, structure monorepo, sous-module `ai`) est un préalable à la Phase 1.
---
## 3bis. Comptes utilisateurs (réels uniquement)
Les comptes de connexion (**docv** / OAuth vers **enso**) doivent être **réels** : créés par les flux prévus du produit (inscription, invitation, admin plateforme / admin office selon les specs zones 1, 5, 12, 13, etc.), pas par seed applicatif, ni par utilisateurs mock, ni par script CLI d’insertion dédié au dépôt. Les migrations SQL décrivent le **schéma** (ex. table `users`) ; la **donnée** compte relève des processus métier et d’exploitation.
---
## 4. Structure cible docv (rappel)
- **docv-back** : Rust ; BDD PostgreSQL dédiée ; handlers/services zones 1–15 ; consommation API ancrage et API IA ; pas d’IdNot ni API notaire/Mailchimp/OVH/Stripe.
- **docv-front** : même stack que pour enso-front (ex. Next.js, TypeScript) ; design system (structure + défauts) ; écrans et actions zones 1–15 ; client API vers docv-back uniquement.
- **docv-shared** (optionnel) : crate Rust partagée (natif + WASM) pour validation, formatage, constantes, règles métier pures ; consommée par docv-back et docv-front (WASM).
---
## 5. Ordre de lecture recommandé pour implémenter docv
1. [ARCHITECTURE_DOCV_ENSO.md](../ARCHITECTURE_DOCV_ENSO.md) (sections 2bis, 2ter, 3.1) — API externes, socle IA, structure docv.
2. [ARCHITECTURE_DOCV_DETAILLEE.md](../ARCHITECTURE_DOCV_DETAILLEE.md) — couches, BDD, contrats API docv.
3. [IMPLEMENTATION.md](IMPLEMENTATION.md) — ordre d’implémentation par zone, stack, schéma BDD, surface API, checklist Phase 1.
4. [PLAN_REALISATION_DOCV_ENSO.md](../PLAN_REALISATION_DOCV_ENSO.md) (Phase 0 et Phase 1) — ordre des étapes 1.1, 1.2, 1.3.
5. [specs/README.md](../features/specs/README.md) et SPEC_01 à SPEC_15 — périmètre fonctionnel des zones 1–15.
6. [implementation/README.md](../features/implementation/README.md) et IMPL_01 à IMPL_15 — implémentation technique (routes, front, back, BDD).
7. [REFERENTIEL_ECRANS_ACTIONS.md](../features/REFERENTIEL_ECRANS_ACTIONS.md) — identifiants stables pour paramétrage (zones 1–15).

48
services/docv/enso-docs/enso/ORDRE_INTEGRATION_ZONE_17.md Normal file
View File

@ -0,0 +1,48 @@
# Ordre d’intégration — Zone 17 (ia_local) dans enso
Proposition d’ordre d’implémentation des sous-blocs de la zone 17 pour limiter les reprises et respecter les dépendances. Référence technique : [IMPL_17_ia_local.md](../features/implementation/IMPL_17_ia_local.md).
---
## 1. Prérequis
- **Zones 1 à 15** (docv) opérationnelles dans enso : auth, offices, rôles, dossiers (zone 2), documents (zone 3), partage (zone 7), paramétrage.
- **BDD enso** : schéma docv + tables zone 17 (establishments, tasks, alerts, debours, datarooms, messages, notifications, device_registrations, etc.) ; migrations et seeds créés.
- **API IA** (sous-module `ai`) et **API ancrage** accessibles depuis enso-back.
- **Spécifiques E1–E31** : au moins les blocs à implémenter en premier passés en statut **Confirmé** dans [SPECIFIQUES_PROJETS.md](../features/SPECIFIQUES_PROJETS.md).
---
## 2. Phases proposées
| Phase | Sous-blocs / actions | Dépendances | Remarque |
|-------|----------------------|-------------|----------|
| **1. Config** | 18.68 (établissements), 18.69 (admin-types) | Zones 1, 5 (admin office) | Base pour CRM, filtres, types documents/dossiers/tâches/alertes. |
| **2. Navigation et dashboard** | 18.81 (Explorer), 18.82 (recherche), 18.53 (dashboard) | Zones 2, 3, 7 | Squelette navigation ; dashboard agrège après phase 4–5. |
| **3. CRM** | 18.54 | Config, zones 2–3 | Clients, DP, dossiers ; utilise établissements et types. |
| **4. Tâches et planning** | 18.64 (tâches), 18.75 (planning) | Zones 2, 3 | Permet d’alimenter le dashboard (18.53). |
| **5. Débours et facturation** | 18.65 (débours), 18.70 (facturation débours) | Zones 2, 3 | Alimente aussi le dashboard. |
| **6. Partage et dataroom** | 18.58 (renvoi), 18.61 (data room), 18.59 (extraction dataroom) | Zone 7, 18.61 avant 18.59 | Renvoi dossier et data room ; extraction IA sur dataroom existant. |
| **7. Alertes** | 18.60 | Zones 2, 3, types (18.69) | Types d’alertes paramétrables. |
| **8. Workflow documentaire** | 18.63 | Zones 2, 3, 7 ; optionnel IA | Statuts documents, transitions par rôle. |
| **9. Communication** | 18.66 (messages), 18.67 (notifications), 18.62 (courriers IFU), 18.72 (mails semi-auto) | Zones 2, 3 | Fils de discussion, notifications, courriers. |
| **10. Actes et juridique** | 18.55, 18.56, 18.57, 18.71–18.74, 18.77, 18.78 | Zones 2, 3, API IA | Composition actes, mise à jour DP, secrétariat ; génération courriers/formalités/fiche prépa AG/listing annexes/devis. |
| **11. Intégrations et IA** | 18.79 (Outlook), 18.76 (organigramme), 18.80 (Chat IA) | 18.81 (Explorer) pour 18.80 | Chat IA utilise le contexte Explorer ; implémenter après Explorer stable. |
| **12. Compte** | 18.83 (appareils) | Zone 1 (auth) | Gestion appareils enregistrés (mon compte). |
---
## 3. Points d’attention
- **Dashboard (18.53)** : peut être livré en mode minimal après phase 2 (liens uniquement), puis enrichi après phases 4 et 5 (tâches, débours).
- **Explorer (18.81)** avant **Chat IA (18.80)** : le contexte « Montre-moi [rubrique] » depuis l’Explorer suppose l’arborescence et la sélection de contexte disponibles.
- **Config (phase 1)** : sans établissements et types (documents, dossiers, tâches, alertes, etc.), les écrans métier ne peuvent pas filtrer ni afficher correctement.
- **API IA** : nécessaire dès la phase 10 (actes, extraction, génération) et phase 11 (Chat, organigramme) ; les phases 1–9 peuvent être réalisées avec des stubs ou appels optionnels si l’API IA n’est pas encore prête.
---
## 4. Références
- [README.md](README.md) (point d’entrée enso)
- [IMPL_17_ia_local.md](../features/implementation/IMPL_17_ia_local.md) (détail technique par action)
- [SPEC_17_ia_local.md](../features/specs/SPEC_17_ia_local.md) (spec fonctionnelle zone 17)

108
services/docv/enso-docs/enso/README.md Normal file
View File

@ -0,0 +1,108 @@
# enso — Documentation projet (avocats)
Point d’entrée de la documentation pour le projet **enso** (déclinaison avocats). enso hérite du socle **docv** (zones 1 à 15) et ajoute les fonctionnalités **ia_local** (zone 17).
**Architecture globale :** [ARCHITECTURE_DOCV_ENSO.md](../ARCHITECTURE_DOCV_ENSO.md) (section 3.2 enso).
**Plan de réalisation :** [PLAN_REALISATION_DOCV_ENSO.md](../PLAN_REALISATION_DOCV_ENSO.md) (Phase 2 — enso).
---
## 1. Périmètre enso
| Source | Contenu |
|--------|---------|
| **docv (hérité)** | Zones 1 à 15 : authentification, offices, rôles, types de dossiers/documents, dossiers, documents, parties et partage, notes et rappels, abonnement, espaces client/invité, admin office, admin plateforme, contenus, technique et design. |
| **enso (spécifique)** | Zone 17 : tableau de bord métier, CRM, composition d’actes, mise à jour DP, secrétariat juridique, renvoi dossier, extraction dataroom, alertes, data room, courriers IFU, workflow documentaire, tâches, débours, messages, notifications, config établissements, types et configuration, facturation débours, courriers annexes, mails semi-auto, édition formalités, fiche prépa AG, planning des charges, organigramme, listing annexes, devis/lettre de mission, Outlook, Chat IA, Explorer, recherche globale, mon compte appareils. |
API externes consommées par **enso-back uniquement** : ancrage (serveur services, api-anchorage), IA (sous-module `ai`). Pas d’IdNot, Mailchimp, OVH, Stripe, API notaire.
---
## 2. Documentation de référence pour enso
| Document | Usage |
|----------|--------|
| [SCREENS_AND_FUNCTIONS_MAP.md](../SCREENS_AND_FUNCTIONS_MAP.md) | Cartographie écrans et actions (sections 1–17, 18.1–18.83). |
| [REFERENTIEL_ECRANS_ACTIONS.md](../features/REFERENTIEL_ECRANS_ACTIONS.md) | Liste exhaustive écrans et actions avec identifiants stables (zones 1–15 et 17). |
| [specs/README.md](../features/specs/README.md) | Spécifications fonctionnelles par zone (SPEC_01 à SPEC_17). Pour enso : toutes les specs 01–15 (docv) + **SPEC_17_ia_local** (spécifique enso). |
| [implementation/README.md](../features/implementation/README.md) | Description technique d’implémentation par zone (IMPL_01 à IMPL_17). Pour enso : IMPL_01–IMPL_15 (docv) + **IMPL_17_ia_local** (spécifique enso). |
| [PARAMETRAGE_ECRANS_ACTIONS.md](../features/PARAMETRAGE_ECRANS_ACTIONS.md) | Modèle de paramétrage (écrans, actions, options). |
| [SPECIFIQUES_PROJETS.md](../features/SPECIFIQUES_PROJETS.md) | Liste des spécifiques enso (E1–E31) ; statut de confirmation. |
| [FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md](../features/FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md) | Détail fonctionnel des fonctionnalités ia_local à intégrer dans enso. |
| [DOCV_API_ENSO_FRONT_MAP.md](../features/DOCV_API_ENSO_FRONT_MAP.md) | **Socle docv consommé par enso-front** : endpoint → handler Rust → fichier TS → écran (`/dashboard`, `/company/...`). |
| [OPERATION_CHECKLISTS.md](../features/OPERATION_CHECKLISTS.md) | Checklists métier (pièces attendues) par slug d’opération : JSON embarqué front, i18n, titre suggéré à la création de dossier ; pas d’API docv. |
---
## 3. Correspondance spécifiques enso (E1–E31) et zone 17
Les spécifiques listés dans [SPECIFIQUES_PROJETS.md](../features/SPECIFIQUES_PROJETS.md) (section 2) correspondent aux écrans et actions de la zone 17. Mapping pour implémentation :
| Spécifique | Identifiant écran (zone 17) | Actions 18.x | Spec / IMPL |
|------------|----------------------------|--------------|-------------|
| E1 Composition d’actes | ia.composition-actes | 18.55 | SPEC_17 / IMPL_17 |
| E2 Mise à jour DP | ia.mise-a-jour-dp | 18.56 | SPEC_17 / IMPL_17 |
| E3 Secrétariat juridique | ia.secretariat | 18.57 | SPEC_17 / IMPL_17 |
| E4 Renvoi de dossier | ia.renvoi-dossier | 18.58 | SPEC_17 / IMPL_17 |
| E5 Extraction dataroom | ia.extraction-dataroom | 18.59 | SPEC_17 / IMPL_17 |
| E6 Alertes fins de dossiers | ia.alertes | 18.60 | SPEC_17 / IMPL_17 |
| E7 Data room | ia.data-room | 18.61 | SPEC_17 / IMPL_17 |
| E8 Courriers IFU / RDPD DVD | ia.courriers-ifu | 18.62 | SPEC_17 / IMPL_17 |
| E9 Workflow documentaire | ia.workflow | 18.63 | SPEC_17 / IMPL_17 |
| E10 Tâches métier | ia.taches | 18.64 | SPEC_17 / IMPL_17 |
| E11 Débours | ia.debours | 18.65 | SPEC_17 / IMPL_17 |
| E12 Messages / Tchat | ia.messages | 18.66 | SPEC_17 / IMPL_17 |
| E13 CRM | ia.crm | 18.54 | SPEC_17 / IMPL_17 |
| E14 Configuration établissements | ia.config-etablissements | 18.68 | SPEC_17 / IMPL_17 |
| E15 Types et configuration | ia.admin-types | 18.69 | SPEC_17 / IMPL_17 |
| E16 Facturation débours | ia.facturation-debours | 18.70 | SPEC_17 / IMPL_17 |
| E17 Courriers annexes | ia.courriers-annexes | 18.71 | SPEC_17 / IMPL_17 |
| E18 Mails semi-auto | ia.mails-semi-auto | 18.72 | SPEC_17 / IMPL_17 |
| E19 Édition formalités | ia.edition-formalites | 18.73 | SPEC_17 / IMPL_17 |
| E20 Fiche prépa AG | ia.fiche-prepa-ag | 18.74 | SPEC_17 / IMPL_17 |
| E21 Planning des charges | ia.planning-charges | 18.75 | SPEC_17 / IMPL_17 |
| E22 Organigramme | ia.organigramme | 18.76 | SPEC_17 / IMPL_17 |
| E23 Listing annexes | ia.listing-annexes | 18.77 | SPEC_17 / IMPL_17 |
| E24 Devis / lettre de mission | ia.devis-lettre-mission | 18.78 | SPEC_17 / IMPL_17 |
| E25 Interfaçage Outlook | ia.outlook | 18.79 | SPEC_17 / IMPL_17 |
| E26 Chat IA | ia.chat | 18.80 | SPEC_17 / IMPL_17 |
| E27 Explorer | ia.explorer | 18.81 | SPEC_17 / IMPL_17 |
| E28 Recherche globale | ia.search | 18.82 | SPEC_17 / IMPL_17 |
| E29 Mon compte – appareils | ia.my-account-devices | 18.83 | SPEC_17 / IMPL_17 |
| E30 Thème / design enso | — | — | Configuration front (theme/, design-system) |
| E31 Textes et libellés avocat | — | — | Configuration i18n (structure docv + surcharges enso) |
E30 et E31 sont de la **configuration** (surcharges thème et i18n), pas des écrans supplémentaires. Tableau de bord métier (18.53) et notifications (18.67) couvrent les usages associés aux spécifiques.
---
## 4. Structure cible enso (rappel)
### 4.1 Répartition des API (docv d’abord, enso pour le spécifique)
| Couche | Rôle | Périmètre |
|--------|------|-----------|
| **docv-back** | API HTTP du **socle** (zones 1 à 15), réutilisable par **tous** les sites produits qui s’appuient sur docv | Auth, offices, rôles, dossiers, documents, partage, abonnement, admin, etc. — tout ce qui doit rester **commun et mutualisable**. |
| **enso-front** | Consomme en **priorité** les API **docv** (chemins publics type **`/docv-api/`** derrière reverse proxy) pour les fonctionnalités héritées du socle ; n’implémente côté Next que ce qui est propre au rendu (Route Handlers **`/api/*`** pour secrets serveur, BFF léger, OAuth token exchange, etc.). | Une nouvelle capacité **métier** exposée à plusieurs produits doit être **portée dans docv** (back + contrats), pas dupliquée dans enso-back. |
| **enso-back** | API **spécifique cabinet / projet enso** : zone **17** (ia_local), extensions ou agrégats réservés au périmètre avocats, intégrations (ancrage, IA) **côté serveur** quand elles ne doivent pas vivre dans docv. | Pas reconstituer dans enso-back ce que **docv-back** porte déjà pour les zones 1 à 15 ; enso-back complète docv pour le **différenciant** enso. |
En résumé : **fonctionnalités destinées à tous les sites** → **docv** ; **spécifique enso (cabinet)** → **enso-back** + front ; le front **enso** dialogue **au maximum** avec **docv-back** pour le cœur métier commun.
### 4.2 Composants et données
- **enso-front** : même stack que docv-front ; hérite design system docv ; surcharges `theme/`, `i18n/` ; pages et composants zone 17 (routes `/ia/*`, `/dashboard`, `/crm`, etc.) ; authentification utilisateur via OAuth2 **docv-back** (redirect `enso` → docv → retour `/auth/docv-callback`). Favicon : conventions Next.js dans `src/app/` — `icon.jpg` et `apple-icon.jpg`, copie du bandeau **`enso-logo-banner.jpg`** (même visuel que l’en-tête de l’application). **`next.config.js`** redirige **`/favicon.ico`** vers **`/icon.jpg`** pour les clients qui ne lisent que l’URL historique.
- **enso-back** : Rust, serveur HTTP **Axum** ; BDD enso (PostgreSQL, schéma dérivé docv + tables zone 17) ; handlers/services pour le **périmètre spécifique** (zone 17 et extensions cabinet) ; consommation API ancrage et API IA côté back uniquement, **en complément** des appels front → **docv-back** pour le socle. **Présence** : `GET /api/v1/enso/status` (JSON `service`, `ready`, `database`, réservés `anchoring` / `ia`) — [DOCV_API_ENSO_FRONT_MAP.md](../features/DOCV_API_ENSO_FRONT_MAP.md) §4, [PORTS_ENSO.md](../PORTS_ENSO.md).
- **Migrations et seeds** : structure docv + tables établissements, tâches, alertes, débours, datarooms, messages, notifications, etc. (voir [IMPL_17_ia_local.md](../features/implementation/IMPL_17_ia_local.md) section 4. Entités BDD).
---
## 5. Ordre de lecture recommandé pour implémenter enso
1. [ARCHITECTURE_DOCV_ENSO.md](../ARCHITECTURE_DOCV_ENSO.md) (section 3.2) — structure enso-front / enso-back.
2. [SPEC_17_ia_local.md](../features/specs/SPEC_17_ia_local.md) — périmètre fonctionnel zone 17.
3. [IMPL_17_ia_local.md](../features/implementation/IMPL_17_ia_local.md) — implémentation technique zone 17 (routes, front, back, BDD, actions 18.53–18.83).
4. [ORDRE_INTEGRATION_ZONE_17.md](ORDRE_INTEGRATION_ZONE_17.md) — ordre d’intégration des sous-blocs zone 17 (phases et dépendances).
5. [REFERENTIEL_ECRANS_ACTIONS.md](../features/REFERENTIEL_ECRANS_ACTIONS.md) — identifiants stables pour paramétrage (screen_config, action_config).
6. [SPECIFIQUES_PROJETS.md](../features/SPECIFIQUES_PROJETS.md) — confirmation des spécifiques E1–E31 avant implémentation.
Pour les zones 1–15 (socle docv), utiliser les SPEC_01 à SPEC_15 et IMPL_01 à IMPL_15 ; enso réutilise ou étend ces zones par configuration et par ajout des écrans zone 17.

33
services/docv/enso-docs/features/ANYTHINGLLM_DATAROOM_SYNC.md Normal file
View File

@ -0,0 +1,33 @@
# AnythingLLM : synchronisation avec `data/dossiers-permanents`
## Objectif
Sur la machine où tourne AnythingLLM, disposer d’un répertoire **à jour** contenant l’arborescence des dossiers permanents types (gabarits + miroirs d’uploads), aligné avec le dépôt Git poussé depuis le serveur web (ex. environnement test).
## Principe
1. **Clone** du même dépôt que l’application (ou d’un dépôt « data » miroir qui ne contient que `data/dossiers-permanents/`), sur un chemin stable, par ex. `/srv/enso` ou `$HOME/workspace/enso`.
2. **Workspace AnythingLLM** : pointer le dossier de documents du workspace vers :
- ` <clone>/data/dossiers-permanents/`
- ou un sous-dossier dédié (`instances/` uniquement) selon le besoin de contexte.
3. **Pull périodique** : tâche cron ou timer systemd exécutant :
```bash
cd /chemin/vers/clone && git pull --ff-only
```
Adapter la branche (`test`, `main`, etc.) selon l’environnement suivie par le serveur qui pousse.
## Correspondance dossier métier ↔ workspace
- Un **dossier applicatif** (folder UUID) peut référencer `folders.dp_layout_root` (ex. `instances/groupe_sci_is`) pour l’organisation fonctionnelle.
- Le workspace AnythingLLM peut couvrir **tout** le périmètre `data/dossiers-permanents/` ou un sous-arbre par client ; la doc métier [`IA_GRANDS_PRINCIPES.md`](IA_GRANDS_PRINCIPES.md) reste valable : les backends n’appellent pas AnythingLLM directement ; l’ingestion par workspace repose sur le contenu disque synchronisé par Git.
## Sécurité
- Le clone sur la machine IA ne doit pas contenir de secrets applicatifs (` .secrets/` non cloné ou ignoré).
- Restreindre les droits du compte qui exécute `git pull` au seul dépôt nécessaire.
## Après modification des gabarits
1. Développeur : `node tools/dp-seed/generate-dp-data.mjs` puis commit / push.
2. Serveur web (sync activée) : les nouveaux uploads ajoutent des fichiers sous `_uploads/` ou chemins mirroir ; commit/push selon [`DOSSIERS_PERMANENTS_DATA_GIT.md`](DOSSIERS_PERMANENTS_DATA_GIT.md).
3. Machine AnythingLLM : le prochain `git pull` recharge les documents du workspace.

42
services/docv/enso-docs/features/CHECKLIST_CESSION_JURIDIQUE_SOCIAL_FISCAL.md Normal file
View File

@ -0,0 +1,42 @@
# Checklist documents — projet de cession (juridique, social, fiscal)
## Objectif
Sur une **fiche dossier** dont le type d’opération est **cession** (`folders.operation_type = cession`), l’espace client affiche la **liste des documents attendus** alignée sur le référentiel cabinet fourni dans :
`docs/liste juridique social et fiscal client 10 2025.xlsx` (feuille **Feuil1**).
## Données côté front
- Fichier généré / maintenu : `enso/enso-front/src/lib/operationChecklists/data/cession.json`
- Registre et types : `enso/enso-front/src/lib/operationChecklists/` (voir [OPERATION_CHECKLISTS.md](OPERATION_CHECKLISTS.md))
- UI : `enso/enso-front/src/screens/case/CaseOperationChecklistCard.tsx` (affichage si `operation_type = cession`)
## Régénération après mise à jour du classeur
```bash
python3 -m venv .venv
.venv/bin/pip install openpyxl
.venv/bin/python3 tools/export_operation_checklist.py \
--input "docs/liste juridique social et fiscal client 10 2025.xlsx" \
--sheet Feuil1 \
--output enso/enso-front/src/lib/operationChecklists/data/cession.json \
--operation-type-slug cession
```
Puis contrôle visuel de la fiche dossier et commit du JSON.
## Légende (fichier source)
**DF** — document fourni ; **NA** — non applicable ; **DM** — document manquant ; **CO** — commentaire.
L’app ne gère pas encore de coches NA/DM par ligne : la checklist est **consultative** sur le périmètre actuel ; le suivi détaillé reste du ressort du cabinet (voir spec zone 18 — workflow documentaire).
## Création dossier « en cours »
Sur la page **société**, **Nouveau dossier** : en choisissant le type **Cession ou projet de cession**, le **titre** est proposé automatiquement (`Projet de cession — &lt;nom société&gt;`) s’il était vide, pour initialiser rapidement un dossier classé dans les dossiers actifs. La liaison slug → clé i18n est centralisée dans **`OPERATION_FOLDER_SUGGESTED_TITLE_I18N`** / **`suggestedFolderTitleMessagePath`** (`lib/operationChecklists/suggestedFolderTitles.ts`) — voir [OPERATION_CHECKLISTS.md](OPERATION_CHECKLISTS.md).
## Références
- Modèle société / dossier : [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md)
- Spec opération (évolution cible) : [specs/SPEC_18_operation.md](specs/SPEC_18_operation.md) §6 (documents attendus)

111
services/docv/enso-docs/features/DOCV_API_ENSO_FRONT_MAP.md Normal file
View File

@ -0,0 +1,111 @@
# Cartographie API docv-back ↔ enso-front
Document de liaison entre **les routes HTTP du socle** (`docv-back`) et **les modules / écrans enso** (`enso-front`).
À maintenir lors de l’ajout d’un endpoint sous `/api/v1/*` ou d’un nouvel appel `docvFetch`.
**Référence socle (migrations, Bearer, parcours UI) :** [docv/IMPLEMENTATION.md](../docv/IMPLEMENTATION.md) §3.1 — **sans** tableau exhaustif des routes dupliqué.
**Contrat front → backends :** [ENSO_FRONT_BACKEND_CONTRACT.md](ENSO_FRONT_BACKEND_CONTRACT.md).
**Client front :** `enso/enso-front/src/lib/docv/client.ts` (`docvFetch`).
**Types JSON :** `enso/enso-front/src/lib/domain/types.ts` (alignés sur les réponses docv).
**Vocabulaire métier (société = dossier permanent, `folder` = dossier d’opération) :** [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md).
---
## 1. Routes `/api/v1/*` (Bearer)
Le **tableau ci-dessous est la référence unique** des méthodes et chemins HTTP docv-back **câblés** avec le front (handler Rust, module TS, écran). Ne pas recopier ce tableau ailleurs : les autres documents renvoient ici.
Préfixe navigateur : `{origine}/docv-api` → nginx → docv-back.
Dispatch Rust : `docv/docv-back/src/server/mod.rs` → `api_v1::handle` → `docv/docv-back/src/server/api_v1.rs` ; **routage POST/DELETE factorisé** dans `server/v1_route.rs` ; **PATCH** dossiers + notifications traités dans `api_v1::handle`.
**Écritures** : `POST` / `PATCH` / `DELETE` avec corps JSON et `Content-Type: application/json` où indiqué.
| Méthode | Chemin | Handler docv-back (`api_v1.rs`) | Module / fonction enso-front | Où c’est utilisé (UI / flux) |
|--------|--------|----------------------------------|------------------------------|------------------------------|
| GET | `/api/v1/me` | `handle_me` | `lib/auth/enrichUserFromDocv.ts` → `docvFetch` | Après login : fusion profil JWT avec BDD (`contexts/auth/useAuthStateValue.ts`). |
| GET | `/api/v1/offices` | `handle_offices_list` | `lib/docv/fetchUserCompanies.ts` | `useOfficesCatalog` → barre latérale (`useAppSidebarData`), tableau de bord (`useDashboardData`). Exclut les offices avec **`archived_at`** non nul. JSON : champs optionnels **`parent_office_uid`**, **`archived_at`** (détail / liste alignés). |
| GET | `/api/v1/offices/:uid` | `handle_office_detail` | `lib/docv/loadOfficePage.ts`, `loadCasePage.ts` | Page société `app/company/[companyId]/page.tsx` (`CompanyDetail` ↔ `useOfficePageData`) ; contexte office sur page dossier. Réponse enrichie : **`permanent_documents[]`** (pièces **`folder_documents`** avec **`category = permanent`**, tout dossier de l’office) ; chaque élément peut inclure **`folderUid`** (dossier d’attache) pour **`PATCH …/workflow** côté UI permanents. |
| GET | `/api/v1/offices/:uid/comments` | `handle_office_comments_list` | `lib/docv/fetchOfficeComments.ts` | Fiche société — **`CompanyOfficeCommentsCard`** (liste commentaires). |
| POST | `/api/v1/offices/:uid/comments` | `handle_office_comments_create` | `lib/docv/postOfficeComment.ts` | Corps JSON : **`content`**, optionnel **`access_level`** (défaut `internal`). |
| GET | `/api/v1/offices/:uid/members` | `handle_office_members` | `lib/docv/fetchOfficeMembers.ts` | **Demander une pièce** (`CaseCabinetDocumentsCard`) ; filtre `role = client`. |
| GET | `/api/v1/folders?office_uid=` | `handle_folders_list` | `fetchUserCompanies.ts`, `loadOfficePage.ts` | Catalogue sociétés/dossiers ; liste dossiers sur la page **société**. JSON dossier : **`extends_permanent_record`** (bool). |
| GET | `/api/v1/folders/:uid` | `handle_folder_detail` | `lib/docv/loadCasePage.ts` | Page dossier : détail + **`documents[]`** (pièces `folder_documents`) en **un** appel (parallèle à `GET /offices/:uid`). Inclut **`extends_permanent_record`**, **`workflowState`** et **`folderUid`** par pièce (identique au dossier courant ; utile au mapping commun avec les permanents agrégés). |
| GET | `/api/v1/document-search?q=&limit=` | `handle_document_search` | `lib/docv/fetchDocumentSearch.ts` | Recherche de pièces dans les offices visibles (membre + filiales descendantes). Fiche dossier — ajout de **sources** (`CaseDetailSoclePanels`). |
| GET | `/api/v1/tasks?office_uid=&folder_uid=&status=` | `handle_tasks_list` | `lib/docv/fetchTasks.ts` | Liste tâches filtrées ; **`office_uid`** requis. Fiche dossier — panneau tâches. |
| POST | `/api/v1/tasks` | `handle_tasks_create` | `lib/docv/postTask.ts` | Corps JSON camelCase : **`officeUid`**, optionnel **`folderUid`**, **`title`**, **`description`**, **`status`**, **`assigneeUserUid`**, **`dueAt`**. |
| PATCH | `/api/v1/tasks/:uid` | `handle_tasks_patch` | `lib/docv/patchTask.ts` | Mise à jour partielle. |
| DELETE | `/api/v1/tasks/:uid` | `handle_tasks_delete` | `lib/docv/deleteTask.ts` | Suppression ; membre de l’**`office_uid`** de la tâche. |
| GET | `/api/v1/folders/:folderUid/document-sources` | `handle_folder_document_sources_list` | `lib/docv/fetchFolderDocumentSources.ts` | Sources (liens vers **`targetDocumentUid`**) ; nom cible joint quand la pièce existe. |
| POST | `/api/v1/folders/:folderUid/document-sources` | `handle_folder_document_sources_create` | `lib/docv/postFolderDocumentSource.ts` | Corps : **`targetDocumentUid`**, optionnel **`label`**. Cible dans un office visible (hiérarchie). **409** si doublon `(folder_uid, target_document_uid)`. |
| DELETE | `/api/v1/folders/:folderUid/document-sources/:sourceUid` | `handle_folder_document_sources_delete` | `lib/docv/deleteFolderDocumentSource.ts` | |
| GET | `/api/v1/folders/:folderUid/notes` | `handle_folder_notes_list` | `lib/docv/fetchFolderNotes.ts` | |
| POST | `/api/v1/folders/:folderUid/notes` | `handle_folder_notes_create` | `lib/docv/postFolderNote.ts` | Corps : **`content`**. |
| PATCH | `/api/v1/folders/:folderUid/notes/:noteUid` | `handle_folder_notes_patch` | `lib/docv/patchFolderNote.ts` | Auteur uniquement. Corps : **`content`**. |
| DELETE | `/api/v1/folders/:folderUid/notes/:noteUid` | `handle_folder_notes_delete` | `lib/docv/deleteFolderNote.ts` | Auteur uniquement. |
| PATCH | `/api/v1/folders/:folderUid/documents/:docUid/workflow` | `handle_patch_document_workflow` | `lib/docv/patchDocumentWorkflow.ts` | Corps : **`workflowState`** (`draft` \| `requested` \| `submitted` \| `validated` \| `rejected` \| `archived`). Transitions selon rôle membre (`client` vs cabinet). |
| POST | `/api/v1/ai/chat` | `handle_ai_chat` | `lib/docv/postAiChat.ts` | Forward JSON vers **`DOCV_AI_SERVICE_URL`** si défini ; sinon **503**. Garde-fou taille **`DOCV_AI_MAX_INPUT_CHARS`**. |
| POST | `/api/v1/ai/documents/:docUid/assist` | `handle_ai_document_assist` | *(non câblé UI v1 ; même forward que chat avec extrait fichier local si stockage disque)* | |
| GET | `/api/v1/folders/:folderUid/dp-layout-entries` + optionnel **`/{segments…}`** ou **`?path=`** | `handle_folder_dp_layout_entries` | `lib/docv/fetchFolderDpLayoutEntries.ts` (**suffix** : **`lib/docv/relativePathAsUrlSuffix.ts`** → **`encodeRelativePathAsUrlSuffix`**), `loadDpLayoutFolderEntries.ts` | Arborescence **lecture seule** sous **`dp_layout_root`** si **`folder_purpose = dp_structure_demo`** ou (**`client_operation`** avec **`operation_type = cession`**) et **`dp_layout_root` non vide**, membre de l’office. Chemin relatif : **recommandé** — suffixe d’URL après **`dp-layout-entries/`**, un segment encodé par composante (ex. `.../dp-layout-entries/foo/bar` pour `foo/bar`), pour éviter **`?path=a%2Fb`** que certains **reverse proxy** neutralisent. **Repli** : query **`path`** (encodée classiquement) si aucun segment supplémentaire. Vide = racine. Disque : **`DOCV_DP_GIT_REPO_ROOT`** / **`DOCV_DP_GIT_DATA_SUBPATH`** / `dp_layout_root` / chemin relatif. **503** si repo non configuré. JSON : `{ "path", "entries": [{ "name", "entry_type": "dir" \| "file" }] }` (dossiers triés avant fichiers ; **`entry_type`** dérivé de **`Path::is_dir` / `is_file`** pour suivre les **symlinks** vers répertoire ou fichier). UI : **`CaseDpLayoutExplorer`**. |
| GET | `/api/v1/folders/:folderUid/dp-layout-file` + optionnel **`/{segments…}`** ou **`?path=`** | `handle_folder_dp_layout_file` | `lib/docv/fetchFolderDpLayoutFile.ts` (**suffix** : **`encodeRelativePathAsUrlSuffix`**) | Mêmes droits que **`dp-layout-entries`**. Chemin relatif d’un **fichier** : suffixe après **`dp-layout-file/`** (segments encodés) **ou** query **`path`**. Extensions **`.md`**, **`.txt`**, **`.markdown`** ; taille max **512 KiB** ; corps UTF-8. JSON : `{ "path", "text" }`. **400** si dossier ou type non autorisé ; **404** si absent ; **413** si trop volumineux. UI : **`DpLayoutFilePreviewDialog`**. **Élargir les formats ou l’aperçu** (PDF, images, etc.) uniquement après **validation métier** explicite (risques contenu / perf / sécurité). |
| GET | `/api/v1/offices/:officeUid/instance-layout-entries` + optionnel **`/{segments…}`** ou **`?path=`** | `handle_office_instance_layout_entries` | `lib/docv/fetchOfficeInstanceLayoutEntries.ts` (**suffix** : **`encodeRelativePathAsUrlSuffix`**), `loadOfficeInstanceLayoutFolderEntries.ts` | Arborescence **lecture seule** au niveau **société** sous `data/dossiers-permanents/instances/`. Résolution racine (`resolve_office_instance_dp_root`) : **1)** premier dossier de l’office avec **`dp_layout_root`** égal à **`instances`** ou préfixe **`instances/`** (tout **`folder_purpose`**) ; **2)** sinon premier **`dp_archetype`** non vide → **`instances/<archetype>`** (segment sûr) ; **3)** sinon racine **`instances`** (arborescence type complète). Même format de chemin relatif et mêmes règles proxy que **`dp-layout-entries`**. **503** si repo non configuré. **403** si non membre de l’office. UI : **`CompanyInstanceLayoutExplorer`** (page société, toujours ; ligne « racine affichée » alignée sur la même logique que le serveur). |
| GET | `/api/v1/offices/:officeUid/instance-layout-file` + optionnel **`/{segments…}`** ou **`?path=`** | `handle_office_instance_layout_file` | `lib/docv/fetchOfficeInstanceLayoutFile.ts` | Mêmes droits et contraintes que **`dp-layout-file`**, pour la racine instance de l’office. UI : **`DpLayoutFilePreviewDialog`** avec **`layoutApiScope = office`**. |
| PUT | `/api/v1/folders/:folderUid/dp-layout-file` + optionnel **`/{segments…}`** ou **`?path=`** | `handle_put_folder_dp_layout_gabarit_file` | `lib/docv/putDpLayoutGabaritFile.ts` → **`putFolderDpLayoutGabaritFile`** | Corps JSON **`{ "text": "..." }`** (UTF-8, max **512 KiB**). Remplace le contenu d’un fichier **déjà existant** dont le nom est **`__GABARIT__.md`** ou se termine par **`.__TEMPLATE__.md`** (convention gabarits sous `data/dossiers-permanents/`). Mêmes droits que **`GET dp-layout-file`**. **`400`** `not_a_gabarit_file` si le nom ne correspond pas ; **`404`** si le fichier n’existe pas. Après écriture : **`git add` / `commit` / `push`** si **`DOCV_DP_GIT_SYNC`** (mutex **`dp_git_serial`**, comme les uploads miroir). Réponse **`{ "path", "saved": true }`**. UI : **`DpLayoutFilePreviewDialog`** (mode édition gabarit). |
| PUT | `/api/v1/offices/:officeUid/instance-layout-file` + optionnel **`/{segments…}`** ou **`?path=`** | `handle_put_office_instance_layout_gabarit_file` | `lib/docv/putDpLayoutGabaritFile.ts` → **`putOfficeInstanceLayoutGabaritFile`** | Idem **`PUT dp-layout-file`**, racine instance société. UI : **`DpLayoutFilePreviewDialog`** avec **`layoutApiScope = office`**. |
| POST | `/api/v1/folders` | `handle_create_folder` | `lib/docv/postCreateFolder.ts` | Corps JSON : `office_uid`, `title`, optionnel **`operation_type`**. Schéma sans **`folder_type_uid`** : insert minimal. Schéma IMPL (colonne présente) : **`ensure_folder_type_uid_for_api_create`** puis insert avec **`folder_type_uid`**, **`folder_purpose = client_operation`**, DP nuls. Page société — **Nouveau dossier** (`CompanyCasesTabsContent`). |
| PATCH | `/api/v1/folders/:uid` | `handle_patch_folder` | `lib/docv/patchFolder.ts` | Corps : `title`, `status`, optionnel **`operation_type`** (chaîne vide = effacer), optionnel **`extends_permanent_record`** (bool — opération qui complète le DP). **`folder_purpose`** non modifiable par API (réservé seed / démo). Fiche dossier — **Modifier** (`CaseDetailHeaderCard`). |
| POST | `/api/v1/folders/:uid/documents` | `handle_create_folder_document` | `lib/docv/postFolderDocument.ts` | Fiche dossier — repli **JSON** si stockage binaire indisponible (`CaseDocumentUploadForm`). |
| POST | `/api/v1/folders/:uid/documents/binary` | `handle_upload_folder_document_binary` | `lib/docv/uploadFolderDocumentBinary.ts` | Corps = **octets** du fichier ; en-têtes `X-Enso-Document-Name` (URL-encoded), `X-Enso-Document-Type`, `X-Enso-Category`, `X-Enso-Uploaded-By` ; optionnel **`X-Enso-Dp-Mirror-Relative-Path`** = chemin relatif sous `data/dossiers-permanents/` (sans `..` ; terminer par `/` pour cible répertoire + nom fichier issu de `X-Enso-Document-Name`). `Content-Type` = MIME. Requiert **`DOCV_FILE_STORAGE_DIR`** sur docv-back ; sinon **503** ; `storage_url` = chemin sous préfixe navigateur (`/docv-api/api/v1/files/:docUid`). Réponse pièce : champ optionnel **`dpMirrorPath`**. Miroir disque + `git add` / `commit` / `push` si **`DOCV_DP_GIT_SYNC`** et **`DOCV_DP_GIT_REPO_ROOT`** sont définis (voir `DOSSIERS_PERMANENTS_DATA_GIT.md`). |
| GET | `/api/v1/files/:docUid` | `handle_get_folder_document_file` | lien `storageUrl` (table pièces, **`DocumentPiecesTable`** → **`DocumentTableRow`** ; écrans **`CaseDocumentRows`** / **`CompanyDocumentTable`**) | Téléchargement du fichier stocké ; accès **membre du dossier** (Bearer). |
| DELETE | `/api/v1/folders/:uid/documents/:docUid` | `handle_delete_folder_document` | `lib/docv/deleteFolderDocument.ts` | Fiche dossier — retirer une pièce (liste cabinet / client) ; fichier disque supprimé si présent. |
| POST | `/api/v1/pending-documents` | `handle_create_pending_document` | `lib/docv/postPendingDocumentRequest.ts` | **Demander une pièce** (cabinet → membre `role=client`) ; notif `request_document` pour le destinataire. |
| DELETE | `/api/v1/pending-documents/:id` | `handle_delete_pending_document` | `lib/docv/deletePendingDocument.ts` | Tableau de bord — **Retirer** (`DashboardPendingPanel`) ; destinataire ou membre non-client de l’office. |
| POST | `/api/v1/conversations/:id/messages` | `handle_post_conversation_message` | `lib/docv/postConversationMessage.ts` | Messagerie — envoi (`useMessagingComposer`) ; persistance puis `refetch` listes. |
| GET | `/api/v1/notifications` | `handle_notifications_list` | `lib/docv/fetchDashboardStubs.ts` | `DocvStubListsProvider` (`loadStubListsOnce` / `useDocvStubLists`). |
| PATCH | `/api/v1/notifications/:id` | `handle_patch_notification_read` | `lib/docv/patchNotificationRead.ts` | Tableau de bord — marquer une notification comme lue (`DashboardNotificationEntry`). Corps JSON : `{ "isRead": true }` (ou corps vide, équivalent). |
| GET | `/api/v1/pending-documents` | `handle_pending_documents_list` | `fetchDashboardStubs.ts` | Idem. |
| GET | `/api/v1/conversations` | `handle_conversations_list` | `lib/docv/fetchConversations.ts` (via `fetchDashboardStubs`) | Idem. |
Les handlers SQL associés sont dans le même fichier `api_v1.rs`. Les événements (document, dossier, demande pièce) **insèrent** des `user_notifications` en excluant l’auteur et en **filtre rôle** : actions **client** → pairs **cabinet** (`role` ≠ `client`) ; actions **cabinet** → pairs **client** (`role` = `client`). Les **demandes pièce** ciblent une **notification dédiée** au `target_user_uid`.
---
## 2. OAuth2 et échange de token (hors `/api/v1`)
Le navigateur obtient un **code** sur docv (`/docv-api/oauth/authorize` → sign-in → callback enso). L’**access_token** (JWT `iss: docv-back`) est récupéré côté **serveur Next** pour ne pas exposer le `client_secret`.
| Flux | docv-back | enso-front |
|------|-----------|------------|
| Autorisation + session cookie | `server/mod.rs` : `handle_authorize`, `handle_sign_in_*` | `lib/oauth.ts`, `app/auth/docv-callback/page.tsx` |
| Échange code → token | `POST /oauth/token` (`handle_token` dans `server/mod.rs`) | `app/api/auth/docv-token/route.ts` → `lib/docvTokenExchange.ts` |
Le **Bearer** utilisé par `docvFetch` est ce jeton d’accès.
---
## 3. Zones fonctionnelles (specs / IMPL)
La surface **actuellement câblée** en prod test correspond au socle **zones 1 + 5 + 2** (auth/session implicite via OAuth, offices/membres, dossiers en lecture).
Pour le détail cible multi-écrans, rester aligné sur :
- [REFERENTIEL_ECRANS_ACTIONS.md](REFERENTIEL_ECRANS_ACTIONS.md)
- [implementation/IMPL_01_auth_compte.md](implementation/IMPL_01_auth_compte.md), [IMPL_05_offices_membres.md](implementation/IMPL_05_offices_membres.md), [IMPL_02_dossiers.md](implementation/IMPL_02_dossiers.md)
Les routes Next **enso** (`/company/...`, `/dashboard`) ne recopient pas les chemins génériques `app/(dashboard)/folders/...` des IMPL tant que l’UI avocat reste structurée par société et dossier : cette cartographie est la **vérité d’implémentation** courante côté enso-front.
---
## 4. enso-back (hors docv-api)
Préfixe : URL directe vers le service **enso-back** (port **3040** en déploiement type, voir [PORTS_ENSO.md](../PORTS_ENSO.md)) — pas de préfixe `/docv-api`.
| Méthode | Chemin | Réponse | Usage |
|--------|--------|---------|-------|
| GET | `/api/v1/enso/status` | JSON `service`, `ready`, `database` (`ok` \| `unavailable`), placeholders `anchoring` / `ia` (null tant non câblés) | Présence service zone 17 / spécifique ; `ready` exige une base joignable (`SELECT 1`). |
Les autres requêtes reçoivent encore une réponse texte **`ok`** (compatibilité sonde TCP / health).
## 5. Maintenance
- Toute nouvelle méthode ou chemin dans `api_v1::handle` : compléter **d’abord** le **tableau §1** (référence unique). [docv/IMPLEMENTATION.md](../docv/IMPLEMENTATION.md) §3.1 ne duplique plus ce tableau : y tenir **migrations**, **comportement Bearer / préfixe**, et le **récit des flux** enso-front si besoin.
- **Checklists « documents attendus » par type d’opération** : pas de route docv ; données **`lib/operationChecklists/data/*.json`** et i18n **`case.operationChecklist.*`** — tenir [OPERATION_CHECKLISTS.md](OPERATION_CHECKLISTS.md) à jour lors de l’ajout d’un slug ou d’un export Excel.
- Tout nouvel appel depuis `enso-front` : documenter ici et, si besoin, dans [INSTALLATION_ENVIRONNEMENT.md](../INSTALLATION_ENVIRONNEMENT.md) §4.2.
- Route ou contrat **enso-back** : mettre à jour le **tableau §4** et [ENSO_FRONT_BACKEND_CONTRACT.md](ENSO_FRONT_BACKEND_CONTRACT.md).

67
services/docv/enso-docs/features/DOSSIERS_PERMANENTS_DATA_GIT.md Normal file
View File

@ -0,0 +1,67 @@
# Dossiers permanents : données sur disque, Git et synchronisation
Référence pour l’arborescence versionnée sous [`data/dossiers-permanents/`](/data/dossiers-permanents/), le lien avec la base PostgreSQL (docv-back) et le flux Git vers les clones (AnythingLLM, CI locale, etc.).
## 1. Stratégie validée (monorepo)
- **Arborescence type** : dans ce dépôt, répertoire `data/dossiers-permanents/` (versionné).
- **Manifeste** : `data/dossiers-permanents/manifest.json` décrit l’arbre canonique (dérivé du dossier type métier ; archive zip locale non versionnée dans `docs/`).
- **Instances de démonstration** : `data/dossiers-permanents/instances/<id>/` — gabarits nommés `groupe_*`, `sous-groupe_*`, `filiale_*`, `entreprise_*` (segments `sci|commercial` × `is|ir`).
- **Dépôt Git dédié (option B)** : si le volume des binaires dépasse ce que le monorepo peut supporter, dupliquer uniquement `data/dossiers-permanents/` dans un dépôt séparé ; conserver le même schéma de chemins pour que les outils et la doc restent valides. **Git LFS** recommandé pour les pièces lourdes si tout reste dans le monorepo.
- **Branche et identifiants push** : sur serveur (ex. test), utiliser une **clé de déploiement** ou token en configuration **hôte / secrets déploiement** — ne pas committer de secrets ; ne pas modifier arbitrairement les `.env` des postes de dev (documenter les variables attendues uniquement).
## 2. Convention de nommage
Format logique : `{groupe|sous-groupe|filiale|entreprise}_{sci|commercial}_{is|ir}` (ex. `groupe_sci_is`, `filiale_commercial_ir`).
- **Filiales hétérogènes** : un même groupe type peut contenir des filiales aux juridiques / fiscaux différents ; la **forme** des dossiers reste celle du manifeste (sous-arborescence `sci` ou `commercial` selon le segment).
- **Sous-groupe** : même forme qu’un groupe, imbriqué sous `sous-groupes/<nom>/`.
## 3. Variables d’environnement (docv-back)
| Variable | Rôle |
|----------|------|
| `DOCV_DP_GIT_SYNC` | Si `1` ou `true`, tente un `git add` / `commit` / `push` après upload réussi (voir ci-dessous). |
| `DOCV_DP_GIT_REPO_ROOT` | Chemin absolu vers la racine du dépôt Git (souvent le clone du monorepo sur le serveur). |
| `DOCV_DP_GIT_DATA_SUBPATH` | Sous-chemin relatif depuis la racine (défaut : `data/dossiers-permanents`). |
| `DOCV_DP_GIT_REMOTE` | Nom du remote (défaut : `origin`). |
| `DOCV_DP_GIT_BRANCH` | Branche à pousser (optionnel ; si vide, pas de `push` ciblé — utilise branche courante du clone). |
**Déploiement (`deploy/scripts_v2`)** : `remote/sync-docv-deploy-opts-to-docv-env.sh` met à jour `docv/docv-back/.env` avec `DOCV_DP_GIT_REPO_ROOT` = racine du clone sur la cible (`ENSO_REMOTE_ROOT`) lorsque la variable n’est pas fournie côté déploiement, et `DOCV_DP_GIT_DATA_SUBPATH` (défaut `data/dossiers-permanents`). `DOCV_DP_GIT_SYNC`, `DOCV_DP_GIT_REMOTE`, `DOCV_DP_GIT_BRANCH` ne sont écrites que si non vides. Voir `deploy/enso-deploy.env.example` et `deploy/scripts_v2/deploy.sh` (exports SSH).
Upload binaire existant : `DOCV_FILE_STORAGE_DIR` (fichiers servis par UUID). En complément :
| En-tête HTTP | Rôle |
|--------------|------|
| `X-Enso-Dp-Mirror-Relative-Path` | Chemin **relatif** sous `DOCV_DP_GIT_DATA_SUBPATH` (sans `..`) où une copie du fichier est écrite pour Git / AnythingLLM (défaut si sync actif : `_uploads/<folder_uid>/<sanitized_name>`). |
## 4. Cohérence BDD ↔ disque
- Table `folders` : `dp_archetype`, `dp_layout_root` (ex. `instances/groupe_sci_is`).
- Table `folder_documents` : `dp_mirror_path` (chemin relatif sous `data/dossiers-permanents/` vers la copie « lisible »).
**Lecture navigateur (enso-front + docv-back)** : au niveau **société**, **`GET /api/v1/offices/:officeUid/instance-layout-entries`** (et **`instance-layout-file`**) sert à parcourir le référentiel **`instances/`** pour tout membre de l’office ; la racine disque est résolue sans exiger un dossier **`dp_structure_demo`** seul (voir [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md) et [DOCV_API_ENSO_FRONT_MAP.md](DOCV_API_ENSO_FRONT_MAP.md)). Au niveau **d’un dossier**, le parcours reste **`GET /api/v1/folders/:folderUid/dp-layout-*`**.
Les migrations appliquent les colonnes au démarrage de docv-back (même mécanisme que les migrations folder_documents existantes).
## 5. Concurrence et limites
- **docv-back** sérialise les opérations **miroir disque + `git add` / `commit` / `push`** pour un même processus via un mutex async (`AppState.dp_git_serial`), ce qui limite les courses entre requêtes concurrentes.
- Des conflits restent possibles si plusieurs instances de docv-back ou d’autres acteurs modifient le même dépôt ; une file dédiée ou une branche par office peut compléter ce dispositif.
- Le push échoue si le clone n’a pas de remote configuré ou sans droits ; l’upload API reste réussi si l’écriture disque + BDD ont réussi — l’échec Git est **journalisé** (`warn`).
## 6. Régénérer les instances et le manifeste
Depuis la racine du dépôt (Node ≥ 18) :
```bash
node tools/dp-seed/generate-dp-data.mjs
```
Prérequis : liste d’entrées zip `tools/dp-seed/_zip_all_paths.txt` (générée par `unzip -Z1 docs/5-DOSSIER\ TYPE\ INFORMATIQUE.zip > tools/dp-seed/_zip_all_paths.txt` lorsque l’archive est présente localement).
## 7. Références
- Plan produit : dataroom / DP dans [`FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md`](FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md) §5.
- Principes IA / workspace : [`IA_GRANDS_PRINCIPES.md`](IA_GRANDS_PRINCIPES.md).
- Procédure clone AnythingLLM : [`ANYTHINGLLM_DATAROOM_SYNC.md`](ANYTHINGLLM_DATAROOM_SYNC.md).

55
services/docv/enso-docs/features/ENSO_FRONT_BACKEND_CONTRACT.md Normal file
View File

@ -0,0 +1,55 @@
# Contrat front enso-front → backends (audit)
Document vivant : **priorité front** ; les évolutions d’API sont pilotées par les écrans, la doc suit.
**Carte détaillée docv HTTP :** [DOCV_API_ENSO_FRONT_MAP.md](DOCV_API_ENSO_FRONT_MAP.md)
## 1. Appels `docvFetch` → docv-back (`/docv-api`)
**Liste exhaustive des routes `/api/v1/*`**, handlers, modules TS et écrans : [DOCV_API_ENSO_FRONT_MAP.md](DOCV_API_ENSO_FRONT_MAP.md) §1 (référence unique, non dupliquée ici).
**OAuth** (hors `docvFetch` navigateur direct) : authorize + `POST` token via Next `docv-token`.
**Déconnexion** : `logout` efface jeton + état OAuth (`sessionStorage`), puis **redirige vers** **`GET {docv}/oauth/sign-out?return_url=<origin>/?signed_out=1`** afin d’effacer le cookie HttpOnly **`docv_oauth_session`** (sans quoi `/oauth/authorize` pouvait encore délivrer un code sans mot de passe). **`/`** redirige vers **`/dashboard?signed_out=1`** ; **`ProtectedRoute`** propage **`signed_out=1`** jusqu’à **`/login?signed_out=1`**. **`LoginPageInner`** n’enchaîne pas le SSO tout de suite ; relance automatique après un court délai ou bouton manuel. Même **`return_url`** pour une **401** docv (`invalidateLocalSessionAndGoHome`). Les **durées** et **sign-out** sont détaillés dans **[docv/AUTH_SESSION.md](../docv/AUTH_SESSION.md)**.
| Ressource | Rappel |
|-----------|--------|
| docv métier (`/docv-api` + `/api/v1/…`) | Voir tableau §1 de la carte API ; persistance : tables `users`, `offices`, `office_members`, `folders`, `folder_documents`, listes utilisateur (`user_notifications`, `user_pending_documents`, `user_conversations`, `conversation_messages`). |
**Données hors backends** : les **checklists « documents attendus »** par type d’opération (`lib/operationChecklists/data/*.json`) ne passent ni par docv ni par enso-back ; le front les affiche selon `folders.operation_type` (slug). Voir [OPERATION_CHECKLISTS.md](OPERATION_CHECKLISTS.md).
## 2. Types JSON attendus par le front (camelCase)
- **Company** (modèle UI après `officeAndFoldersToCompany`) : champs office + dossiers ; **`organizationArchetypes`** = liste triée des **`dp_archetype`** distincts des dossiers (types d’organisation DP : groupe / filiale / SCI · commercial · IS / IR), pour affichage « Types d’organisation » sur le tableau de bord, la fiche société et la sidebar.
- **Chargement dashboard** : le catalogue **`GET /api/v1/offices`** et les stubs (notifications, pending, conversations) ne doivent **pas** être bloqués sur l’objet **`user`** React encore `null` alors que le jeton est déjà en session — le filtre d’appel est la présence du **Bearer** (`useOfficesCatalog`, `useDocvStubListsState`).
- **Notification** : `id`, `type` (`new_document` \| `request_document` \| `case_update`), `message`, `companyId`, `companyName`, `caseId?`, `createdAt`, `isRead`.
- **PendingDocument** : `id`, `name`, `description`, `companyId`, `companyName`, `caseId`, `caseName`, `requestedAt`, `dueDate?`.
- **Conversation** : `id`, `contactName`, `contactRole`, `lastMessage`, `lastMessageAt`, `unreadCount`, `messages[]`
**Message** : `id`, `senderId`, `senderName`, `senderRole` (`client` \| `cabinet`), `content`, `createdAt`, `isRead`.
Les handlers docv-back sérialisent en **camelCase** pour ces trois ressources en **réponse**.
**Corps `POST /api/v1/pending-documents`** (aligné docv-back, **snake_case** dans le JSON) : `target_user_uid`, `office_uid`, `case_uid`, `name`, `description`, optionnellement `case_name`, `due_date`.
**Corps `POST /api/v1/folders/:uid/documents`** : `name`, `type`, `category`, `uploaded_by`, `size` (conventions actuelles du client) ; optionnel **`storage_url`**, **`mime_type`**.
**`POST /api/v1/folders/:uid/documents/binary`** : corps brut = fichier ; métadonnées en en-têtes `X-Enso-*` (voir [DOCV_API_ENSO_FRONT_MAP.md](DOCV_API_ENSO_FRONT_MAP.md) §1), optionnel **`X-Enso-Dp-Mirror-Relative-Path`** ; activé si **`DOCV_FILE_STORAGE_DIR`** est défini ; réponse pièce peut inclure **`dpMirrorPath`** (camelCase). Sync Git : `DOCV_DP_GIT_*` — [DOSSIERS_PERMANENTS_DATA_GIT.md](DOSSIERS_PERMANENTS_DATA_GIT.md).
**`GET /api/v1/folders/:uid`** : champs dossier optionnels snake_case **`dp_archetype`**, **`dp_layout_root`** (alignés sur docv-back `FolderJson`).
**Arborescence DP sur disque** : listing et fichier texte — **`GET /api/v1/folders/:folderUid/dp-layout-entries`** / **`dp-layout-file`** (périmètre **dossier**) ; **`GET /api/v1/offices/:officeUid/instance-layout-entries`** / **`instance-layout-file`** (périmètre **société**, racine sous **`instances/`** résolue côté serveur pour tout membre d’office, sans filtre **`dp_structure_demo`** seul — voir carte API §1).
**Corps `POST /api/v1/conversations/:id/messages`** : `content` (chaîne).
**`PATCH /api/v1/notifications/:id`** : `{ "isRead": true }` pour enregistrer la lecture côté BDD (notification appartenant à l’utilisateur Bearer). Corps vide accepté (comportement identique à `isRead: true`).
## 3. enso-back (zone 17 / spécifique)
Le front **ne consomme pas encore** d’JSON métier enso-back dans le socle actuel ; les appels Next `/api/*` concernent surtout OAuth.
Point d’entrée de présence : **`GET /api/v1/enso/status`** sur le port enso-back (voir [PORTS_ENSO.md](../PORTS_ENSO.md)) — JSON : `service`, `ready`, `database`, champs réservés `anchoring` / `ia` (null tant que non intégrés). **`ready`** est vrai lorsque le pool PostgreSQL répond à `SELECT 1`.
## 4. Prochaines évolutions (hors ce lot)
- Stockage objet (S3 / pré-signé) ou réplication hors disque local du répertoire **`DOCV_FILE_STORAGE_DIR`**.
- Appels enso-front → enso-back pour zone 17 quand les routes existent.

134
services/docv/enso-docs/features/FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md Normal file
View File

@ -0,0 +1,134 @@
# Fonctionnalités issues du projet ia_local à intégrer (enso)
Ce document liste les fonctionnalités décrites dans le projet **ia_local** (`/home/desk/code/ia_local`) — site web et documentation fonctionnelle — à intégrer dans le projet **enso**. Le projet ia_local est arrêté ; on ne reprend pas l’implémentation existante, uniquement le périmètre fonctionnel.
**Sources :** `ia_local/docs/FONCTIONNALITES_ATTENDUES.md`, `ia_local/docs/UX_UI_SPECIFICATIONS.md`, `ia_local/docs/WORKFLOWS.md`, `ia_local/docs/CLIENT_FOLDERS.md`, `ia_local/docs/DATAROOM_FOLDERS.md`, et le site web `ia_local/code/web` (écrans « Aller à »).
---
## 1. Fonctionnalités métier par priorité (référence ia_local)
### Priorité maximale
| Fonctionnalité | Description fonctionnelle |
|----------------|---------------------------|
| **Extraction de données pour rédaction d’actes** | Extraction à partir d’Excel, PDF, JPG pour la rédaction d’actes de cession : listes salariés (qualification, rémunération, ancienneté), synthèse contrats, baux commerciaux, OCR baux, données de loyer, identification sociétés (KBIS), conventions intragroupe. |
| **Mise à jour DP (Dossier Permanent)** | Mise à jour automatique du dossier permanent à partir de documents PDF : KBIS, PV d’AG, baux, conventions intragroupe, pactes Dutreil, feuille de présence, mandat effet posthume, registre de mouvement de titres, statuts. |
| **Secrétariat juridique** | Prérédaction des AG à partir du dossier N-1 ou trame vierge ; intégration des données chiffrées (comptes PDF/EDI) ; affectation du résultat ; alertes (réserve légale, perte 1/2 capitaux propres, seuils CAC, consolidation, fin de mandat CAC) ; priorisation rapport de gestion et résolutions/PV ; rapport spécial ; convocations et publipostage. |
| **Renvoi de dossier clients (partage d’espace)** | Partage de documents avec les clients, la comptabilité, les CAC. |
| **Extraction de données de la dataroom** | Synthèse des pièces de la dataroom ; rapport d’audit avec caractéristiques principales (condition et durée bail, loyer, durée et montant emprunts, date CRD, etc.). |
| **Outil d’alerte sur les fins de dossiers** | Compilation des durées de vie des sociétés, expirations (baux, marques, pactes Dutreil, mandats CAC et dirigeants, rapports d’imposition) ; liste par date d’échéance et type ; notifications à l’associé et au collaborateur concerné. |
| **Data room** | Espace de partage de documents avec droits (dépôt, suppression, modification, copie) ; notification à chaque nouveau dépôt ; fermeture d’accès après délai ; pré-liste de pièces à fournir et relance sur pièces manquantes ; tri/filtres par tag ; sous-dossiers selon volume. |
| **Courriers renvois IFU avec croisement RDPD DVD** | Extraction PDF RDPD DVD (distributions de l’année), intégration des sociétés dans la base du cabinet, publipostage des courriers de renvoi ; ou intégration directe des IFU pour classement automatique (recoupement SIRET). |
### Priorité moyenne
| Fonctionnalité | Description fonctionnelle |
|----------------|---------------------------|
| **Interfaçage des mails (Outlook / dossier client)** | Relier les mails depuis Outlook au dossier client concerné. |
| **Courriers annexes aux cessions** | Lettre d’information salariés (bulletins de salaire), urbanisme et préemption, bailleur, fin de séquestre, courrier renvoi chèque de séquestre (tableau oppositions). |
| **Facturation de débours** | Transmission dématérialisée des débours ; réception et affectation à un dossier par le collaborateur ; réception par la comptabilité ; comparaison provision / débours engagés en temps réel ; alerte dépassement ; tableau de synthèse ; en fin de dossier, renvoi de la facture pour validation au collaborateur. |
### Priorité faible ou complémentaire
| Fonctionnalité | Description fonctionnelle |
|----------------|---------------------------|
| **Envoi de mails ou courrier semi-auto pour alertes** | Alertes (déclaration plus-value, report d’imposition, expiration baux/marques) avec notification 1 à 6 mois à l’avance ; mail pré-rédigé proposé. |
| **Édition des pièces de formalités** | Pouvoir, déclaration de non-condamnation, 2759, LAB, extrait PV, autorisation de domiciliation, mise à jour statuts (remplacement d’articles), courriers de cession de fonds. |
| **Fiche de prépa AG pour groupe** | Données N-1, N-2, N-3 (dividendes, résultats), données N (résultats), convention intragroupe et rémunération dirigeants, date fin de mandat CAC et dirigeant. |
| **Workflow (calendrier d’opération)** | Dates limites pour les tâches (séquestres, envoi convocation, etc.) ; chaque étape workflow documentaire (à_demander, demandé, reçu, validé, refusé) liée à au moins une tâche. |
| **Planning des charges** | Affectation de tâches à un collaborateur ; liste des tâches à traiter avec échéances et état d’avancement par collaborateur. |
| **Organigramme** | Réalisation d’organigrammes à partir des feuilles de présence ou des statuts. |
| **Listing d’annexes et intercalaires** | Reprise des annexes citées dans un acte ; liste et intercalaire par annexe ; compilation automatique des annexes en PDF. |
| **Devis ou lettre de mission** | Création automatique de devis ou lettre de mission. |
| **Édition collaborative (OnlyOffice ou équivalent)** | Rédactions des actes en mode collaboratif. |
---
## 2. Écrans / vues du site web ia_local (à aligner avec la cartographie enso)
Écrans accessibles via le sélecteur « Aller à » et la navigation :
| Écran (valeur route) | Libellé | Zone |
|----------------------|--------|------|
| `dashboard` | Tableau de bord | Vue d’ensemble (tâches en cours, débours) |
| `mon-compte` | Mon compte | Compte utilisateur (profil, appareils) |
| `crm` | CRM (Clients, DP, Dossiers) | Vue d’ensemble clients et dossiers permanents |
| `composition-actes` | Composition d’actes | Rédaction d’actes |
| `mise-a-jour-dp` | Mise à jour DP (Dossier Permanent) | Mise à jour dossier permanent |
| `secretariat-juridique` | Secrétariat juridique | AG, PV, résolutions |
| `renvoi-dossier` | Renvoi de dossier (partage) | Partage avec clients / CAC / comptabilité |
| `extraction-dataroom` | Extraction données dataroom | Synthèse pièces dataroom |
| `alertes` | Alertes fins de dossiers | Alertes échéances (baux, mandats, etc.) |
| `data-room` | Data room | Espace partagé, droits, invitations |
| `courriers-ifu` | Courriers renvois IFU / RDPD DVD | Courriers fiscaux |
| `workflow` | Workflow documentaire | Documents par statut (à demander, demandé, reçu, validé, refusé) |
| `taches` | Tâches | Tâches par dossier, échéances |
| `debours` | Débours | Débours par dossier, validation |
| `messages` | Messages / Tchat | Fil de discussion par contexte |
| `notifications` | Notifications | Liste des notifications (lu / non lu) |
| `configuration-etablissements` | Configuration établissements | Admin : établissements (associé) |
| `admin-types` | Types et configuration | Admin : types (documents, dossiers, tâches, alertes, rôles, etc.) |
| `facturation-debours` | Facturation de débours | Workflow facturation débours |
| `courriers-annexes` | Courriers annexes aux cessions | Courriers types cessions |
| `mails-semi-auto` | Mails ou courrier semi-auto | Envoi semi-automatique pour alertes |
| `edition-formalites` | Édition des pièces de formalités | Génération pièces formalités |
| `fiche-prepa-ag` | Fiche prépa AG groupe | Préparation AG groupe |
| `planning-charges` | Planning des charges | Répartition et suivi des tâches |
| `organigramme` | Organigramme | Visualisation organigramme (actionnariat / structure) |
| `listing-annexes` | Listing annexes et intercalaires | Liste et PDF des annexes |
| `devis-lettre-mission` | Devis / lettre de mission | Génération devis et lettres de mission |
| `outlook` | Interfaçage Outlook | Lien mails / dossier client |
**Navigation complémentaire :** Explorer (arborescence Commun / Datarooms), Chat IA (panneau droit), recherche globale (texte et tags), filtres (établissement, dossier, client, dates), sélecteur de membre (filtrer les vues par membre), barre de contexte (Tâches, Alertes, Inviter) sur un dossier ouvert.
---
## 3. Workflow documentaire (référence ia_local)
- **Statuts canoniques :** à_demander → demandé → reçu → validé | refusé.
- **Transitions par rôle :** Collaborateur (demander, relancer, réceptionner) ; Avocat / Validateur (valider, refuser) ; Associé / Avocat (archiver) ; Associé (supprimer).
- **Tâches liées :** chaque type de tâche (demande document, relance, réception, extraction données, rédaction PV/acte/statuts/pacte, due diligence, validation document, formalité, mise à jour DP) est associé à une étape du workflow et peut mettre à jour le statut du document à la clôture.
- **Alertes et notifications :** types d’alertes (expiration KBIS, pacte Dutreil, fin bail, échéance AG, signature, échéance tâche) ; notifications (changement statut, relance, dépôt dataroom, partage, mention, alerte échéance, info système).
---
## 4. Dataroom (référence ia_local)
- **Lien** vers un chemin métier (établissement, dossiers permanents, société, DP) avec droits en surcharge (viewer / editor).
- **Invitation** : ajout de membres avec rôle (viewer / editor), date de fin d’accès optionnelle.
- **Documents attendus** : configuration par type (workflow, alertes, durée de conservation, motivation collecte).
---
## 5. Dossiers permanents et structure client (référence ia_local)
- Organisation par type de client : groupe (SCI IR/IS, sociétés commerciales SAS/SARL) ou sociétés hors groupe.
- Structure type par société : Baux, Conventions intragroupe, Dossier permanent (KBIS, statuts, PV AG, registre, etc.), Secrétariat (AGO, comptes annuels, convocations, dividendes, formalités, etc.), Facturations, Options fiscales, Correspondances, etc.
- Les dossiers types (grandes activités, dossiers permanents) définissent le contenu attendu et les configurations (workflow, alertes, rôles, membres en cascade).
---
## 6. Rôles et espaces (référence ia_local)
- **Rôles internes :** Associé (établissement complet), Avocat (grandes activités + dossiers permanents), Collaborateur (dossiers avec tâches assignées), Comptabilité (débours), Admin système / RSSI / CNIL / Support (alertes), Backup / IA (health check).
- **Rôles client / confrère / tiers / validateur :** accès aux tableaux documents, notifications, alertes, tchat selon périmètre.
- **Rôle validateur :** tableau des documents à valider (reçu → validé / refusé).
- **Rôle espionnage_etat :** export des messages/tchats par établissement ou dossier (usage encadré).
- **Rôles API :** configuration des clés API uniquement.
---
## 7. Synthèse : ajouts par rapport à la cartographie docv/enso actuelle
À intégrer dans la cartographie des écrans et des actions enso :
- **Écrans métier spécifiques avocat :** Composition d’actes, Mise à jour DP, Secrétariat juridique, Renvoi dossier (partage), Extraction dataroom, Alertes fins de dossiers, Data room, Courriers IFU, Workflow documentaire (vue par statut), Tâches, Débours, Messages/Tchat, Notifications.
- **Admin :** Configuration établissements, Types et configuration (documents, dossiers, tâches, alertes, rôles, grandes activités, etc.).
- **Outils IA / complémentaires :** Facturation débours, Courriers annexes, Mails semi-auto, Édition formalités, Fiche prépa AG, Planning des charges, Organigramme, Listing annexes, Devis/lettre de mission, Interfaçage Outlook.
- **Navigation :** Explorer (Commun / Datarooms), Chat IA contextuel, recherche globale avec filtres, sélecteur de membre, barre de contexte dossier (Tâches, Alertes, Inviter).
- **Workflow documentaire :** statuts et transitions par rôle, lien tâches ↔ statut document, alertes et notifications associées.
- **Dataroom :** droits viewer/editor, invitation, date de fin d’accès, documents attendus.
- **Mon compte :** gestion des appareils (en plus du profil).
Ces éléments sont à fusionner avec les sections existantes de `docs/SCREENS_AND_FUNCTIONS_MAP.md` (écrans et liste des actions par écran) pour la déclinaison enso.

54
services/docv/enso-docs/features/I18N_ENSO_FRONT.md Normal file
View File

@ -0,0 +1,54 @@
# Internationalisation (enso-front)
## Catalogues et locale
- **Référence des clés** : `enso/enso-front/src/i18n/messages.fr.ts` (littéraux `as const`). Les chemins valides pour `translate()` / `t()` sont typés via `MessagePath` (`enso/enso-front/src/i18n/messagePath.ts`).
- **Second catalogue** : `enso/enso-front/src/i18n/messages.en.ts`, même forme typée avec `MessageCatalog` (`DeepStringMap` dans `messages.fr.ts`).
- **Locale par défaut (sans stockage)** : `DEFAULT_LOCALE` (`fr`) dans `enso/enso-front/src/i18n/catalog.ts`.
- **Préférence utilisateur** : `enso/enso-front/src/i18n/localeStorage.ts` — clé `localStorage` `APP_LOCALE_STORAGE_KEY` (`enso-front-app-locale`), valeurs `fr` | `en`.
- **React** : `I18nProvider` (`enso/enso-front/src/i18n/context.tsx`) lit la valeur au montage (`useLayoutEffect`), expose `locale`, `setLocale` (persiste), et `t` sur `getMessages(locale)`. Composant `DocumentLangSync` : `document.documentElement.lang` = préfixe BCP 47 (`fr` ou `en`). Écoute `storage` pour les autres ondulations.
- **Hors React (formatters, messages docv/OAuth)** : `getActiveAppLocale()` / `setActiveAppLocale()` dans `enso/enso-front/src/i18n/activeLocale.ts`, synchronisés avec le provider.
- **BCP 47 pour `Intl`** : `bcp47ForAppLocale()` — `fr` → `fr-FR`, `en` → `en-US` (`catalog.ts`).
- **Métadonnées Next (serveur)** : `app/layout.tsx` utilise encore `getMessages(DEFAULT_LOCALE)` pour `metadata` ; le `<html lang="fr">` statique est complété côté client par `DocumentLangSync`.
- **Résolution** : `translate()` lève si la clé est absente (`enso/enso-front/src/i18n/translate.ts`).
## Libellés partagés
- Clés sous `shared.*` pour éviter les doublons (ex. `shared.labelActiveCasesShort`, `shared.labelPermanentInfoShort`) : stats tableau de bord, barre latérale, onglets société.
## Menu utilisateur et 404
- **Langue** : `AppLayoutUserMenu` — `layout.menuLanguage`, `layout.languageFr`, `layout.languageEn`, groupe radio relié à `setLocale`.
- **404** : `NotFoundContent` — `layout.notFoundTitle`, `layout.notFoundBackToDashboard`.
## Erreurs docv (pas de texte serveur brut à l’écran)
- `translateDocvFailure()` (`enso/enso-front/src/i18n/docvErrorMessage.ts`) mappe statuts HTTP, configuration manquante, et erreurs réseau vers `errors.docv*` du catalogue **actif** (`getActiveAppLocale()`).
- Utilisé par : `loadStubListsOnce`, `useOfficesCatalog`, `resolveOfficePageLoad`, `resolveCasePageLoad`.
## OAuth / docv callback
- `runDocvCallbackExchange` : union discriminée (`enso/enso-front/src/lib/docvOAuthBrowser.ts`), messages via `getMessages(getActiveAppLocale())`.
## Données métier
- `Company.siren` / `address` : `null` si l’API ne les fournit pas ; affichage `common.notProvided`.
- **Société vs dossier d’opération** : une **société** (écran + `DocvOffice`) correspond au **dossier permanent** et **n’est pas** une opération ; les lignes **Dossiers** sous la fiche société sont les **opérations / demandes** (ressource API `folders`, type `Case`). Libellés orientés utilisateur : `dashboard.companiesDescription`, `company.permanentDescription`, `shared.labelPermanentInfoShort`. Référence : [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md).
- **Type d’opération** : préfixes `case.operationType.*` (presets, section démo, formulaire nouveau dossier, fiche dossier). **Checklists métier par slug** : `case.operationChecklist.<slug>.*` (`title`, `description`, `sourceLine`, `legendTitle`, `suggestedTitle` — ce dernier pour le dialogue nouveau dossier si le slug est enregistré dans `suggestedFolderTitles.ts`). Référence : [OPERATION_CHECKLISTS.md](OPERATION_CHECKLISTS.md). **Messagerie** : `messaging.description` (sociétés + opérations).
## Formatters et `Intl` partagé
- Module **`enso/enso-front/src/lib/intlAppLocale.ts`** : `appIntlBcp47()` (BCP 47 = `bcp47ForAppLocale(getActiveAppLocale())`), `formatNumberForAppLocale()` pour les nombres à l’écran.
- **Hors enso-front** : pas de runtime JavaScript/`Intl` dans `enso-back` ou `docv` (Rust) ; seul le front consomme ce module.
- Types de pièces, statuts de dossier, tailles fichiers, archétype DP : `translate(getMessages(getActiveAppLocale()), …)` dans `enso/enso-front/src/lib/formatters.ts` (ex. `company.dpArchetypeDemoEnterprise` pour `dp_archetype = entreprise_demo`).
- **Dates courtes** : `formatDate()` utilise `toLocaleDateString(appIntlBcp47(), …)`.
- **Sidebar** : tri des sociétés et listes de dossiers actifs dans `appSidebarModel.ts` via `localeCompare(..., appIntlBcp47())` ; ordre secondaire société / titre lorsque le statut « action en attente » est identique.
- **Graphiques** : tooltip Recharts (`components/ui/chart.tsx`) formate les valeurs numériques avec `formatNumberForAppLocale` lorsque la valeur est un nombre fini.
## Suspense
- Repli React explicite traduit : `I18nSuspenseFallback` (`enso/enso-front/src/components/i18n/I18nSuspenseFallback.tsx`).
## Recherche sidebar
- `AppSidebarSearchResults` : `layout.searchNoResults`, `layout.searchContextSeparator` (séparation société / dossier dans la ligne secondaire).

68
services/docv/enso-docs/features/IA_GRANDS_PRINCIPES.md Normal file
View File

@ -0,0 +1,68 @@
# Grands principes de l’IA (sous-module ai, AnythingLLM)
Ce document décrit les grands principes d’intégration de l’IA dans le projet (sous-module `ai`, socle AnythingLLM/Ollama). Les backends **docv** et **enso** consomment l’API IA ; ils n’appellent pas directement AnythingLLM ou Ollama. Référence : `docs/ARCHITECTURE_DOCV_ENSO.md` (sections 2bis, 2ter).
---
## 1. Dossier ↔ Workspace AnythingLLM
- Un **dossier** (métier) est **synchronisé** avec un **workspace AnythingLLM**.
- Correspondance bijective ou dédiée : un dossier applicatif = un workspace AnythingLLM pour le contexte et les opérations IA sur ce dossier.
- La synchronisation assure que le contenu pertinent du dossier (documents, métadonnées, structure) est disponible dans le workspace pour les requêtes et les opérations IA.
- **Arborescence versionnée** : le répertoire `data/dossiers-permanents/` du dépôt (gabarits + miroirs d’upload optionnels) peut alimenter le workspace après `git pull` sur la machine AnythingLLM ; procédure : [ANYTHINGLLM_DATAROOM_SYNC.md](ANYTHINGLLM_DATAROOM_SYNC.md). Référence données / Git côté API : [DOSSIERS_PERMANENTS_DATA_GIT.md](DOSSIERS_PERMANENTS_DATA_GIT.md).
---
## 2. Pré-traitement par librairies (avant appel IA)
L’API IA s’appuie au **maximum sur des librairies classiques** pour préparer les données et réduire la charge sur le modèle. L’IA reçoit des entrées normalisées et vérifiées.
| Domaine | Règle | Objectif |
|--------|--------|----------|
| **Traductions** | Uniquement **vers l’anglais**. | Langue cible unique pour les requêtes IA ; les librairies de traduction traitent les textes avant envoi au modèle. |
| **Extraction de données** | Uniquement **vers du JSON**. | Sorties structurées, exploitables par le code ; extraction par librairies (OCR, parsing PDF/Excel, etc.) avant ou en complément de l’IA. |
| **Vérification de vraisemblance** | Codes, identifiants, clés : **vérification en amont** de l’appel IA. | Validation de format, plages, existence (regex, schémas, BDD) avant de soumettre à l’IA ; l’IA ne remplace pas la vérification de cohérence des codes/IDs/clés. |
| **Images et formats non convertibles** | Si le format est **nécessaire à l’interprétation** et **non convertible** en texte/JSON : **amélioration de la qualité**, **retournement dans le bon sens** (orientation), puis envoi à l’IA. | Préparation des visuels (redressement, contraste, netteté) par librairies classiques ; autres supports possibles avec les librairies usuelles avant appel au modèle. |
En résumé : traductions → anglais uniquement ; extractions → JSON uniquement ; vérification des codes/IDs/clés en amont ; pour les images ou formats non convertibles, prétraitement (qualité, orientation) puis IA.
---
## 3. Rôle de l’IA
- L’**IA effectue les opérations demandées** sur les données préparées (contexte du workspace, entrées normalisées).
- Elle ne remplace pas les librairies pour la traduction systématique, l’extraction structurée vers JSON ni la vérification de vraisemblance des codes/identifiants/clés.
---
## 4. Workflow optionnel : IA distante (cloud)
Optionnellement, l’IA peut **déclencher un workflow** pour déléguer à une IA distante (cloud) :
1. **Anonymisation** : suppression ou masquage des données identifiantes dans la question ou le contexte envoyé.
2. **Décontextualisation** : formulation de la question (ou du lot) sans référence directe au dossier ou à l’office.
3. **Appel IA distante (cloud)** : envoi de la requête anonymisée et décontextualisée au service IA cloud.
4. **Récupération du résultat** : réception de la réponse du cloud.
5. **Renommage et recontextualisation** : réinjection des identifiants, du contexte dossier/office et adaptation des libellés pour réintégrer la réponse dans l’application.
Ce workflow est **optionnel** et paramétrable (activation par office, par type d’opération ou par configuration).
---
## 5. Déclenchement des fonctionnalités IA : Cursor instrumenté
- Les **fonctionnalités IA** sont déclenchées à travers un **Cursor instrumenté** pour l’API : un **projet/workspace** dédié expose les points d’entrée et le contexte pour les appels IA.
- **Agents, subagents, commandes, skills et plans** sont **systématiquement utilisés** par le code et par les **hooks** : pas d’appel IA ad hoc sans passer par ces mécanismes (agents, subagents, commandes, skills, plans).
- Le code applicatif et les hooks s’appuient sur ce Cursor instrumenté pour toute opération IA (chat, extraction, génération, etc.).
---
## 6. Synthèse
| Principe | Description |
|----------|-------------|
| Dossier ↔ Workspace | Un dossier métier est synchronisé avec un workspace AnythingLLM. |
| Librairies en priorité | Traductions → anglais uniquement ; extractions → JSON uniquement ; vérification des codes/IDs/clés en amont ; images/formats non convertibles : amélioration qualité et orientation avant IA. |
| Rôle de l’IA | L’IA réalise les opérations demandées sur des entrées préparées. |
| Workflow cloud (optionnel) | Anonymisation → décontextualisation → appel IA cloud → récupération → renommage et recontextualisation. |
| Cursor instrumenté | Fonctionnalités IA déclenchées via un Cursor instrumenté pour l’API (projet/workspace) ; agents, subagents, commandes, skills et plans utilisés systématiquement par le code et les hooks. |

71
services/docv/enso-docs/features/MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md Normal file
View File

@ -0,0 +1,71 @@
# Modèle métier : sociétés (dossiers permanents) et dossiers d’opération
## Espaces, rôles et docv
Le déploiement docv peut alimenter **plusieurs espaces** (applications). **Société** (`office` API) = **société cliente du cabinet** dans le périmètre suivi. **Espace cabinet** (collaborateurs, associés, comptables, experts-comptables, stagiaires, administrateurs, etc.) : les habilitations exposent les sociétés clientes selon le **rôle** de session. **Espace clients** : utilisateurs **rattachés à leurs sociétés** avec rôles et sous-rôles dédiés. Un **même e-mail** peut ouvrir plusieurs contextes : le **choix au login** (espace / rôle) est **géré par docv**. Le détail des durées OAuth et des variables **`DOCV_*`** de secours pour bases de test : [AUTH_SESSION.md](../docv/AUTH_SESSION.md).
## Vocabulaire produit
| Terme UI / métier | Définition | Rôle dans l’application |
|-------------------|------------|---------------------------|
| **Société** (entreprise) | entité client **stable** rattachée au cabinet ; **dossier permanent** (DP) pour tout ce qui relève de l’identité juridique et des pièces de fond à jour dans le temps. **Une société n’est pas une opération** : elle apparaît dans **Sociétés** ; les opérations sont les dossiers listés dans l’autre onglet. | Représentée par une ressource **`office`** côté API docv (`GET /api/v1/offices`, etc.). Écran **Société** : onglet « dossier permanent », synthèse (SIREN, types d’organisation issus des archetypes liés aux dossiers, etc.). |
| **Dossier** (dans l’app client) | **opération ou demande** du client : création d’entreprise, AGE / AGO, clôture des comptes, augmentation de capital, nouveau bail, projet de cession, autre formalité ponctuelle | Représentée par une ressource **`folder`** docv. Type front : **`Case`** ; liste et fiche dossier sous la société concernée. |
| Lien des deux | un **dossier d’opération** est rattaché à une société et **peut compléter** le dossier permanent (pièces nouvelles, suites d’actes) | `folder.office_uid` → société ; indicateur API **`folders.extends_permanent_record`** (bool) lorsque l’opération complète explicitement le DP — exposé en UI sur la fiche dossier. |
## Où voir le « dossier permanent » dans l’UX ?
Les **cartes du tableau de bord et de la barre latérale « Sociétés »** listent des **entreprises (sociétés)** : c’est bien là que doivent apparaître les sociétés, car **le dossier permanent est porté par la société** (pas l’inverse). Il n’y a pas de ligne séparée « dossier permanent » dans cette liste : sous chaque carte, la **fiche société** offre l’onglet **Dossier permanent** (pièces d’identité juridique et documents tenus dans la durée) et l’onglet **Dossiers**, qui liste **uniquement les opérations** (`Case`). Les entreprises elles-mêmes **ne figurent pas** dans cette liste d’opérations.
## Données techniques `folders`
| Colonne | Valeurs | Rôle |
|---------|---------|------|
| **`folder_purpose`** | `client_operation` (défaut) \| `dp_structure_demo` | Distingue une **opération réelle** d’une ligne **structure type** (seed démo, lien `instances/<id>/`). |
| **`operation_type`** | texte court, souvent un **slug** catalogue (cession, age, …) ou libellé libre | **Type métier d’opération** ; `NULL` pour les structures démo et si non renseigné. Si le slug correspond à une checklist embarquée ([OPERATION_CHECKLISTS.md](OPERATION_CHECKLISTS.md)), la fiche dossier affiche la liste consultative des pièces attendues. |
| **`extends_permanent_record`** | bool (`false` par défaut) | Marque une **opération** qui complète / prolonge le dossier permanent côté métier (PATCH dossier + badge fiche). |
Réponses JSON liste / détail dossier : champs `folder_purpose`, `operation_type`, `extends_permanent_record` (snake_case, alignés `DocvFolder`).
## Données techniques `offices` (socle société SPEC_18)
| Colonne / objet | Rôle |
|-----------------|------|
| **`parent_office_uid`** | Lien optionnel vers une société « tête de groupe » (hiérarchie données, en complément du regroupement UI **Filiales**). |
| **`archived_at`** | Archivage société : les offices archivés n’apparaissent pas dans **`GET /api/v1/offices`** (liste client). |
| **`office_comments`** | Commentaires au niveau société (`GET` / `POST …/offices/:uid/comments`) — distincts des fils dossier / opération. |
Les **contacts société** au sens SPEC_18 (`SocietyContact`) ne sont pas encore modélisés en table dédiée : le flux **société liée / contacts** reste porté par la zone **opération** jusqu’à extension du schéma.
## Démo : offices (UX « Sociétés »)
Quand la table `offices` est vide, docv-back crée **neuf** sociétés fictives : **huit** cartes « **sociétés types** » (une par archétype `instances/<id>/`, libellés du type *Entreprise · Société commerciale · IR*) et **« Entreprise démo (fictive) »** (`DEMO_OFFICE_DISPLAY_NAME`), avec un dossier structure lié à **`instances/entreprise_demo/`** dans le dépôt. **Chaque carte = un `office`** : la liste latérale / tableau de bord « Sociétés » aligne l’UX des types sur celle de l’entreprise démo. Les anciennes bases **un seul office démo + huit dossiers** sont migrées au démarrage vers ce schéma (réattribution des stubs notifications / conversations). Les libellés « Cabinet démo » sont renommés en **« Entreprise démo (fictive) »** par migration SQL existante.
## Ce que n’est pas un « dossier » produit
- Le répertoire **`data/dossiers-permanents/instances/`** (arborescence fichier + archétypes **jeu type**, y compris **`entreprise_demo`**) sert de **modèle de classement** et de miroir Git pour le DP ; ce n’est pas la liste des opérations clients affichée dans l’UI.
- Les seeds **démonstration** (`folder_purpose = dp_structure_demo`) exposent une **fiche « dossier » structure** par société type ou par entreprise démo ; l’UI les regroupe à part des **opérations** (`client_operation`).
## Arborescence disque dans l’UI (enso-front)
Deux parcours **lecture seule** distincts, pour éviter la confusion **répertoires type `instances/`** vs **arborescence rattachée à un dossier d’opération** (souvent sous **`operations/`** ou autre `dp_layout_root`) :
| Contexte | API docv-back | Rôle |
|----------|----------------|------|
| **Fiche société** (`/company/[companyId]`) | **`GET /api/v1/offices/:officeUid/instance-layout-entries`** et **`instance-layout-file`** | Parcours **lecture seule** du référentiel **`instances/`** pour tout membre de l'office : racine = premier **`dp_layout_root`** sous **`instances`** (quel que soit le **`folder_purpose`**), sinon **`instances/<dp_archetype>`**, sinon **`instances`** (arbre type complet). Le front affiche toujours **`CompanyInstanceLayoutExplorer`** ; la ligne « racine affichée » suit **`companyInstanceLayoutRoot`**. |
| **Fiche dossier** (`/company/.../case/...`) | **`GET /api/v1/folders/:folderUid/dp-layout-entries`** et **`dp-layout-file`** | Parcours relatif au **`dp_layout_root`** **de ce dossier** (structure démo, cession démo sous **`operations/`**, etc.) — **`CaseDpLayoutExplorer`**. |
Les composants partagés **`DpLayoutExplorerTreeList`** et **`DpLayoutFilePreviewDialog`** prennent un **`layoutApiScope`** : **`folder`** (UID dossier) ou **`office`** (UID société / office). Détail des chemins d’URL (suffixe par segments, repli `?path=`) : [DOCV_API_ENSO_FRONT_MAP.md](DOCV_API_ENSO_FRONT_MAP.md).
## Cartographie technique courte
- **Types front** : `Company` (société + agrégation), `Case` (`folderPurpose`, `operationType`, `dpLayoutRoot`, `dpArchetype`, …), `Document` avec catégorie `permanent` | `dossier`.
- **Agrégation** : `officeAndFoldersToCompany` — les **`organizationArchetypes`** viennent des dossiers **`dp_structure_demo`**. Compteurs **tableau de bord**, **barre latérale « Dossiers en cours »**, **notifications** et **pièces à transmettre** : **opérations uniquement** (`client_operation`). En **démo**, chaque **société / type** est un **`office`** distinct (carte « Sociétés ») ; la **fiche société** liste encore les structures démo et les opérations comme dossiers.
- **Navigation liste sociétés (enso-front)** : lorsque le **`dp_archetype`** permet de lier un office **`filiale_*`** ou **`sous-groupe_*`** à un office **`groupe_<segment>_<tax>`** présent dans le même catalogue chargé, le **tableau de bord** et la **barre latérale** affichent ces offices sous un regroupement visuel **« Filiales »** (premier niveau sous la tête de groupe), dérivé de `buildCompanyNavHierarchy`.
## Documents liés
- [OPERATION_CHECKLISTS.md](OPERATION_CHECKLISTS.md) — pattern checklists par type d’opération (`operationChecklists/`, export Excel).
- [CHECKLIST_CESSION_JURIDIQUE_SOCIAL_FISCAL.md](CHECKLIST_CESSION_JURIDIQUE_SOCIAL_FISCAL.md) — liste consultative cession (référence Excel cabinet).
- [DOCV_API_ENSO_FRONT_MAP.md](DOCV_API_ENSO_FRONT_MAP.md) — routes `offices` / `folders`.
- [DOSSIERS_PERMANENTS_DATA_GIT.md](DOSSIERS_PERMANENTS_DATA_GIT.md) — données `data/dossiers-permanents/`.
- [ENSO_FRONT_BACKEND_CONTRACT.md](ENSO_FRONT_BACKEND_CONTRACT.md) — contrat front / backends.

79
services/docv/enso-docs/features/OPERATION_CHECKLISTS.md Normal file
View File

@ -0,0 +1,79 @@
# Checklists métier par type d’opération (enso-front)
## Principe
Les types d’opération catalogués (`folders.operation_type` = slug : `cession`, `age`, …) peuvent avoir une **checklist embarquée** : fichier JSON sous `enso/enso-front/src/lib/operationChecklists/data/<slug>.json`, enregistré dans **`registry.ts`**, textes UI sous **`case.operationChecklist.<slug>.*`** dans les catalogues i18n (`messages.fr.ts` / `messages.en.ts`), et affichage via **`CaseOperationChecklistCard`** sur la fiche dossier.
**Il n’existe pas d’endpoint docv** pour ces listes : elles sont versionnées dans le dépôt avec le front, comme les traductions.
## Parcours utilisateur
| Étape | Composant / module | Règle |
|--------|----------------------|--------|
| Page société, onglet Dossiers | `CompanyCasesTabsContent` | Dialogue **Nouveau dossier** : sélection du type (`OPERATION_TYPE_SLUGS`). Si le titre est encore vide et que **`suggestedFolderTitleMessagePath(slug)`** renvoie une clé i18n, le titre est prérempli (ex. cession). |
| Fiche dossier (`CaseDetail`) | `CaseDetailBody` | Rend **`CaseOperationChecklistCard`** avec le **`Case`** courant. La carte appelle **`operationChecklistBundleForCase(caseItem)`** ; si `null`, rien n’est affiché. |
## Conditions d’affichage de la carte checklist
1. **`folder_purpose === client_operation`** (dossier d’opération réel, pas ligne démo `dp_structure_demo`).
2. **`operation_type`** doit être un **slug** reconnu par **`isOperationTypeSlug`** (valeurs dans `lib/domain/operationTypes.ts`). Un type saisi comme **Autre** (texte libre) ne correspond à aucune checklist embarquée.
3. Le slug doit avoir une entrée dans **`REGISTRY`** (`registry.ts`).
Les libellés de la checklist (titres de sections, items) proviennent du **JSON** ; la **légende** DF/NA/DM/CO et les textes d’en-tête de carte viennent du **JSON** (légende) et des clés i18n (`title`, `description`, etc.).
## Fichier JSON (`OperationChecklistData`)
| Champ | Rôle |
|--------|------|
| **`meta.sourceFile`** | Nom du fichier source (Excel), affiché dans la ligne « Fichier source ». |
| **`meta.sheet`** | Feuille Excel utilisée pour l’export. |
| **`meta.legend`** | Texte de légende (souvent une ligne commençant par `DF :`). |
| **`meta.operationTypeSlug`** | Optionnel ; rappel documentaire du slug (l’UI utilise le slug déduit du dossier). |
| **`blocks`** | Liste ordonnée de blocs `section`, `subsection` ou `item` (`ref` + `label` pour les items). |
## Module `lib/operationChecklists/`
| Export (`index.ts`) | Usage |
|---------------------|--------|
| Types `OperationChecklistBlock`, `OperationChecklistData` | Contrat du JSON. |
| `operationChecklistBundleForCase` | Résolution checklist + slug pour un `Case`. |
| `operationChecklistSlugs` | Liste des slugs ayant un fichier dans le registre (inspection / outils). |
| `OPERATION_FOLDER_SUGGESTED_TITLE_I18N`, `suggestedFolderTitleMessagePath` | Carte slug → clé **`MessagePath`** pour le titre proposé à la création du dossier. |
## Ajouter une checklist pour un nouveau type
1. **Excel** (ou autre source) : préparer une feuille avec la même convention que la checklist cession (colonne A : numéro de section / sous-section / item, B : libellé ; légende en ligne commençant par `DF :`).
2. **Export JSON** :
```bash
python3 -m venv .venv
.venv/bin/pip install openpyxl
.venv/bin/python3 tools/export_operation_checklist.py \
--input docs/<votre-fichier>.xlsx \
--sheet <NomFeuille> \
--output enso/enso-front/src/lib/operationChecklists/data/<slug>.json \
--operation-type-slug <slug>
```
Le slug doit exister dans **`OPERATION_TYPE_SLUGS`** (`lib/domain/operationTypes.ts`).
3. **Registre** : dans `enso/enso-front/src/lib/operationChecklists/registry.ts`, importer le JSON et ajouter une ligne dans **`REGISTRY`** (même clé que le slug).
4. **i18n** : ajouter **`case.operationChecklist.<slug>`** avec au minimum `title`, `description`, `sourceLine`, `legendTitle`, et si besoin **`suggestedTitle`** pour le dialogue « Nouveau dossier » (paramètre **`{{companyName}}`**). Référence catalogue : [I18N_ENSO_FRONT.md](I18N_ENSO_FRONT.md).
5. **Titre suggéré (optionnel)** : ajouter une entrée dans **`OPERATION_FOLDER_SUGGESTED_TITLE_I18N`** (`suggestedFolderTitles.ts`) : slug → clé **`MessagePath`** (souvent `case.operationChecklist.<slug>.suggestedTitle`). Le dialogue « Nouveau dossier » appelle **`suggestedFolderTitleMessagePath`** ; pas de branche par slug dans **`CompanyCasesTabsContent`**.
## Fichiers clés
| Fichier | Rôle |
|---------|------|
| `lib/operationChecklists/types.ts` | Types `OperationChecklistBlock`, `OperationChecklistData` |
| `lib/operationChecklists/registry.ts` | `REGISTRY`, `operationChecklistBundleForCase`, `operationChecklistSlugs` |
| `lib/operationChecklists/suggestedFolderTitles.ts` | `OPERATION_FOLDER_SUGGESTED_TITLE_I18N`, `suggestedFolderTitleMessagePath` |
| `lib/operationChecklists/index.ts` | Ré-exports publics |
| `lib/operationChecklists/data/*.json` | Données par slug |
| `screens/case/CaseOperationChecklistCard.tsx` | Carte réutilisable |
| `tools/export_operation_checklist.py` | Export Excel → JSON |
## Limite fonctionnelle actuelle
La checklist est **consultative** : pas de persistance des coches DF/NA/DM/CO ni synchronisation avec **`user_pending_documents`** ou les pièces du dossier. L’évolution cible (workflow documentaire) est décrite côté spec zone 18 ([SPEC_18_operation.md](specs/SPEC_18_operation.md) §6).
## Référence cession
Détail métier et fichier source Excel : [CHECKLIST_CESSION_JURIDIQUE_SOCIAL_FISCAL.md](CHECKLIST_CESSION_JURIDIQUE_SOCIAL_FISCAL.md).

114
services/docv/enso-docs/features/PARAMETRAGE_ECRANS_ACTIONS.md Normal file
View File

@ -0,0 +1,114 @@
# Paramétrage des écrans, des actions et des options d’implémentation
**Objectif :** Chaque écran, chaque action (fonctionnalité) et chaque option d’implémentation doit être paramétrable, sans recours au code pour activer, désactiver ou adapter le comportement.
**Référence :** `docs/SCREENS_AND_FUNCTIONS_MAP.md` (principe de paramétrabilité).
---
## 1. Périmètre
| Élément | Description | Exemples de paramètres |
|--------|--------------|-------------------------|
| **Écran** | Page ou vue identifiée par une route ou un identifiant. | Visible (oui/non), ordre d’affichage, libellé, icône, regroupement menu, rôles autorisés, offices concernés, types de dossiers concernés. |
| **Action** | Opération utilisateur (bouton, commande, lien). | Visible (oui/non), activée (oui/non), droits requis, conditions (ex. « si dossier partagé »), libellé. |
| **Option d’implémentation** | Choix technique ou métier qui modifie le comportement. | Workflow (nombre d’étapes, libellés), intégrations (Outlook, IA, ancrage), seuils (alertes, conservation), éditeur (OnlyOffice ou autre), mode Chat IA (activé/désactivé). |
---
## 2. Niveaux de paramétrage
Les paramètres peuvent s’appliquer à un ou plusieurs niveaux. La résolution est du plus global au plus local (plateforme → office → type de dossier → contexte utilisateur).
| Niveau | Portée | Qui paramètre | Exemple |
|--------|--------|----------------|---------|
| **Plateforme** | Tous les offices du déploiement concerné (**docv** / **enso**). | Admin plateforme. | Activation globale de l’ancrage, des textes i18n, des plans d’abonnement. |
| **Office** | Un office donné. | Admin d’office (ou rôle dédié). | Liste des écrans visibles, ordre des menus, activation du workflow documentaire, intégration Outlook pour l’office. |
| **Type de dossier** | Tous les dossiers d’un type (ex. « Vente », « Dossier permanent »). | Admin d’office ou config par type. | Écrans et actions disponibles pour ce type, workflow associé, documents attendus. |
| **Rôle** | Tous les utilisateurs ayant un rôle donné (dans un office ou global). | Admin plateforme ou admin d’office. | Matrice de permissions (écrans et actions accessibles), libellés par rôle. |
| **Préférence utilisateur** | Un utilisateur donné (dans les limites de son rôle). | L’utilisateur. | Ordre des favoris, panneaux ouverts par défaut, langue. |
---
## 3. Écrans : paramètres typiques
Pour chaque écran répertorié dans la cartographie :
- **Identifiant** : stable (ex. `dashboard`, `folders`, `composition-actes`).
- **Visible** : oui / non (par office, par rôle, ou par type de dossier si l’écran est lié à un type).
- **Ordre** : position dans le menu ou dans le sélecteur « Aller à » (entier ou clé de tri).
- **Libellé** : texte affiché (surchargeable par office ou par locale).
- **Accès** : liste des rôles (ou permission) autorisés ; défaut = selon matrice des permissions.
- **Condition d’affichage** : optionnelle (ex. afficher « Data room » seulement si au moins une dataroom existe ou si la fonction dataroom est activée pour l’office).
Stockage recommandé : table ou entité `screen_config` (ou équivalent) avec `screen_id`, `office_id` (nullable pour plateforme), `role_id` (nullable), `case_type_id` (nullable), champs `visible`, `order`, `label_override`, `condition`.
---
## 4. Actions : paramètres typiques
Pour chaque action (bouton, lien, commande) listée dans la cartographie :
- **Identifiant** : stable (ex. `folder.create`, `document.download`, `share.invite`).
- **Écran parent** : écran ou contexte où l’action est proposée.
- **Visible** : oui / non (par office, rôle, type de dossier).
- **Activée** : oui / non (peut dépendre d’une option d’implémentation, ex. « Télécharger avec filigrane » seulement si filigrane activé).
- **Droits requis** : permission(s) nécessaire(s) ; défaut = selon matrice rôle × ressource × action.
- **Condition** : expression ou règle métier (ex. « Inviter » visible seulement si partage activé pour le dossier).
- **Libellé** : surchargeable par office ou locale.
Stockage recommandé : table ou entité `action_config` (ou équivalent) avec `action_id`, `screen_id`, `office_id`, `role_id`, `case_type_id`, champs `visible`, `enabled`, `permission_override`, `condition`, `label_override`.
---
## 5. Options d’implémentation : paramètres typiques
Les options d’implémentation couvrent les choix techniques ou métier qui influencent le comportement sans changer le code.
| Catégorie | Exemples d’options | Niveau | Valeurs typiques |
|-----------|--------------------|--------|-------------------|
| **Workflow** | Nombre d’étapes, libellés des statuts, transitions autorisées par rôle. | Office, type de dossier | Référentiel workflow (id), JSON ou table des états. |
| **Intégrations** | Outlook, API IA, ancrage ; identité fédérée ou API métier secteur notarial uniquement si un tel déploiement est ouvert hors périmètre actuel. | Plateforme, office | Activé (oui/non), URL, clés (masquées). |
| **Alertes** | Délais (jours/mois), types d’alertes actifs, destinataires par type. | Office, type de dossier | Configuration par type d’alerte. |
| **Documents** | Types de documents attendus, durée de conservation, motivation collecte. | Office, type de dossier | Référentiel types de documents, champs par type. |
| **Dataroom** | Droits par défaut (viewer/editor), date de fin d’accès max. | Office | Valeurs par défaut. |
| **UI / comportement** | Chat IA activé, éditeur de rédaction (OnlyOffice ou autre), pagination. | Plateforme, office, utilisateur | Feature flags, préférences. |
Stockage : tables ou entités dédiées (workflow, integration_config, alert_config, document_type_config, etc.) + table générique `system_configuration` (clé / valeur ou JSON) pour les feature flags et options globales.
---
## 6. Résolution et priorité
Lors de l’affichage d’un écran ou d’une action :
1. Charger les paramètres **plateforme** (défauts globaux).
2. Surcharger avec les paramètres **office** (si utilisateur dans un office).
3. Surcharger avec les paramètres **type de dossier** (si écran/action dans un contexte de type de dossier).
4. Surcharger avec les paramètres **rôle** (matrice permissions + éventuelles surcharges écran/action).
5. Appliquer les **préférences utilisateur** pour l’ordre, les panneaux, la langue (sans dépasser les droits).
Un paramètre non défini à un niveau donné conserve la valeur du niveau parent. Une désactivation à un niveau ne peut pas être réactivée à un niveau plus local (sécurité).
---
## 7. Interface de paramétrage
- **Admin plateforme :** écrans et actions visibles au niveau plateforme, options d’implémentation globales (intégrations, feature flags), rôles et permissions plateforme.
- **Admin d’office :** écrans et actions pour l’office, ordre et libellés, options d’implémentation de l’office (workflow, alertes, types de documents, dataroom), gestion des rôles et membres de l’office.
- **Utilisateur :** préférences personnelles (ordre, panneaux, langue) dans les limites de son rôle.
Les écrans « Configuration établissements », « Types et configuration », « Configuration système » (super-admin) et « Mon compte » exposent les entrées correspondant à ces niveaux.
---
## 8. Référence croisée avec la cartographie
- La **liste des écrans** dans `docs/SCREENS_AND_FUNCTIONS_MAP.md` (sections 1 à 17) constitue le référentiel des identifiants d’écrans à rendre paramétrables.
- La **liste des actions par écran** (section 18) constitue le référentiel des actions à rendre paramétrables.
- **Référentiel exhaustif** : `docs/features/REFERENTIEL_ECRANS_ACTIONS.md` — table de tous les écrans (zone, identifiant stable, route, actions 18.x) et liste des actions par écran parent, pour paramétrage et implémentation.
- **Sociétés (enso-front)** : écrans **`companies.list`** (`/dashboard`, navigation latérale) et **`companies.detail`** (`/company/[companyId]`) — mêmes leviers de paramétrage que les autres écrans (visible, ordre, rôles, libellés). Les actions sous-jacentes restent celles des dossiers (zone 2) et des documents (zone 3) pour l’onglet dossier permanent.
- **Description technique d’implémentation** : `docs/features/implementation/README.md` — documents IMPL_xx par zone (routes, composants front, handlers/services/repos back, BDD, paramétrage).
- Chaque **option d’implémentation** mentionnée dans la cartographie ou dans `docs/features/FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md` (workflow, intégrations, seuils, éditeur, etc.) doit avoir un paramètre ou une table de configuration dédiée.
Aucun écran ni action ne doit être codé en dur comme toujours visible ou toujours masqué sans passer par ce paramétrage.

278
services/docv/enso-docs/features/REFERENTIEL_ECRANS_ACTIONS.md Normal file
View File

@ -0,0 +1,278 @@
# Référentiel des écrans et des actions
Document de référence exhaustif : **tous les écrans** (zones 1 à 15, 17 et 18) et **toutes les actions** (18.1 à 18.96) avec identifiants stables pour le paramétrage et l’implémentation.
**Sources :** [SCREENS_AND_FUNCTIONS_MAP.md](../SCREENS_AND_FUNCTIONS_MAP.md) (sections 1 à 17 et 18). **Paramétrage :** [PARAMETRAGE_ECRANS_ACTIONS.md](PARAMETRAGE_ECRANS_ACTIONS.md). **Specs détaillées :** [specs/README.md](specs/README.md). **Description technique d’implémentation :** [implementation/README.md](implementation/README.md).
---
## 1. Écrans par zone (identifiant stable, route, actions)
### Zone 1 — Authentification et compte
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `auth.login` | Connexion | auth | 18.1 |
| `auth.logout` | Déconnexion | `/logout-callback` | 18.2 |
| `auth.my-account` | Mon compte | `/my-account` | 18.3 |
### Zone 2 — Dossiers
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `folders.list` | Liste des dossiers | `/folders` | 18.4 |
| `folders.select` | Sélection de dossier | `/folders/select` | 18.5 |
| `folders.detail` | Détail d’un dossier | `/folders/[folderUid]` | 18.6 |
| `folders.archived` | Dossiers archivés | `/folders/archived` | 18.7 |
| `folders.deleted` | Dossiers supprimés | `/folders/deleted` | 18.8 |
| `folders.create`, `folders.edit` | Création / édition de dossier | formulaire / route dédiée | 18.9 |
### Espace client Enso — Sociétés (offices clients)
Identifiants dédiés à l’application **enso-front** (société cliente = ressource `office` docv). Les actions 18.x réutilisent la zone 2 (dossiers) et la zone 3 (documents) lorsque le comportement est identique.
| Identifiant stable | Écran | Route implémentée | Actions (référence) |
|--------------------|-------|-------------------|---------------------|
| `companies.list` | Liste des sociétés | `/dashboard` (cartes) + barre latérale « Sociétés » | 18.4 (liste dossiers par société), 18.40 (contexte client) |
| `companies.detail` | Fiche société | `/company/[companyId]` | 18.6 (dossiers sous onglet Dossiers), 18.13 / 18.14 (dossier permanent, téléversement) |
Voir [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md).
### Zone 3 — Documents et types de documents
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `document-types.list` | Types de documents | `/document-types` | 18.10 |
| `document-types.create` | Création type de document | `/document-types/create` | 18.11 |
| `document-types.detail` | Détail type de document | `/document-types/[documentTypeUid]` | 18.12 |
| `documents.folder` | Documents d’un dossier | dans `/folders/[folderUid]` | 18.13 |
| `documents.upload`, `documents.detail` | Téléversement / détail document | modal / panneau | 18.14 |
### Zone 4 — Types de dossiers
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `case-types.list` | Types de dossiers | `/case-types` ou `/folder-types` | 18.15 |
| `case-types.create` | Création type de dossier | `/case-types/create` | 18.16 |
| `case-types.detail` | Détail type de dossier | `/case-types/[caseTypeUid]` | 18.17 |
### Zone 5 — Offices et membres
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `offices.list` | Liste des offices | `/offices` | 18.18 |
| `offices.detail` | Détail d’un office | `/offices/[officeUid]` | 18.19 |
| `offices.rib` | Coordonnées bancaires | `/offices/rib` | 18.20 |
| `collaborators.list` | Collaborateurs | `/collaborators` | 18.21 |
| `collaborators.detail` | Détail collaborateur | `/collaborators/[collaboratorUid]` | 18.22 |
| `users.list` | Utilisateurs | `/users` | 18.23 |
| `users.detail` | Détail utilisateur | `/users/[userUid]` | 18.24 |
### Zone 6 — Rôles et permissions
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `roles.list` | Rôles | `/roles` | 18.25 |
| `roles.create` | Création rôle | `/roles/create` | 18.26 |
| `roles.detail` | Détail rôle | `/roles/[roleUid]` | 18.27 |
### Zone 7 — Parties au dossier et partage
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `customers.list` | Parties au dossier | `/customers` | 18.28 |
| `sharing.folder` | Partage de dossier | dans détail dossier | 18.29 |
| `sharing.invitees` | Parties externes / invités | dans détail dossier | 18.30 |
### Zone 8 — Notes et rappels
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `notes.list` | Notes | `/notes` | 18.31 |
| `notes.folder`, `notes.detail` | Notes d’un dossier | `/notes/folder`, `/notes/[noteUid]` | 18.32 |
| `reminders.list` | Rappels | `/reminders` | 18.33 |
### Zone 9 — Abonnement et facturation
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `subscription.overview` | Abonnement | `/subscription` | 18.34 |
| `subscription.subscribe` | Souscrire | `/subscription/subscribe`, `/subscription/new` | 18.35 |
| `subscription.manage` | Gérer l’abonnement | `/subscription/manage` | 18.36 |
| `subscription.collaborators` | Gérer les collaborateurs | `/subscription/manage-collaborators` | 18.37 |
| `subscription.invite` | Invitation | `/subscription/invite` | 18.38 |
| `subscription.success`, `subscription.error` | Succès / erreur | `/subscription/success`, `/subscription/error` | 18.39 |
### Zones 10 et 11 — Espace client et espace invité
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `client.dashboard` | Tableau de bord client | `/client-dashboard` | 18.40 |
| `client.folder-detail` | Détail dossier client | `/client-dashboard/[folderUid]` | 18.41 |
| `invitee.auth` | Connexion invité | auth tiers | 18.42 |
| `invitee.dashboard` | Tableau de bord invité | `/third-party/dashboard` | 18.43 |
### Zone 12 — Admin d’office
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `admin.portal` | Admin | `/admin` | 18.44 |
| `admin.helpers` | Helpers admin | `/admin/helpers` | 18.44 |
### Zone 13 — Admin plateforme
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `super-admin.overview` | Super-admin | `/super-admin` | 18.45 |
| `super-admin.roles` | Gestion des rôles plateforme | `/super-admin/roles-management` | 18.46 |
| `super-admin.plans` | Plans d’abonnement | `/super-admin/subscription-plans` | 18.47 |
| `super-admin.texts` | Textes du site | super-admin | 18.48 |
| `super-admin.config` | Configuration système | super-admin | 18.49 |
### Zone 14 — Contenus et paramètres globaux
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `legal.mentions` | Mentions légales | `/legal` | 18.50 |
*(Gestion des textes et de la configuration : zone 13, 18.48, 18.49.)*
### Zone 15 — Technique et design
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `design-system.doc` | Design system | `/design-system` | 18.51 |
| `anchor.verify` | Vérification d’ancrage | route publique | 18.52 |
### Zone 17 — Fonctionnalités ia_local (enso)
| Identifiant stable | Écran (référence ia_local) | Route | Actions |
|--------------------|----------------------------|--------|---------|
| `ia.dashboard` | Tableau de bord métier | dashboard | 18.53 |
| `ia.crm` | CRM (Clients, DP, Dossiers) | crm | 18.54 |
| `ia.composition-actes` | Composition d’actes | composition-actes | 18.55 |
| `ia.mise-a-jour-dp` | Mise à jour DP | mise-a-jour-dp | 18.56 |
| `ia.secretariat` | Secrétariat juridique | secretariat-juridique | 18.57 |
| `ia.renvoi-dossier` | Renvoi de dossier (partage) | renvoi-dossier | 18.58 |
| `ia.extraction-dataroom` | Extraction données dataroom | extraction-dataroom | 18.59 |
| `ia.alertes` | Alertes fins de dossiers | alertes | 18.60 |
| `ia.data-room` | Data room | data-room | 18.61 |
| `ia.courriers-ifu` | Courriers renvois IFU / RDPD DVD | courriers-ifu | 18.62 |
| `ia.workflow` | Workflow documentaire | workflow | 18.63 |
| `ia.taches` | Tâches | taches | 18.64 |
| `ia.debours` | Débours | debours | 18.65 |
| `ia.messages` | Messages / Tchat | messages | 18.66 |
| `ia.notifications` | Notifications | notifications | 18.67 |
| `ia.config-etablissements` | Configuration établissements | configuration-etablissements | 18.68 |
| `ia.admin-types` | Types et configuration | admin-types | 18.69 |
| `ia.facturation-debours` | Facturation débours | facturation-debours | 18.70 |
| `ia.courriers-annexes` | Courriers annexes aux cessions | courriers-annexes | 18.71 |
| `ia.mails-semi-auto` | Mails ou courrier semi-auto | mails-semi-auto | 18.72 |
| `ia.edition-formalites` | Édition des pièces de formalités | edition-formalites | 18.73 |
| `ia.fiche-prepa-ag` | Fiche prépa AG groupe | fiche-prepa-ag | 18.74 |
| `ia.planning-charges` | Planning des charges | planning-charges | 18.75 |
| `ia.organigramme` | Organigramme | organigramme | 18.76 |
| `ia.listing-annexes` | Listing annexes et intercalaires | listing-annexes | 18.77 |
| `ia.devis-lettre-mission` | Devis / lettre de mission | devis-lettre-mission | 18.78 |
| `ia.outlook` | Interfaçage Outlook | outlook | 18.79 |
| `ia.chat` | Chat IA | panneau | 18.80 |
| `ia.explorer` | Explorer (Commun / Datarooms) | arborescence | 18.81 |
| `ia.search` | Recherche globale | barre de recherche | 18.82 |
| `ia.my-account-devices` | Mon compte (appareils) | mon-compte | 18.83 |
### Zone 18 — Opération (cabinet/office)
| Identifiant stable | Écran | Route | Actions |
|--------------------|-------|--------|---------|
| `operations.list` | Liste des opérations | `/operations` | 18.84 |
| `operations.detail` | Détail d’une opération | `/operations/[operationUid]` | 18.85 |
| `operations.create` | Création d’opération | `/operations/create` | 18.86 |
| `operations.edit` | Édition d’opération | `/operations/[operationUid]/edit` | 18.87 |
| `operations.society` | Société liée (dans opération) | section / modal | 18.88 |
| `operations.contacts` | Contacts (dans opération) | section / modal | 18.89 |
| `operations.validate` | Validation/correction post-création | `/operations/[operationUid]/validate` | 18.94 |
| `operations.documents` | Documents (dans opération) | onglets par rôle/sous-rôle | 18.90, 18.91, 18.95 |
| `operation-types.list` | Types d’opération (paramétrage) | `/settings/operation-types` | 18.92 |
| `operation-type-steps.list` | Étapes par type d’opération (paramétrage) | `/settings/operation-types/[typeUid]/steps` | 18.96 |
| `activity-types.list` | Types d’activité (paramétrage) | `/settings/activity-types` | 18.93 |
---
## 2. Liste des actions (18.x) par écran parent
| Action | Écran parent (identifiant) | Libellé court |
|--------|----------------------------|----------------|
| 18.1 | auth.login | Connexion : saisie identifiant/mot de passe, SSO, choix office |
| 18.2 | auth.logout | Déconnexion, nettoyage session, redirection |
| 18.3 | auth.my-account | Mon compte : consulter/modifier profil, changer mot de passe |
| 18.4 | folders.list, companies.list | Liste dossiers : afficher, filtrer, trier, accès archivés/supprimés, créer ; sous **companies.list** : liste des opérations par société (enso-front) |
| 18.5 | folders.select | Sélection dossier : choisir, valider, annuler |
| 18.6 | folders.detail, companies.detail | Détail dossier : consulter, modifier, archiver, supprimer, ancrage, documents, notes, partage ; **companies.detail** : synthèse société, explorateur `instances/`, onglets Dossier permanent / Dossiers |
| 18.7 | folders.archived | Dossiers archivés : liste, restaurer, consulter |
| 18.8 | folders.deleted | Dossiers supprimés : liste, restaurer, supprimer définitivement |
| 18.9 | folders.create, folders.edit | Création/édition dossier : saisie, validation, annulation |
| 18.10 | document-types.list | Types de documents : liste, créer, ouvrir détail |
| 18.11 | document-types.create | Création type de document : saisie, enregistrer, annuler |
| 18.12 | document-types.detail | Détail type de document : consulter, modifier, supprimer |
| 18.13 | documents.folder | Documents d’un dossier : liste, téléverser, télécharger, supprimer, valider, ancrage |
| 18.14 | documents.upload, documents.detail | Téléversement/détail document : sélection fichiers, métadonnées, envoi, preuve ancrage |
| 18.15 | case-types.list | Types de dossiers : liste, créer, ouvrir détail |
| 18.16 | case-types.create | Création type de dossier : saisie, associer types documents, enregistrer |
| 18.17 | case-types.detail | Détail type de dossier : consulter, modifier, supprimer |
| 18.18 | offices.list | Liste offices : afficher, sélectionner office actif, ouvrir détail |
| 18.19 | offices.detail | Détail office : consulter, modifier, rôles, membres, RIB |
| 18.20 | offices.rib | Coordonnées bancaires : consulter, saisir/modifier, enregistrer |
| 18.21 | collaborators.list | Collaborateurs : liste, créer/inviter, ouvrir détail |
| 18.22 | collaborators.detail | Détail collaborateur : consulter, modifier rôle/droits, désactiver |
| 18.23 | users.list | Utilisateurs : liste, filtrer, ouvrir détail, créer |
| 18.24 | users.detail | Détail utilisateur : consulter, modifier, désactiver |
| 18.25 | roles.list | Rôles : liste, créer, ouvrir détail, supprimer |
| 18.26 | roles.create | Création rôle : nom, permissions, enregistrer |
| 18.27 | roles.detail | Détail rôle : consulter matrice, modifier, supprimer |
| 18.28 | customers.list | Parties au dossier : liste, créer, modifier, supprimer, lier à dossier |
| 18.29 | sharing.folder | Partage dossier : consulter, créer, modifier rôle, révoquer, renvoyer invitation |
| 18.30 | sharing.invitees | Invités : liste, ajouter, modifier rôle, renvoyer invitation, retirer |
| 18.31 | notes.list | Notes : liste, filtrer, ouvrir |
| 18.32 | notes.folder, notes.detail | Notes d’un dossier : créer, consulter, modifier, supprimer |
| 18.33 | reminders.list | Rappels : liste, détail, configurer par type/office |
| 18.34 | subscription.overview | Abonnement : consulter plan, collaborateurs, renouvellement |
| 18.35 | subscription.subscribe | Souscrire : choisir plan, paiement, valider |
| 18.36 | subscription.manage | Gérer abonnement : plan, moyens de paiement, annuler |
| 18.37 | subscription.collaborators | Gérer collaborateurs : sièges, lier collaborateurs |
| 18.38 | subscription.invite | Invitation : saisir email, envoyer, renvoyer/annuler |
| 18.39 | subscription.success, subscription.error | Succès/erreur abonnement : afficher résultat, retour |
| 18.40 | client.dashboard | Tableau de bord client : dossiers partagés, télécharger |
| 18.41 | client.folder-detail | Détail dossier client : consulter, télécharger, déposer |
| 18.42 | invitee.auth | Connexion invité : code/lien, 2FA, valider |
| 18.43 | invitee.dashboard | Tableau de bord invité : dossiers, consulter, déposer |
| 18.44 | admin.portal, admin.helpers | Admin : métriques, paramètres, liens gestion, helpers |
| 18.45 | super-admin.overview | Super-admin : vue plateforme, rôles, plans, config, textes |
| 18.46 | super-admin.roles | Rôles plateforme : afficher, modifier, matrice |
| 18.47 | super-admin.plans | Plans abonnement : liste, créer, modifier, désactiver |
| 18.48 | super-admin.texts | Textes du site : liste, créer/modifier, publier |
| 18.49 | super-admin.config | Configuration système : clés, créer/modifier, masquer/révéler |
| 18.50 | legal.mentions | Mentions légales : consulter (lecture seule) |
| 18.51 | design-system.doc | Design system : consulter doc composants/tokens |
| 18.52 | anchor.verify | Vérification ancrage : saisir lien, afficher résultat |
| 18.53 à 18.83 | ia.* | Voir section 17 de la cartographie et SPEC_17_ia_local |
| 18.84 | operations.list | Liste opérations : afficher, filtrer, trier, créer |
| 18.85 | operations.detail | Détail opération : consulter, modifier, entreprise, contacts, documents |
| 18.86 | operations.create | Création opération : saisie, validation, annulation |
| 18.87 | operations.edit | Édition opération : modifier sections |
| 18.88 | operations.society | Société liée : saisie, extraction KBIS, commentaires |
| 18.89 | operations.contacts | Contacts : ajout, modification, suppression, alerte doublon |
| 18.90 | operations.documents | Documents : liste, upload, workflow |
| 18.91 | operations.documents | Upload ZIP : répartition IA par type de document |
| 18.94 | operations.validate | Validation post-création : infos, contacts, affectations ZIP, fichiers de synthèse |
| 18.95 | operations.documents | Actions documents : demande, relance, exclusion, modification, suppression, visualisation preview, téléchargement, validation, refus (selon droits) |
| 18.92 | operation-types.list | Types d’opération : liste, créer, modifier, supprimer |
| 18.96 | operation-type-steps.list | Étapes par type d’opération : liste, créer, modifier, ordre |
| 18.93 | activity-types.list | Types d’activité : liste, créer, modifier, supprimer |
---
## 3. Usage pour le paramétrage
- **Écrans :** chaque identifiant stable (ex. `folders.list`, `ia.workflow`) est la clé d’entrée pour la table ou entité `screen_config` (visible, ordre, libellé, accès, condition). Voir [PARAMETRAGE_ECRANS_ACTIONS.md](PARAMETRAGE_ECRANS_ACTIONS.md) section 3.
- **Actions :** chaque numéro 18.x (et éventuellement un identifiant dérivé tel que `folder.create`, `document.download`) est la clé pour `action_config` (visible, activée, droits, condition). Voir PARAMETRAGE section 4.
- Aucun écran ni action ne doit être codé en dur comme toujours visible ou masqué sans passer par ce paramétrage.

76
services/docv/enso-docs/features/SPECIFIQUES_PROJETS.md Normal file
View File

@ -0,0 +1,76 @@
# Spécifiques du projet enso
**Principe :** Le **code** est dans **docv**. Le projet **enso** fait de la **configuration** (paramétrage des écrans, actions, options, données par défaut) plus des **spécifiques uniques** lorsqu’un besoin n’est pas couvert par docv. **Tous les spécifiques doivent être confirmés** avant implémentation.
**Référence :** `docs/ARCHITECTURE_DOCV_ENSO.md` (section 1ter).
---
## 1. Règle de confirmation
- Tout **spécifique** (écran, action, service métier, intégration API, libellé ou flux non générique) proposé pour **enso** doit être **listé** dans ce document avec le statut **À faire confirmer**.
- Aucune implémentation d’un spécifique ne doit commencer sans **confirmation explicite** (passage du statut à **Confirmé**).
- Après confirmation, le spécifique peut être implémenté dans **enso** ; si le besoin devient générique, il peut être remonté dans docv après validation.
---
## 2. Spécifiques enso (avocats)
Écrans, actions, services ou intégrations propres à enso, non couverts par le socle docv générique. Correspondance avec la zone 17 (ia_local), les écrans et actions 18.x : voir **`docs/enso/README.md`** (section 3).
| # | Spécifique | Description | Statut |
|---|------------|-------------|--------|
| E1 | Composition d’actes | Écran et flux de rédaction d’actes à partir de données extraites (Excel, PDF, JPG) ; listes salariés, contrats, baux, KBIS, conventions intragroupe. | À faire confirmer |
| E2 | Mise à jour DP (Dossier Permanent) | Écran et flux de mise à jour automatique du dossier permanent à partir de KBIS, PV AG, baux, statuts, etc. | À faire confirmer |
| E3 | Secrétariat juridique | Prérédaction AG, PV, résolutions ; données comptables ; alertes (réserve légale, seuils CAC, etc.) ; convocations et publipostage. | À faire confirmer |
| E4 | Renvoi de dossier (partage clients / CAC / comptabilité) | Partage de documents avec clients, comptabilité, CAC ; gestion des destinataires et des accès. | À faire confirmer |
| E5 | Extraction données dataroom | Synthèse des pièces de la dataroom ; rapport d’audit (baux, emprunts, CRD, etc.). | À faire confirmer |
| E6 | Alertes fins de dossiers | Alertes par type et échéance (baux, marques, pactes Dutreil, mandats, rapports d’imposition) ; notifications associé / collaborateur. | À faire confirmer |
| E7 | Data room (espaces partagés) | Espace partagé avec droits viewer/editor, invitations, date de fin d’accès, notifications à chaque dépôt. | À faire confirmer |
| E8 | Courriers renvois IFU / RDPD DVD | Intégration RDPD DVD, publipostage des courriers de renvoi ; ou classement automatique par IFU (SIRET). | À faire confirmer |
| E9 | Workflow documentaire (vue par statut) | Documents par statut (à demander, demandé, reçu, validé, refusé) ; transitions par rôle ; lien tâches ↔ statut. | À faire confirmer |
| E10 | Tâches métier (échéances, assignation) | Liste des tâches par dossier, prochaines échéances, affectation aux collaborateurs. | À faire confirmer |
| E11 | Débours | Liste des débours par dossier ; statuts (en attente, validé, refusé, payé) ; validation ; synthèse. | À faire confirmer |
| E12 | Messages / Tchat par contexte | Fil de discussion par dossier ou établissement ; pièces jointes ; lien avec l’IA. | À faire confirmer |
| E13 | CRM (Clients, DP, Dossiers) | Vue d’ensemble clients et dossiers permanents ; recherche CRM ; navigation vers un dossier ou une grande activité. | À faire confirmer |
| E14 | Configuration établissements | Admin : liste des établissements ; ajout, modification, suppression (rôle associé). | À faire confirmer |
| E15 | Types et configuration (grandes activités, etc.) | Gestion des types : documents, dossiers, tâches, alertes, débours, grandes activités, rôles, établissements, clients, contrats, salariés, membres. | À faire confirmer |
| E16 | Facturation débours | Workflow de facturation des débours ; transmission dématérialisée ; comparaison provision / débours ; validation en fin de dossier. | À faire confirmer |
| E17 | Courriers annexes aux cessions | Génération de courriers types (salariés, urbanisme, bailleur, séquestre, renvoi chèque séquestre). | À faire confirmer |
| E18 | Mails ou courrier semi-auto pour alertes | Envoi semi-automatique de mails pour alertes (plus-value, report d’imposition, baux, marques) avec texte pré-rédigé. | À faire confirmer |
| E19 | Édition des pièces de formalités | Génération de pièces (pouvoir, déclaration non-condamnation, 2759, LAB, extrait PV, domiciliation, statuts, cession de fonds). | À faire confirmer |
| E20 | Fiche prépa AG groupe | Données N à N-3 (dividendes, résultats), conventions intragroupe, rémunération dirigeants, fin de mandat CAC / dirigeant. | À faire confirmer |
| E21 | Planning des charges | Affectation des tâches aux collaborateurs ; liste des tâches avec échéances et état d’avancement. | À faire confirmer |
| E22 | Organigramme | Visualisation de l’organigramme (actionnariat, structure) à partir des feuilles de présence ou statuts. | À faire confirmer |
| E23 | Listing annexes et intercalaires | Liste des annexes d’un acte ; génération d’intercalaires ; compilation PDF des annexes. | À faire confirmer |
| E24 | Devis / lettre de mission | Création automatique de devis ou lettre de mission. | À faire confirmer |
| E25 | Interfaçage Outlook | Lien des mails Outlook avec le dossier client concerné. | À faire confirmer |
| E26 | Chat IA contextuel | Chat avec l’IA ; contexte de l’arborescence Explorer ; envoi « Montre-moi [rubrique] » depuis l’Explorer. | À faire confirmer |
| E27 | Explorer (Commun / Datarooms) | Arborescence des dossiers ; Datarooms pour le rôle client, Commun pour les rôles internes. | À faire confirmer |
| E28 | Recherche globale (texte et tags) | Recherche texte libre et par tags (#tag) ; filtres établissement, dossier, client, dates. | À faire confirmer |
| E29 | Mon compte – appareils | Gestion des appareils enregistrés (en plus du profil et du mot de passe). | À faire confirmer |
| E30 | Thème / design enso | Surcharges du design system docv (couleurs, marque ENSO Avocats). | À faire confirmer |
| E31 | Textes et libellés avocat | Textes i18n et libellés métier spécifiques avocat (structure héritée docv, surcharges enso). | À faire confirmer |
---
## 3. Périmètre notaire (hors dépôt actuel)
Intégrations ou spécifiques propres à un déploiement notarial ne sont pas listés ici pour l’instant. Orientation : **`docs/HORS_PERIMETRE_NOTAIRE.md`**.
---
## 4. Processus de confirmation
1. **Proposition** : ajouter ou modifier une ligne dans la section 2 avec le statut **À faire confirmer** et une description claire.
2. **Validation** : un responsable valide le spécifique (hors scope du présent document : qui valide, selon quel canal).
3. **Mise à jour** : passer le statut à **Confirmé** et, si besoin, indiquer la date ou la référence de validation.
4. **Implémentation** : le spécifique peut alors être développé dans **enso** (sans modifier docv sauf si remontée de besoin générique validée).
5. **Remontée dans docv** : si un spécifique devient un besoin commun à plusieurs déclinaisons sur **docv**, une évolution docv peut être planifiée ; le spécifique reste listé ici avec une mention du type « Remonté dans docv (réf. …) ».
---
## 5. Configuration vs spécifique
- **Configuration** : utilisation des mécanismes de paramétrage (écrans, actions, options, seeds, system_configuration, rôles, types de documents/dossiers). Aucune confirmation spécifique n’est requise pour ajouter une **valeur** de configuration (ex. un nouveau type de document dans l’office) ; la **structure** de configuration est dans docv.
- **Spécifique** : **code** ou **flux métier** ou **intégration API** qui n’existe pas dans docv et qui est propre à **enso**. Tout spécifique doit être listé ici et confirmé avant implémentation.

73
services/docv/enso-docs/features/implementation/IMPL_01_auth_compte.md Normal file
View File

@ -0,0 +1,73 @@
# Implémentation technique : Authentification et compte
**Zone** : 1 — Authentification et compte
**Spec fonctionnelle** : [SPEC_01_auth_compte.md](../specs/SPEC_01_auth_compte.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 1.
## 1. Vue d’ensemble
- **Périmètre** : front (pages login, logout-callback, my-account), back (handlers auth, user), BDD (users, sessions/tokens), paramétrage (auth.login, auth.logout, auth.my-account).
- **Dépendances** : zone 5 (Offices) pour le choix d’office actif ; pas de client externe ancrage/IA.
## 2. Écrans (détail technique)
### auth.login — Connexion
- **Route(s)** : `app/(auth)/login/page.tsx` (ou `pages/login.tsx`).
- **Front** :
- Page : formulaire login (email/identifiant, mot de passe), bouton SSO si activé, lien « Mot de passe oublié » si prévu. Après succès : si multi-offices, redirection vers sélecteur d’office ; sinon vers dashboard.
- Composants : `LoginForm`, `Input`, `Button`, éventuellement `OfficeSelector` (modal ou page dédiée).
- State : local (email, password, loading, errorMessage) ; pas de store global pour les credentials.
- Appels API : `POST /auth/login` (body: email, password) au submit ; réponse : token/session + user + offices ; `GET /auth/me` ou équivalent après login pour hydrater le contexte.
- Validation : email format, mot de passe non vide (côté client) ; erreur 401 → message i18n (clé `auth.login.error`).
- Paramétrage : `auth.login` ; visibilité SSO selon config plateforme.
- **Back** :
- Handler : `handlers/auth.rs` — `POST /auth/login` : extraire body, appeler `auth_service::login`, retourner token + user (+ offices si multi).
- Service : `auth_service::login` : vérifier credentials (user_repository), générer token/session, logger échec.
- Repository : `user_repository::find_by_email`, éventuellement `session_repository::create`.
- **BDD** : `users` (id, email, password_hash, name, phone, preferences, …) ; table `sessions` ou token JWT sans persistance selon implémentation.
- **Paramétrage** : identifiant `auth.login` ; pas de condition d’affichage (écran public).
### auth.logout — Déconnexion
- **Route(s)** : `app/logout-callback/page.tsx` ou redirect côté client vers `/logout-callback` puis nettoyage.
- **Front** :
- Page ou middleware : appel `POST /auth/logout` (avec token), suppression token/session du storage, redirection vers `/login` ou page publique.
- State : aucun ; nettoyage du store auth (user, token).
- Appels API : `POST /auth/logout` (header Authorization).
- **Back** :
- Handler : `POST /auth/logout` : invalider session/token (auth_service), retour 204.
- Service : `auth_service::logout` : suppression session en BDD ou blacklist token.
- **BDD** : `sessions` si persistées ; sinon JWT stateless (blacklist optionnelle).
- **Paramétrage** : `auth.logout` ; visible après connexion (lien header/footer).
### auth.my-account — Mon compte
- **Route(s)** : `app/(dashboard)/my-account/page.tsx`.
- **Front** :
- Page : formulaire profil (nom, email, téléphone, préférences), section changement mot de passe (ancien, nouveau, confirmation), bouton Enregistrer.
- Composants : `ProfileForm`, `PasswordForm`, `Input`, `Button`.
- State : user depuis context/store ; local pour formulaire (dirty), loading, errors.
- Appels API : `GET /auth/me` au mount ; `PATCH /users/me` (profil), `POST /auth/change-password` (body: currentPassword, newPassword) au submit.
- Validation : email format, téléphone optionnel ; mot de passe : complexité (WASM ou utils), confirmation égale. Messages i18n `my-account.profile.error`, `my-account.password.error`.
- Paramétrage : `auth.my-account` ; visible si utilisateur authentifié et option activée (screen_config par office).
- **Back** :
- Handlers : `GET /auth/me` (middleware auth), `PATCH /users/me`, `POST /auth/change-password` dans `handlers/auth.rs` ou `handlers/users.rs`.
- Services : `user_service::update_me`, `auth_service::change_password` (vérifier ancien, hasher nouveau, mettre à jour user).
- Repository : `user_repository::update`.
- **BDD** : `users` (name, email, phone, preferences, password_hash).
- **Paramétrage** : `auth.my-account` ; condition : config par office (visible/non).
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.1 | Formulaire login, bouton Connexion / SSO | POST /auth/login | auth handler → auth_service::login → user_repository | 401 → message erreur ; champs requis |
| 18.2 | Lien Déconnexion, redirect /logout-callback | POST /auth/logout | auth handler → auth_service::logout | 4xx → afficher message, rediriger quand même |
| 18.3 | Formulaire profil / mot de passe, bouton Enregistrer | GET /auth/me (mount), PATCH /users/me, POST /auth/change-password | auth/users handlers → user_service, auth_service | 400 validation ; 401 si mot de passe actuel incorrect |
## 4. Points d’attention
- Tokens : stockage sécurisé (httpOnly cookie ou storage protégé) ; jamais mot de passe en clair côté client.
- Erreurs : types `AuthError`, `ValidationError` ; pas de fallback silencieux sur login/logout.
- i18n : `auth.login.title`, `auth.login.error`, `auth.logout`, `my-account.title`, `my-account.profile.success`, `my-account.password.error`.

72
services/docv/enso-docs/features/implementation/IMPL_02_dossiers.md Normal file
View File

@ -0,0 +1,72 @@
# Implémentation technique : Dossiers
**Zone** : 2 — Dossiers
**Spec fonctionnelle** : [SPEC_02_dossiers.md](../specs/SPEC_02_dossiers.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 2.
## 1. Vue d’ensemble
- **Périmètre** : front (folders liste, sélection, détail, archivés, supprimés, création/édition), back (handlers folders), BDD (folders, folder_parties), paramétrage (folders.*). Ancrage optionnel (back).
- **Espace client enso (docv)** : champs réels `folder_purpose`, `operation_type` ; UI liste opérations vs blocs « structures type (démo) » — voir [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](../MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md) et [DOCV_API_ENSO_FRONT_MAP.md](../DOCV_API_ENSO_FRONT_MAP.md).
- **Dépendances** : zone 4 (types de dossiers), zone 7 (parties), zone 3 (documents) ; anchoring_client si activé.
## 2. Écrans (détail technique)
### folders.list — Liste des dossiers
- **Route(s)** : `app/(dashboard)/folders/page.tsx`.
- **Front** : Liste paginée, filtres (statut, type, recherche), tri ; `GET /folders` (query: page, status, folder_type_uid, q) ; liens archivés, supprimés, bouton Créer. State : liste, filters, pagination. Paramétrage : `folders.list`.
- **Back** : `GET /folders` → folder_service::list (office_uid depuis context) → folder_repository (pagination, filtres).
- **BDD** : `folders` (uid, office_uid, name, folder_type_uid, status, description, created_at, archived_at, deleted_at).
### folders.select — Sélection de dossier
- **Route(s)** : `app/(dashboard)/folders/select/page.tsx` ou modal `FolderSelectModal`.
- **Front** : Liste/recherche dossiers ; `GET /folders` (limit, q) ; bouton Valider (retour avec folderUid), Annuler. Paramétrage : `folders.select`.
- **Back** : même GET /folders.
- **BDD** : `folders`.
### folders.detail — Détail d’un dossier
- **Route(s)** : `app/(dashboard)/folders/[folderUid]/page.tsx`.
- **Front** : En-tête (nom, type, statut, dates), onglets ou sections (parties, documents, notes, partages) ; `GET /folders/:id` ; actions Modifier, Archiver, Supprimer, Ancrage selon action_config ; téléversement document, ajout note, gestion partage (zones 3, 7, 8). Paramétrage : `folders.detail`.
- **Back** : `GET /folders/:id`, `PATCH /folders/:id`, `POST /folders/:id/archive`, `POST /folders/:id/restore`, `DELETE /folders/:id` (soft), `DELETE /folders/:id/permanent` ; folder_service, folder_repository.
- **BDD** : `folders`, `folder_parties`, `documents`, `notes`, `folder_shares`.
### folders.archived — Dossiers archivés
- **Route(s)** : `app/(dashboard)/folders/archived/page.tsx`.
- **Front** : `GET /folders/archived` ; liste ; Restaurer, Consulter détail. Paramétrage : `folders.archived`.
- **Back** : `GET /folders/archived` → folder_repository où archived_at IS NOT NULL.
- **BDD** : `folders`.
### folders.deleted — Dossiers supprimés
- **Route(s)** : `app/(dashboard)/folders/deleted/page.tsx`.
- **Front** : `GET /folders/deleted` ; Restaurer, Supprimer définitivement. Paramétrage : `folders.deleted`.
- **Back** : `GET /folders/deleted`, `POST /folders/:id/restore`, `DELETE /folders/:id/permanent`.
- **BDD** : `folders` (deleted_at).
### folders.create, folders.edit — Création / édition de dossier
- **Route(s)** : `app/(dashboard)/folders/new/page.tsx`, `folders/[folderUid]/edit/page.tsx` ou modal.
- **Front** : Formulaire (nom, type de dossier, description, parties liées) ; `GET /folder-types`, `GET /customers` pour listes ; `POST /folders`, `PATCH /folders/:id`. Validation nom et type requis. Paramétrage : `folders.create`, `folders.edit`.
- **Back** : folder_service::create, update ; folder_repository, folder_party_repository.
- **BDD** : `folders`, `folder_parties`.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.4 | Page liste, filtres, tri, liens | GET /folders, GET /folders/archived, /deleted | folder_service | 403 |
| 18.5 | Modal sélection, Valider | GET /folders, retour context | folder_service | 404 |
| 18.6 | Détail dossier, onglets, boutons | GET/PATCH /folders/:id, POST archive/restore, DELETE | folder_service, anchoring si activé | 403, 404 |
| 18.7 | Page archivés | GET /folders/archived, POST restore | folder_service | 403 |
| 18.8 | Page supprimés | GET /folders/deleted, POST restore, DELETE permanent | folder_service | 403 |
| 18.9 | Formulaire création/édition | POST /folders, PATCH /folders/:id | folder_service | Nom et type requis |
## 4. Points d’attention
- Transitions statut : ouvert → archivé (archived_at), → supprimé (deleted_at) ; restauration remet deleted_at/archived_at à NULL.
- Ancrage : appel back depuis folder_service ou document_service selon périmètre.
- i18n : `folders.*`, `folders.archived`, `folders.deleted`.

63
services/docv/enso-docs/features/implementation/IMPL_03_documents_types.md Normal file
View File

@ -0,0 +1,63 @@
# Implémentation technique : Documents et types de documents
**Zone** : 3 — Documents et types de documents
**Spec fonctionnelle** : [SPEC_03_documents_types.md](../specs/SPEC_03_documents_types.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 3.
## 1. Vue d’ensemble
- **Périmètre** : front (document-types liste/création/détail, documents dans détail dossier, upload/détail document), back (handlers document_types, documents, upload), BDD (document_types, documents, stockage fichiers), paramétrage (document-types.*, documents.*). Ancrage appelé par le back si activé.
- **Dépendances** : zone 2 (dossiers) ; zone 4 (types de dossiers) ; client ancrage (back) si activé.
## 2. Écrans (détail technique)
### document-types.list — Types de documents
- **Route(s)** : `app/(dashboard)/document-types/page.tsx`.
- **Front** : Liste types de l’office ; `GET /document-types` ; Créer, lien détail. Paramétrage : `document-types.list`.
- **Back** : `GET /document-types` → document_type_service::list_by_office → document_type_repository.
- **BDD** : `document_types` (uid, office_uid, label, description, is_required).
### document-types.create — Création type de document
- **Route(s)** : `app/(dashboard)/document-types/create/page.tsx`.
- **Front** : Formulaire (libellé, description, obligatoire) ; `POST /document-types`. Paramétrage : `document-types.create`.
- **Back** : `POST /document-types` → document_type_service::create → document_type_repository.
- **BDD** : `document_types`.
### document-types.detail — Détail type de document
- **Route(s)** : `app/(dashboard)/document-types/[documentTypeUid]/page.tsx`.
- **Front** : GET /document-types/:id, PUT, DELETE (si non utilisé). Paramétrage : `document-types.detail`.
- **Back** : document_type_service ; delete refusé si documents utilisent ce type.
- **BDD** : `document_types`, `documents`.
### documents.folder — Documents d’un dossier
- **Route(s)** : Onglet ou section dans `app/(dashboard)/folders/[folderUid]/page.tsx` (composant `DocumentList` ou équivalent).
- **Front** : `GET /folders/:folderUid/documents` ; liste avec actions (télécharger, supprimer, valider, preuve ancrage) selon action_config ; bouton Téléverser ouvre modal. Paramétrage : `documents.folder`, actions 18.13.
- **Back** : `GET /folders/:folderUid/documents`, `POST` (upload), `GET/DELETE /documents/:id`, `POST /documents/:id/validate` ; service document peut appeler anchoring_client après validation.
- **BDD** : `documents` (uid, folder_uid, document_type_uid, file_ref, status, anchored_at), stockage fichiers (S3 ou filesystem).
### documents.upload, documents.detail — Téléversement / détail document
- **Route(s)** : Modal ou panneau dans contexte dossier ; route optionnelle `folders/[folderUid]/documents/new`, `documents/[documentUid]`.
- **Front** : Formulaire upload (fichiers, métadonnées, type de document) ; `POST /folders/:folderUid/documents` (multipart) ; affichage détail (statut, preuve ancrage en lecture seule). Paramétrage : `documents.upload`, `documents.detail`.
- **Back** : Upload handler (multipart) → document_service::create → stockage fichier + ligne BDD ; ancrage appelé selon config (workflow ou manuel).
- **BDD** : `documents`, stockage fichiers.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.10 | Page types de documents | GET /document-types | document_type_service | 403 |
| 18.11 | Formulaire création type | POST /document-types | document_type_service::create | Label requis |
| 18.12 | Fiche type, Enregistrer / Supprimer | GET/PUT/DELETE /document-types/:id | document_type_service | 409 si type utilisé |
| 18.13 | Liste documents dossier, boutons | GET/POST /folders/:id/documents, GET/DELETE /documents/:id, POST validate | document_service | 413 taille, 415 type fichier |
| 18.14 | Modal upload, détail | POST multipart, GET /documents/:id | document_service, anchoring_client si activé | Erreur upload, ancrage |
## 4. Points d’attention
- Upload : limite taille et types MIME depuis config ; pas de fallback silencieux sur échec.
- Ancrage : appel back uniquement (document_service ou job async) ; preuve stockée et renvoyée en GET.
- i18n : `document-types.*`, `documents.*`, `upload.*`.

46
services/docv/enso-docs/features/implementation/IMPL_04_types_dossiers.md Normal file
View File

@ -0,0 +1,46 @@
# Implémentation technique : Types de dossiers
**Zone** : 4 — Types de dossiers
**Spec fonctionnelle** : [SPEC_04_types_dossiers.md](../specs/SPEC_04_types_dossiers.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 4.
## 1. Vue d’ensemble
- **Périmètre** : front (case-types liste, création, détail), back (handlers folder_types / case_types), BDD (folder_types, folder_type_document_types), paramétrage (case-types.*).
- **Dépendances** : zone 3 (types de documents) pour les associations ; pas de client externe.
## 2. Écrans (détail technique)
### case-types.list — Types de dossiers
- **Route(s)** : `app/(dashboard)/case-types/page.tsx` ou `folder-types/page.tsx`.
- **Front** : Liste des types de dossiers de l’office ; `GET /folder-types` (ou /case-types) ; bouton Créer, lien détail. Paramétrage : `case-types.list`.
- **Back** : Handler `GET /folder-types` → folder_type_service::list_by_office → folder_type_repository.
- **BDD** : `folder_types` (uid, office_uid, label).
### case-types.create — Création type de dossier
- **Route(s)** : `app/(dashboard)/case-types/create/page.tsx`.
- **Front** : Formulaire libellé + liste types de documents (requis/optionnel) ; `GET /document-types` pour les options ; `POST /folder-types` (body: label, document_types: [{ document_type_uid, is_required }]). Paramétrage : `case-types.create`.
- **Back** : `POST /folder-types` → folder_type_service::create → folder_type_repository + folder_type_document_type_repository.
- **BDD** : `folder_types`, `folder_type_document_types` (folder_type_uid, document_type_uid, is_required).
### case-types.detail — Détail type de dossier
- **Route(s)** : `app/(dashboard)/case-types/[caseTypeUid]/page.tsx`.
- **Front** : Affichage propriétés + types de documents liés ; `GET /folder-types/:id` ; formulaire édition, `PUT /folder-types/:id` ; Supprimer (si non utilisé). Paramétrage : `case-types.detail`.
- **Back** : `GET /folder-types/:id`, `PUT /folder-types/:id`, `DELETE /folder-types/:id` ; delete refusé si des dossiers utilisent ce type (folder_repository::count_by_type).
- **BDD** : `folder_types`, `folder_type_document_types`, `folders`.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.15 | Page types de dossiers | GET /folder-types | folder_type_service | 403 |
| 18.16 | Formulaire création | POST /folder-types | folder_type_service::create | Label requis, document_types optionnels |
| 18.17 | Fiche type, Enregistrer / Supprimer | GET/PUT/DELETE /folder-types/:id | folder_type_service | 409 si type utilisé (delete) |
## 4. Points d’attention
- Suppression : vérifier `SELECT COUNT(*) FROM folders WHERE folder_type_uid = ?` avant delete.
- i18n : `case-types.*`, `folder-types.*`.

79
services/docv/enso-docs/features/implementation/IMPL_05_offices_membres.md Normal file
View File

@ -0,0 +1,79 @@
# Implémentation technique : Offices et membres
**Zone** : 5 — Offices et membres
**Spec fonctionnelle** : [SPEC_05_offices_membres.md](../specs/SPEC_05_offices_membres.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 5.
## 1. Vue d’ensemble
- **Périmètre** : front (offices, collaborators, users, RIB), back (handlers offices, collaborators, users, rib), BDD (offices, office_members, users, office_rib), paramétrage (offices.*, collaborators.*, users.*).
- **Dépendances** : zone 1 (auth, office actif) ; zone 6 (rôles) pour les droits ; pas de client externe.
## 2. Écrans (détail technique)
### offices.list — Liste des offices
- **Route(s)** : `app/(dashboard)/offices/page.tsx`.
- **Front** : Page liste ; composants `OfficeList`, `OfficeCard` ; state : offices depuis API, officeActif depuis context ; `GET /offices` au mount ; sélection office actif → `PATCH /users/me` ou `POST /context/office` (selon API). Paramétrage : `offices.list`.
- **Back** : Handler `GET /offices` → office_service::list_for_user → office_repository ; retour liste offices accessibles à l’utilisateur.
- **BDD** : `offices`, `office_members` (user_uid, office_uid, role_uid).
### offices.detail — Détail d’un office
- **Route(s)** : `app/(dashboard)/offices/[officeUid]/page.tsx`.
- **Front** : Fiche office (nom, adresse, paramètres), liens vers RIB, collaborateurs, rôles ; `GET /offices/:id` ; `PUT /offices/:id` (formulaire). Paramétrage : `offices.detail`.
- **Back** : `GET /offices/:id`, `PUT /offices/:id` → office_service → office_repository ; vérification droit admin office.
- **BDD** : `offices` (uid, name, address, …).
### offices.rib — Coordonnées bancaires
- **Route(s)** : `app/(dashboard)/offices/rib/page.tsx` ou sous-route `offices/[officeUid]/rib`.
- **Front** : Formulaire RIB (IBAN, BIC, etc.) ; `GET /offices/:id/rib`, `PUT /offices/:id/rib`. Affichage masqué (derniers caractères). Paramétrage : `offices.rib`.
- **Back** : Handlers rib ; office_rib_repository ; valeurs sensibles masquées en lecture.
- **BDD** : `office_rib` (office_uid, iban_encrypted, bic, …).
### collaborators.list — Collaborateurs
- **Route(s)** : `app/(dashboard)/collaborators/page.tsx`.
- **Front** : Liste collaborateurs de l’office actif ; `GET /collaborators` (query office_uid ou depuis context) ; lien création/invitation. Paramétrage : `collaborators.list`.
- **Back** : `GET /collaborators` → collaborator_service::list_by_office → office_members + users.
- **BDD** : `office_members`, `users`.
### collaborators.detail — Détail collaborateur
- **Route(s)** : `app/(dashboard)/collaborators/[collaboratorUid]/page.tsx`.
- **Front** : Fiche profil, rôle, dossiers partagés ; `GET /collaborators/:id`, `PATCH /collaborators/:id` (rôle, droits). Paramétrage : `collaborators.detail`.
- **Back** : collaborator_service (get, update) ; office_members update.
- **BDD** : `office_members`, `users`.
### users.list — Utilisateurs
- **Route(s)** : `app/(dashboard)/users/page.tsx`.
- **Front** : Liste utilisateurs (office ou plateforme selon rôle) ; `GET /users` (query scope) ; filtre, recherche. Paramétrage : `users.list`.
- **Back** : `GET /users` → user_service::list (scope office ou super-admin) → user_repository.
- **BDD** : `users`, `office_members`.
### users.detail — Détail utilisateur
- **Route(s)** : `app/(dashboard)/users/[userUid]/page.tsx`.
- **Front** : Fiche profil, offices, rôles ; `GET /users/:id`, `PATCH /users/:id`, désactivation. Paramétrage : `users.detail`.
- **Back** : user_service::get, update, deactivate ; user_repository, office_members.
- **BDD** : `users`, `office_members`.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.18 | Page offices, sélecteur | GET /offices, PATCH context office | office_service::list_for_user | 403 si non membre |
| 18.19 | Clic détail office | GET /offices/:id, PUT /offices/:id | office_service | 404, 403 |
| 18.20 | Formulaire RIB | GET/PUT /offices/:id/rib | office_rib_service | Validation IBAN/BIC |
| 18.21 | Liste collaborateurs, bouton Créer | GET /collaborators, POST /collaborators | collaborator_service | 403 |
| 18.22 | Fiche collaborateur | GET/PATCH /collaborators/:id, DELETE | collaborator_service | 403, 404 |
| 18.23 | Liste utilisateurs | GET /users | user_service | scope office/plateforme |
| 18.24 | Fiche utilisateur | GET/PATCH /users/:id | user_service | 403, désactivation irréversible |
## 4. Points d’attention
- RIB : chiffrement ou masquage en BDD ; audit log sur consultation/modification.
- Changement d’office actif : mise à jour contexte global ; rechargement config écrans/actions (paramétrage).
- i18n : clés `offices.*`, `collaborators.*`, `users.*`, `rib.*`.

47
services/docv/enso-docs/features/implementation/IMPL_06_roles_permissions.md Normal file
View File

@ -0,0 +1,47 @@
# Implémentation technique : Rôles et permissions
**Zone** : 6 — Rôles et permissions
**Spec fonctionnelle** : [SPEC_06_roles_permissions.md](../specs/SPEC_06_roles_permissions.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 6.
## 1. Vue d’ensemble
- **Périmètre** : front (pages roles liste, création, détail avec matrice permissions), back (handlers roles, permissions), BDD (roles, role_permissions), paramétrage (roles.*).
- **Dépendances** : zone 5 (office) ; pas de client externe.
## 2. Écrans (détail technique)
### roles.list — Rôles
- **Route(s)** : `app/(dashboard)/roles/page.tsx`.
- **Front** : Liste des rôles (globaux et/ou par office) ; `GET /roles` (query office_uid) ; bouton Créer, lien vers détail ; paramétrage `roles.list`.
- **Back** : Handler `GET /roles` → role_service::list → role_repository (filtré par office ou scope).
- **BDD** : `roles` (uid, office_uid nullable, name).
### roles.create — Création rôle
- **Route(s)** : `app/(dashboard)/roles/create/page.tsx`.
- **Front** : Formulaire nom + matrice permissions (ressources × actions, cases à cocher ou sélecteurs) ; `POST /roles` (body: name, office_uid?, permissions[]) ; validation nom requis. Paramétrage : `roles.create`.
- **Back** : `POST /roles` → role_service::create → role_repository + role_permission_repository (bulk insert).
- **BDD** : `roles`, `role_permissions` (role_uid, resource, action, granted).
### roles.detail — Détail rôle
- **Route(s)** : `app/(dashboard)/roles/[roleUid]/page.tsx`.
- **Front** : Affichage rôle + matrice ; `GET /roles/:id` (avec permissions) ; formulaire édition nom + permissions, `PUT /roles/:id` ; bouton Supprimer (si non utilisé). Paramétrage : `roles.detail`.
- **Back** : `GET /roles/:id`, `PUT /roles/:id`, `DELETE /roles/:id` → role_service (get, update, delete si aucun usage) ; vérification usage (office_members, etc.) avant delete.
- **BDD** : `roles`, `role_permissions`.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.25 | Page rôles | GET /roles, POST /roles (créer), DELETE | role_service | 403 admin ; 409 si nom dupliqué |
| 18.26 | Formulaire création | POST /roles | role_service::create | Validation nom, permissions array |
| 18.27 | Fiche rôle, Enregistrer / Supprimer | GET/PUT/DELETE /roles/:id | role_service | 400 si rôle utilisé (delete) |
## 4. Points d’attention
- Rôles système : flag ou convention (ex. name préfixé) pour interdire suppression.
- Matrice : liste ressources/actions depuis config ou endpoint `GET /permissions/schema` ; stockage role_permissions en bulk.
- i18n : `roles.title`, `roles.create`, `roles.permissions.*`.

47
services/docv/enso-docs/features/implementation/IMPL_07_parties_partage.md Normal file
View File

@ -0,0 +1,47 @@
# Implémentation technique : Parties au dossier et partage
**Zone** : 7 — Parties au dossier et partage
**Spec fonctionnelle** : [SPEC_07_parties_partage.md](../specs/SPEC_07_parties_partage.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 7.
## 1. Vue d’ensemble
- **Périmètre** : front (customers liste/création/édition, partage et invités dans détail dossier), back (handlers customers, folder_shares), BDD (customers, folder_parties, folder_shares), envoi emails invitations. Paramétrage : customers.*, sharing.*.
- **Dépendances** : zone 2 (dossiers) ; zone 10–11 (espaces client/invité pour destinataires).
## 2. Écrans (détail technique)
### customers.list — Parties au dossier
- **Route(s)** : `app/(dashboard)/customers/page.tsx`.
- **Front** : Liste parties (clients) ; `GET /customers` (office) ; Créer, modifier, supprimer, lier à dossier. Paramétrage : `customers.list`.
- **Back** : `GET /customers`, `POST /customers`, `GET/PATCH/DELETE /customers/:id` → customer_service → customer_repository.
- **BDD** : `customers` (uid, office_uid, name, email, …), `folder_parties` (folder_uid, customer_uid).
### sharing.folder — Partage de dossier
- **Route(s)** : Section dans `app/(dashboard)/folders/[folderUid]/page.tsx` (onglet Partages ou panneau).
- **Front** : Liste partages actifs ; `GET /folders/:id/shares` ; ajouter partage (office ou email), modifier rôle, révoquer, renvoyer invitation ; `POST /folders/:id/shares`, `PATCH/DELETE /folders/:id/shares/:shareId`, `POST .../resend`. Paramétrage : `sharing.folder`.
- **Back** : folder_share_service (create, list, update role, revoke, resend) ; envoi email via service notification ou queue.
- **BDD** : `folder_shares` (folder_uid, target_office_uid ou invitee_email, role, status, token).
### sharing.invitees — Parties externes / invités
- **Route(s)** : Même contexte détail dossier ; liste invités avec email, rôle, actions (modifier rôle, renvoyer, retirer).
- **Front** : Mêmes endpoints que sharing.folder ; distinction UI invités (email) vs partage office. Paramétrage : `sharing.invitees`.
- **Back** : folder_share_service ; invités = shares où invitee_email IS NOT NULL.
- **BDD** : `folder_shares`.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.28 | Liste parties, formulaire | GET/POST/PATCH/DELETE /customers, POST folder_parties | customer_service | Email unique, 403 |
| 18.29 | Panneau partage, boutons | GET/POST/PATCH/DELETE /folders/:id/shares, resend | folder_share_service, email | 403, doublon email |
| 18.30 | Liste invités | Idem 18.29 (même API) | folder_share_service | Rôle lecteur/contributeur |
## 4. Points d’attention
- Envoi invitation : service email (SMTP ou provider) ; token/lien généré et stocké ; pas de fallback silencieux si envoi échoue (remonter erreur).
- Révocation : suppression ou status=revoked ; accès retiré immédiatement.
- i18n : `customers.*`, `sharing.*`, `invitees.*`.

47
services/docv/enso-docs/features/implementation/IMPL_08_notes_rappels.md Normal file
View File

@ -0,0 +1,47 @@
# Implémentation technique : Notes et rappels
**Zone** : 8 — Notes et rappels
**Spec fonctionnelle** : [SPEC_08_notes_rappels.md](../specs/SPEC_08_notes_rappels.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 8.
## 1. Vue d’ensemble
- **Périmètre** : front (notes liste, notes par dossier, rappels liste et config), back (handlers notes, reminders, reminder_config), BDD (notes, reminders, reminder_config). Paramétrage : notes.*, reminders.*.
- **Dépendances** : zone 2 (dossiers), zone 3 (types de documents pour config rappels).
## 2. Écrans (détail technique)
### notes.list — Notes
- **Route(s)** : `app/(dashboard)/notes/page.tsx`.
- **Front** : Liste notes (globale ou par dossier selon droits) ; `GET /notes` (query folder_uid optionnel) ; filtres dossier, date ; lien détail/édition. Paramétrage : `notes.list`.
- **Back** : `GET /notes` → note_service::list (filtré par office/droits) → note_repository.
- **BDD** : `notes` (uid, folder_uid, content, author_uid, created_at, updated_at).
### notes.folder, notes.detail — Notes d’un dossier
- **Route(s)** : `app/(dashboard)/notes/folder/page.tsx` (query folder_uid), `notes/[noteUid]/page.tsx` ou section dans détail dossier.
- **Front** : Création note (formulaire contenu, folder_uid) ; `POST /notes` ; GET/PATCH/DELETE /notes/:id. Paramétrage : `notes.folder`, `notes.detail`.
- **Back** : note_service (create, get, update, delete) ; note_repository.
- **BDD** : `notes`.
### reminders.list — Rappels
- **Route(s)** : `app/(dashboard)/reminders/page.tsx`.
- **Front** : Liste rappels (documents à fournir, échéances) ; `GET /reminders` ; détail ; config par type de document et office : `GET/PATCH /reminders/config` (ou /offices/:id/reminder-config). Paramétrage : `reminders.list`.
- **Back** : reminder_service::list ; reminder_config_service (get/update par office, document_type).
- **BDD** : `reminders` (uid, folder_uid, document_type_uid, due_date, …), `reminder_config` (office_uid, document_type_uid, delay_days, …).
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.31 | Page notes, filtres | GET /notes | note_service | 403 |
| 18.32 | Création/édition note (dossier ou liste) | POST /notes, GET/PATCH/DELETE /notes/:id | note_service | 403, contenu requis |
| 18.33 | Page rappels, config | GET /reminders, GET/PATCH /reminders/config | reminder_service, reminder_config_service | 403 |
## 4. Points d’attention
- Notes : suppression définitive ; pas de corbeille.
- Config rappels : résolution par office et type de document ; droits admin office.
- i18n : `notes.*`, `reminders.*`.

71
services/docv/enso-docs/features/implementation/IMPL_09_abonnement_facturation.md Normal file
View File

@ -0,0 +1,71 @@
# Implémentation technique : Abonnement et facturation
**Zone** : 9 — Abonnement et facturation
**Spec fonctionnelle** : [SPEC_09_abonnement_facturation.md](../specs/SPEC_09_abonnement_facturation.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 9.
## 1. Vue d’ensemble
- **Périmètre** : front (subscription overview, subscribe, manage, collaborators, invite, success/error), back (handlers subscription, intégration prestataire paiement), BDD (subscriptions, subscription_invites, plans). Paramétrage : subscription.*.
- **Dépendances** : zone 13 (plans en super-admin) ; prestataire paiement (back uniquement).
## 2. Écrans (détail technique)
### subscription.overview — Abonnement
- **Route(s)** : `app/(dashboard)/subscription/page.tsx`.
- **Front** : `GET /subscription` ; affichage plan, collaborateurs, date renouvellement ; liens Gérer / Souscrire selon état. Paramétrage : `subscription.overview`.
- **Back** : subscription_service::get_current → subscription_repository, plan_repository.
- **BDD** : `subscriptions` (office_uid, plan_uid, status, current_period_end), `plans`.
### subscription.subscribe — Souscrire
- **Route(s)** : `app/(dashboard)/subscription/subscribe/page.tsx`, `subscription/new/page.tsx`.
- **Front** : Choix plan ; `GET /plans` ; formulaire paiement (si intégré) ou redirection vers prestataire ; `POST /subscription/subscribe` (body: plan_uid, payment_metadata ou return_url). Paramétrage : `subscription.subscribe`.
- **Back** : subscription_service::subscribe → appel prestataire, création subscription ; redirect URL retour (success/error).
- **BDD** : `subscriptions`, `plans`.
### subscription.manage — Gérer l’abonnement
- **Route(s)** : `app/(dashboard)/subscription/manage/page.tsx`.
- **Front** : GET /subscription ; formulaire modification plan, moyens de paiement ; PATCH /subscription ; annulation si prévu. Paramétrage : `subscription.manage`.
- **Back** : subscription_service::update_plan, update_payment_method ; prestataire.
- **BDD** : `subscriptions`.
### subscription.collaborators — Gérer les collaborateurs
- **Route(s)** : `app/(dashboard)/subscription/manage-collaborators/page.tsx`.
- **Front** : GET /subscription/collaborators (sièges utilisés/disponibles) ; PATCH pour lier/délier sièges. Paramétrage : `subscription.collaborators`.
- **Back** : subscription_service + office_members count.
- **BDD** : `subscriptions`, `office_members`, `plans` (seats).
### subscription.invite — Invitation
- **Route(s)** : `app/(dashboard)/subscription/invite/page.tsx`.
- **Front** : Formulaire email (+ rôle) ; POST /subscription/invites ; liste en attente, renvoyer, annuler. Paramétrage : `subscription.invite`.
- **Back** : subscription_invite_service (create, list, resend, cancel) ; vérification sièges disponibles ; envoi email.
- **BDD** : `subscription_invites` (office_uid, email, role_uid, token, status).
### subscription.success, subscription.error — Succès / erreur
- **Route(s)** : `app/(dashboard)/subscription/success/page.tsx`, `subscription/error/page.tsx`.
- **Front** : Pages de retour après redirect prestataire ; affichage message ; lien tableau de bord ou gestion. Paramétrage : `subscription.success`, `subscription.error`.
- **Back** : Webhook ou callback GET avec query params (session_id, status) ; mise à jour subscription si besoin.
- **BDD** : `subscriptions`.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.34 | Page abonnement | GET /subscription | subscription_service | 403 |
| 18.35 | Formulaire souscription | POST /subscription/subscribe, redirect | subscription_service, prestataire | Paiement refusé, 402 |
| 18.36 | Gérer abonnement | GET/PATCH /subscription | subscription_service | 403 |
| 18.37 | Gérer collaborateurs | GET/PATCH /subscription/collaborators | subscription_service | Sièges insuffisants |
| 18.38 | Formulaire invitation | POST /subscription/invites, resend, cancel | subscription_invite_service | Sièges pleins, email dupliqué |
| 18.39 | Retour prestataire | GET /subscription/success|error | Affichage statut, pas d’appel métier direct |
## 4. Points d’attention
- Paiement : clés API prestataire uniquement en back ; URLs callback configurées par environnement.
- Sièges : refuser invitation si plus de sièges disponibles ; message explicite.
- i18n : `subscription.*`.

55
services/docv/enso-docs/features/implementation/IMPL_10_espace_client_invite.md Normal file
View File

@ -0,0 +1,55 @@
# Implémentation technique : Espace client et espace invité
**Zone** : 10 et 11 — Espace client et espace invité
**Spec fonctionnelle** : [SPEC_10_espace_client_invite.md](../specs/SPEC_10_espace_client_invite.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zones 10 et 11.
## 1. Vue d’ensemble
- **Périmètre** : front (client-dashboard liste/détail dossier, auth invité, third-party dashboard), back (handlers client-dashboard, auth invité, third-party) ; mêmes données folders/documents filtrées par partage. Paramétrage : client.*, invitee.*.
- **Dépendances** : zone 7 (partage) ; zone 1 (auth invité par token/code).
## 2. Écrans (détail technique)
### client.dashboard — Tableau de bord client
- **Route(s)** : `app/(client)/client-dashboard/page.tsx` (layout dédié, pas menu office).
- **Front** : `GET /client-dashboard/folders` (dossiers partagés avec le client) ; liste ; lien détail dossier ; téléchargement documents. State : folders. Paramétrage : `client.dashboard`.
- **Back** : Handler `GET /client-dashboard/folders` → folder_share_service::list_folders_for_client (user ou customer identifié) → folder_repository (filtré par folder_shares).
- **BDD** : `folder_shares`, `folders`, `documents`.
### client.folder-detail — Détail dossier client
- **Route(s)** : `app/(client)/client-dashboard/[folderUid]/page.tsx`.
- **Front** : GET /client-dashboard/folders/:id ; liste documents ; télécharger ; déposer si contributeur (POST /client-dashboard/folders/:id/documents). Paramétrage : `client.folder-detail`.
- **Back** : folder_share_service vérifie accès ; document_service en lecture ou création selon rôle partage.
- **BDD** : `folders`, `documents`, `folder_shares`.
### invitee.auth — Connexion invité
- **Route(s)** : `app/(auth)/invite/page.tsx` (route publique avec token ou code en query).
- **Front** : Saisie code ou suivi lien email ; `POST /auth/invitee` (body: code ou token) ; 2FA si activé ; redirection dashboard invité. Paramétrage : `invitee.auth`.
- **Back** : auth_service::invitee_authenticate (vérifier token/code, créer session limitée) ; retour token + user context limité.
- **BDD** : `folder_shares` (token, status).
### invitee.dashboard — Tableau de bord invité
- **Route(s)** : `app/(invitee)/third-party/dashboard/page.tsx`.
- **Front** : GET /third-party/folders ; liste dossiers partagés ; détail dossier, téléchargement, dépôt si contributeur. Paramétrage : `invitee.dashboard`.
- **Back** : Même logique que client-dashboard mais identité = invité (session issue de invitee auth). Handlers sous préfixe /third-party.
- **BDD** : idem client.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.40 | Dashboard client | GET /client-dashboard/folders | folder_share_service | 401 si non identifié client |
| 18.41 | Détail dossier client, télécharger, déposer | GET /client-dashboard/folders/:id, GET/POST documents | document_service (filtré) | 403 si pas partagé |
| 18.42 | Page connexion invité | POST /auth/invitee | auth_service::invitee_authenticate | Token invalide ou expiré |
| 18.43 | Dashboard invité | GET /third-party/folders, documents | folder_share_service, document_service | 401 session invité |
## 4. Points d’attention
- Séparation layout : client et invité n’ont pas accès au menu office ; layout dédié (client-dashboard, third-party).
- Session invité : durée limitée ou liée au token ; pas d’élévation de droit.
- i18n : `client.*`, `invitee.*`, `third-party.*`.

38
services/docv/enso-docs/features/implementation/IMPL_12_admin_office.md Normal file
View File

@ -0,0 +1,38 @@
# Implémentation technique : Admin d’office
**Zone** : 12 — Admin d’office
**Spec fonctionnelle** : [SPEC_12_admin_office.md](../specs/SPEC_12_admin_office.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 12.
## 1. Vue d’ensemble
- **Périmètre** : front (page admin portail, helpers), back (endpoint métriques ou agrégation) ; pas de BDD dédiée (agrégation des données existantes). Paramétrage : admin.portal, admin.helpers.
- **Dépendances** : zones 3, 4, 5, 6 (liens vers gestion rôles, utilisateurs, types documents, types dossiers).
## 2. Écrans (détail technique)
### admin.portal — Admin
- **Route(s)** : `app/(dashboard)/admin/page.tsx`.
- **Front** : Page portail : cartes ou blocs métriques (nombre dossiers, collaborateurs, stockage, etc.) ; liens vers /roles, /users, /document-types, /case-types. Données : `GET /admin/metrics` (ou plusieurs GET ciblés). Paramétrage : `admin.portal` ; visible seulement si rôle admin office.
- **Back** : Handler `GET /admin/metrics` → admin_service::get_metrics (agrégations folder_repository, office_members, etc.) ; ou pas d’endpoint dédié et front appelle GET /folders (count), GET /collaborators (count). Middleware : vérifier permission admin_office.
- **BDD** : lecture seule sur folders, office_members, etc.
### admin.helpers — Helpers admin
- **Route(s)** : `app/(dashboard)/admin/helpers/page.tsx`.
- **Front** : Outils ou aides techniques (export, diagnostic, logs selon implémentation) ; appels API dédiés si besoin. Paramétrage : `admin.helpers`.
- **Back** : Endpoints optionnels (ex. GET /admin/helpers/export, GET /admin/helpers/health). Non obligatoire selon implémentation.
- **BDD** : aucune spécifique.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.44 | Page admin, liens | GET /admin/metrics, navigation vers rôles, users, document-types, case-types | admin_service (metrics), autres zones | 403 si non admin office |
## 4. Points d’attention
- Droits : accès réservé aux rôles avec permission admin_office (ou équivalent) ; vérification middleware sur /admin/*.
- Métriques : ne pas exposer de données personnelles ; agrégats uniquement.
- i18n : `admin.*`, `admin.helpers.*`.

63
services/docv/enso-docs/features/implementation/IMPL_13_admin_plateforme.md Normal file
View File

@ -0,0 +1,63 @@
# Implémentation technique : Admin plateforme (super-admin)
**Zone** : 13 — Admin plateforme
**Spec fonctionnelle** : [SPEC_13_admin_plateforme.md](../specs/SPEC_13_admin_plateforme.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 13.
## 1. Vue d’ensemble
- **Périmètre** : front (super-admin overview, roles-management, subscription-plans, texts, config), back (handlers super_admin), BDD (roles scope plateforme, plans, site_texts, system_configuration). Paramétrage : super-admin.*.
- **Dépendances** : zone 9 (plans consommés) ; toute l’app consomme config et textes i18n.
## 2. Écrans (détail technique)
### super-admin.overview — Super-admin
- **Route(s)** : `app/(dashboard)/super-admin/page.tsx`.
- **Front** : Vue d’ensemble (offices, utilisateurs, santé services) ; GET /super-admin/overview ; liens vers rôles, plans, textes, config. Paramétrage : `super-admin.overview` ; middleware rôle super-admin.
- **Back** : GET /super-admin/overview → agrégation offices, users, health checks.
- **BDD** : offices, users (counts).
### super-admin.roles — Gestion des rôles plateforme
- **Route(s)** : `app/(dashboard)/super-admin/roles-management/page.tsx`.
- **Front** : Liste rôles plateforme (scope global) ; GET/POST/PATCH /super-admin/roles ; matrice permissions plateforme. Paramétrage : `super-admin.roles`.
- **Back** : role_service avec scope plateforme (office_uid = null).
- **BDD** : `roles`, `role_permissions`.
### super-admin.plans — Plans d’abonnement
- **Route(s)** : `app/(dashboard)/super-admin/subscription-plans/page.tsx`.
- **Front** : GET /super-admin/plans ; CRUD plans (créer, modifier, désactiver). Paramétrage : `super-admin.plans`.
- **Back** : plan_service (list, create, update, deactivate) ; plan_repository.
- **BDD** : `plans` (uid, name, features, price, seats, active).
### super-admin.texts — Textes du site
- **Route(s)** : `app/(dashboard)/super-admin/texts/page.tsx` ou sous-route.
- **Front** : GET /super-admin/texts (liste par clé, locale, version) ; créer, modifier, publier. Paramétrage : `super-admin.texts`.
- **Back** : site_text_service ; site_text_repository.
- **BDD** : `site_texts` (key, locale, version, content, published_at).
### super-admin.config — Configuration système
- **Route(s)** : `app/(dashboard)/super-admin/config/page.tsx`.
- **Front** : GET /super-admin/config (clés par catégorie, valeurs masquées si sensibles) ; PATCH pour modifier ; révélation valeur sensible avec confirmation. Paramétrage : `super-admin.config`.
- **Back** : system_configuration_service ; masquage des clés sensibles ; audit sur révélation.
- **BDD** : `system_configuration` (key, value, sensitive, category).
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.45 | Page super-admin | GET /super-admin/overview | admin_service | 403 si non super-admin |
| 18.46 | Gestion rôles plateforme | GET/PATCH /super-admin/roles | role_service (scope null) | 403 |
| 18.47 | Plans abonnement | GET/POST/PATCH /super-admin/plans | plan_service | 403 |
| 18.48 | Textes du site | GET/POST/PATCH /super-admin/texts, publish | site_text_service | 403 |
| 18.49 | Configuration système | GET/PATCH /super-admin/config | system_configuration_service | 403, audit révélation |
## 4. Points d’attention
- Tous les endpoints /super-admin/* protégés par rôle super-admin (middleware ou guard).
- Valeurs sensibles : jamais renvoyées en clair sauf révélation explicite avec audit.
- i18n : `super-admin.*`.

31
services/docv/enso-docs/features/implementation/IMPL_14_contenus_parametres.md Normal file
View File

@ -0,0 +1,31 @@
# Implémentation technique : Contenus et paramètres globaux
**Zone** : 14 — Contenus et paramètres globaux
**Spec fonctionnelle** : [SPEC_14_contenus_parametres.md](../specs/SPEC_14_contenus_parametres.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 14.
## 1. Vue d’ensemble
- **Périmètre** : consultation des contenus légaux (mentions, CGU, confidentialité) ; la gestion des textes i18n et de la configuration système est en zone 13 (super-admin). Consommation des textes et de la config dans toute l’app. Paramétrage : legal.mentions.
- **Dépendances** : zone 13 (source des textes et config).
## 2. Écrans (détail technique)
### legal.mentions — Mentions légales
- **Route(s)** : `app/legal/page.tsx` ou `app/(public)/legal/page.tsx` (accessible sans auth ou avec).
- **Front** : Page lecture seule ; contenu depuis GET /texts?key=legal.mentions (ou clés dédiées legal.cgu, legal.privacy) et locale ; ou chargement statique au build. Pas de formulaire. Paramétrage : `legal.mentions` ; lien footer selon config.
- **Back** : GET /site-texts/public?key=... (endpoint public pour textes publiés) ou pas d’API si contenu injecté au build. Pas de mutation.
- **BDD** : `site_texts` (lecture seule, clés legal.*).
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.50 | Navigation vers /legal | GET /site-texts/public (ou contenu statique) | site_text_service (read-only public) | Aucune |
## 4. Points d’attention
- Contenu légal : pas de données sensibles ; mise à jour uniquement via super-admin (zone 13).
- Feature flags et config : lus par le front depuis un endpoint unique (ex. GET /config/public) ou injectés au build ; pas d’exposition de valeurs sensibles.
- i18n : clés legal.mentions, legal.cgu, legal.privacy (ou équivalent).

39
services/docv/enso-docs/features/implementation/IMPL_15_technique_design.md Normal file
View File

@ -0,0 +1,39 @@
# Implémentation technique : Technique et design
**Zone** : 15 — Technique et design
**Spec fonctionnelle** : [SPEC_15_technique_design.md](../specs/SPEC_15_technique_design.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 15.
## 1. Vue d’ensemble
- **Périmètre** : design system (doc statique ou route dédiée), page publique de vérification d’ancrage ; back uniquement pour l’ancrage (endpoint verify). Paramétrage : design-system.doc, anchor.verify.
- **Dépendances** : service d’ancrage (back) pour la vérification ; zones 2/3 si ancrage activé (liens depuis documents).
## 2. Écrans (détail technique)
### design-system.doc — Design system
- **Route(s)** : `app/design-system/page.tsx` ou dossier `design-system/` (doc statique, ex. Storybook ou MDX).
- **Front** : Documentation des composants et tokens (lecture seule) ; pas d’appel API métier ; contenu statique ou généré au build. Paramétrage : `design-system.doc` ; visible en dev/staging ou par rôle technique.
- **Back** : Aucun endpoint dédié.
- **BDD** : Aucune.
### anchor.verify — Vérification d’ancrage
- **Route(s)** : `app/verify-anchor/page.tsx` ou `app/anchor/verify/page.tsx` (route publique).
- **Front** : Formulaire ou URL avec paramètre (id ou lien certificat) ; GET ou POST /anchor/verify?id=... (ou body) ; affichage résultat (validité, date, hash). Paramétrage : `anchor.verify`.
- **Back** : Handler GET/POST /anchor/verify → anchoring_client::verify (appel API ancrage serveur services) ou lecture BDD si preuves stockées ; retour JSON ou page rendue côté serveur avec résultat.
- **BDD** : optionnel (stockage preuves) ; sinon appel direct au service ancrage.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.51 | Navigation design system | Aucun (statique) | — | — |
| 18.52 | Saisie lien/id, soumission | GET/POST /anchor/verify | anchoring_client::verify | Certificat invalide ou introuvable → message clair |
## 4. Points d’attention
- Design system : pas d’exposition de données métier ; accès restreint en prod si besoin.
- Vérification ancrage : pas d’auth requise ; pas d’exposition de données métier (uniquement résultat de vérification).
- i18n : `design-system.*`, `anchor.verify.*`.

136
services/docv/enso-docs/features/implementation/IMPL_17_ia_local.md Normal file
View File

@ -0,0 +1,136 @@
# Implémentation technique : Fonctionnalités ia_local (enso)
**Zone** : 17 — ia_local (enso)
**Spec fonctionnelle** : [SPEC_17_ia_local.md](../specs/SPEC_17_ia_local.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 17 ; actions 18.53 à 18.83.
## 1. Vue d’ensemble
- **Périmètre** : tous les écrans et actions issus du projet ia_local à intégrer dans enso : dashboard, CRM, composition d’actes, mise à jour DP, secrétariat juridique, renvoi dossier, extraction dataroom, alertes, data room, courriers IFU, workflow documentaire, tâches, débours, messages, notifications, config établissements, admin-types, facturation débours, courriers annexes, mails semi-auto, édition formalités, fiche prépa AG, planning charges, organigramme, listing annexes, devis/lettre de mission, Outlook, Chat IA, Explorer, recherche globale, mon compte appareils. Back : services métier, clients IA. BDD : établissements, dossiers permanents, tâches, alertes, débours, datarooms, messages, etc.
- **Dépendances** : zones 2 (dossiers), 3 (documents), 7 (partage) ; API IA (sous-module ai) ; architecture docv pour socle commun.
## 2. Écrans (détail technique)
Les écrans sont listés dans le référentiel (section Zone 17). Pour chaque sous-bloc, même structure : route, front (page, composants, state, API), back (handler, service, repository), BDD.
### Sous-bloc Dashboard et navigation (18.53, 18.81, 18.82)
- **ia.dashboard** : `app/(dashboard)/dashboard/page.tsx` ; GET /ia/dashboard (tâches en cours, débours) ; cartes et liens vers écrans métier.
- **ia.explorer** : Composant arborescence (Commun / Datarooms) ; GET /ia/explorer/tree ; sélection dossier → affichage contenu centre.
- **ia.search** : Barre recherche globale ; GET /ia/search?q=...&filters= ; résultats par section (CRM, dossiers, etc.).
### Sous-bloc CRM (18.54)
- **ia.crm** : `app/(dashboard)/crm/page.tsx` ; GET /ia/crm/clients, /ia/crm/dossiers ; liste clients et dossiers permanents ; filtres, recherche.
### Sous-bloc Actes et juridique (18.55, 18.56, 18.57, 18.71–18.74, 18.77, 18.78)
- **ia.composition-actes** : Upload sources (Excel, PDF, JPG) ; POST /ia/extract ; affichage données extraites ; rédaction acte ; appel IA back.
- **ia.mise-a-jour-dp** : Sélection DP et documents ; POST /ia/dp/update ; service IA.
- **ia.secretariat** : Événements AG, prérédaction, données comptables, alertes ; endpoints dédiés secrétariat.
- **ia.courriers-annexes**, **ia.edition-formalites**, **ia.fiche-prepa-ag**, **ia.listing-annexes**, **ia.devis-lettre-mission** : Génération documents ; POST /ia/generate/:type ; templates et données dossier.
### Sous-bloc Partage et dataroom (18.58, 18.59, 18.61)
- **ia.renvoi-dossier** : Partage destinataires (clients, comptabilité, CAC) ; POST /ia/share ; folder_share_service étendu.
- **ia.extraction-dataroom** : Synthèse pièces dataroom ; POST /ia/dataroom/extract ; ia_client.
- **ia.data-room** : Liste datarooms ; GET /ia/datarooms ; CRUD documents, invitations, droits ; notifications dépôt.
### Sous-bloc Alertes (18.60)
- **ia.alertes** : GET /ia/alertes ; filtres type, période ; actions marquer notifié, ajouter alerte.
### Sous-bloc Workflow et tâches (18.63, 18.64, 18.75)
- **ia.workflow** : Documents par statut ; GET /ia/workflow ; actions par ligne (Voir, Télécharger, Analyse IA, Archiver, etc.) ; PATCH statut.
- **ia.taches** : GET /ia/taches ; CRUD tâches ; filtres dossier, type, statut, assigné.
- **ia.planning-charges** : Liste tâches par collaborateur ; GET /ia/planning ; PATCH affectation.
### Sous-bloc Débours et facturation (18.65, 18.70)
- **ia.debours** : GET /ia/debours ; CRUD débours ; validation.
- **ia.facturation-debours** : Workflow facturation ; transmission dématérialisée ; comparaison provision/débours.
### Sous-bloc Communication (18.66, 18.67, 18.62, 18.72)
- **ia.messages** : Fil discussion par contexte ; GET/POST /ia/messages ; pièces jointes.
- **ia.notifications** : GET /ia/notifications ; filtre type, période, lu ; PATCH marquer lu.
- **ia.courriers-ifu** : Import RDPD DVD, publipostage ; POST /ia/courriers-ifu.
- **ia.mails-semi-auto** : Alertes éligibles, envoi mail pré-rédigé ; POST /ia/mails-semi-auto.
### Sous-bloc Config (18.68, 18.69)
- **ia.config-etablissements** : GET/POST/PATCH/DELETE /ia/establishments.
- **ia.admin-types** : GET/PATCH /ia/admin-types (catégories : documents, dossiers, tâches, alertes, etc.).
### Sous-bloc Intégrations et IA (18.79, 18.80, 18.76)
- **ia.outlook** : Association mail Outlook → dossier ; POST /ia/outlook/link ; consultation mails liés.
- **ia.chat** : Panneau Chat IA ; POST /ia/chat (message, contexte Explorer) ; streaming réponse ; ia_client.
- **ia.organigramme** : GET /ia/organigramme?source=... ; visualisation actionnariat/structure.
### Sous-bloc Compte (18.83)
- **ia.my-account-devices** : GET/DELETE /users/me/devices ; gestion appareils enregistrés.
## 3. Actions (mapping technique)
Pour chaque action 18.53 à 18.83 : déclencheur UI, endpoint ou action locale, handler → service (et ia_client si IA). Référence : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 18.
| Action | Déclencheur (UI) | Appel / action | Back | Validation / erreur |
|--------|------------------|----------------|------|---------------------|
| 18.53 | Page dashboard, cartes et liens | GET /ia/dashboard | dashboard_service (tâches, débours agrégés) | 403 |
| 18.54 | Page CRM, recherche, filtres, clic client/DP | GET /ia/crm/clients, /ia/crm/dossiers, GET /ia/crm/:id | crm_service | 403 |
| 18.55 | Upload sources, bouton Extraire, rédaction | POST /ia/extract, POST /ia/actes/compose | ia_client, composition_service | Erreur extraction, format invalide |
| 18.56 | Sélection DP + documents, bouton Mettre à jour | POST /ia/dp/update | ia_client, dp_service | 404 DP, documents manquants |
| 18.57 | Événements AG, prérédaction, données comptables, convocations | GET/POST/PATCH /ia/secretariat/* | secretariat_service, ia_client | Alertes seuils, 403 |
| 18.58 | Panneau partage, ajout destinataire, révoquer | GET/POST/PATCH/DELETE /ia/share, /folders/:id/shares | folder_share_service étendu | 403 |
| 18.59 | Sélection dataroom, bouton Synthèse | POST /ia/dataroom/extract | ia_client, dataroom_service | 404 dataroom |
| 18.60 | Liste alertes, filtres, marquer notifié, ajouter | GET/PATCH/POST /ia/alertes | alerte_service | 403 |
| 18.61 | Liste datarooms, ouvrir, inviter, dépôt doc | GET/POST/PATCH /ia/datarooms, /ia/datarooms/:id/documents | dataroom_service | Droits viewer/editor |
| 18.62 | Import RDPD DVD, publipostage, config IFU | POST /ia/courriers-ifu/import, /publish | courriers_ifu_service | Fichier invalide |
| 18.63 | Liste workflow, filtres, actions par ligne (Voir, Télécharger, Analyse IA, etc.) | GET /ia/workflow, PATCH /ia/workflow/documents/:id | workflow_service, ia_client | Transition statut selon rôle |
| 18.64 | Liste tâches, filtres, formulaire ajout/édition | GET/POST/PATCH/DELETE /ia/taches | tache_service | 403 |
| 18.65 | Liste débours, ajout, validation | GET/POST/PATCH /ia/debours | debours_service | Statuts en attente → validé → payé |
| 18.66 | Fil discussion, envoi message, pièce jointe | GET/POST /ia/messages | message_service | 403 contexte |
| 18.67 | Liste notifications, filtre, marquer lu | GET /ia/notifications, PATCH /ia/notifications/:id/read | notification_service | 403 |
| 18.68 | Liste établissements, formulaire ajout/édition | GET/POST/PATCH/DELETE /ia/establishments | establishment_service | 403 |
| 18.69 | Catégories types, modification par catégorie | GET/PATCH /ia/admin-types | admin_types_service | 403 |
| 18.70 | Workflow facturation, transmission, comparaison provision | GET/POST/PATCH /ia/facturation-debours | facturation_debours_service | Alerte dépassement |
| 18.71 | Choix type courrier, génération | POST /ia/generate/courrier-annexe | ia_client, courrier_service | Type requis |
| 18.72 | Liste alertes éligibles, mail pré-rédigé, envoyer | GET /ia/mails-semi-auto/eligible, POST /ia/mails-semi-auto/send | mails_semi_auto_service | 403 |
| 18.73 | Choix type pièce, saisie données, génération | POST /ia/generate/formalite | ia_client, formalite_service | Données manquantes |
| 18.74 | Formulaire fiche prépa AG, génération | GET/POST/PATCH /ia/fiche-prepa-ag, POST /export | fiche_prepa_ag_service | 403 |
| 18.75 | Liste planning, affectation tâche | GET /ia/planning, PATCH /ia/taches/:id/assign | tache_service, planning_service | 403 |
| 18.76 | Sélection périmètre, affichage organigramme | GET /ia/organigramme | organigramme_service, ia_client | Source invalide |
| 18.77 | Sélection acte, extraction annexes, compilation PDF | POST /ia/listing-annexes/extract, /compile | listing_annexes_service | Acte introuvable |
| 18.78 | Choix modèle devis/lettre, génération | POST /ia/generate/devis | devis_service | 403 |
| 18.79 | Lien mail → dossier, liste mails liés | POST /ia/outlook/link, GET /ia/outlook/links | outlook_service (intégration) | 403 |
| 18.80 | Champ chat, envoi message ; clic Explorer « Montre-moi » | POST /ia/chat (streaming) | ia_client | Contexte Explorer, erreur IA |
| 18.81 | Arborescence, sélection nœud, bascule Datarooms/Commun | GET /ia/explorer/tree | explorer_service | Rôle client = Datarooms, internes = Commun |
| 18.82 | Barre recherche, filtres, résultats | GET /ia/search | search_service | 403 |
| 18.83 | Liste appareils, révoquer, enregistrer | GET/DELETE /users/me/devices, POST /users/me/devices | device_service | 403 |
## 4. Entités BDD (zone 17)
Tables principales à prévoir ou étendre pour ia_local (alignement avec ARCHITECTURE_DOCV_DETAILLEE et migrations) :
- **establishments** (établissements) : uid, office_uid, name, address, reference, email, phone, updated_at.
- **permanent_folders** / **dossiers_permanents** : lien avec folders ou table dédiée ; structure type DP.
- **tasks** / **taches** : uid, folder_uid, establishment_uid, type_uid, title, due_date, status, assigned_to_uid, created_at.
- **alerts** / **alertes** : uid, folder_uid, type_uid, label, due_date, notified_at, dossier_uid.
- **debours** : uid, folder_uid, task_uid, label, amount, status (en_attente, valide, refuse, paye).
- **datarooms** : uid, folder_uid ou establishment_uid, name, end_access_at ; **dataroom_members** : dataroom_uid, user_uid ou email, role (viewer/editor).
- **messages** / **threads** : uid, context_type (folder, establishment), context_uid, author_uid, body, created_at ; pièces jointes.
- **notifications** : uid, user_uid, type, title, body, read_at, created_at.
- **workflow_documents** : extension documents avec statut (a_demander, demande, recu, valide, refuse) et lien tâche.
- **device_registrations** : uid, user_uid, device_id, name, created_at (pour 18.83).
Référentiels de types métier : **task_types**, **alert_types**, **debours_types**, **courrier_types**, etc. (ou table générique **admin_types** par catégorie).
## 5. Points d’attention
- API IA : tous les appels IA passent par le back (ia_client) ; jamais d’appel direct depuis le front.
- Entités BDD : établissements, dossiers permanents, tâches, alertes, débours, datarooms, messages, notifications, types métier ; schéma à aligner avec ARCHITECTURE_DOCV_DETAILLEE et migrations.
- Paramétrage : identifiants stables ia.* pour screen_config et action_config ; résolution par office et rôle.
- i18n : clés ia.*, dataroom.*, workflow.*, taches.*, etc.

144
services/docv/enso-docs/features/implementation/IMPL_18_operation.md Normal file
View File

@ -0,0 +1,144 @@
# Implémentation technique : Opération
**Zone** : 18 — Opération (cabinet/office)
**Spec fonctionnelle** : [SPEC_18_operation.md](../specs/SPEC_18_operation.md)
**Référentiel** : [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — Zone 18.
## 1. Vue d’ensemble
- **Périmètre** : front (operations liste [où user a un rôle], détail, création [peut créer société], édition, validation/correction post-création [ordre fixe, pas de retour], onglets rôle → sous-rôle → membres), back (handlers societies, operations, operation_societies, contacts, operation_documents), BDD (societies, operations, operation_societies, operation_contacts, society_contacts, operation_documents, operation_document_societies, operation_document_files), paramétrage. Extraction KBIS, répartition IA, génération/complétion fichiers de synthèse via services back.
- **Homogénéisation** : dossier = société = entreprise ; société mère ou fille ; archivage au niveau société.
- **Étapes** : chaque type d’opération a plusieurs étapes ; paramétrage (droits, types de documents, workflow) dépend des étapes.
- **Liste opérations** : opérations où la personne connectée a un rôle.
- **Accès onglets** : seuls cabinets avocats et offices notariaux ; autres : vue documents les concernant (envoyés, reçus, visualisation).
- **Dépendances** : zone 3 (types de documents), zone 6 (rôles), zone 17 (IA, OnlyOffice local pour association variables).
## 2. Écrans (détail technique)
### operations.list — Liste des opérations
- **Route(s)** : `app/(dashboard)/operations/page.tsx` ou `app/(dashboard)/societies/[societyUid]/operations/page.tsx`.
- **Front** : Liste paginée des opérations où la personne connectée a un rôle ; filtres (date, type d’opération, société, recherche), tri ; `GET /operations` (filtré par user) ou `GET /societies/:id/operations` ; bouton Créer. Paramétrage : `operations.list`.
- **Back** : `GET /operations` → operation_service::list (user_uid, office_uid) → opérations où user a un rôle.
- **BDD** : `operations` (uid, society_uid, office_uid, …).
### operations.detail — Détail d’une opération
- **Route(s)** : `app/(dashboard)/operations/[operationUid]/page.tsx`.
- **Front** : En-tête ; **onglets rôle → sous-rôle → membres** (selects multiples ou cases à cocher) ; tableau documents (type, sociétés liées, état, dates) ; actions selon droits (demande, relance, exclusion, modification, suppression, visualisation preview, téléchargement, validation, refus). Seuls cabinets/offices ont onglets complets ; autres : vue documents les concernant. Paramétrage : `operations.detail`.
- **Back** : `GET /operations/:id` ; résolution droits (rôle, sous-rôle, statut dossier, type opération, type activité, type document, statut document, héritage).
- **BDD** : `operations`, `operation_societies`, `operation_contacts`, `contacts`, `operation_documents`, `operation_document_societies`, `operation_document_files`.
### operations.create — Création d’opération
- **Route(s)** : `app/(dashboard)/operations/create/page.tsx` ou `app/(dashboard)/societies/[societyUid]/operations/create/page.tsx`.
- **Front** : Formulaire (opération, sociétés liées, contacts, documents) ; `POST /operations` (body: society_uid ou création société) ; une opération peut générer la création d’une nouvelle société. Paramétrage : `operations.create`.
- **Back** : operation_service::create ; peut créer une société ; operation_repository, operation_society_repository, operation_contact_repository.
- **BDD** : `operations`, `operation_societies`, `operation_contacts`.
### operations.edit — Édition d’opération
- **Route(s)** : `app/(dashboard)/operations/[operationUid]/edit/page.tsx`.
- **Front** : Formulaire pré-rempli ; `PATCH /operations/:id` ; sections entreprise, contacts, documents éditables. Paramétrage : `operations.edit`.
- **Back** : operation_service::update ; repositories associés.
- **BDD** : `operations`, `operation_societies`, `operation_contacts`, `operation_documents`.
### operations.society — Société liée (dans opération)
- **Route(s)** : Section dans détail/création/édition ; modal `SocietyFormModal`.
- **Front** : Formulaire (type, imposition, SCI, SIRET, type d’activité) ; upload KBIS ; `POST /operations/:id/societies`, `PATCH /operations/:id/societies/:societyUid`, `POST /operations/:id/societies/:societyUid/extract-kbis`. Paramétrage : `operations.society`.
- **Back** : operation_society_service ; kbis_extraction_service.
- **BDD** : `operation_societies`, `activity_types`.
### operations.contacts — Contacts (dans opération)
- **Route(s)** : Section dans détail/création/édition ; modal `ContactFormModal`.
- **Front** : Liste contacts ; ajout (recherche `GET /contacts?q=` ; si doublon → pas de création, alerte choix manuel) ; rôles/sous-rôles opération cumulatifs ; `POST /operations/:id/contacts`, etc. Paramétrage : `operations.contacts`.
- **Back** : operation_contact_service ; contact_repository (doublon : email, nom+prénom).
- **BDD** : `contacts`, `operation_contacts`, `society_contacts`.
### operations.validate — Validation/correction post-création
- **Route(s)** : `app/(dashboard)/operations/[operationUid]/validate/page.tsx`.
- **Front** : **Ordre fixe** : (1) infos → (2) contacts → (3) affectations ZIP → (4) fichiers de synthèse. **Pas de retour** sur étape validée. `PATCH /operations/:id/validate-step`, `POST /operations/:id/validate-complete`. Paramétrage : `operations.validate`.
- **Back** : operation_validate_service ; synthèse : si aucune → génération auto ; sinon complétion (écran + BDD).
- **BDD** : `operations`, `operation_societies`, `operation_contacts`, `operation_documents`.
### operations.documents — Documents (dans opération)
- **Route(s)** : Onglets rôle → sous-rôle → membres dans détail opération.
- **Front** : Tableau documents ; colonnes : document, type, sociétés liées, état ; actions selon droits (rôle, sous-rôle, statut dossier, type opération, type activité, type document, statut document, héritage) ; preview selon format ; upload ; ZIP ; rattachement opération ou société selon config type. Paramétrage : `operations.documents`.
- **Back** : operation_document_service ; zip_distribution_service ; résolution droits ; workflow configuré.
- **BDD** : `operation_documents`, `operation_document_societies`, `operation_document_files`, `document_types`.
### operation-types.list — Types d’opération (paramétrage)
- **Route(s)** : `app/(dashboard)/settings/operation-types/page.tsx`.
- **Front** : Liste ; création, édition ; définition des étapes par type ; `GET /operation-types`, `POST /operation-types`, `PATCH /operation-types/:id`, `DELETE /operation-types/:id`. Paramétrage : `operation-types.list`.
- **Back** : operation_type_service ; operation_type_repository ; operation_type_step_repository.
- **BDD** : `operation_types`, `operation_type_steps`.
### operation-type-steps.list — Étapes par type d’opération (paramétrage)
- **Route(s)** : `app/(dashboard)/settings/operation-types/[typeUid]/steps/page.tsx`.
- **Front** : Liste des étapes ; création, édition, ordre ; `GET /operation-types/:id/steps`, `POST /operation-types/:id/steps`, `PATCH /operation-types/:id/steps/:stepUid`, réordonnancement. Paramétrage : `operation-type-steps.list`.
- **Back** : operation_type_step_service ; operation_type_step_repository.
- **BDD** : `operation_type_steps`.
### activity-types.list — Types d’activité (paramétrage)
- **Route(s)** : `app/(dashboard)/settings/activity-types/page.tsx`.
- **Front** : Liste ; création, édition ; `GET /activity-types`, `POST /activity-types`, `PATCH /activity-types/:id`, `DELETE /activity-types/:id`. Paramétrage : `activity-types.list`.
- **Back** : activity_type_service ; activity_type_repository.
- **BDD** : `activity_types`.
## 3. Actions (mapping technique)
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.84 | Page liste, filtres, tri | GET /operations | operation_service | 403 |
| 18.85 | Détail opération | GET /operations/:id | operation_service | 403, 404 |
| 18.86 | Formulaire création | POST /operations | operation_service | Titre, date, type requis |
| 18.87 | Formulaire édition | PATCH /operations/:id | operation_service | 403, 404 |
| 18.88 | Section société liée, upload KBIS | POST/PATCH /operations/:id/societies, POST extract-kbis | operation_society_service, kbis_extraction_service | SIRET requis, erreur extraction |
| 18.89 | Section contacts, ajout | POST /operations/:id/contacts, GET /contacts?q= | operation_contact_service, contact_repository | Alerte doublon, rôles requis |
| 18.90 | Section documents, upload | POST /operations/:id/documents | operation_document_service | 403 |
| 18.91 | Upload ZIP | POST /operations/:id/documents/upload-zip | zip_distribution_service (IA) | Proposition modifiable |
| 18.94 | Validation post-création | POST /operations/:id/validate-step, validate-complete | operation_validate_service | Infos, contacts, affectations ZIP, fichiers synthèse |
| 18.95 | Actions documents (demande, relance, exclusion, etc.) | PATCH /operations/:id/documents/:docId/action | operation_document_service | Selon droits rôle/état |
| 18.92 | Paramétrage types opération | GET/POST/PATCH/DELETE /operation-types | operation_type_service | 403 |
| 18.96 | Paramétrage étapes par type | GET/POST/PATCH /operation-types/:id/steps | operation_type_step_service | 403 |
| 18.93 | Paramétrage types activité | GET/POST/PATCH/DELETE /activity-types | activity_type_service | 403 |
## 4. BDD — Schéma (tables principales)
| Table | Colonnes clés |
|-------|----------------|
| **societies** | uid, parent_society_uid, office_uid, type, imposition, is_sci, siret, activity_type_uid, kbis_document_uid, … — dossier = société = entreprise ; archivage ; données complètes |
| **operations** | uid, society_uid, office_uid, title, date, case_number, accounting_number, has_company, operation_type_uid, current_step_uid, status (ouvert, en cours, clôturé), created_at, updated_at |
| **operation_type_steps** | uid, operation_type_uid, label, order |
| **operation_comments** | uid, operation_uid, content, access_level, author_uid, created_at |
| **operation_societies** | operation_uid, society_uid — jointure ; données société dans `societies` |
| **contacts** | uid, office_uid, last_name, first_name, email, phone, created_at — un utilisateur peut avoir plusieurs contacts |
| **user_contacts** | user_uid, contact_uid — liaison utilisateur ↔ contact |
| **operation_contacts** | uid, operation_uid, contact_uid, roles_operation (JSON/array), sub_roles_operation, is_shareholder, shares_count |
| **society_contacts** | uid, society_uid, contact_uid, roles_enterprise, sub_roles_enterprise |
| **operation_documents** | uid, operation_uid, society_uid?, document_type_uid, attachment_target (operation\|society), status, deleted, signed, … |
| **operation_document_societies** | operation_document_uid, society_uid — N-N |
| **operation_document_files** | uid, operation_document_uid, file_ref, template, template_variables, info_type, cnil_expiry, created_at |
| **operation_types** | uid, office_uid, label, order |
| **activity_types** | uid, office_uid, label, order |
## 5. Points d’attention
- **Homogénéisation** : dossier = société = entreprise ; société mère ou fille ; archivage au niveau société.
- **Liste opérations** : filtrée par rôles de la personne connectée.
- **Onglets** : rôle → sous-rôle → membres (selects multiples / cases à cocher) ; seuls cabinets/offices ont onglets complets ; autres : vue documents les concernant.
- **Workflow** : configuré par rôle, type opération, **étape**, type activité, type document, état document, état opération (héritage) ; transitions à demander → exclure → final ; à demander → demandé → à envoyer → envoyé → validé/refusé ou téléchargé ou final.
- **Post-création** : ordre fixe (infos → contacts → affectations ZIP → fichiers synthèse) ; pas de retour sur étape validée.
- **Synthèse** : si aucune → génération auto ; sinon complétion (écran + BDD).
- **Documents** : rattachement opération ou société selon config type ; pas à société parente.
- **Contacts doublons** : critères email, nom+prénom ; pas de création si identique ; alerte choix manuel.
- **Association variables** : config pour génération documents OnlyOffice local.
- **Preview** : selon format, solution technique adaptée.
- **i18n** : `operations.*`, `operation-types.*`, `activity-types.*`, `operations.society`, `operations.contacts`, `operations.documents`, `operations.validate`.

25
services/docv/enso-docs/features/implementation/IMPL_ENSO_COMPANIES_SCREENS.md Normal file
View File

@ -0,0 +1,25 @@
# Implémentation technique : écrans Sociétés (enso-front)
**Périmètre** : identifiants **`companies.list`** et **`companies.detail`** ([REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) — section *Espace client Enso — Sociétés*).
**Modèle métier** : [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](../MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md).
## companies.list
- **Route(s)** : `app/dashboard/page.tsx` ; liste dans `AppSidebarCompanies.tsx` (barre latérale).
- **Front** : `useOfficesCatalog` → `fetchUserCompanies` ; hiérarchie `buildCompanyNavHierarchy` (`companyGroupHierarchy.ts`).
- **Back** : `GET /api/v1/offices` (docv-back) ; offices avec `archived_at` non nul exclus de la liste par défaut.
- **Paramétrage** : clé d’écran `companies.list` (visible, ordre, rôles) — stockage futur `screen_config`.
## companies.detail
- **Route(s)** : `app/company/[companyId]/page.tsx` → `CompanyDetail.tsx` → `CompanyDetailBody.tsx`.
- **Front** : `useOfficePageData` / `loadOfficePage` ; onglets `CompanyDetailTabs` (Dossiers / Dossier permanent) ; `CompanyInstanceLayoutExplorer` ; commentaires `CompanyOfficeCommentsCard` (si activé).
- **Back** : `GET /api/v1/offices/:uid` (détail avec `permanent_documents`, `parent_office_uid`, `archived_at`) ; `GET /api/v1/folders?office_uid=` ; `GET/PATCH /api/v1/folders/:uid` ; `POST /api/v1/offices/:uid/comments` ; `GET /api/v1/offices/:uid/comments`.
- **Paramétrage** : clé `companies.detail`.
## Données SPEC_18 (socle)
- **`folders.extends_permanent_record`** : lien explicite opération → prolonge le dossier permanent (PATCH dossier).
- **`offices.parent_office_uid`**, **`offices.archived_at`** : hiérarchie et archivage société (liste filtrée).
- **`office_comments`** : commentaires au niveau société (lecture / création par membres de l’office).
- **`SocietyContact` / carnet contacts société** : non implémenté — à prévoir via table dédiée ou réutilisation du référentiel **contacts** opération lorsque le schéma SPEC_18 sera étendu.

30
services/docv/enso-docs/features/implementation/README.md Normal file
View File

@ -0,0 +1,30 @@
# Implémentation technique par zone
Description technique d’implémentation de tous les écrans et toutes les actions (zones 1 à 15, 17 et 18) : routes, composants front, handlers/services/repositories back, BDD, paramétrage.
**Référentiel écrans et actions :** [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md).
**Specs fonctionnelles :** [specs/README.md](../specs/README.md).
**Architecture :** [ARCHITECTURE_DOCV_DETAILLEE.md](../../ARCHITECTURE_DOCV_DETAILLEE.md).
**Implémentation réelle enso-front ↔ docv-back (routes et fichiers) :** [DOCV_API_ENSO_FRONT_MAP.md](../DOCV_API_ENSO_FRONT_MAP.md) — complète les IMPL pour le périmètre déjà câblé (OAuth, `/api/v1/me`, offices, folders, listes dashboard). **Contrat front / enso-back :** [ENSO_FRONT_BACKEND_CONTRACT.md](../ENSO_FRONT_BACKEND_CONTRACT.md).
| # | Document | Zone | Spec |
|---|----------|------|------|
| 1 | [IMPL_01_auth_compte.md](IMPL_01_auth_compte.md) | 1 — Authentification et compte | [SPEC_01](../specs/SPEC_01_auth_compte.md) |
| 2 | [IMPL_05_offices_membres.md](IMPL_05_offices_membres.md) | 5 — Offices et membres | [SPEC_05](../specs/SPEC_05_offices_membres.md) |
| 3 | [IMPL_06_roles_permissions.md](IMPL_06_roles_permissions.md) | 6 — Rôles et permissions | [SPEC_06](../specs/SPEC_06_roles_permissions.md) |
| 4 | [IMPL_04_types_dossiers.md](IMPL_04_types_dossiers.md) | 4 — Types de dossiers | [SPEC_04](../specs/SPEC_04_types_dossiers.md) |
| 5 | [IMPL_03_documents_types.md](IMPL_03_documents_types.md) | 3 — Documents et types | [SPEC_03](../specs/SPEC_03_documents_types.md) |
| 6 | [IMPL_02_dossiers.md](IMPL_02_dossiers.md) | 2 — Dossiers | [SPEC_02](../specs/SPEC_02_dossiers.md) |
| 7 | [IMPL_07_parties_partage.md](IMPL_07_parties_partage.md) | 7 — Parties et partage | [SPEC_07](../specs/SPEC_07_parties_partage.md) |
| 8 | [IMPL_08_notes_rappels.md](IMPL_08_notes_rappels.md) | 8 — Notes et rappels | [SPEC_08](../specs/SPEC_08_notes_rappels.md) |
| 9 | [IMPL_09_abonnement_facturation.md](IMPL_09_abonnement_facturation.md) | 9 — Abonnement et facturation | [SPEC_09](../specs/SPEC_09_abonnement_facturation.md) |
| 10 | [IMPL_10_espace_client_invite.md](IMPL_10_espace_client_invite.md) | 10, 11 — Espace client / invité | [SPEC_10](../specs/SPEC_10_espace_client_invite.md) |
| 11 | [IMPL_12_admin_office.md](IMPL_12_admin_office.md) | 12 — Admin d’office | [SPEC_12](../specs/SPEC_12_admin_office.md) |
| 12 | [IMPL_13_admin_plateforme.md](IMPL_13_admin_plateforme.md) | 13 — Admin plateforme | [SPEC_13](../specs/SPEC_13_admin_plateforme.md) |
| 13 | [IMPL_14_contenus_parametres.md](IMPL_14_contenus_parametres.md) | 14 — Contenus et paramètres | [SPEC_14](../specs/SPEC_14_contenus_parametres.md) |
| 14 | [IMPL_15_technique_design.md](IMPL_15_technique_design.md) | 15 — Technique et design | [SPEC_15](../specs/SPEC_15_technique_design.md) |
| 15 | [IMPL_17_ia_local.md](IMPL_17_ia_local.md) | 17 — ia_local (enso) | [SPEC_17](../specs/SPEC_17_ia_local.md) |
| 16 | [IMPL_18_operation.md](IMPL_18_operation.md) | 18 — Opération (cabinet/office) | [SPEC_18](../specs/SPEC_18_operation.md) |
| — | [IMPL_ENSO_COMPANIES_SCREENS.md](IMPL_ENSO_COMPANIES_SCREENS.md) | Enso — Sociétés (`companies.*`) | [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](../MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md) |
**Template :** [TEMPLATE_IMPL.md](TEMPLATE_IMPL.md).

53
services/docv/enso-docs/features/implementation/TEMPLATE_IMPL.md Normal file
View File

@ -0,0 +1,53 @@
# Template — Document d’implémentation technique par zone
Ce template définit la structure d’un document d’implémentation technique pour une zone fonctionnelle. Les sections 2 et 3 s’appuient sur [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) pour la liste des identifiants d’écrans et des actions 18.x, et sur la SPEC correspondante pour les règles métier et les endpoints.
---
# Implémentation technique : [Nom de la zone]
**Zone** : [N°] — [Titre]
**Spec fonctionnelle** : [lien vers SPEC_xx]
**Référentiel** : [lien REFERENTIEL section zone]
## 1. Vue d’ensemble
- Périmètre technique (front, back, BDD, paramétrage) de la zone.
- Dépendances (autres zones, clients externes).
## 2. Écrans (détail technique)
Pour chaque écran du référentiel (identifiant stable) :
### [identifiant stable] — [Nom écran]
- **Route(s)** : chemin(s) front (ex. `app/(auth)/login/page.tsx`, route Next.js ou équivalent).
- **Front** :
- Page / composant principal (fichier, rôle).
- Composants enfants (liste ou arbre court).
- State : local (useState/useReducer) ou global (store/context), données chargées.
- Appels API : méthode, endpoint, moment (mount, submit, etc.), mapping réponse.
- Validation : côté client (WASM ou utils), champs concernés, messages d’erreur (i18n).
- Paramétrage : clé `screen_config` (identifiant stable), effet sur visibilité/ordre.
- **Back** :
- Handler(s) : fichier, route HTTP, extraction params/body, appel service, retour JSON/erreur.
- Service(s) : logique métier, appels repository et/ou clients externes.
- Repository / modèle : tables, requêtes principales (lecture/écriture).
- **BDD** : tables et colonnes concernées (rappel si déjà dans ARCHITECTURE_DOCV_DETAILLEE).
- **Paramétrage** : identifiant stable pour `screen_config`, conditions d’affichage.
(Répéter le bloc pour chaque écran de la zone.)
## 3. Actions (mapping technique)
Table synthétique : pour chaque action 18.x de la zone, le déclencheur UI, l’appel API ou l’action locale, le handler/service back, et la validation ou contrainte éventuelle.
| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.x | Bouton/lien/form | GET/POST/… endpoint | handler → service → repo | règle métier, message |
## 4. Points d’attention
- Erreurs typées, pas de fallback silencieux.
- Clients externes (ancrage, IA) : uniquement côté back, depuis quels services.
- i18n : clés utilisées pour libellés et messages d’erreur.

30
services/docv/enso-docs/features/specs/README.md Normal file
View File

@ -0,0 +1,30 @@
# Spécifications par fonctionnalité
Référentiel des spécifications détaillées par zone fonctionnelle pour docv / enso.
**Source des écrans et actions :** [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) (sections 1 à 17 et 18, liste des actions 18.1 à 18.96).
**Référentiel exhaustif (écrans + actions, identifiants stables) :** [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md).
**Description technique d’implémentation (routes, composants, back, BDD) :** [implementation/README.md](../implementation/README.md).
| # | Spec | Zone | Actions cartographie (18.x) |
|---|------|------|-----------------------------|
| 1 | [SPEC_01_auth_compte.md](SPEC_01_auth_compte.md) | 1 — Authentification et compte | 18.1, 18.2, 18.3 |
| 2 | [SPEC_02_dossiers.md](SPEC_02_dossiers.md) | 2 — Dossiers | 18.4 à 18.9 |
| 3 | [SPEC_03_documents_types.md](SPEC_03_documents_types.md) | 3 — Documents et types de documents | 18.10 à 18.14 |
| 4 | [SPEC_04_types_dossiers.md](SPEC_04_types_dossiers.md) | 4 — Types de dossiers | 18.15 à 18.17 |
| 5 | [SPEC_05_offices_membres.md](SPEC_05_offices_membres.md) | 5 — Offices et membres | 18.18 à 18.24 |
| 6 | [SPEC_06_roles_permissions.md](SPEC_06_roles_permissions.md) | 6 — Rôles et permissions | 18.25 à 18.27 |
| 7 | [SPEC_07_parties_partage.md](SPEC_07_parties_partage.md) | 7 — Parties au dossier et partage | 18.28 à 18.30 |
| 8 | [SPEC_08_notes_rappels.md](SPEC_08_notes_rappels.md) | 8 — Notes et rappels | 18.31 à 18.33 |
| 9 | [SPEC_09_abonnement_facturation.md](SPEC_09_abonnement_facturation.md) | 9 — Abonnement et facturation | 18.34 à 18.39 |
| 10 | [SPEC_10_espace_client_invite.md](SPEC_10_espace_client_invite.md) | 10, 11 — Espace client / invité | 18.40 à 18.43 |
| 11 | [SPEC_12_admin_office.md](SPEC_12_admin_office.md) | 12 — Admin d’office | 18.44 |
| 12 | [SPEC_13_admin_plateforme.md](SPEC_13_admin_plateforme.md) | 13 — Admin plateforme | 18.45 à 18.49 |
| 13 | [SPEC_14_contenus_parametres.md](SPEC_14_contenus_parametres.md) | 14 — Contenus et paramètres globaux | 18.50 |
| 14 | [SPEC_15_technique_design.md](SPEC_15_technique_design.md) | 15 — Technique et design | 18.51, 18.52 |
| 15 | [SPEC_17_ia_local.md](SPEC_17_ia_local.md) | 17 — Fonctionnalités ia_local (enso) | 18.53 à 18.83 |
| 16 | [SPEC_18_operation.md](SPEC_18_operation.md) | 18 — Opération (cabinet/office) | 18.84 à 18.93 |
Chaque spec détaille : objectif, écrans et routes, actions, règles métier, paramétrage, données et API, sécurité et accessibilité, impacts, déploiement, analyse.

70
services/docv/enso-docs/features/specs/SPEC_01_auth_compte.md Normal file
View File

@ -0,0 +1,70 @@
# Spec : Authentification et compte
**Zone** : 1 — Authentification et compte
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 1, actions 18.1 à 18.3.
## 1. Objectif
- Permettre l’identification et la gestion de session des utilisateurs (connexion, déconnexion, choix d’office actif).
- Permettre la consultation et la mise à jour du profil utilisateur (données personnelles, préférences, mot de passe).
- Périmètre identique pour **docv** et **enso** dans ce dépôt ; les options (SSO, 2FA, choix d’office) sont paramétrables par plateforme ou par office.
**Login par défaut docv et usage par enso :** docv implémente un **système de login par défaut** (identifiant / mot de passe, session ou JWT, choix d’office) pour **tous les types de membres** (rôles des offices, membres des dossiers, offices). **enso** l’utilise par défaut. Un fournisseur d’identité ou un flux de connexion entièrement distinct pour un autre déploiement reste **hors périmètre** de ce clone (voir `docs/HORS_PERIMETRE_NOTAIRE.md`). Lorsqu’un flux d’authentification propre est ajouté ailleurs, les contrats côté back (user, office actif, rôles) restent alignés sur le modèle docv pour la suite du parcours (dossiers, documents, partage).
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Connexion | auth (page de login) | `auth.login` | Connexion identifiant/mot de passe ou SSO ; choix d’office actif si multi-offices. |
| Déconnexion | `/logout-callback` | `auth.logout` | Déconnexion sécurisée, redirection, nettoyage session. |
| Mon compte | `/my-account` | `auth.my-account` | Consultation et mise à jour profil (nom, email, téléphone, préférences) ; changement mot de passe si applicable. |
## 3. Actions détaillées
- **18.1 Connexion** : Saisir identifiant et mot de passe (ou SSO) ; valider ; choisir office actif si multi-offices ; afficher message d’erreur en cas d’échec.
- **18.2 Déconnexion** : Déclencher déconnexion ; nettoyer session côté client ; rediriger vers page de connexion ou page publique.
- **18.3 Mon compte** : Consulter profil ; modifier profil ; changer mot de passe (si applicable) ; enregistrer.
Droits : toute action « Mon compte » requiert un utilisateur authentifié ; pas de droit spécifique au-delà de l’auth. Conditions d’affichage : écran « Mon compte » visible si l’option est activée (paramétrage plateforme/office).
## 4. Règles métier et contraintes
- Connexion : champs identifiant et mot de passe obligatoires (ou flux SSO) ; après authentification réussie, si un seul office → redirection directe ; si plusieurs offices → écran de choix d’office puis redirection.
- Déconnexion : invalidation du token/session côté serveur ; suppression des données de session côté client ; pas de fallback silencieux en cas d’erreur (afficher message et proposer redirection).
- Mon compte : validation des champs (email format, téléphone optionnel) ; changement de mot de passe soumis aux règles de complexité configurées ; en cas d’erreur API, afficher le message et ne pas perdre les données saisies.
## 5. Paramétrage
- Visibilité des écrans : Connexion (toujours), Déconnexion (lien après connexion), Mon compte (paramétrable par office).
- Options : activation SSO, activation 2FA, choix d’office obligatoire ou non.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `User` (id, email, name, phone, preferences, office_affiliations), `Session` / token.
- Endpoints typiques : `POST /auth/login`, `POST /auth/logout`, `GET /auth/me`, `PATCH /users/me`, `POST /auth/change-password` ; SSO callbacks selon implémentation.
- Pas de dépendance ancrage ou IA sur cette zone.
## 7. Sécurité et accessibilité
- Auth : stockage sécurisé des tokens ; pas de mot de passe en clair côté client.
- Données sensibles : mot de passe jamais affiché ; email et téléphone masquables selon politique.
- Accessibilité : labels sur tous les champs de formulaire ; focus géré (ordre de tabulation) ; messages d’erreur associés aux champs (ARIA) ; contraste suffisant sur boutons et liens.
## 8. Impacts
- Front : pages auth, my-account, composants formulaire et messages d’erreur.
- Back : module auth, gestion session, endpoints utilisateur.
- Shared : types User, Session, préférences.
- Dépendances : zone 5 (Offices) pour le choix d’office actif.
## 9. Modalités de déploiement
- Prérequis : configuration SSO si activé (clients, URLs de callback) ; variables d’environnement pour l’URL de redirection post-logout.
- Aucune migration spécifique obligatoire pour la zone seule ; déploiement standard front + back.
## 10. Modalités d’analyse
- Recette : connexion avec identifiant valide/invalide ; déconnexion puis tentative d’accès à une page protégée ; modification du profil et vérification en base ; changement de mot de passe puis reconnexion.
- Logs : échecs de connexion, déconnexion, modification du profil (audit si requis).
- Données : vérifier que le profil mis à jour est bien persisté et reflété sur l’écran Mon compte.

77
services/docv/enso-docs/features/specs/SPEC_02_dossiers.md Normal file
View File

@ -0,0 +1,77 @@
# Spec : Dossiers
**Zone** : 2 — Dossiers (folders / cases)
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 2, actions 18.4 à 18.9.
**Vocabulaire espace client (société = dossier permanent, dossier liste = opération)** : [MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md](../MODELE_SOCIETES_ET_DOSSIERS_DOPERATION.md).
## 1. Objectif
- Gérer le cycle de vie des dossiers (création, consultation, modification, archivage, suppression) au sein de l’office actif.
- Fournir listes, filtres, tri et accès aux dossiers archivés et supprimés.
- Périmètre docv / enso identique ; libellés et options (ex. ancrage) selon paramétrage métier.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Liste des dossiers | `/folders` | `folders.list` | Liste paginée, filtres (statut, type, recherche), tri ; accès archivés/supprimés ; création. |
| Sélection de dossier | `/folders/select` | `folders.select` | Choix d’un dossier pour une action contextuelle. |
| Détail d’un dossier | `/folders/[folderUid]` | `folders.detail` | Fiche : en-tête, parties, documents, notes, partages, historique ; actions modifier, archiver, supprimer, ancrage. |
| Dossiers archivés | `/folders/archived` | `folders.archived` | Liste archivés ; restauration ou consultation. |
| Dossiers supprimés | `/folders/deleted` | `folders.deleted` | Liste corbeille ; restauration ou suppression définitive. |
| Création / édition de dossier | modal ou route dédiée | `folders.create`, `folders.edit` | Formulaire nom, type, description, parties ; validation. |
## 3. Actions détaillées
- **18.4 Liste des dossiers** : Afficher liste paginée ; filtrer par statut, type, recherche ; tri ; ouvrir détail ; accès archivés/supprimés ; créer (si droit).
- **18.5 Sélection de dossier** : Afficher liste/recherche ; sélectionner et valider ; annuler.
- **18.6 Détail dossier** : Consulter en-tête, parties, documents, notes, partages, historique ; modifier, archiver, supprimer, ancrage ; téléverser document, ajouter note, gérer partage/invités.
- **18.7 Dossiers archivés** : Afficher liste ; restaurer (si droit) ; consulter détail.
- **18.8 Dossiers supprimés** : Afficher liste ; restaurer ou supprimer définitivement (si droit).
- **18.9 Création / édition** : Saisir nom, type, description, parties ; valider ; annuler.
Droits : matrice rôle × ressource `folder` × actions (create, read, update, archive, delete). Conditions d’affichage : écrans archivés/supprimés selon paramétrage office ; ancrage si option activée.
## 4. Règles métier et contraintes
- Validation : nom obligatoire ; type de dossier obligatoire et doit appartenir aux types configurés pour l’office ; statuts et transitions définis (ex. ouvert → en cours → archivé).
- Archivage : un dossier archivé n’apparaît plus dans la liste principale ; restauration remet le dossier en liste principale.
- Suppression : suppression logique (corbeille) ; suppression définitive irréversible ; pas de fallback silencieux sur erreur (message explicite).
- Cohérence : un dossier appartient à un office ; les parties liées sont optionnelles à la création.
## 5. Paramétrage
- Visibilité et ordre des écrans (liste, archivés, supprimés) par office ; libellés par type de dossier.
- Actions : activation archivage, suppression définitive, ancrage par office ou type de dossier.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `Folder` (uid, office_uid, name, folder_type_uid, status, description, created_at, updated_at, archived_at, deleted_at), `FolderParty` (liaison dossier–partie).
- **Implémentation docv actuelle (espace client)** : champs supplémentaires sur `folders` : **`folder_purpose`** (`client_operation` \| `dp_structure_demo`), **`operation_type`** (slug ou texte libre, type métier d’opération). Les dossiers « Jeu type … » (seed démo DP) sont des structures **`dp_structure_demo`** ; création utilisateur = **`client_operation`**. Voir [DOCV_API_ENSO_FRONT_MAP.md](../DOCV_API_ENSO_FRONT_MAP.md) (`POST` / `PATCH` / réponses dossier).
- Endpoints : `GET/POST /folders`, `GET/PATCH/DELETE /folders/[folderUid]`, `POST /folders/[folderUid]/archive`, `POST /folders/[folderUid]/restore`, `DELETE /folders/[folderUid]/permanent` ; `GET /folders/archived`, `GET /folders/deleted`.
- Dépendances : zone 4 (types de dossiers), zone 7 (parties) ; ancrage si activé (back).
## 7. Sécurité et accessibilité
- Autorisation : accès limité aux dossiers de l’office actif (et partagés selon zone 7).
- Données sensibles : pas d’affichage de données sensibles sans contrôle de droit.
- Accessibilité : listes avec en-têtes de colonnes, tri au clavier ; formulaires avec labels et erreurs associées ; boutons d’action identifiables.
## 8. Impacts
- Front : pages folders (liste, détail, archivés, supprimés, sélection), formulaires.
- Back : module folders, règles métier statuts/archivage/suppression.
- Shared : types Folder, statuts.
- Dépendances : zones 3 (documents), 4 (types de dossiers), 7 (partage), 8 (notes).
## 9. Modalités de déploiement
- Prérequis : types de dossiers existants (zone 4) ; migrations éventuelles pour statuts ou champs (selon modèle existant).
- Déploiement standard ; pas d’étape spécifique hors flux standard.
## 10. Modalités d’analyse
- Recette : création, édition, archivage, restauration, suppression logique et définitive ; filtres et tri sur la liste ; accès au détail et vérification des onglets (documents, notes, partages).
- Logs : création, modification, archivage, suppression (audit).
- Données : cohérence statut/archived_at/deleted_at en base.

73
services/docv/enso-docs/features/specs/SPEC_03_documents_types.md Normal file
View File

@ -0,0 +1,73 @@
# Spec : Documents et types de documents
**Zone** : 3 — Documents et types de documents
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 3, actions 18.10 à 18.14.
## 1. Objectif
- Gérer les types de documents (référentiel office) : création, édition, liste.
- Gérer les documents d’un dossier : téléversement, liste, téléchargement, suppression, validation (workflow si activé), filigrane et ancrage si applicable.
- Périmètre docv / enso identique ; options (workflow, filigrane, ancrage) paramétrables.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Types de documents | `/document-types` | `document-types.list` | Liste des types paramétrés ; création ; ouverture détail. |
| Création type de document | `/document-types/create` | `document-types.create` | Création d’un type (libellé, description, obligatoire, etc.). |
| Détail type de document | `/document-types/[documentTypeUid]` | `document-types.detail` | Consultation et édition du type. |
| Documents d’un dossier | dans `/folders/[folderUid]` (onglet ou section) | `documents.folder` | Liste documents ; upload, téléchargement, suppression, validation ; filigrane, ancrage. |
| Téléversement / détail document | modal ou panneau | `documents.upload`, `documents.detail` | Upload fichiers, métadonnées ; statut validation ; preuve ancrage. |
## 3. Actions détaillées
- **18.10 Types de documents** : Afficher liste ; créer (si droit) ; ouvrir détail.
- **18.11 Création type de document** : Saisir libellé, description, options ; enregistrer ; annuler.
- **18.12 Détail type de document** : Consulter ; modifier ou supprimer (si droit et non utilisé).
- **18.13 Documents d’un dossier** : Afficher liste ; téléverser ; télécharger (original ou filigrané) ; supprimer ; valider ; consulter preuve ancrage ; ouvrir détail.
- **18.14 Téléversement / détail document** : Sélectionner fichiers ; saisir métadonnées ; envoyer ; consulter statut et preuve ancrage ; annuler/fermer.
Droits : ressource `document_type` (CRUD) ; ressource `document` (create, read, update, delete, validate). Conditions : workflow, filigrane, ancrage selon paramétrage office/type de dossier.
## 4. Règles métier et contraintes
- Types de documents : libellé obligatoire ; suppression interdite si le type est utilisé par au moins un document.
- Documents : un document appartient à un dossier et optionnellement à un type de document ; statuts de workflow (ex. à demander, demandé, reçu, validé, refusé) si activé.
- Téléversement : types de fichiers autorisés et taille max selon configuration ; en cas d’échec (réseau, validation), message explicite sans fallback silencieux.
- Ancrage : si activé, preuve consultable en lecture seule ; pas de modification post-ancrage sans nouvelle version.
## 5. Paramétrage
- Visibilité des écrans « Types de documents » par office ; options par type (obligatoire, ordre d’affichage).
- Options document : workflow à N statuts, filigrane, ancrage, types de fichiers, taille max.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `DocumentType` (uid, office_uid, label, description, is_required, …), `Document` (uid, folder_uid, document_type_uid, file_ref, status, anchored_at, …).
- Endpoints : `GET/POST /document-types`, `GET/PATCH/DELETE /document-types/[documentTypeUid]` ; `GET/POST /folders/[folderUid]/documents`, `GET/DELETE /documents/[documentUid]`, `POST /documents/[documentUid]/validate`, upload (multipart).
- Dépendances : zone 2 (dossiers) ; ancrage (service back) si activé.
## 7. Sécurité et accessibilité
- Autorisation : types de documents par office ; documents selon droit sur le dossier (et partage).
- Données sensibles : téléchargement filigrané selon rôle ; preuve d’ancrage en lecture seule.
- Accessibilité : formulaires upload avec labels ; statuts et erreurs annoncés ; liens de téléchargement explicites.
## 8. Impacts
- Front : pages document-types, bloc documents dans détail dossier, modals upload/détail.
- Back : module document-types, documents, stockage fichiers, workflow, ancrage.
- Shared : types DocumentType, Document, statuts.
- Dépendances : zones 2 (dossiers), 4 (types de dossiers pour association).
## 9. Modalités de déploiement
- Prérequis : stockage fichiers configuré ; migrations pour tables document_types, documents ; seeds éventuels pour types par défaut.
- Pas d’étape spécifique hors flux standard.
## 10. Modalités d’analyse
- Recette : CRUD types de documents ; téléversement, téléchargement, suppression, validation (si workflow) ; vérification preuve ancrage si activée.
- Logs : création/suppression de type, upload, validation, erreurs d’upload.
- Données : intégrité folder–document, statuts cohérents avec workflow.

68
services/docv/enso-docs/features/specs/SPEC_04_types_dossiers.md Normal file
View File

@ -0,0 +1,68 @@
# Spec : Types de dossiers
**Zone** : 4 — Types de dossiers (case types / folder types)
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 4, actions 18.15 à 18.17.
## 1. Objectif
- Définir le référentiel des types de dossiers pour l’office (ex. Vente, Prêt) et leur association aux types de documents (requis ou optionnels).
- Permettre la création, l’édition et la consultation des types de dossiers.
- Périmètre docv / enso identique ; libellés métier selon projet.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Types de dossiers | `/case-types` ou `/folder-types` | `case-types.list` | Liste des types ; création ; ouverture détail. |
| Création type de dossier | `/case-types/create` | `case-types.create` | Création et liaison aux types de documents. |
| Détail type de dossier | `/case-types/[caseTypeUid]` | `case-types.detail` | Consultation et édition ; types de documents liés. |
## 3. Actions détaillées
- **18.15 Types de dossiers** : Afficher liste ; créer (si droit) ; ouvrir détail.
- **18.16 Création type de dossier** : Saisir libellé ; associer types de documents requis/optionnels ; enregistrer ; annuler.
- **18.17 Détail type de dossier** : Consulter propriétés et types de documents liés ; modifier ou supprimer (si droit et non utilisé).
Droits : ressource `case_type` (ou `folder_type`) × actions create, read, update, delete. Conditions : suppression interdite si au moins un dossier utilise ce type.
## 4. Règles métier et contraintes
- Libellé du type de dossier obligatoire et unique par office.
- Association aux types de documents : liste de types avec indicateur requis/optionnel ; les types de documents doivent exister (zone 3).
- Suppression : interdite si le type est utilisé par au moins un dossier ; message d’erreur explicite.
- Pas de fallback silencieux sur erreur de validation ou contrainte.
## 5. Paramétrage
- Visibilité des écrans par office ; ordre d’affichage des types dans les listes déroulantes (création dossier).
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `CaseType` / `FolderType` (uid, office_uid, label, …), `CaseTypeDocumentType` (case_type_uid, document_type_uid, is_required).
- Endpoints : `GET/POST /case-types`, `GET/PATCH/DELETE /case-types/[caseTypeUid]` ; association types de documents dans le payload ou endpoint dédié.
- Dépendances : zone 3 (types de documents) pour les références.
## 7. Sécurité et accessibilité
- Autorisation : accès limité aux types de l’office actif ; création/édition/suppression selon rôle admin ou droit dédié.
- Accessibilité : formulaires avec labels ; messages d’erreur liés aux champs ; listes triables.
## 8. Impacts
- Front : pages case-types (liste, création, détail).
- Back : module case-types, contraintes et vérification d’usage avant suppression.
- Shared : types CaseType, association document types.
- Dépendances : zones 2 (dossiers), 3 (types de documents).
## 9. Modalités de déploiement
- Prérequis : types de documents existants si association à la création ; migrations pour tables case_types et liaison.
- Seeds possibles pour types par défaut par métier (enso).
- Déploiement standard.
## 10. Modalités d’analyse
- Recette : création type avec association de types de documents ; édition ; tentative de suppression d’un type utilisé (doit échouer avec message clair).
- Logs : création, modification, suppression (si autorisée).
- Données : unicité libellé par office ; intégrité des liaisons case_type–document_type.

77
services/docv/enso-docs/features/specs/SPEC_05_offices_membres.md Normal file
View File

@ -0,0 +1,77 @@
# Spec : Offices et membres
**Zone** : 5 — Offices et membres
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 5, actions 18.18 à 18.24.
## 1. Objectif
- Gérer les offices accessibles à l’utilisateur et le contexte (office actif).
- Gérer la fiche office (détail, paramètres, coordonnées bancaires si applicable).
- Gérer les collaborateurs et utilisateurs (liste, détail, rôles, droits, désactivation).
- Périmètre docv / enso identique ; RIB/coordonnées bancaires selon périmètre métier.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Liste des offices | `/offices` | `offices.list` | Liste des offices accessibles ; sélection office actif. |
| Détail d’un office | `/offices/[officeUid]` | `offices.detail` | Fiche office : nom, adresse, paramètres ; rôles et membres. |
| Coordonnées bancaires | `/offices/rib` | `offices.rib` | Saisie et mise à jour des coordonnées bancaires (si périmètre). |
| Collaborateurs | `/collaborators` | `collaborators.list` | Liste des collaborateurs ; création/invitation ; détail. |
| Détail collaborateur | `/collaborators/[collaboratorUid]` | `collaborators.detail` | Fiche : contact, rôle, dossiers partagés ; édition droits. |
| Utilisateurs | `/users` | `users.list` | Liste utilisateurs (office ou plateforme selon rôle) ; détail. |
| Détail utilisateur | `/users/[userUid]` | `users.detail` | Fiche : profil, offices, rôles, affiliations ; édition, désactivation. |
## 3. Actions détaillées
- **18.18 Liste des offices** : Afficher liste ; sélectionner office actif ; ouvrir détail (si droit).
- **18.19 Détail office** : Consulter infos ; modifier (si droit) ; accéder rôles/membres ; accéder RIB si applicable.
- **18.20 Coordonnées bancaires** : Consulter ; saisir ou modifier (si droit) ; enregistrer.
- **18.21 Collaborateurs** : Afficher liste ; créer ou inviter (si droit) ; ouvrir détail.
- **18.22 Détail collaborateur** : Consulter profil et rôle ; consulter dossiers partagés ; modifier rôle/droits ou désactiver/retirer (si droit).
- **18.23 Utilisateurs** : Afficher liste ; filtrer/rechercher ; ouvrir détail ; créer (si admin plateforme).
- **18.24 Détail utilisateur** : Consulter profil, offices, rôles ; modifier ou désactiver (si droit).
Droits : ressource `office` (read, update), `rib` (read, update) ; ressource `collaborator` (CRUD) ; ressource `user` (read, update, delete) avec périmètre office ou plateforme selon rôle.
## 4. Règles métier et contraintes
- Office actif : un seul office actif par session ; changement d’office recharge le contexte (dossiers, types, etc.).
- Collaborateur vs utilisateur : collaborateur = membre d’un office avec rôle ; utilisateur = compte plateforme (peut être lié à plusieurs offices).
- Désactivation : un collaborateur ou utilisateur désactivé ne peut plus se connecter ; les dossiers existants restent accessibles selon règles de partage.
- RIB : validation des champs (IBAN, BIC, etc.) selon règles métier ; pas de fallback silencieux.
## 5. Paramétrage
- Visibilité des écrans (offices, RIB, collaborators, users) par rôle ; RIB activé/désactivé par plateforme ou métier.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `Office` (uid, name, address, …), `OfficeRib` (office_uid, iban, bic, …), `Collaborator` (user_uid, office_uid, role_uid, …), `User` (uid, email, name, …).
- Endpoints : `GET /offices`, `GET/PATCH /offices/[officeUid]`, `GET/PATCH /offices/[officeUid]/rib` ; `GET/POST /collaborators`, `GET/PATCH/DELETE /collaborators/[collaboratorUid]` ; `GET/POST /users`, `GET/PATCH /users/[userUid]`.
- Pas de dépendance ancrage/IA sur cette zone.
## 7. Sécurité et accessibilité
- Autorisation : liste offices limitée aux affiliations de l’utilisateur ; détail office et collaborateurs limité à l’office actif (ou tous pour admin plateforme).
- Données sensibles : RIB masqué en affichage (masquage partiel) ; audit sur consultation/modification RIB.
- Accessibilité : tableaux avec en-têtes ; formulaires avec labels ; messages d’erreur associés.
## 8. Impacts
- Front : pages offices, collaborators, users (listes et détails), formulaire RIB.
- Back : modules offices, collaborators, users, RIB.
- Shared : types Office, Collaborator, User.
- Dépendances : zone 6 (rôles) pour les droits ; zone 1 (auth) pour le choix d’office.
## 9. Modalités de déploiement
- Prérequis : structure BDD offices, users, collaborators, RIB ; seeds pour premier office/admin si bootstrap.
- Déploiement standard.
## 10. Modalités d’analyse
- Recette : changement d’office actif ; édition fiche office ; gestion RIB ; CRUD collaborateurs ; consultation/édition utilisateurs ; désactivation et vérification de l’accès.
- Logs : changement office actif, modification office/RIB, ajout/retrait collaborateur, désactivation utilisateur.
- Données : cohérence user–collaborator–office ; RIB validé selon règles.

68
services/docv/enso-docs/features/specs/SPEC_06_roles_permissions.md Normal file
View File

@ -0,0 +1,68 @@
# Spec : Rôles et permissions
**Zone** : 6 — Rôles et permissions
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 6, actions 18.25 à 18.27.
## 1. Objectif
- Définir les rôles (globaux et/ou par office) et la matrice des permissions (ressources × actions).
- Permettre la création, l’édition et la suppression des rôles (sous réserve de non-utilisation).
- Périmètre docv / enso identique ; les ressources et actions sont alignées sur la cartographie et le paramétrage.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Rôles | `/roles` | `roles.list` | Liste des rôles ; création ; détail. |
| Création rôle | `/roles/create` | `roles.create` | Création et attribution des permissions. |
| Détail rôle | `/roles/[roleUid]` | `roles.detail` | Consultation et édition ; matrice des permissions. |
## 3. Actions détaillées
- **18.25 Rôles** : Afficher liste ; créer (si droit) ; ouvrir détail ; supprimer (si droit et non utilisé).
- **18.26 Création rôle** : Saisir nom ; attribuer permissions (matrice ou par ressource/action) ; enregistrer ; annuler.
- **18.27 Détail rôle** : Consulter rôle et matrice ; modifier nom ou permissions (si droit) ; supprimer (si droit).
Droits : ressource `role` × create, read, update, delete. Un rôle ne peut être supprimé que s’il n’est attribué à aucun collaborateur/utilisateur.
## 4. Règles métier et contraintes
- Nom du rôle obligatoire et unique (par scope : global ou office).
- Matrice : ressources (folder, document, document_type, case_type, office, collaborator, user, role, subscription, …) × actions (create, read, update, delete, archive, share, …) ; les valeurs sont booléennes ou niveau (aucun, lecture, écriture, admin).
- Suppression : interdite si le rôle est utilisé ; message d’erreur explicite.
- Au moins un rôle avec droits suffisants doit exister pour l’office (éviter lockout).
## 5. Paramétrage
- Rôles système (non supprimables) vs rôles personnalisés ; visibilité des écrans par rôle.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `Role` (uid, office_uid ou null pour global, name, …), `Permission` (role_uid, resource, action, granted).
- Endpoints : `GET/POST /roles`, `GET/PATCH/DELETE /roles/[roleUid]` ; permissions dans le payload ou `GET/PATCH /roles/[roleUid]/permissions`.
- Pas de dépendance ancrage/IA.
## 7. Sécurité et accessibilité
- Autorisation : accès à la gestion des rôles réservé aux admins (office ou plateforme selon scope).
- Données sensibles : la matrice des permissions est sensible ; audit sur modification.
- Accessibilité : matrice lisible (en-têtes de ligne/colonne) ; cases à cocher ou sélecteurs accessibles au clavier.
## 8. Impacts
- Front : pages roles (liste, création, détail avec matrice).
- Back : module roles et permissions ; vérification d’usage avant suppression.
- Shared : types Role, Permission, liste des ressources/actions.
- Dépendances : zone 5 (collaborators, users) pour l’attribution des rôles ; toutes les zones consomment les permissions pour l’affichage et les actions.
## 9. Modalités de déploiement
- Prérequis : migrations pour roles et permissions ; seeds pour rôles par défaut (admin, membre, lecteur, etc.).
- Déploiement standard.
## 10. Modalités d’analyse
- Recette : création rôle avec attribution de permissions ; édition matrice ; tentative de suppression d’un rôle utilisé (doit échouer).
- Logs : création, modification, suppression de rôle.
- Données : unicité du nom de rôle par scope ; intégrité role–permission et role–collaborator.

69
services/docv/enso-docs/features/specs/SPEC_07_parties_partage.md Normal file
View File

@ -0,0 +1,69 @@
# Spec : Parties au dossier et partage
**Zone** : 7 — Parties au dossier et partage
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 7, actions 18.28 à 18.30.
## 1. Objectif
- Gérer les parties au dossier (clients) : liste, création, édition, suppression, liaison à un dossier.
- Gérer le partage de dossier avec d’autres offices ou avec des parties externes (invités) : invitations, rôles (lecture/écriture), révocation.
- Périmètre docv / enso identique ; libellés (client, tiers, invité) selon métier.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Parties au dossier | `/customers` | `customers.list` | Liste des parties ; création, édition, suppression ; liaison à un dossier. |
| Partage de dossier | dans détail dossier `/folders/[folderUid]` | `sharing.folder` | Liste partages actifs ; créer partage ; modifier rôle ; révoquer ; renvoyer invitation. |
| Parties externes / invités | dans détail dossier | `sharing.invitees` | Liste invités ; ajouter (email, rôle) ; modifier rôle ; renvoyer invitation ; retirer. |
## 3. Actions détaillées
- **18.28 Parties au dossier** : Afficher liste ; créer, modifier, supprimer (si droit) ; lier une partie à un dossier.
- **18.29 Partage de dossier** : Consulter partages ; créer (inviter office ou partie externe) ; modifier rôle (lecture/écriture) ; révoquer ; renvoyer invitation en attente.
- **18.30 Parties externes / invités** : Afficher liste invités ; ajouter (email, rôle lecteur/contributeur) ; modifier rôle ; renvoyer invitation ; retirer invité.
Droits : ressource `customer` / `party` (CRUD) ; ressource `folder_share` (create, read, update, delete). Conditions : partage visible seulement si fonction partage activée pour l’office ou le type de dossier.
## 4. Règles métier et contraintes
- Parties : une même partie peut être liée à plusieurs dossiers ; champs obligatoires selon modèle (nom, email, etc.).
- Partage : un partage lie un dossier à un office ou à un invité (email) avec un rôle ; invitation en attente jusqu’à acceptation (si applicable).
- Révocation : retrait immédiat de l’accès ; les documents déjà téléchargés restent hors contrôle.
- Pas de fallback silencieux : erreur d’envoi d’invitation, doublon email, etc. → message explicite.
## 5. Paramétrage
- Activation du partage (inter-offices, invités externes) par office ou type de dossier.
- Rôles de partage : lecture seule, contributeur (lecture + dépôt) ; libellés paramétrables.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `Customer` / `Party` (uid, office_uid, name, email, …), `FolderParty` (folder_uid, party_uid), `FolderShare` (folder_uid, target_office_uid ou invitee_email, role, status, token).
- Endpoints : `GET/POST /customers`, `GET/PATCH/DELETE /customers/[customerUid]`, `POST /folders/[folderUid]/parties` ; `GET/POST /folders/[folderUid]/shares`, `PATCH/DELETE /folders/[folderUid]/shares/[shareUid]`, `POST /folders/[folderUid]/shares/[shareUid]/resend`.
- Dépendances : zone 2 (dossiers) ; envoi d’emails pour invitations (back).
## 7. Sécurité et accessibilité
- Autorisation : parties selon office ; partage selon droit sur le dossier (partager).
- Données sensibles : emails des invités ; audit des créations/révocations de partage.
- Accessibilité : formulaires avec labels ; listes avec actions clairement identifiées ; messages de confirmation avant révocation.
## 8. Impacts
- Front : page customers, blocs partage et invités dans détail dossier.
- Back : modules customers, folder_shares, envoi d’invitations.
- Shared : types Customer, FolderShare, rôles de partage.
- Dépendances : zones 2 (dossiers), 10–11 (espaces client et invité pour les destinataires du partage).
## 9. Modalités de déploiement
- Prérequis : tables customers, folder_shares (ou équivalent) ; configuration envoi d’emails (invitations).
- Déploiement standard.
## 10. Modalités d’analyse
- Recette : CRUD parties et liaison à un dossier ; création partage (office et invité) ; modification rôle ; révocation ; renvoi d’invitation ; vérification accès côté client/invité.
- Logs : création/révocation partage ; envoi invitation ; échec envoi.
- Données : cohérence folder–parties et folder–shares ; statut des invitations.

68
services/docv/enso-docs/features/specs/SPEC_08_notes_rappels.md Normal file
View File

@ -0,0 +1,68 @@
# Spec : Notes et rappels
**Zone** : 8 — Notes et rappels
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 8, actions 18.31 à 18.33.
## 1. Objectif
- Gérer les notes (liste globale ou par dossier, création, édition, suppression).
- Gérer les rappels (documents à fournir, échéances) et leur configuration par type de document et par office.
- Périmètre docv / enso identique.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Notes | `/notes` | `notes.list` | Liste des notes (par dossier ou globale selon droits) ; filtres ; ouverture détail/édition. |
| Notes d’un dossier | `/notes/folder`, `/notes/[noteUid]` | `notes.folder`, `notes.detail` | Création, consultation, modification, suppression de notes liées au dossier. |
| Rappels | `/reminders` | `reminders.list` | Liste des rappels ; détail ; configuration par type de document et par office (si droit). |
## 3. Actions détaillées
- **18.31 Notes** : Afficher liste ; filtrer par dossier ou date ; ouvrir note (détail ou édition).
- **18.32 Notes d’un dossier** : Créer note liée au dossier ; consulter ; modifier ou supprimer (si droit).
- **18.33 Rappels** : Afficher liste ; consulter détail ; configurer rappels par type de document et par office (si droit).
Droits : ressource `note` (create, read, update, delete) ; ressource `reminder_config` (read, update). Conditions : liste globale des notes selon droit (sinon limitée aux dossiers accessibles).
## 4. Règles métier et contraintes
- Note : liée à un dossier (ou globale si prévu) ; contenu texte ; date de création/modification.
- Rappel : peut être lié à un type de document, une échéance, un dossier ; configuration = règles par office et/ou type de document (ex. délai en jours avant échéance).
- Suppression d’une note : définitive ; pas de corbeille spécifique.
- Pas de fallback silencieux sur erreur de sauvegarde ou de configuration.
## 5. Paramétrage
- Visibilité des écrans Notes et Rappels par office ; activation des rappels par type de document.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `Note` (uid, folder_uid, content, author_uid, created_at, updated_at), `Reminder` (uid, folder_uid, document_type_uid, due_date, …), `ReminderConfig` (office_uid, document_type_uid, delay_days, …).
- Endpoints : `GET/POST /notes` (query folder_uid), `GET/PATCH/DELETE /notes/[noteUid]` ; `GET /reminders`, `GET/PATCH /reminders/config` (ou par office/type).
- Dépendances : zone 2 (dossiers), zone 3 (types de documents pour rappels).
## 7. Sécurité et accessibilité
- Autorisation : notes selon accès au dossier ; rappels selon accès aux dossiers et à la config.
- Données sensibles : contenu des notes peut être sensible ; audit en lecture si requis.
- Accessibilité : listes et formulaires avec labels ; champs date accessibles.
## 8. Impacts
- Front : pages notes (liste, détail), rappels (liste, config).
- Back : modules notes, reminders, reminder_config.
- Shared : types Note, Reminder, ReminderConfig.
- Dépendances : zones 2 (dossiers), 3 (types de documents).
## 9. Modalités de déploiement
- Prérequis : tables notes, reminders, reminder_config ; migrations si champs ajoutés.
- Déploiement standard.
## 10. Modalités d’analyse
- Recette : création/édition/suppression de note (depuis liste et depuis détail dossier) ; liste des rappels ; modification de la configuration des rappels.
- Logs : création, modification, suppression de note ; modification config rappels.
- Données : intégrité note–folder ; rappels cohérents avec la config.

75
services/docv/enso-docs/features/specs/SPEC_09_abonnement_facturation.md Normal file
View File

@ -0,0 +1,75 @@
# Spec : Abonnement et facturation
**Zone** : 9 — Abonnement et facturation
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 9, actions 18.34 à 18.39.
## 1. Objectif
- Consulter l’abonnement de l’office (plan, nombre de collaborateurs, renouvellement).
- Souscrire un plan, gérer l’abonnement (modification de plan, moyens de paiement), gérer les sièges/collaborateurs et les invitations.
- Gérer les retours post-paiement (succès / erreur).
- Périmètre selon métier : docv / enso peuvent activer ou non cette zone (facturation interne ou externe).
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Abonnement | `/subscription` | `subscription.overview` | Vue d’ensemble : plan, collaborateurs, renouvellement. |
| Souscrire | `/subscription/subscribe`, `/subscription/new` | `subscription.subscribe` | Choix du plan ; souscription ; paiement si intégré. |
| Gérer l’abonnement | `/subscription/manage` | `subscription.manage` | Modification plan ; mise à jour moyens de paiement ; annulation si prévu. |
| Gérer les collaborateurs | `/subscription/manage-collaborators` | `subscription.collaborators` | Sièges utilisés/disponibles ; activation/désactivation sièges ; lien sièges–collaborateurs. |
| Invitation | `/subscription/invite` | `subscription.invite` | Envoi d’invitations ; liste invitations en attente ; renvoyer ou annuler. |
| Succès / erreur | `/subscription/success`, `/subscription/error` | `subscription.success`, `subscription.error` | Résultat du paiement ; retour tableau de bord ou gestion. |
## 3. Actions détaillées
- **18.34 Abonnement** : Consulter plan et nombre de collaborateurs ; date de renouvellement ; accéder à la gestion ou à la souscription selon état.
- **18.35 Souscrire** : Choisir plan ; saisir infos de paiement (si intégré) ; valider ; annuler.
- **18.36 Gérer l’abonnement** : Consulter plan et moyens de paiement ; modifier plan ; mettre à jour paiement ; annuler abonnement si prévu.
- **18.37 Gérer les collaborateurs** : Consulter sièges utilisés/disponibles ; activer ou désactiver sièges ; lier sièges aux collaborateurs.
- **18.38 Invitation** : Saisir email (et rôle) ; envoyer invitation ; consulter en attente ; renvoyer ou annuler.
- **18.39 Succès / erreur** : Afficher résultat du paiement ; lien vers tableau de bord ou gestion abonnement.
Droits : ressource `subscription` (read, update) ; ressource `subscription_invite` (create, read, delete). Conditions : visibilité des écrans selon rôle (admin office ou équivalent).
## 4. Règles métier et contraintes
- Souscription : choix parmi les plans actifs (définis en admin plateforme) ; paiement via prestataire externe ou manuel selon configuration.
- Sièges : nombre maximal selon plan ; impossible d’inviter au-delà des sièges disponibles sans upgrade.
- Invitation : email unique par invitation en attente ; renvoi possible avec limite (rate limiting) ; pas de fallback silencieux sur échec d’envoi.
- Retour paiement : pages success/error appelées par le prestataire (redirect ou webhook) ; affichage clair du statut.
## 5. Paramétrage
- Activation de la zone abonnement par plateforme ; plans et prix en admin plateforme (zone 13).
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `Subscription` (office_uid, plan_uid, status, current_period_end, …), `Plan` (défini en zone 13), `SubscriptionInvite` (office_uid, email, role_uid, token, status).
- Endpoints : `GET /subscription`, `POST /subscription/subscribe`, `GET/PATCH /subscription/manage`, `GET/PATCH /subscription/collaborators`, `GET/POST /subscription/invites`, `POST /subscription/invites/[id]/resend`, `DELETE /subscription/invites/[id]` ; callbacks success/error (URLs fournies au prestataire).
- Dépendances : zone 13 (plans) ; prestataire de paiement (back).
## 7. Sécurité et accessibilité
- Autorisation : accès réservé aux rôles autorisés (admin office) ; pas d’exposition des clés de paiement côté client.
- Données sensibles : moyens de paiement gérés par le prestataire ; audit sur changement de plan ou d’invitation.
- Accessibilité : formulaires avec labels ; messages de succès/erreur clairs ; liens de navigation explicites.
## 8. Impacts
- Front : pages subscription (overview, subscribe, manage, collaborators, invite, success, error).
- Back : module subscription, intégration prestataire paiement, gestion invitations.
- Shared : types Subscription, Plan, SubscriptionInvite.
- Dépendances : zone 13 (admin plateforme pour les plans) ; zone 5 (collaborators pour le lien sièges).
## 9. Modalités de déploiement
- Prérequis : plans créés en super-admin ; configuration du prestataire de paiement (clés, URLs de callback) ; migrations subscription, invites.
- Déploiement standard ; vérifier les URLs de redirection post-paiement (environnement test/prod).
## 10. Modalités d’analyse
- Recette : consultation abonnement ; souscription (test avec mode sandbox) ; modification plan ; gestion invitations (envoi, renvoi, annulation) ; retour depuis prestataire (success/error).
- Logs : souscription, changement de plan, envoi invitation, échecs paiement.
- Données : cohérence subscription–plan–office ; nombre de sièges vs collaborateurs actifs.

70
services/docv/enso-docs/features/specs/SPEC_10_espace_client_invite.md Normal file
View File

@ -0,0 +1,70 @@
# Spec : Espace client et espace invité
**Zone** : 10 et 11 — Espace client (partie au dossier) et Espace partie externe (invité)
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) sections 10 et 11, actions 18.40 à 18.43.
## 1. Objectif
- **Espace client** : permettre à une partie au dossier (client) d’accéder aux dossiers partagés avec elle : tableau de bord, détail dossier, téléchargement et dépôt de documents si autorisé.
- **Espace invité** : permettre à un invité externe (tiers) de se connecter via lien d’invitation ou code, puis d’accéder aux dossiers partagés selon son rôle (lecture / contribution).
- Périmètre docv / enso identique ; libellés (client, invité) selon métier.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Tableau de bord client | `/client-dashboard` | `client.dashboard` | Liste des dossiers partagés ; accès documents et téléchargements. |
| Détail dossier client | `/client-dashboard/[folderUid]` | `client.folder-detail` | Fiche dossier ; téléchargement ; dépôt si autorisé. |
| Connexion invité | auth tiers | `invitee.auth` | Connexion par lien d’invitation ou code ; 2FA si applicable. |
| Tableau de bord invité | `/third-party/dashboard` | `invitee.dashboard` | Dossiers partagés avec l’invité ; consultation/téléchargement ; dépôt si contributeur. |
## 3. Actions détaillées
- **18.40 Tableau de bord client** : Afficher liste des dossiers partagés ; ouvrir un dossier ; télécharger les documents visibles.
- **18.41 Détail dossier client** : Consulter infos et liste des documents ; télécharger ; déposer un document (si rôle contributeur et autorisé).
- **18.42 Connexion invité** : Saisir code ou suivre lien email ; compléter 2FA si applicable ; valider et accéder au tableau de bord invité.
- **18.43 Tableau de bord invité** : Afficher liste des dossiers partagés ; ouvrir un dossier ; consulter/télécharger (selon rôle) ; déposer (si contributeur).
Droits : pas de matrice rôle classique ; accès déterminé par le partage (zone 7) : rôle client = lecture (et dépôt si configuré) ; rôle invité = lecture ou contributeur selon partage.
## 4. Règles métier et contraintes
- Client : identifié par le lien partie au dossier–compte utilisateur (ou accès dédié sans compte selon implémentation) ; ne voit que les dossiers partagés avec lui.
- Invité : identifié par le token/lien d’invitation ; un même email peut avoir plusieurs accès (plusieurs dossiers) ; date de fin d’accès optionnelle.
- Dépôt : seulement si le partage autorise la contribution ; types de fichiers et taille selon configuration ; pas de fallback silencieux sur erreur d’upload.
- 2FA : si activée pour les invités, flux obligatoire après saisie du code/lien.
## 5. Paramétrage
- Activation espaces client et invité par office ; rôle par défaut (lecture / contributeur) ; durée de validité des liens d’invitation.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : mêmes dossiers et documents que zone 2 et 3 ; accès filtré par `FolderShare` (target = client ou invitee_email) et rôle.
- Endpoints : auth invité : `POST /auth/invitee` (code ou token) ; client : `GET /client-dashboard/folders`, `GET /client-dashboard/folders/[folderUid]`, `GET/POST /client-dashboard/folders/[folderUid]/documents` ; invité : `GET /third-party/folders`, `GET /third-party/folders/[folderUid]`, téléchargement et dépôt selon même logique.
- Dépendances : zone 7 (partage) pour la création des partages et la détermination des droits.
## 7. Sécurité et accessibilité
- Autorisation : pas d’accès aux dossiers non partagés ; pas d’élévation de droit côté client/invité.
- Données sensibles : documents filigranés pour certains rôles si configuré ; pas d’exposition des données d’autres parties.
- Accessibilité : tableaux de bord avec structure claire ; formulaires de connexion invité avec labels et messages d’erreur ; liens de téléchargement et boutons de dépôt identifiables.
## 8. Impacts
- Front : pages client-dashboard (liste, détail dossier), third-party (connexion, dashboard, détail dossier).
- Back : modules auth invité, endpoints client et third-party (lecture + dépôt filtrés).
- Shared : types partagés avec zone 2 et 3 ; rôles de partage.
- Dépendances : zones 2 (dossiers), 3 (documents), 7 (partage).
## 9. Modalités de déploiement
- Prérequis : partage activé (zone 7) ; envoi d’emails pour invitations invité ; migrations éventuelles pour tokens invité.
- Déploiement standard ; vérifier les URLs des liens d’invitation (environnement).
## 10. Modalités d’analyse
- Recette : connexion client (si applicable) et accès uniquement aux dossiers partagés ; téléchargement et dépôt côté client ; flux invité : lien/code → 2FA → dashboard ; vérification que l’invité ne voit que ses dossiers et que les actions (dépôt) respectent le rôle.
- Logs : connexion invité ; accès client/invité aux dossiers ; dépôts.
- Données : cohérence partages–accès effectifs ; date de fin d’accès respectée.

63
services/docv/enso-docs/features/specs/SPEC_12_admin_office.md Normal file
View File

@ -0,0 +1,63 @@
# Spec : Admin d’office
**Zone** : 12 — Admin d’office
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 12, action 18.44.
## 1. Objectif
- Fournir un portail d’administration de l’office : métriques, paramètres, accès centralisés à la gestion des rôles, utilisateurs, types de documents, types de dossiers.
- Proposer des aides ou outils techniques pour l’admin (helpers) selon implémentation.
- Périmètre docv / enso identique.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Admin | `/admin` | `admin.portal` | Métriques de l’office ; paramètres ; liens vers rôles, utilisateurs, types de documents, types de dossiers. |
| Helpers admin | `/admin/helpers` | `admin.helpers` | Outils ou aides techniques pour l’admin (selon implémentation). |
## 3. Actions détaillées
- **18.44 Admin** : Consulter les métriques de l’office ; accéder aux paramètres et aux liens de gestion (rôles, utilisateurs, types de documents, types de dossiers) ; consulter les aides ou outils techniques (`/admin/helpers` si présent).
Droits : réservé aux rôles admin d’office (ou équivalent avec permission `admin.portal`). Les sous-écrans (rôles, utilisateurs, etc.) appliquent leurs propres droits (zones 5, 6, 3, 4).
## 4. Règles métier et contraintes
- Accès : seul un utilisateur avec rôle admin d’office (ou permission dédiée) accède à `/admin`.
- Métriques : contenu défini par implémentation (ex. nombre de dossiers, collaborateurs, stockage).
- Pas de fallback silencieux : en cas d’indisponibilité d’un service ou métrique, affichage d’un message explicite.
## 5. Paramétrage
- Visibilité du portail admin et des liens par office ; activation des helpers par plateforme ou office.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : agrégations sur dossiers, collaborateurs, etc. ; pas d’entité dédiée « admin ».
- Endpoints : `GET /admin/metrics` (ou équivalent) ; les autres données proviennent des zones 3, 4, 5, 6 (redirections ou appels API existants).
- Pas de dépendance ancrage/IA spécifique.
## 7. Sécurité et accessibilité
- Autorisation : accès strictement limité aux admins d’office.
- Données sensibles : les métriques ne doivent pas exposer de données personnelles non nécessaires ; audit des accès admin si requis.
- Accessibilité : liens et cartes de métriques identifiables ; navigation claire.
## 8. Impacts
- Front : page admin (portail), page helpers.
- Back : endpoint métriques (ou agrégation des données existantes).
- Dépendances : zones 3, 4, 5, 6 pour le contenu et les liens.
## 9. Modalités de déploiement
- Aucun prérequis spécifique hors droits admin ; déploiement standard.
- Helpers : selon implémentation (outils de diagnostic, export, etc.).
## 10. Modalités d’analyse
- Recette : accès à `/admin` avec rôle admin ; vérification des liens vers rôles, utilisateurs, types ; consultation des métriques ; accès à `/admin/helpers` si présent.
- Logs : accès à la page admin (audit si configuré).
- Données : cohérence des métriques avec les données réelles (dossiers, collaborateurs).

73
services/docv/enso-docs/features/specs/SPEC_13_admin_plateforme.md Normal file
View File

@ -0,0 +1,73 @@
# Spec : Admin plateforme (super-admin)
**Zone** : 13 — Admin plateforme (super-admin)
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 13, actions 18.45 à 18.49.
## 1. Objectif
- Fournir une vue d’ensemble plateforme : offices, utilisateurs, santé des services, configuration globale.
- Gérer les rôles et permissions au niveau plateforme, les plans d’abonnement, les textes du site (i18n) et la configuration système (feature flags, limites, URLs).
- Périmètre docv / enso : réservé aux super-admins (admin plateforme).
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Super-admin | `/super-admin` | `super-admin.overview` | Vue d’ensemble : offices, utilisateurs, santé des services ; accès rôles, plans, textes, config. |
| Gestion des rôles plateforme | `/super-admin/roles-management` | `super-admin.roles` | Rôles et permissions au niveau plateforme. |
| Plans d’abonnement | `/super-admin/subscription-plans` | `super-admin.plans` | Création et édition des offres d’abonnement. |
| Textes du site | super-admin (section ou route dédiée) | `super-admin.texts` | Gestion des textes i18n : clés, locales, versions, publication. |
| Configuration système | super-admin (section ou route dédiée) | `super-admin.config` | Clés de configuration (feature flags, limites, URLs) ; valeurs masquées. |
## 3. Actions détaillées
- **18.45 Super-admin** : Consulter vue d’ensemble ; accéder à la gestion des rôles plateforme, aux plans d’abonnement, à la configuration système et aux textes du site.
- **18.46 Gestion des rôles plateforme** : Afficher et modifier les rôles au niveau plateforme ; gérer la matrice des permissions plateforme.
- **18.47 Plans d’abonnement** : Afficher la liste des offres ; créer une offre (si droit) ; modifier ou désactiver une offre (si droit).
- **18.48 Textes du site** : Afficher les textes par clé, locale, version ; créer ou modifier un texte ; publier ou dépublier une version.
- **18.49 Configuration système** : Afficher les clés par catégorie ; créer ou modifier une clé (feature flags, limites, URLs) ; masquer ou révéler les valeurs sensibles (avec contrôle d’accès).
Droits : réservé au rôle super-admin (admin plateforme). Toute action modifie des données à portée plateforme.
## 4. Règles métier et contraintes
- Rôles plateforme : distincts des rôles office ; utilisés pour les droits globaux (ex. accès super-admin, gestion des plans).
- Plans : au moins un plan actif pour permettre les souscriptions (zone 9) ; désactivation d’un plan n’affecte pas les abonnements existants (jusqu’à renouvellement selon règles métier).
- Textes : versioning et publication ; pas d’écrasement silencieux des textes en production sans workflow défini.
- Configuration : valeurs sensibles (clés API, secrets) jamais affichées en clair par défaut ; révélation avec confirmation et audit.
- Pas de fallback silencieux sur erreur de sauvegarde ou contrainte.
## 5. Paramétrage
- Accès super-admin : rôle unique ou liste de rôles plateforme ; pas de paramétrage « par office » pour cette zone (plateforme uniquement).
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : `Role` (scope plateforme), `Plan` (uid, name, features, price, …), `Text` / `I18nEntry` (key, locale, version, content, published), `ConfigKey` (key, value, sensitive, category).
- Endpoints : `GET /super-admin/overview` ; `GET/PATCH /super-admin/roles`, `GET/PATCH /super-admin/roles/[roleUid]/permissions` ; `GET/POST/PATCH /super-admin/plans` ; `GET/POST/PATCH /super-admin/texts`, `POST /super-admin/texts/publish` ; `GET/PATCH /super-admin/config` (valeurs sensibles masquées ou révélées avec contrôle).
- Dépendances : zone 9 (abonnement) consomme les plans ; toute l’app consomme config et textes i18n.
## 7. Sécurité et accessibilité
- Autorisation : accès réservé aux super-admins ; pas d’exposition des endpoints en dehors de ce rôle.
- Données sensibles : configuration sensible masquée ; audit sur modification des plans, textes et config.
- Accessibilité : tableaux et formulaires avec labels ; messages de confirmation avant actions critiques (désactiver un plan, révéler un secret).
## 8. Impacts
- Front : pages super-admin (overview, roles, plans, texts, config).
- Back : modules super-admin (rôles plateforme, plans, textes, config).
- Shared : types Plan, Text, ConfigKey ; rôles plateforme.
- Dépendances : zone 9 (plans) ; zones 1 à 14 consomment config et i18n.
## 9. Modalités de déploiement
- Prérequis : rôle super-admin créé et attribué ; migrations pour plans, textes, config ; seeds pour config par défaut et premiers textes.
- Déploiement standard ; attention aux valeurs de config selon environnement (test/prod).
## 10. Modalités d’analyse
- Recette : accès super-admin ; modification des rôles plateforme ; CRUD plans ; édition et publication de textes ; consultation et modification de la config (vérifier masquage des valeurs sensibles).
- Logs : toutes les modifications (rôles, plans, textes, config) ; accès à la révélation de valeurs sensibles.
- Données : cohérence plans–abonnements ; textes publiés reflétés dans l’app.

67
services/docv/enso-docs/features/specs/SPEC_14_contenus_parametres.md Normal file
View File

@ -0,0 +1,67 @@
# Spec : Contenus et paramètres globaux
**Zone** : 14 — Contenus et paramètres globaux
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 14, action 18.50 (Mentions légales) ; textes et configuration système couverts en zone 13 (super-admin).
## 1. Objectif
- Exposer la consultation des contenus juridiques (mentions légales, CGU, politique de confidentialité) en lecture seule pour tous les utilisateurs ou visiteurs.
- La gestion des textes éditoriaux (i18n) et de la configuration système est couverte par la zone 13 (Admin plateforme) ; cette spec couvre l’usage côté applicatif et les pages légales publiques.
- Périmètre docv / enso identique.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Textes du site | gérés en super-admin (zone 13) | — | Gestion : zone 13. Consommation : affichage dans l’app selon clé et locale. |
| Configuration système | gérée en super-admin (zone 13) | — | Gestion : zone 13. Consommation : feature flags, limites, URLs utilisés par le front et le back. |
| Mentions légales | `/legal` | `legal.mentions` | Consultation mentions légales, CGU, politique de confidentialité (lecture seule). |
## 3. Actions détaillées
- **18.50 Mentions légales** : Consulter les mentions légales, CGU, politique de confidentialité (lecture seule).
La liste détaillée des actions pour textes et configuration figure en zone 13 (18.48, 18.49). Ici on précise uniquement : affichage des textes selon clé/locale ; respect des feature flags et limites côté front/back.
Droits : mentions légales accessibles à tous (y compris non connectés) ou selon politique (ex. connectés uniquement). Pas de droit d’édition sur cette zone (édition en zone 13).
## 4. Règles métier et contraintes
- Contenus légaux : source = textes i18n ou CMS selon implémentation ; mise à jour uniquement via super-admin ; pas de modification par les utilisateurs.
- Configuration : lecture seule côté applicatif ; les feature flags activent/désactivent des blocs ou routes ; pas de fallback silencieux si une clé requise est absente (log ou erreur explicite).
- Pas de fallback silencieux sur contenu manquant : afficher un message ou une clé par défaut documentée plutôt que masquer.
## 5. Paramétrage
- Visibilité des liens vers mentions légales (footer, etc.) par plateforme ; choix des clés i18n pour CGU, mentions, confidentialité.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Entités : mêmes que zone 13 pour textes et config ; pas d’entité dédiée « legal » (les pages légales sont des textes i18n identifiés par clé).
- Endpoints : `GET /legal` ou `GET /texts/[key]?locale=xx` pour les pages légales ; configuration et textes chargés au build ou au runtime selon architecture.
- Dépendances : zone 13 pour la source des textes et de la config.
## 7. Sécurité et accessibilité
- Contenus légaux : pas de données sensibles ; accessibles sans authentification si prévu.
- Configuration : les valeurs sensibles ne sont jamais envoyées au client (sauf si révélation super-admin en zone 13).
- Accessibilité : pages légales avec structure de titres et paragraphes ; contraste et lisibilité ; liens « Retour » ou navigation claire.
## 8. Impacts
- Front : page `/legal` (ou sous-routes), consommation des textes i18n et des feature flags dans l’ensemble de l’app.
- Back : fourniture des textes et de la config (endpoints ou injection au build).
- Shared : types pour Text, Config ; clés documentées pour legal.
- Dépendances : zone 13 (source des données).
## 9. Modalités de déploiement
- Prérequis : textes des mentions légales/CGU/confidentialité renseignés en super-admin (ou seed) ; config par défaut déployée.
- Déploiement standard.
## 10. Modalités d’analyse
- Recette : affichage de `/legal` avec le bon contenu selon locale ; vérification que les feature flags désactivent/activent bien les blocs prévus ; vérification des limites (ex. taille max upload) appliquées.
- Logs : pas de log spécifique pour la lecture des pages légales ; logs applicatifs pour les accès refusés (limites, feature désactivée).
- Données : cohérence entre textes publiés en zone 13 et contenu affiché.

67
services/docv/enso-docs/features/specs/SPEC_15_technique_design.md Normal file
View File

@ -0,0 +1,67 @@
# Spec : Technique et design
**Zone** : 15 — Technique et design
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 15, actions 18.51 et 18.52.
## 1. Objectif
- **Design system** : documenter les composants et tokens pour les développeurs (écran ou site dédié, pas un écran métier).
- **Vérification d’ancrage** : fournir une page publique de vérification d’un certificat d’ancrage (lien depuis un document ancré).
- Périmètre docv / enso identique ; ancrage activable selon projet.
## 2. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Design system | `/design-system` | `design-system.doc` | Documentation des composants et tokens (lecture seule, usage développeur). |
| Vérification d’ancrage | route publique (ex. `/verify-anchoring` ou `/anchor/verify`) | `anchor.verify` | Saisie ou suivi d’un lien vers un certificat ; affichage du résultat de vérification (validité, date, hash). |
## 3. Actions détaillées
- **18.51 Design system** : Consulter la documentation des composants et des tokens (lecture seule).
- **18.52 Vérification d’ancrage** : Saisir ou suivre un lien vers un certificat d’ancrage ; afficher le résultat (validité, date, hash, etc.) en lecture seule.
Droits : design system réservé aux développeurs ou à un rôle technique (ou public en lecture selon choix) ; vérification d’ancrage accessible à tous (page publique) sans authentification.
## 4. Règles métier et contraintes
- Design system : pas de modification des composants depuis cette page (documentation uniquement) ; contenu maintenu à jour avec le code.
- Vérification d’ancrage : entrée = URL du certificat ou identifiant ; sortie = résultat de vérification (signature, chaîne de blocs, etc.) sans modification des données ; en cas de certificat invalide ou introuvable, message explicite.
- Pas de fallback silencieux : erreur de chargement du certificat ou vérification échouée → message clair.
## 5. Paramétrage
- Visibilité du design system : par environnement (affichage en dev/staging uniquement) ou par rôle.
- Vérification d’ancrage : activée si la fonction ancrage est activée (zones 2, 3) ; URL publique documentée.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 6. Données et API
- Design system : pas d’entité BDD ; contenu statique ou généré depuis le code (Storybook, doc statique).
- Vérification d’ancrage : pas de stockage côté app ; appel au service d’ancrage (back ou externe) avec l’identifiant/URL du certificat ; retour = structure lue (validité, date, hash).
- Endpoints : `GET /anchor/verify?id=...` ou `POST /anchor/verify` (body avec URL ou id) ; réponse en JSON ou page rendue côté serveur.
## 7. Sécurité et accessibilité
- Design system : pas de donnée sensible ; accès restreint si nécessaire pour éviter l’exposition d’informations internes.
- Vérification d’ancrage : pas d’authentification requise ; pas d’exposition de données métier (uniquement le certificat et son résultat de vérification).
- Accessibilité : design system avec navigation et contrastes ; page de vérification avec formulaire labellisé et résultat structuré (titres, liste des champs).
## 8. Impacts
- Front : page design-system (doc) ; page vérification d’ancrage (formulaire + affichage résultat).
- Back : endpoint de vérification d’ancrage (délégation au service d’ancrage).
- Shared : types pour le résultat de vérification (AnchorVerificationResult ou équivalent).
- Dépendances : zones 2 et 3 si ancrage activé (liens depuis les documents ancrés vers la page de vérification).
## 9. Modalités de déploiement
- Design system : déploiement d’une app doc ou d’une route dédiée ; pas de migration.
- Vérification d’ancrage : prérequis = service d’ancrage opérationnel ; URL publique configurée (reverse proxy, SEO si besoin).
- Déploiement standard.
## 10. Modalités d’analyse
- Recette : accès au design system et vérification de la cohérence avec les composants utilisés dans l’app ; soumission d’un lien/ID de certificat valide et invalide sur la page de vérification et vérification du résultat affiché.
- Logs : appels à l’endpoint de vérification (optionnel, pour statistiques) ; pas de log des certificats eux-mêmes si sensibles.
- Données : aucun stockage spécifique ; cohérence entre le résultat renvoyé par le service d’ancrage et l’affichage.

90
services/docv/enso-docs/features/specs/SPEC_17_ia_local.md Normal file
View File

@ -0,0 +1,90 @@
# Spec : Fonctionnalités ia_local (enso)
**Zone** : 17 — Fonctionnalités ia_local (à intégrer dans enso)
**Référence cartographie** : [SCREENS_AND_FUNCTIONS_MAP.md](../../SCREENS_AND_FUNCTIONS_MAP.md) section 17, actions 18.53 à 18.83. Détail fonctionnel : [FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md](../FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md).
## 1. Objectif
- Intégrer dans enso les fonctionnalités issues du projet ia_local (arrêté) : tableau de bord métier, CRM (clients, dossiers permanents), composition d’actes, mise à jour DP, secrétariat juridique, renvoi de dossier, extraction dataroom, alertes, data room, courriers IFU/RDPD, workflow documentaire, tâches, débours, messages/tchat, notifications, configuration établissements, types et configuration, facturation débours, courriers annexes, mails semi-auto, édition formalités, fiche prépa AG, planning des charges, organigramme, listing annexes, devis/lettre de mission, Outlook, Chat IA, Explorer, recherche globale, mon compte appareils.
- Périmètre : enso (avocats) ; découpage possible en plusieurs specs (CRM/workflow, Data room, Outils IA métier) selon choix de réalisation. Cette spec couvre l’ensemble en un bloc cohérent avec renvois aux actions 18.53–18.83.
## 2. Écrans et routes
Voir le tableau de la section 17 de la cartographie et le fichier FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md. Résumé des écrans principaux :
| Bloc | Écrans (référence ia_local) | Identifiants stables (exemples) |
|------|-----------------------------|----------------------------------|
| Dashboard & navigation | Tableau de bord métier, Explorer (Commun / Datarooms), Recherche globale | `ia.dashboard`, `ia.explorer`, `ia.search` |
| CRM & dossiers | CRM (Clients, DP, Dossiers) | `ia.crm` |
| Actes & juridique | Composition d’actes, Mise à jour DP, Secrétariat juridique, Édition formalités, Fiche prépa AG, Listing annexes, Courriers annexes, Devis / lettre de mission | `ia.composition-actes`, `ia.mise-a-jour-dp`, `ia.secretariat`, etc. |
| Partage & dataroom | Renvoi de dossier, Data room, Extraction dataroom | `ia.renvoi-dossier`, `ia.data-room`, `ia.extraction-dataroom` |
| Workflow & tâches | Workflow documentaire, Tâches, Alertes, Planning des charges | `ia.workflow`, `ia.taches`, `ia.alertes`, `ia.planning-charges` |
| Débours & facturation | Débours, Facturation débours | `ia.debours`, `ia.facturation-debours` |
| Communication | Messages / Tchat, Notifications, Mails semi-auto, Courriers IFU | `ia.messages`, `ia.notifications`, `ia.mails-semi-auto`, `ia.courriers-ifu` |
| Admin & config | Configuration établissements, Types et configuration | `ia.config-etablissements`, `ia.admin-types` |
| Intégrations & IA | Interfaçage Outlook, Chat IA, Organigramme | `ia.outlook`, `ia.chat`, `ia.organigramme` |
| Compte | Mon compte (appareils) | `ia.my-account-devices` |
## 3. Actions détaillées
Renvoi aux actions 18.53 à 18.83 de la cartographie pour le détail par écran. Synthèse :
- **Dashboard & navigation** : 18.53, 18.81, 18.82.
- **CRM** : 18.54.
- **Actes & juridique** : 18.55, 18.56, 18.57, 18.71, 18.72, 18.73, 18.74, 18.77, 18.78.
- **Partage & dataroom** : 18.58, 18.59, 18.61.
- **Alertes** : 18.60.
- **Workflow & tâches** : 18.63, 18.64, 18.75.
- **Débours & facturation** : 18.65, 18.70.
- **Communication** : 18.66, 18.67, 18.62.
- **Config** : 18.68, 18.69.
- **Intégrations & IA** : 18.79, 18.80, 18.76.
- **Compte** : 18.83.
Droits : matrice rôle × ressource (établissement, dossier, tâche, alerte, débours, dataroom, etc.) × actions ; conditions d’affichage par rôle (ex. Datarooms pour rôle client, Commun pour rôles internes). Référence : [SPECIFIQUES_PROJETS.md](../SPECIFIQUES_PROJETS.md) pour le détail des entrées ia_local couvertes.
## 4. Règles métier et contraintes
- Alignement avec les zones 1 à 15 : dossiers, documents, partage, types restent cohérents avec le modèle docv ; les concepts ia_local (établissement, dossier permanent, grande activité) sont mappés ou étendus selon l’architecture retenue.
- Workflow documentaire : statuts (à demander, demandé, reçu, validé, refusé) ; transitions selon rôle ; pas de fallback silencieux.
- Data room : droits consultation/édition ; date de fin d’accès ; notifications à chaque dépôt.
- Tâches et alertes : échéances, assignation, filtres ; validation et clôture selon droits.
- Débours : statuts (en attente, validé, refusé, payé) ; workflow de facturation et comparaison provision/débours.
- Chat IA et Explorer : contexte de l’arborescence ; envoi « Montre-moi [rubrique] » depuis l’Explorer.
- Contraintes de validation et cas d’erreur : messages explicites ; pas de contournement des règles métier.
## 5. Paramétrage
- Activation des blocs ia_local par office ou par projet (enso) ; paramétrage des types (documents, dossiers, tâches, alertes, débours, établissements, etc.) selon zone 14 et admin-types.
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md) et paramétrage spécifique décrit dans FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md.
## 6. Données et API
- Entités : nombreuses (établissements, dossiers permanents, tâches, alertes, débours, datarooms, messages, notifications, types métier, etc.) ; détail dans ARCHITECTURE_DOCV_DETAILLEE.md et FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md.
- Endpoints : à définir par bloc (CRM, workflow, tâches, débours, data room, messages, config établissements, types, Chat IA, etc.) ; ancrage et IA en back uniquement.
- Dépendances : zones 2 (dossiers), 3 (documents), 7 (partage) ; services IA et ancrage si applicables.
## 7. Sécurité et accessibilité
- Auth et autorisation : mêmes principes que les zones 1–15 ; rôles et permissions étendus aux ressources ia_local (établissement, tâche, alerte, débours, dataroom, etc.).
- Données sensibles : masquage et audit selon règles métier (débours, documents clients, messages).
- Accessibilité : ARIA, clavier, contraste sur tous les écrans ; listes et formulaires labellisés ; notifications et messages annoncés.
## 8. Impacts
- Front : nombreux écrans (dashboard, CRM, workflow, tâches, débours, data room, messages, notifications, config, Chat IA, Explorer, recherche, etc.).
- Back : modules métier ia_local, workflow, tâches, alertes, débours, dataroom, messages, notifications, établissements, types, intégrations Outlook et IA.
- Shared : types pour toutes les entités ia_local.
- Dépendances : zones 2, 3, 4, 5, 6, 7, 8 ; architecture docv pour le socle commun.
## 9. Modalités de déploiement
- Prérequis : migrations pour toutes les entités ia_local ; seeds pour types et configurations par défaut ; configuration des services IA et Outlook si intégrés.
- Déploiement par blocs recommandé (CRM/workflow d’abord, puis data room, puis outils IA) ; chaque bloc peut faire l’objet d’une spec détaillée séparée si besoin.
- Référence : PLAN_REALISATION_DOCV_ENSO.md et FONCTIONNALITES_IA_LOCAL_A_INTEGRER.md pour l’ordre et les priorités.
## 10. Modalités d’analyse
- Recette : par bloc fonctionnel (dashboard, CRM, workflow, tâches, débours, data room, messages, notifications, config, Chat IA, Explorer, recherche, appareils) ; critères de recette alignés sur les actions 18.53–18.83.
- Logs : création, modification, suppression sur les entités métier ; accès aux datarooms ; envoi de messages et notifications ; appels IA ; erreurs métier et techniques.
- Données : cohérence des statuts (workflow, débours, tâches) ; intégrité des liaisons (dossier–établissement–tâche–alerte–débours) ; respect des droits par rôle et établissement.

372
services/docv/enso-docs/features/specs/SPEC_18_operation.md Normal file
View File

@ -0,0 +1,372 @@
# Spec : Opération (cabinet/office)
**Zone** : 18 — Opération (cloisonnée au cabinet/office)
**Référence cartographie** : nouvelle zone, actions 18.84 à 18.96.
## 1. Objectif
- Gérer les opérations au sein du cabinet/office : création (peut créer une société), consultation, modification, avec société(s) liée(s), contacts, documents et commentaires.
- Périmètre cloisonné : aucune donnée n’est partagée hors du cabinet/office ; accès selon rôles internes (accès interne, restreint au dossier, secret avocat/notaire associé).
- Extraction de données depuis KBIS, répartition IA de fichiers ZIP par type de document, workflow documentaire étendu.
## 2. Périmètre et relations
### 2.1 Homogénéisation : Dossier = Société = Entreprise
Un **dossier** est une **société** qui est une **entreprise**. Homogénéisation sous le terme **société**.
- Une société peut être **société mère** ou **société fille** d’une société mère.
- L’archivage est au niveau des sociétés (dossiers).
- Tous les objets ont un `uid` technique (non affiché) ; les numéros (dossier, comptable, etc.) sont des **références métier**.
### 2.2 Hiérarchie des entités
| Entité | Relation | Description |
|--------|----------|-------------|
| **Société** | 1 société = 1 entité + parent optionnel (société mère) | Dossier/entreprise ; niveau archivage ; peut avoir des sociétés filles ; données dans table `societies` |
| **Opération** | 1 opération appartient à une société (société dossier) | `society_uid` = société dossier qui contient l’opération ; une opération peut créer une nouvelle société (qui devient société liée et société fille de la société dossier) |
| **Société liée** | 1 opération → N sociétés (jointure) | Une société liée = une société ; « lié » = jointure à un objet commun ; peut être référence vers société existante OU société créée pour l’opération |
| **Document** | 1 document = plusieurs fichiers + statut workflow | Selon config type : rattaché à l’opération OU à la société ; N-N avec sociétés liées |
| **Fichier** | 1 fichier = 1 fichier + document parent | Commentaires, certificats d’ancrage, template, CNIL |
| **Contact** | 1 contact = 1 personne + rôles opération + rôles entreprise | Un utilisateur peut avoir plusieurs contacts ; un contact peut avoir des rôles différents selon la société |
### 2.3 Niveaux d’accès aux commentaires
| Niveau | Libellé | Qui peut accéder |
|--------|---------|------------------|
| `internal` | Accès interne | Tous les membres du cabinet |
| `restricted` | Restreint au dossier | Gestionnaires de l’opération (cabinet avocat ou notaire) |
| `secret` | Secret | Avocat et avocat associé, ou Notaire et notaire associé uniquement |
## 3. Opération — Description
### 3.1 Champs
| Champ | Obligatoire | Éditable | Description |
|-------|-------------|----------|-------------|
| Titre | Oui | Oui | Libellé de l’opération |
| Date | Oui | Oui | Date de l’opération (par défaut : date du jour) |
| Numéro de dossier | Non | Oui | Référence métier (dossier) |
| Numéro comptable | Non | Oui | Référence métier (comptable) |
| Entreprise | Oui (coche) | Oui | Indique si l’opération concerne au moins une société liée ; certaines opérations ne concernent que des particuliers sans société |
| Type d’opération | Oui | Oui | Liste paramétrable : cession, approbation des comptes, autres + bouton ajout |
| Commentaires | Non | Oui | Ajout/modification/suppression ; niveau d’accès (interne, restreint au dossier, secret) |
### 3.2 Types d’opération
Liste paramétrable par office. Valeurs par défaut : cession, approbation des comptes, autres. Bouton d’ajout pour nouveaux types.
### 3.3 Étapes par type d’opération (distinctes des étapes de création)
**Deux concepts distincts** :
- **Étapes de création d’opération** (section 7) : infos → contacts → affectations ZIP → fichiers de synthèse — ordre fixe, pas de retour.
- **Étapes par type d’opération** : ex. promesse, acte, AGE/AGO (Assemblées Générales Extra/Ordinaire) — séquence métier propre au type ; une opération est à tout moment dans une étape donnée.
Les AGE/AGO ont un **workflow d’édition du PV** (procès-verbal).
**Passage d’étape** : automatique en fonction des actions réalisées (boutons).
**État de l’opération** : état global propre à l’opération (ouverte, en cours, clôturée, etc.), distinct de l’étape et des états des documents.
Le **paramétrage** (droits, types de documents, états/workflow) **dépend aussi des étapes** du type d’opération.
## 4. Société liée — Description
Une **société liée** = une **société** ; « lié » désigne la jointure à un objet commun (opération). Les données sont dans la table `societies` ; la liaison se fait via une table de jointure (operation_uid, society_uid). Une société liée peut être une référence vers une société existante ou une société créée pour l’opération.
### 4.1 Champs
| Champ | Obligatoire | Source | Description |
|-------|-------------|--------|-------------|
| KBIS | Non | Document uploadé | Extraction des données pour compléter les champs |
| Type | Oui | Saisie / extraction | Groupe ou Entreprise |
| Imposition | Oui | Saisie | IS ou IR |
| SCI | Oui | Saisie | Oui ou Non |
| Numéro SIRET | Oui | Extraction KBIS / saisie | Obligatoire |
| Type d’activité | Oui | Liste paramétrable | Particulier (par défaut), boulangerie, etc. + bouton ajout |
| Commentaires | Non | Saisie | Niveau d’accès : interne, restreint au dossier, secret |
### 4.2 Extraction KBIS
Document attendu (optionnel). Extraction des champs pour pré-remplissage : SIRET, dénomination, forme juridique, adresse, etc.
## 5. Contacts — Description
### 5.1 Modèle de contact
**1 contact = 1 contact** avec :
- **Rôles opération** : plusieurs rôles et sous-rôles opération par opération, dans plusieurs opérations.
- **Rôles entreprise** : plusieurs rôles et sous-rôles entreprise par société, dans plusieurs sociétés.
Un contact peut avoir **plusieurs sous-rôles pour la même opération**. Les rôles et sous-rôles sont **cumulatifs**.
### 5.2 Champs
| Champ | Obligatoire | Description |
|-------|-------------|-------------|
| Nom | Oui | Nom de famille |
| Prénom | Oui | Prénom |
| Email | Oui | Adresse email |
| Téléphone | Oui | Numéro de téléphone |
| Rôles opération | Oui | Rôle(s) et sous-rôle(s) dans l’opération (cumulatifs) |
| Rôles entreprise | Non | Rôle(s) et sous-rôle(s) dans la société (cumulatifs) |
| Actionnaire | Non | Coche + nombre de parts |
| Commentaires | Non | Niveau d’accès : interne, restreint au dossier, secret |
### 5.3 Rôles principaux et sous-rôles
| Rôle principal | Sous-rôles possibles |
|----------------|----------------------|
| Client | client 1, 2, 3… ; cabinet d’avocat ; office notarié ; commissaire aux comptes ; comptable ; DAF ; dirigeant ; agence ; diagnostiqueur ; **banque ; vendeur ; acheteur** |
| Cabinet d’avocat | avocat ; avocat associé ; collaborateur ; secrétariat ; **stagiaire** ; commissaire aux comptes ; comptable ; DAF ; dirigeant |
| Office notarié | notaire ; notaire associé ; collaborateur ; secrétariat ; **stagiaire** ; commissaire aux comptes ; comptable ; DAF ; dirigeant |
| Confrère avocat | avocat ; avocat associé ; collaborateur ; secrétariat ; commissaire aux comptes ; comptable ; DAF ; dirigeant |
| Confrère notaire | notaire ; notaire associé ; collaborateur ; secrétariat ; commissaire aux comptes ; comptable ; DAF ; dirigeant |
| **Infogreffe** | — |
| **Mairie** | — |
| **INSEE** | — |
| **Dataroom** | invité — rôle externe ; on peut lui demander occasionnellement des documents ou lui en fournir (ex. cession). Quand on ajoute un membre dans un rôle/sous-rôle à un utilisateur dans un dossier et qu’on lui envoie/demande/valide/refuse un document → il reçoit un mail pour se connecter avec **confirmation SMS** (pas de mot de passe) |
### 5.4 Rôles entreprise (par société)
avocat, avocat associé, notaire, notaire associé, collaborateur, secrétariat, commissaire aux comptes, comptable, DAF, dirigeant.
### 5.5 Gestion des doublons
- **Critères** : email, nom+prénom, ou autre selon configuration.
- **Comportement** : si nouveau contact identique à un existant → **pas de création** ; **alerte pour choix manuel** (sélectionner l’existant ou **fusion** avec l’existant).
## 6. Documents — Description
### 6.1 Document (entité)
| Attribut | Description |
|----------|-------------|
| Type de document | Liste paramétrable + bouton ajout |
| Rattachement | Selon config du type de document : à l’opération OU à la société (pas à la société parente) |
| Sociétés liées | Un document peut avoir plusieurs sociétés liées (N-N) |
| Fichiers | Plusieurs fichiers par document |
| Commentaires | Niveau d’accès : interne, restreint au dossier, secret |
| Statut | Voir workflow (section 6.2) |
| Supprimé | Oui / Non (logique) |
| Signé | Oui / Non ; **signé par défaut** = éviter validation/refus |
| Dates des statuts | Horodatage par transition |
| Dépositaire attendu | Rôle attendu pour le dépôt |
| Validé par défaut | Oui / Non |
| Droits | Par rôle, sous-rôle, statut dossier, type opération, **étape**, type activité, type document, statut document (héritage) |
**Note :** L’archivage est au niveau des sociétés (dossiers), pas des documents.
### 6.2 Workflow documentaire — Transitions
| Chemin | Description |
|--------|-------------|
| à demander → exclure → final | Vide sans doc, sans demande ; exclusion des docs attendus par le notaire ou l’avocat |
| à demander → demandé → à envoyer → envoyé → validé/refusé → final | Documents envoyés par les autres que membres ; hors cabinet/office gestionnaire |
| à demander → demandé → à envoyer → envoyé → téléchargé → final | Documents envoyés par les membres ; hors cabinet/office gestionnaire |
| à demander → demandé → à envoyer → envoyé → final | Documents envoyés sans validation particulière requise |
**Configuration des workflows** : par rôle, type d’opération, **étape**, type d’activité, type de document, état du document, état de l’opération (héritage pour le rôle).
**Par défaut** : tout est d’abord « à demander » ; rôle client et sous-rôle client : leurs membres doivent envoyer les documents reçus ; membres des cabinets/offices : valident, refusent, excluent, suppriment, relancent ou demandent.
### 6.3 Preview / vignette
En fonction des formats de fichier, utiliser la solution technique la plus adaptée pour la génération des vignettes.
### 6.4 Fichier (entité)
| Attribut | Description |
|----------|-------------|
| Document parent | Référence au document |
| Commentaires | Niveau d’accès |
| Certificats d’ancrage | Blocage / preuve |
| Template | Oui / Non |
| Variables template | Optionnel |
| Type d’informations | Classification |
| CNIL | Délai d’expiration |
| Utilisateurs (rôles) des données | Liste + usage + justification |
### 6.5 Types de documents attendus (liste paramétrable)
- Fiche INSEE (option)
- Annonce BODACC (option)
- Droit de préemption (mairie)
- État des comptes (par années, option)
- Certificat d’urbanisme (option)
- Liste de salariés (option)
- Autres : liste paramétrable + bouton ajout
### 6.6 Upload ZIP et répartition IA
- Option : upload d’un ZIP de dossiers et fichiers.
- L’IA analyse et affecte automatiquement chaque fichier au type de document approprié.
### 6.7 Association variables et sources
- **Configuration** : liste d’association variables ↔ source des informations (type d’informations) ↔ type de document contenant le fichier source.
- **Usage** : génération de documents à éditer depuis des fenêtres sur **serveur OpenOffice/OnlyOffice local**.
### 6.8 Édition de documents à envoyer par le notaire
Tout document à envoyer par le notaire peut faire l’objet d’une **édition** :
- Choix du modèle
- Génération du document .docx par IA (templates + variables + tout le contenu de l’opération + IA)
- Document .docx en visualisation sur un serveur OpenOffice
## 7. Étapes après création
**Ordre fixe** : 1. infos → 2. contacts → 3. affectations ZIP → 4. fichiers de synthèse. **Pas de retour** possible sur une étape validée pour corriger.
### 7.1 Validation et correction des données complétées automatiquement
- **Informations** : validation et correction des champs pré-remplis par extraction (KBIS, documents, etc.).
- **Contacts** : validation et correction des contacts complétés automatiquement (extraction depuis documents, doublons cabinet).
- **Affectations documents ZIP** : validation et correction des affectations automatiques des documents issus du ZIP (répartition IA par type de document).
### 7.2 Validation des fichiers de synthèse
| Fichier de synthèse | Description |
|--------------------|-------------|
| Fiche entreprise | Synthèse des données entreprise |
| Liste des mouvements du capital | Historique des mouvements de capital |
| Liste des associés | Liste des associés/actionnaires |
| Liste des salariés | Liste des salariés |
| Liste des baux | Liste des baux |
| Liste des contrats | Liste des contrats |
**Génération/complétion** : si la société (dossier ou liée, n’importe) n’a pas encore de synthèse → elle est **générée automatiquement** ; sinon elle est **complétée** (écran + données en BDD).
**Périmètre** : les 6 fichiers de synthèse sont définis **par société** (chaque société a sa propre synthèse).
## 8. Accès à l’opération après corrections/validations
### 8.1 Structure des onglets
- **Niveau 1** : onglets par **rôle**.
- **Niveau 2** : dans chaque rôle, onglets par **sous-rôle**.
- **Niveau 3** : dans chaque sous-rôle, onglets des **membres** de ce sous-rôle (selects multiples ou cases à cocher, selon ergonomie).
**Membres** : contacts de l’opération ayant ce rôle/sous-rôle + utilisateurs du cabinet (collaborateurs) affectés au dossier. Rôles et sous-rôles sont affectés aux contacts saisis et extraits. **À la création du dossier** : le créateur du dossier + choix des collaborateurs sur le dossier.
### 8.2 Accès aux onglets
- **Seuls les rôles des cabinets d’avocats et des offices notariaux** ont accès aux onglets complets.
- **Les autres** (clients, dataroom invité, infogreffe, mairie, INSEE, etc.) n’ont que la **vue des documents qui les concernent** : envoyés, reçus, ou accès en visualisation.
### 8.3 Liste des opérations
Opérations dans lesquelles la **personne connectée a un rôle**.
### 8.4 Tableau des documents par onglet
Dans chaque onglet (rôle / sous-rôle / membre) :
- **Colonnes** : document, type, sociétés liées, état, dates des statuts.
- **Actions possibles** (selon droits par rôle, sous-rôle, statut dossier, type opération, **étape**, type activité, type document, statut document) :
- Demande, Relance, Exclusion du document, Modification, Suppression, Visualisation (vignette preview), Téléchargement, Validation, Refus.
## 9. Écrans et routes
| Écran | Route | Identifiant stable | Fonctions attendues |
|-------|--------|---------------------|---------------------|
| Liste des opérations | `/operations` | `operations.list` | Liste paginée, filtres, tri, création |
| Détail opération | `/operations/[operationUid]` | `operations.detail` | Fiche complète : en-tête, société(s) liée(s), contacts, documents ; onglets rôle → sous-rôle → membres |
| Création opération | `/operations/create` | `operations.create` | Formulaire opération + entreprise + contacts + documents |
| Édition opération | `/operations/[operationUid]/edit` | `operations.edit` | Modification des sections |
| Validation/correction (post-création) | `/operations/[operationUid]/validate` | `operations.validate` | Validation infos, contacts, affectations ZIP, fichiers de synthèse |
| Société liée (dans opération) | section ou modal | `operations.society` | Formulaire société liée, extraction KBIS |
| Contacts (dans opération) | section ou modal | `operations.contacts` | Liste, ajout, modification, suppression ; alerte doublon |
| Documents (dans opération) | onglets rôle → sous-rôle → membres | `operations.documents` | Tableau documents ; états ; actions selon droits ; seuls cabinets/offices ont onglets complets ; autres : vue documents les concernant |
| Types d’opération (paramétrage) | `/settings/operation-types` | `operation-types.list` | Liste, création, édition ; définition des étapes par type |
| Étapes par type d’opération (paramétrage) | `/settings/operation-types/[typeUid]/steps` | `operation-type-steps.list` | Liste des étapes, création, édition, ordre |
| Types d’activité (paramétrage) | `/settings/activity-types` | `activity-types.list` | Liste, création, édition |
## 10. Règles métier et contraintes
- **Cloisonnement** : toutes les données restent dans le cabinet/office ; pas de partage externe.
- **Archivage** : au niveau des sociétés (dossiers), pas des opérations ni des documents.
- **Hiérarchie** : société = dossier = entreprise ; société → opérations ; opération peut créer une nouvelle société ; document rattaché à l’opération OU à la société selon config.
- **Création opération** : pas obligatoirement dans une société existante ; pas d’opération orpheline — **à minima le SIRET** (société avec au moins SIRET).
- **Validation** : titres, dates, SIRET, rôles obligatoires selon les champs définis ; pas de fallback silencieux.
- **Contacts** : doublon → pas de création, alerte pour choix manuel.
- **Documents** : workflow configuré par rôle, type opération, **étape**, type activité, type document, état document, état opération (héritage).
- **Extraction KBIS** : appel service back (IA ou parsing) ; erreur explicite si échec.
- **Répartition ZIP** : appel service IA back ; proposition d’affectation modifiable par l’utilisateur.
- **Post-création** : séquence fixe (infos → contacts → affectations ZIP → fichiers synthèse) ; pas de retour sur étape validée.
## 11. Paramétrage
- Types d’opération : liste par office, ordre d’affichage.
- **Étapes par type d’opération** : chaque type d’opération définit une séquence d’étapes (paramétrable).
- Types d’activité : liste par office, ordre d’affichage.
- Types de documents : extension de la zone 3 avec rattachement (opération ou société) ; **par étape** : les types de documents attendus peuvent varier selon l’étape.
- Rôles et sous-rôles : liste paramétrable (client, cabinet avocat, office notarié, confrère avocat, confrère notaire, infogreffe, mairie, INSEE, dataroom).
- **Droits** : par rôle principal, par sous-rôle, par **statut du dossier** (statut de la société : archivée, etc.), par type d’opération, **par étape**, par type d’activité, par type de document, par statut du document.
- **Héritage** : les règles sont définies à tous les niveaux ; par défaut le niveau du dessus s’applique.
- **Workflow / états** : configuration par rôle, type d’opération, **étape**, type d’activité, type de document, état du document, **état de l’opération** (ouvert, en cours, clôturé, etc. — global à l’opération, distinct des documents/étapes).
- Référence : [PARAMETRAGE_ECRANS_ACTIONS.md](../PARAMETRAGE_ECRANS_ACTIONS.md).
## 12. Données et API
### 12.1 Entités
- `Society` (uid, parent_society_uid, office_uid, …) — dossier = société = entreprise ; société mère ou fille ; niveau archivage
- `Operation` (uid, society_uid, office_uid, title, date, case_number, accounting_number, has_company, operation_type_uid, **current_step_uid**, **status** (état global : ouvert, en cours, clôturé), created_at, updated_at) — société dossier ; peut créer une société (devient société liée + société fille) ; étape courante
- `OperationTypeStep` (uid, operation_type_uid, label, order) — étapes par type d’opération
- `OperationComment` (uid, operation_uid, content, access_level, author_uid, created_at)
- `OperationSociety` (operation_uid, society_uid) — table de jointure ; une société liée = une société (données dans `societies`)
- `SocietyComment` (uid, society_uid, content, access_level, author_uid, created_at) — commentaires sur la société
- `Contact` (uid, office_uid, last_name, first_name, email, phone, created_at) — réutilisable ; **un utilisateur peut avoir plusieurs contacts**
- `OperationContact` (uid, operation_uid, contact_uid, roles_operation, sub_roles_operation, is_shareholder, shares_count, created_at) — rôles/sous-rôles cumulatifs
- `SocietyContact` (uid, society_uid, contact_uid, roles_enterprise, sub_roles_enterprise, created_at) — rôles entreprise par société
- `ContactComment` (uid, operation_contact_uid ou society_contact_uid, content, access_level, author_uid, created_at)
- `UserContact` (user_uid, contact_uid) — un utilisateur peut avoir plusieurs contacts
- `OperationDocument` (uid, operation_uid, society_uid?, document_type_uid, attachment_target, status, deleted, signed, expected_depositor_role, validated_by_default, created_at, updated_at) — attachment_target : operation | society
- `OperationDocumentSociety` (operation_document_uid, society_uid) — N-N : document → N sociétés liées
- `OperationDocumentFile` (uid, operation_document_uid, file_ref, template, template_variables, info_type, cnil_expiry, created_at)
- `OperationType` (uid, office_uid, label, order)
- `ActivityType` (uid, office_uid, label, order)
**Identifiants** : tous les objets ont un `uid` technique (non affiché) ; numéros = références métier.
### 12.2 Endpoints (principaux)
- `GET /operations` — opérations où la personne connectée a un rôle
- `GET/POST /societies/[societyUid]/operations`, `GET/PATCH/DELETE /operations/[operationUid]` — une opération peut créer une société
- `GET/POST /operations/[operationUid]/societies`, `GET/PATCH/DELETE /operations/[operationUid]/societies/[societyUid]` — sociétés liées
- `POST /operations/[operationUid]/validate` — étapes post-création (ordre fixe, pas de retour)
- `GET/POST /operations/[operationUid]/contacts`, `GET/PATCH/DELETE /operations/[operationUid]/contacts/[contactUid]`
- `GET /contacts?q=` (recherche cabinet, alerte doublon, pas de création si identique)
- `GET/POST /operations/[operationUid]/documents`, `GET/PATCH/DELETE /operations/[operationUid]/documents/[documentUid]`
- `GET/PATCH /operations/[operationUid]/documents/[documentUid]/societies` (liaison N-N sociétés liées)
- `POST /operations/[operationUid]/documents/upload-zip` (répartition IA)
- `POST /operations/[operationUid]/societies/[societyUid]/extract-kbis`
- `GET/POST /operation-types`, `GET/PATCH/DELETE /operation-types/[uid]`
- `GET/POST /operation-types/[uid]/steps`, `GET/PATCH/DELETE /operation-types/[uid]/steps/[stepUid]` (étapes par type d’opération)
- `GET/POST /activity-types`, `GET/PATCH/DELETE /activity-types/[uid]`
## 13. Sécurité et accessibilité
- **Autorisation** : accès aux opérations où la personne a un rôle ; contrôle du niveau d’accès (interne, restreint au gestionnaire de l’opération, secret) selon rôle.
- **Invités dataroom** : connexion par mail + confirmation SMS (pas de mot de passe) lorsqu’un document leur est envoyé/demandé/validé/refusé.
- **Données sensibles** : commentaires secret visibles uniquement avocat/avocat associé ou notaire/notaire associé.
- **Accessibilité** : formulaires avec labels, erreurs associées ; listes avec en-têtes ; boutons identifiables.
## 14. Impacts
- **Front** : pages operations (liste, détail, création [créateur + collaborateurs], édition), page validation/correction post-création, onglets rôle → sous-rôle → membres (contacts + collaborateurs) ; édition documents .docx (modèle, IA, OpenOffice) ; modals ; paramétrage.
- **Back** : modules societies, operations, operation_society (jointure), contacts, operation_documents ; services extraction KBIS, répartition IA, génération fichiers de synthèse, édition documents ; repositories.
- **Shared** : types Operation, Society, Contact, OperationDocument, statuts, niveaux d’accès.
- **Dépendances** : zones 3 (types de documents), 6 (rôles), 17 (IA pour extraction et répartition).
## 15. Modalités de déploiement
- Prérequis : migrations pour tables societies, operations, operation_society (jointure), operation_contacts, society_contacts, user_contacts, operation_documents, operation_document_societies, operation_document_files, operation_types, operation_type_steps, activity_types ; seeds pour types par défaut.
- Déploiement standard ; pas d’étape spécifique hors flux standard.
## 16. Modalités d’analyse
- Recette : création opération complète (entreprise, contacts, documents) ; extraction KBIS ; upload ZIP et répartition IA ; validation/correction post-création (infos, contacts, affectations ZIP, fichiers de synthèse) ; accès par onglets rôle/sous-rôle ; tableau documents avec actions (demande, relance, exclusion, modification, suppression, visualisation preview, téléchargement, validation, refus) ; archivage au niveau dossier.
- Logs : création, modification, extraction, répartition IA, erreurs.
- Données : cohérence opération–entreprise–contacts–documents ; intégrité SIRET, rôles.

23
services/docv/enso-docs/installation-docv-enso-front-supplement.md Normal file
View File

@ -0,0 +1,23 @@
# Supplément §4.2 — enso-front / docv API (plan 0 mock)
Le contenu **canonique** est dans **`docs/INSTALLATION_ENVIRONNEMENT.md`** §4.2 et **`deploy/scripts_v2/remote/bootstrap-enso-remote.sh`** (depuis la version **0.0.46**). Ce fichier conserve le même texte pour **référence rapide** ou clones désynchronisés ; en cas de divergence, **le guide d’installation et le script du dépôt priment**.
## Ligne de tableau (référence)
| `NEXT_PUBLIC_DOCV_API_BASE` | client | Optionnel : base URL des appels API métier avec Bearer (`/api/v1/…`). Défaut navigateur : origine du site + `/docv-api`. Écrit par **`bootstrap-enso-remote.sh`** sur les déploiements bootstrap. |
## Paragraphe (API Bearer, nginx)
Le tableau de bord et la barre latérale appellent **docv-back** en HTTPS sur **`{origine publique}/docv-api/api/v1/…`** avec l’en-tête **`Authorization: Bearer`** (token d’accès OAuth). Nginx route le préfixe **`/docv-api/`** vers docv-back (port **3038** en interne sur l’infra de référence). Liste des routes HTTP et câblage front : [features/DOCV_API_ENSO_FRONT_MAP.md](features/DOCV_API_ENSO_FRONT_MAP.md) §1 ; socle, migrations et narrative : [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) §3.1.
## Bootstrap distant (`deploy/scripts_v2/remote/bootstrap-enso-remote.sh`)
Dans le heredoc **`enso/enso-front/.env.production.local`**, **après** `NEXT_PUBLIC_DOCV_OAUTH_AUTHORIZE_BASE=…` :
```bash
NEXT_PUBLIC_DOCV_API_BASE=${DOCV_PUB}
```
(`DOCV_PUB` est déjà défini comme `${ENSO_PUBLIC_ORIGIN}/docv-api`.)
Côté runtime, le front agrège **trois** requêtes docv stubs (notifications, pending-documents, conversations) dans **`DocvStubListsProvider`** — un aller-retour réseau amorti par **`Promise.all`**.

BIN
services/docv/enso-docs/liste juridique social et fiscal client 10 2025.xlsx Normal file
View File

Binary file not shown.

51
services/docv/enso-docs/operations/NGINX_ENSO_API_ROUTING.md Normal file
View File

@ -0,0 +1,51 @@
# Reverse proxy — préfixe `/api/` sur les vhosts `*.enso.*`
Sur **test**, **pprod** et **prod**, le vhost public **enso** (ex. `test.enso.4nkweb.com`) doit envoyer **`location /api/`** vers **enso-front** (**port 3032**), pas vers **enso-back** (**3040**).
## Pourquoi
- **enso-front** (Next.js) expose des Route Handlers sous **`/api/`**, notamment **`POST /api/auth/docv-token`** pour l’échange du code OAuth.
- **enso-back** sur **3040** est pour l’instant un accepteur TCP minimal qui répond **`ok`** (texte brut) à **toute** requête. Si nginx route **`/api/`** vers **3040**, le navigateur reçoit **`ok`** au lieu de JSON → échec du parse côté client et écran bloqué sur « Connexion en cours… » après le retour OAuth.
## Référence dépôt
Fichiers snippets : **`deploy/nginx/test.enso.4nkweb.com.locations.snippet`**, **`pprod.enso…`**, **`prod.enso…`** — blocs **`location /api/`** avec **`proxy_pass`** vers **3032** sur la machine cible (**101** / **102** / **103**).
Après modification du proxy (**192.168.1.100**), recharger nginx et contrôler :
```bash
curl -sS -D- -o /tmp/b.txt -X POST "https://test.enso.4nkweb.com/api/auth/docv-token" \
-H "Content-Type: application/json" \
-d '{"code":"x","redirect_uri":"https://test.enso.4nkweb.com/auth/docv-callback"}'
head -1 /tmp/b.txt
# Attendu : Content-Type JSON (erreur 400/500 avec corps JSON), pas text/plain « ok ».
```
## Variables Next sur l’hôte applicatif
Sur la machine qui exécute **`next start`** (3032), **`enso/enso-front/.env.production.local`** doit contenir au minimum **`DOCV_OAUTH_TOKEN_URL`**, **`DOCV_OAUTH_CLIENT_ID`**, **`DOCV_OAUTH_CLIENT_SECRET`** (alignés sur **docv-back**). Les seules clés **`VITE_*`** ne suffisent pas.
## Évolution : enso-back (3040) quand il expose une vraie API
Le périmètre produit est documenté dans **[docs/enso/README.md](../enso/README.md) §4.1** : le **socle** métier commun vit dans **docv-back** (**`/docv-api/`** → **3038**) ; **enso-back** (**3040**) porte le **spécifique cabinet** (zone 17, agrégats enso, intégrations serveur réservées au projet).
Quand **enso-back** servira des routes HTTP réelles, ne **pas** reprendre le préfixe **`/api/`** en entier vers **3032** pour tout le trafic métier enso : ajouter un bloc **plus spécifique** **avant** le `location /api/` générique, par exemple :
```nginx
# Exemple (à ajuster selon les chemins réels choisis pour enso-back)
location /api/enso/ {
proxy_pass http://192.168.1.101:3040;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /api/ {
proxy_pass http://192.168.1.101:3032;
# … (Next.js : /api/auth/docv-token et autres Route Handlers)
}
```
Le navigateur et **enso-front** continuent d’appeler **docv** pour les fonctionnalités communes via **`/docv-api/`** ; seules les routes **dédiées enso** passent par **`/api/enso/`** (ou le préfixe retenu dans le contrat d’API).

25
services/docv/enso-docs/patches/INSTALLATION_4.2_AND_BOOTSTRAP_DOCV_API_BASE.patch.md Normal file
View File

@ -0,0 +1,25 @@
# Patch manuel — `NEXT_PUBLIC_DOCV_API_BASE`
**Intégré dans le dépôt** depuis **0.0.46** (`INSTALLATION_ENVIRONNEMENT.md` §4.2 + `bootstrap-enso-remote.sh`). Conserver ce fichier pour **forks / branches anciennes** ou copier-coller manuel.
## 1. `docs/INSTALLATION_ENVIRONNEMENT.md` §4.2
**Tableau** — insérer une ligne après `NEXT_PUBLIC_DOCV_OAUTH_AUTHORIZE_BASE` :
```markdown
| `NEXT_PUBLIC_DOCV_API_BASE` | client | Optionnel : base URL des appels API métier avec Bearer (`/api/v1/…`). Défaut navigateur : origine du site + `/docv-api`. À définir en prod si le script bootstrap l’écrit (voir **`deploy/scripts_v2/remote/bootstrap-enso-remote.sh`**). |
```
**Paragraphe** — après le bloc sur `VITE_DOCV_*` et `/api/auth/docv-token`, avant `### 4.3 Par environnement` :
```markdown
Le tableau de bord et la barre latérale appellent **docv-back** en HTTPS sur **`{origine publique}/docv-api/api/v1/…`** avec l’en-tête **`Authorization: Bearer`** (token d’accès OAuth). Nginx route le préfixe **`/docv-api/`** vers docv-back (port **3038** sur l’infra de référence). Liste des routes HTTP et câblage front : [features/DOCV_API_ENSO_FRONT_MAP.md](../features/DOCV_API_ENSO_FRONT_MAP.md) §1 ; socle, migrations et narrative : [docv/IMPLEMENTATION.md](../docv/IMPLEMENTATION.md) §3.1. Le front agrège les requêtes stubs (notifications, pending-documents, conversations) dans **`DocvStubListsProvider`** via **`Promise.all`**.
```
## 2. `deploy/scripts_v2/remote/bootstrap-enso-remote.sh`
Dans le heredoc `FRONT_ENV`, **après** la ligne `NEXT_PUBLIC_DOCV_OAUTH_AUTHORIZE_BASE=…`, ajouter :
```bash
NEXT_PUBLIC_DOCV_API_BASE=${DOCV_PUB}
```

4
services/docv/enso-docs/patches/INSTALLATION_4.2_DOCV_FRAGMENT.md Normal file
View File

@ -0,0 +1,4 @@
# Fragment §4.2 (docv / enso-front)
- **[installation-docv-enso-front-supplement.md](../installation-docv-enso-front-supplement.md)** — texte fusionnable §4.2 + bootstrap.
- **[INSTALLATION_4.2_AND_BOOTSTRAP_DOCV_API_BASE.patch.md](INSTALLATION_4.2_AND_BOOTSTRAP_DOCV_API_BASE.patch.md)** — même contenu en blocs prêts à coller pour compte **`desk`** (ACL).