# 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**.