docs: deployed data over SSH, docv/AnythingLLM/services, IDE project config

- Add features/remote-deployed-data-ssh.md (source of truth on test/pprod/prod) - Extend projects conf smart_ide.remote_data_access and anythingllm slugs (enso example) - active-project.json.example + gitignore; .vscode/settings smartIde.activeProjectId - Update docv integration docs, anythingllm-workspaces, ecosystem, API README - Cursor rule: resolve project id from active-project / env / workspace setting
2026-04-03 17:55:08 +02:00 · 2026-04-03 17:55:08 +02:00 · 0f9a69e368
commit 0f9a69e368
parent d98e6bce60
17 changed files with 285 additions and 39 deletions
--- a/.cursor/rules/smart-ide-ia-dev-bridge.mdc
+++ b/.cursor/rules/smart-ide-ia-dev-bridge.mdc
@ -8,13 +8,14 @@ alwaysApply: false

 Quand le périmètre touche ce dépôt et le module **`ia_dev/`** :

- **Identifiant projet ia_dev :** `smart_ide` ; conf versionnée : **`projects/smart_ide/conf.json`** à la racine du workspace ; `ia_dev/projects/smart_ide` doit être un **lien** vers ce dossier (script `scripts/ensure-ia-dev-smart-ide-project-link.sh`).
- **Environnement :** `test` | `pprod` | `prod`. Le reprendre depuis le message utilisateur ; **demander** s’il manque avant des actions dépendantes du env.
+- **Projet courant (IDE / smart_ide) :** lire dans l’ordre : fichier local **`projects/active-project.json`** (champ **`id`**, non versionné — copier depuis `projects/active-project.json.example`) ; sinon variable **`SMART_IDE_PROJECT_ID`** ; sinon paramètre workspace **`smartIde.activeProjectId`** dans le fichier **`.code-workspace`** ou **`.vscode/settings.json`** ; sinon défaut **`smart_ide`**. La conf versionnée du projet est **`projects/<id>/conf.json`**. Données déployées et SSH : [docs/features/remote-deployed-data-ssh.md](../../docs/features/remote-deployed-data-ssh.md).
+- **Lien ia_dev :** pour l’id choisi, `ia_dev/projects/<id>` doit être un **lien** vers `../../projects/<id>` lorsque les scripts ia_dev résolvent ce chemin (script `scripts/ensure-ia-dev-smart-ide-project-link.sh` pour `smart_ide`).
+- **Environnement :** `test` | `pprod` | `prod`. Le reprendre depuis le message utilisateur ou depuis **`default_env`** dans `projects/active-project.json` ; **demander** s’il manque avant des actions dépendantes du env.
 - **Exécution des scripts ia_dev :** répertoire courant = racine **`ia_dev/`** (dans le workspace smart_ide). Pas de mélange avec la racine smart_ide pour `deploy/`, `gitea-issues/`, etc.
- **Sélection projet pour les scripts :** `IA_PROJECT_ID=smart_ide` et/ou `--project smart_ide` selon le script ; détail : `ia_dev/projects/README.md`.
- **MAIL_TO (ticketing / mails) :** lire `projects/smart_ide/conf.json` (racine workspace) → `tickets.authorized_emails.to` pour l’env choisi (ex. test → `AI.SMART_IDE.TEST@4nkweb.com`).
- **Code et doc applicative :** racine du workspace smart_ide ; doc indexée sous `docs/` à la racine. `ia_dev/projects/smart_ide/docs` peut être absent.
- **Chemins absolus** dans la doc ou agents ia_dev rédigés pour un autre poste : les remplacer par les chemins du workspace actuel et par `project_path` dans `conf.json`.
+- **Sélection projet pour les scripts :** `IA_PROJECT_ID=<id>` et/ou `--project <id>` selon le script ; détail : `ia_dev/projects/README.md`.
+- **MAIL_TO (ticketing / mails) :** lire `projects/<id>/conf.json` → `tickets.authorized_emails.to` pour l’env choisi.
+- **Code et doc applicative :** pour le monorepo smart_ide, racine du workspace et `docs/` ; pour un autre id, suivre **`project_path`** dans `conf.json`.
+- **Chemins absolus** dans la doc ou agents ia_dev rédigés pour un autre poste : les remplacer par les chemins du workspace actuel et par `project_path` / bloc **`smart_ide.remote_data_access`** dans `conf.json` si pertinent.
 - **`projects/*/conf.json` :** ne pas modifier sans validation utilisateur (règle ia_dev).

 Les agents nommés **`ia-dev-*`** dans `.cursor/agents/` renvoient explicitement vers `ia_dev/.cursor/agents/*.md` avec ce contexte.
--- a/.gitignore
+++ b/.gitignore
@ -5,3 +5,9 @@ core_ide/

 # Rust build output if docv workspace is present under services/docv/
 services/docv/target/
+
+# Surcharges locales pull-sync (cron)
+cron/config.local.env
+
+# Projet IDE actif (copie locale de active-project.json.example)
+projects/active-project.json
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@ -0,0 +1,3 @@
+{
+	"smartIde.activeProjectId": "smart_ide"
+}
--- a/docs/API/README.md
+++ b/docs/API/README.md
@ -21,4 +21,6 @@ Documentation des **API HTTP** exposées par les services sous [`services/`](../

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

+**Données sur environnements déployés** : les services qui lisent des fichiers ou index (ex. **agent-regex-search-api** sous `REGEX_SEARCH_ROOT`, **langextract-api**, usages futurs côté orchestrateur) doivent pouvoir consommer un **répertoire local alimenté par SSH** depuis test / pprod / prod ; la déclaration des alias et chemins distants est dans `projects/<id>/conf.json` → **`smart_ide.remote_data_access`** — [features/remote-deployed-data-ssh.md](../features/remote-deployed-data-ssh.md).
+
 Voir aussi : [services.md](../services.md), [system-architecture.md](../system-architecture.md), README de chaque dossier sous `services/`.
--- a/docs/README.md
+++ b/docs/README.md
@ -43,6 +43,12 @@ Index des documents à la racine de `docs/`. Les **fonctionnalités** détaillé
 | [../logs/README.md](../logs/README.md) | Journaux locaux : pull Git planifié, exécutions `ia_dev` |
 | [../services/ia_dev/README.md](../services/ia_dev/README.md) | Contrat d’intégration du module `ia_dev` |

+## Données déployées et SSH
+
+| Document | Contenu |
+|----------|---------|
+| [features/remote-deployed-data-ssh.md](./features/remote-deployed-data-ssh.md) | Données hors Git sur test/pprod/prod ; SSH pour docv, AnythingLLM, services ; bloc `smart_ide` dans `conf.json` ; config IDE `projects/active-project.json` |
+
 ## Fonctionnalités (`features/`)

 | Document | Contenu |
--- a/docs/anythingllm-workspaces.md
+++ b/docs/anythingllm-workspaces.md
@ -5,10 +5,10 @@
 - Un **workspace AnythingLLM** est créé (ou associé) **par projet** : documents indexés, embeddings, threads et paramètres RAG sont **scopés au projet**, pas mélangés entre dépôts.
 - Cela permet à la mémoire interrogée par `ask` / les agents de rester **pertinente** et **traçable** par contexte métier.

-## Synchronisation avec le dépôt
+## Synchronisation avec les sources de corpus

- Une **moulinette** (pipeline de synchro) met à jour le workspace à partir de fichiers sélectionnés du dépôt : sources, doc, configs exposées volontairement, etc.
- Les règles de ce qu’on synchronise (inclusions / exclusions, secrets interdits) doivent être **explicites** et alignées avec la politique de sécurité du projet.
+- Une **moulinette** (pipeline de synchro) met à jour le workspace à partir de fichiers **sélectionnés** : en plus du dépôt Git (sources, doc versionnée), le corpus peut inclure des fichiers **issus des environnements déployés**, obtenus par **SSH** (rsync, dumps, exports) vers un répertoire local ou de service — voir [features/remote-deployed-data-ssh.md](./features/remote-deployed-data-ssh.md).
+- Les règles d’inclusion / exclusion (`.4nkaiignore`, secrets interdits) doivent rester **explicites** ; les données métier **ne doivent pas** être commitées dans Git sous `data/` sur les dépôts applicatifs.

 ## Exploitation

--- a/docs/ecosystem-architecture-and-sync.md
+++ b/docs/ecosystem-architecture-and-sync.md
@ -98,8 +98,8 @@ Objectif : après un changement **tracé dans Git**, les systèmes en aval (Anyt

 ### 4.2 Cycle de travail développeur (projet applicatif)

-1. `git pull` (ou `merge`) sur le clone du projet — peut être **automatisé** par [`cron/git-pull-project-clones.sh`](../cron/git-pull-project-clones.sh) à partir des `projects/<id>/conf.json` (voir [`cron/README.md`](../cron/README.md)).
-2. Le hook **post-merge** exécute **`scripts/anythingllm-pull-sync/sync.mjs`** : envoi des fichiers **modifiés ou ajoutés** vers le workspace AnythingLLM du projet, avec exclusions **`.4nkaiignore`**.
+1. `git pull` (ou `merge`) sur le clone du projet — peut être **automatisé** par [`cron/git-pull-project-clones.sh`](../cron/git-pull-project-clones.sh) à partir des `projects/<id>/conf.json` (voir [`cron/README.md`](../cron/README.md)). Le clone porte le **code** ; les **données métier** restent sur les **environnements déployés** (pas dans Git, voir [features/remote-deployed-data-ssh.md](./features/remote-deployed-data-ssh.md)).
+2. Pour le **RAG / AnythingLLM** : en parallèle du dépôt, un flux **SSH** (ou job docv) alimente un **miroir local** des données déployées ; le hook **post-merge** et **`scripts/anythingllm-pull-sync/sync.mjs`** peuvent cibler **à la fois** le clone (fichiers versionnés) et ce miroir, selon la configuration du projet, avec exclusions **`.4nkaiignore`**.
 3. Limites documentées : pas de suppression automatique des documents retirés du repo dans la version actuelle du script ; traiter les gros refactors par une **resynchro** manuelle ou évolution du script si le besoin est récurrent.

 ### 4.3 Cycle de travail sur smart_ide
@ -124,11 +124,11 @@ Objectif : après un changement **tracé dans Git**, les systèmes en aval (Anyt

 ## 5. Intégrations tierces (docv)

- **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).
+- **Gestion documentaire** : données de référence sur **serveurs déployés**, accès **SSH** pour docv / AnythingLLM / services — [features/remote-deployed-data-ssh.md](./features/remote-deployed-data-ssh.md), [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.
+Sur un **hôte distinct**, docv résout un répertoire de travail local (**`DOCV_PROJECTS_ROOT`** ou équivalent) alimenté par **SSH** depuis les environnements cibles ; smart_ide atteint docv via **`DOCV_BASE_URL`**.

 ## 6. Non-objectifs explicites dans cette stratégie

--- a/docs/features/docv-ai-integration.md
+++ b/docs/features/docv-ai-integration.md
@ -1,6 +1,6 @@
 # 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).
+**Gestion documentaire**, données sur **environnements déployés** et **SSH** (plus de vérité métier dans un `data/` Git), adaptation du dépôt docv et multi-hôte : [docv-service-integration.md](./docv-service-integration.md), [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md).

 ## Rôle de smart_ide

@ -13,7 +13,7 @@ Référence d’arborescence côté Enso (machine de développement type) : dép
 Pour chaque **projet logique** (ex. périmètre docv, autre produit) :

 1. **Clone Git** : le dépôt applicatif doit être **déjà cloné** au même titre que les autres projets de l’espace de travail, en général sous une **racine de clones** **distincte** du dossier `./projects/` du monorepo (voir [projects/README.md](../../projects/README.md)) — convention fréquente : répertoire **frère** `../projects/<nom>/` par rapport à la racine `smart_ide`.
-2. **AnythingLLM** : le projet doit être **rattaché à un workspace** AnythingLLM (un workspace par projet). Si le clone ou le workspace **manque** ou est désynchronisé, la procédure d’exploitation prévoit de **créer / mettre à jour** le clone et d’**aligner** le workspace (synchronisation déterministe, voir [anythingllm-workspaces.md](../anythingllm-workspaces.md) et scripts sous `scripts/`).
+2. **AnythingLLM** : le projet doit être **rattaché à un workspace** AnythingLLM (un workspace par projet). L’alimentation du workspace repose sur un corpus **aligné sur les données déployées** : récupération via **SSH** depuis test / pprod / prod puis pipeline de synchro (voir [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md), [anythingllm-workspaces.md](../anythingllm-workspaces.md), scripts sous `scripts/`).
 3. **Configuration ia_dev** : lorsqu’un id projet est enregistré pour les agents ou le ticketing, un `conf.json` peut être versionné sous **`smart_ide/projects/<id>/conf.json`** ; les scripts `ia_dev` y accèdent via le lien `ia_dev/projects/<id>` lorsque le script [`ensure-ia-dev-smart-ide-project-link.sh`](../../scripts/ensure-ia-dev-smart-ide-project-link.sh) (ou équivalent) a été exécuté.

 ## Flux cible (vue simplifiée)
--- a/docs/features/docv-service-integration.md
+++ b/docs/features/docv-service-integration.md
@ -2,7 +2,7 @@

 ## 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.
+**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, comment les **données projet** sont servies depuis les **environnements déployés** (SSH), et comment **adapter** le dépôt docv pour ne pas dépendre de chemins machine figés dans le code.

 Les **intégrations IA** (orchestrateur, Ollama, AnythingLLM, etc.) sont décrites séparément : [docv-ai-integration.md](./docv-ai-integration.md).

@ -10,23 +10,25 @@ Les **intégrations IA** (orchestrateur, Ollama, AnythingLLM, etc.) sont décrit

 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/`
+## Convention disque : clones et données
+
+**Vérité données déployées** : la **source de référence** des données métier (fichiers, index, bases utilisées pour la doc et le RAG) est sur les **environnements déployés** (test, pprod, prod), pas dans Git. **docv** doit pouvoir **récupérer** ces données via **SSH** (voir [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md)) avant synchronisation vers AnythingLLM ou traitement local. Les répertoires `data/` dans les clones applicatifs restent des **miroirs ou caches** : à exclure de l’historique Git (`.gitignore` dans chaque dépôt produit).

 ```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]
+  subgraph deployed [Serveurs_test_pprod_prod]
+    D[data_et_BDD]
  end
+  subgraph local [Poste_ou_service_docv]
+    M[miroir_ou_cache_local]
+    DV[docv_repo]
+  end
+  deployed -->|SSH_rsync_ou_dump| M
+  M --> DV
 ```

- **`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.
+- **`PROJECTS_CLONE_ROOT`** : répertoire absolu parent des clones **`<projet>/`** (code). Convention : souvent **`../projects`** relatif à smart_ide ([projects/README.md](../../projects/README.md)).
+- **Zone de travail docv** : chemin résolu par **`DOCV_PROJECTS_ROOT`** (ou équivalent) vers un répertoire où les **fichiers issus des environnements déployés** sont présents après **pont SSH** (structure exacte à documenter dans le dépôt docv : sous-dossiers par `projectId`, par env, etc.).

 ## Adaptations attendues dans le dépôt docv (amont)

@ -36,14 +38,14 @@ flowchart TB
 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).
+4. Par **environnement** (test, pprod, prod), utiliser des fichiers d’environnement **hors Git** avec des valeurs distinctes pour `DOCV_PROJECTS_ROOT` (ou équivalent : répertoire du **miroir** après fetch SSH), URLs, et paramètres SSH côté hôte — alignés sur [platform-target.md](../platform-target.md) et [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md).

-## Multi-hôte : poste local docv vs serveur SSH smart_ide
+## Multi-hôte : poste local docv, smart_ide, environnements déployés

-**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).
+**docv** peut tourner sur un **hôte différent** de l’orchestrateur et des services smart_ide.

 - 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.
+- L’alignement des **données** avec les serveurs **test / pprod / prod** repose sur **SSH** (ou équivalent) depuis l’hôte qui exécute docv ou un job dédié, pas sur un `data/` versionné dans le clone Git — détail : [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md). Un **stockage partagé** (NFS, etc.) reste une option alternative si la politique projet le prévoit.

 ## Orchestrateur et routage

--- a/docs/features/remote-deployed-data-ssh.md
+++ b/docs/features/remote-deployed-data-ssh.md
@ -0,0 +1,84 @@
+# Données sur environnements déployés — SSH, docv, AnythingLLM, services
+
+## Règle de périmètre
+
+- La **vérité opérationnelle des données métier** (fichiers documentaires, volumes applicatifs, dumps ou extractions de bases utilisées pour l’IA / docv / recherche) réside sur les **machines déployées** **test**, **pprod** et **prod**, pas dans l’historique Git des dépôts applicatifs.
+- Les dépôts sources (clone local ou CI) contiennent le **code** et la **doc versionnée** ; les répertoires du type **`data/`**, caches d’index, exports SQL destinés au RAG, etc. doivent être **ignorés par Git** (`.gitignore` dans chaque dépôt applicatif concerné). Smart_ide ne remplace pas le `.gitignore` des projets externes : la convention est **documentée ici** pour alignement équipe.
+
+## Objectifs par consommateur
+
+| Consommateur | Besoin | Moyen prévu |
+|--------------|--------|-------------|
+| **docv** | Lire / actualiser la vue documentaire et les données projet alignées sur l’état **déployé** | Connexion **SSH** (ou rebond **ProxyJump**) vers les hôtes ou bastions par environnement ; copie contrôlée (**rsync**, **scp**, **sftp**) ou **commandes distantes** (ex. `pg_dump` sur le serveur) vers une **zone de travail locale ou de service** autorisée, puis ingestion AnythingLLM / API docv selon les pipelines du dépôt docv. |
+| **AnythingLLM** | Workspace par projet alimenté avec un corpus **proche de la prod** (ou de test) | Après **récupération SSH** depuis l’environnement cible (fichiers + éventuels dumps transformés en documents), exécution des scripts de synchro existants ([anythingllm-workspaces.md](../anythingllm-workspaces.md), [anythingllm-pull-sync-after-pull.md](./anythingllm-pull-sync-after-pull.md)) en pointant vers ce **miroir local ou volume monté**, pas vers un `data/` versionné dans Git. |
+| **Services smart_ide** (éditeur, IA, extraction, recherche dans les données) | Opérer sur des fichiers ou flux qui **ne sont pas** dans le clone Git | Même principe : les services qui doivent lire des **données déployées** obtiennent un **chemin résolu après fetch SSH** (répertoire cache par projet / environnement) ou exécutent des **commandes distantes** via SSH ; les contrats HTTP existants ([API/README.md](../API/README.md)) peuvent être étendus côté implémentation pour accepter une **racine de lecture** (`*_ROOT`, `*_CACHE_DIR`) alimentée par ce flux. |
+
+Les **secrets** (clés SSH, mots de passe BDD) restent **hors dépôt** : fichiers sous `~/.ssh/config`, agents SSH, coffres locaux — jamais dans `projects/*/conf.json`.
+
+## Schéma logique
+
+```mermaid
+flowchart TB
+  subgraph deployed [Environnements déployés]
+    T[test]
+    P[pprod]
+    R[prod]
+  end
+  subgraph git [Dépôts Git]
+    APP[clone applicatif]
+  end
+  subgraph bridge [Pont SSH]
+    SSH[ssh_rsync_ou_commande_distante]
+  end
+  subgraph consumers [Consommateurs]
+    DV[docv]
+    ALLM[AnythingLLM]
+    SVC[services_smart_ide]
+  end
+  T --> SSH
+  P --> SSH
+  R --> SSH
+  SSH --> DV
+  SSH --> ALLM
+  SSH --> SVC
+  APP --> git
+  APP -.-x|pas de data versionnée| git
+```
+
+## Déclaration dans `projects/<id>/conf.json`
+
+Bloc optionnel **`smart_ide`** (ignoré par les outils qui ne le lisent pas, ex. parties d’**ia_dev** qui ne sélectionnent que leurs champs) :
+
+- **`remote_data_access.environments.<test|pprod|prod>`** : pour chaque environnement,
+  - **`ssh_host_alias`** : nom d’**hôte SSH** tel que défini dans **`~/.ssh/config`** (recommandé : `Host enso-test-app`, `ProxyJump`, `IdentityFile`, etc.).
+  - **`remote_data_directories`** : liste d’objets `{ "role": "…", "path_on_server": "…" }` décrivant les chemins **sur la machine déployée** (ex. répertoire docv, dossier de pièces jointes, répertoire de dumps). Les chemins sont **indicatifs** : les ajuster sur chaque ferme.
+  - **`database` (optionnel)** : description **non secrète** du besoin (moteur, stratégie dump) ; pas d’URL ni mot de passe dans le JSON versionné.
+
+- **`anythingllm_workspace_slug` (optionnel)** : objet ou chaînes par env — slugs de workspace alignés sur [anythingllm-workspaces.md](../anythingllm-workspaces.md).
+
+Un exemple structuré est donné sous **`projects/enso/conf.json`** ; copier / adapter pour d’autres ids.
+
+## Configuration projet dans l’IDE
+
+Objectif : indiquer **quel** `projects/<id>/` est actif pour l’éditeur et les agents, sans mélanger avec `IA_PROJECT_ID` ia_dev quand ils divergent.
+
+1. **Fichier local (recommandé)**  
+   - Copier [`projects/active-project.json.example`](../projects/active-project.json.example) vers **`projects/active-project.json`**.  
+   - Ce fichier est **ignoré par Git** (voir racine `.gitignore`).  
+   - Champs : **`id`** (obligatoire, ex. `enso`), **`default_env`** (optionnel : `test` | `pprod` | `prod`).
+
+2. **Paramètres du fichier workspace VS Code / Cursor**  
+   - Dans le **`.code-workspace`** que vous ouvrez (ex. [`projects/enso/smart_ide.code-workspace`](../enso/smart_ide.code-workspace)), renseigner :  
+     `"smartIde.activeProjectId": "<id>"`  
+   - Même clé possible dans **`.vscode/settings.json`** à la racine du dossier smart_ide pour un dossier unique.  
+   - Ces clés ne sont **pas** des clés natives VS Code : elles servent de **convention** lue par scripts, extensions maison ou règles Cursor (voir [`.cursor/rules/smart-ide-ia-dev-bridge.mdc`](../../.cursor/rules/smart-ide-ia-dev-bridge.mdc)).
+
+Ordre de priorité suggéré pour les automatisations : **`projects/active-project.json`** → variable d’environnement **`SMART_IDE_PROJECT_ID`** si défini au lancement → **`smartIde.activeProjectId`** dans les settings du workspace → demande explicite à l’utilisateur.
+
+## Liens
+
+- Intégration docv et chemins historiques locaux : [docv-service-integration.md](./docv-service-integration.md)  
+- IA docv : [docv-ai-integration.md](./docv-ai-integration.md)  
+- AnythingLLM : [anythingllm-workspaces.md](../anythingllm-workspaces.md)  
+- Écosystème Git / synchro : [ecosystem-architecture-and-sync.md](../ecosystem-architecture-and-sync.md)  
+- Index `projects/` : [projects/README.md](../../projects/README.md)  
--- a/projects/README.md
+++ b/projects/README.md
@ -30,6 +30,21 @@ Pour **chaque** `projects/<id>/conf.json`, le tirage automatique utilise la **co

 Détail : [`cron/README.md`](../cron/README.md). Les clones restent sous le chemin **absolu** `project_path`.

+## Données déployées, SSH, AnythingLLM et IDE
+
+- Les **données métier** vivent sur les **serveurs test / pprod / prod** ; elles ne doivent **pas** être versionnées dans les dépôts applicatifs (répertoires du type `data/`, dumps, etc. en **`.gitignore`** sur chaque clone applicatif). **docv**, **AnythingLLM** et les **services** smart_ide qui lisent ces données s’appuient sur des **accès SSH** documentés vers ces environnements. Spécification : [features/remote-deployed-data-ssh.md](../docs/features/remote-deployed-data-ssh.md).
+
+### Bloc optionnel `smart_ide` dans `conf.json`
+
+Chaque `projects/<id>/conf.json` peut contenir une clé **`smart_ide`** (hors périmètre strict ia_deploy) avec notamment **`remote_data_access`** (alias SSH `Host`, chemins **sur serveur** par environnement). Voir l’exemple sous **`enso/conf.json`**.
+
+### Projet actif pour l’éditeur / Cursor
+
+1. Copier [`active-project.json.example`](./active-project.json.example) vers **`projects/active-project.json`** (fichier **non versionné**) et renseigner **`id`** (`smart_ide`, `enso`, …).
+2. Dans un fichier **`.code-workspace`**, renseigner **`smartIde.activeProjectId`** dans **`settings`** (ex. [`enso/smart_ide.code-workspace`](./enso/smart_ide.code-workspace)).
+
+Les agents Cursor lisent cette convention via [`.cursor/rules/smart-ide-ia-dev-bridge.mdc`](../.cursor/rules/smart-ide-ia-dev-bridge.mdc).
+
 ## Référence amont

-Schéma des champs : `ia_dev/projects/README.md` dans le sous-module (documentation ia_dev). Le bloc optionnel **`cron`** est une extension **smart_ide** pour les scripts locaux ; `ia_dev` peut l’ignorer s’il ne le lit pas.
+Schéma des champs : `ia_dev/projects/README.md` (documentation ia_dev). Le bloc optionnel **`cron`** est une extension **smart_ide** pour les scripts locaux ; `ia_dev` peut l’ignorer s’il ne le lit pas. Le bloc **`smart_ide`** est une extension **smart_ide** pour données distantes et IDE ; les outils ia_dev qui ne le lisent pas peuvent l’ignorer.
--- a/projects/active-project.json.example
+++ b/projects/active-project.json.example
@ -0,0 +1,4 @@
+{
+	"id": "smart_ide",
+	"default_env": "test"
+}
--- a/projects/enso/conf.json
+++ b/projects/enso/conf.json
@ -0,0 +1,84 @@
+{
+	"id": "enso",
+	"name": "enso",
+	"cron": {
+		"git_pull": true
+	},
+	"project_path": "/home/ncantu/code/enso",
+	"build_dirs": [
+		"/home/ncantu/code/enso",
+		"/home/ncantu/code/enso/enso/enso-front"
+	],
+	"deploy": {
+		"repository_root": "/home/ncantu/code/enso",
+		"scripts_path": "/home/ncantu/code/enso/deploy/scripts_v2",
+		"deploy_script_path": "/home/ncantu/code/enso/deploy/scripts_v2/deploy.sh",
+		"project_orchestrator_path": "deploy/scripts_v2/deploy.sh",
+		"secrets_path": "/home/ncantu/code/enso/.secrets"
+	},
+	"version": {
+		"package_json_paths": [
+			"/home/ncantu/code/enso/package.json",
+			"/home/ncantu/code/enso/enso/enso-front/package.json"
+		],
+		"splash_app_name": "enso"
+	},
+	"mail": {
+		"imap_bridge_env": ".secrets/gitea-issues/imap-bridge.env"
+	},
+	"git": {
+		"wiki_url": "https://git.4nkweb.com/4nk/enso/wiki",
+		"token_file": ".secrets/gitea-issues/token"
+	},
+	"tickets": {
+		"ticketing_url": "https://git.4nkweb.com/4nk/enso/issues",
+		"authorized_emails": {
+			"to": [
+				{
+					"test": "AI.ENSO.TEST@4nkweb.com",
+					"pprod": "AI.ENSO.PPROD@4nkweb.com",
+					"prod": "AI.ENSO.PROD@4nkweb.com"
+				}
+			],
+			"from": ["nicolas.4nk@pm.me"]
+		}
+	},
+	"smart_ide": {
+		"remote_data_access": {
+			"environments": {
+				"test": {
+					"ssh_host_alias": "enso-test-app",
+					"remote_data_directories": [
+						{
+							"role": "docv_storage",
+							"path_on_server": "/var/lib/enso/test/data"
+						}
+					]
+				},
+				"pprod": {
+					"ssh_host_alias": "enso-pprod-app",
+					"remote_data_directories": [
+						{
+							"role": "docv_storage",
+							"path_on_server": "/var/lib/enso/pprod/data"
+						}
+					]
+				},
+				"prod": {
+					"ssh_host_alias": "enso-prod-app",
+					"remote_data_directories": [
+						{
+							"role": "docv_storage",
+							"path_on_server": "/var/lib/enso/prod/data"
+						}
+					]
+				}
+			}
+		},
+		"anythingllm_workspace_slug": {
+			"test": "enso-test",
+			"pprod": "enso-pprod",
+			"prod": "enso-prod"
+		}
+	}
+}
--- a/projects/enso/smart_ide.code-workspace
+++ b/projects/enso/smart_ide.code-workspace
@ -0,0 +1,16 @@
+{
+	"folders": [
+		{
+			"path": "../.."
+		},
+		{
+			"path": "../../../enso"
+		},
+		{
+			"path": "../../../builazoo"
+		}
+	],
+	"settings": {
+		"smartIde.activeProjectId": "enso"
+	}
+}
--- a/projects/smart_ide/conf.json
+++ b/projects/smart_ide/conf.json
@ -1,6 +1,9 @@
 {
 	"id": "smart_ide",
 	"name": "smart_ide",
+	"cron": {
+		"git_pull": true
+	},
 	"project_path": "/home/ncantu/code/smart_ide",
 	"build_dirs": [],
 	"deploy": {},
@ -27,5 +30,23 @@
 			],
 			"from": ["nicolas.4nk@pm.me"]
 		}
+	},
+	"smart_ide": {
+		"remote_data_access": {
+			"environments": {
+				"test": {
+					"ssh_host_alias": "smart-ide-test",
+					"remote_data_directories": []
+				},
+				"pprod": {
+					"ssh_host_alias": "smart-ide-pprod",
+					"remote_data_directories": []
+				},
+				"prod": {
+					"ssh_host_alias": "smart-ide-prod",
+					"remote_data_directories": []
+				}
+			}
+		}
 	}
 }
--- a/services/docv/.env.example
+++ b/services/docv/.env.example
@ -3,3 +3,7 @@
 #
 # DOCV_BASE_URL=https://docv.example.internal
 # DOCV_API_TOKEN=
+#
+# Données déployées (miroir local après fetch SSH) — pas de secrets ici :
+# DOCV_PROJECTS_ROOT=/chemin/vers/miroir/projets
+# Les alias SSH (Host …) sont dans ~/.ssh/config — voir docs/features/remote-deployed-data-ssh.md
--- a/services/docv/README.md
+++ b/services/docv/README.md
@ -13,18 +13,16 @@ 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.
+**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** de référence vivent sur les **environnements déployés** ; docv (et les jobs de synchro AnythingLLM) les **récupèrent via SSH** vers une zone locale ou de service — voir [features/remote-deployed-data-ssh.md](../../docs/features/remote-deployed-data-ssh.md).

-## Convention de chemins : `PROJECTS_CLONE_ROOT` et `data/`
+## Convention de chemins : clones et zone de travail

 | Concept | Description |
 |---------|-------------|
-| **`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.). |
+| **`PROJECTS_CLONE_ROOT`** | Répertoire absolu parent des **clones** **`<projet>/`** (code). Souvent **`../projects`** relatif à **smart_ide** ([projects/README.md](../../projects/README.md)). |
+| **Données pour docv / RAG** | Répertoire résolu par **`DOCV_PROJECTS_ROOT`** (ou équivalent) : contenu **aligné sur les serveurs** test / pprod / prod après **pont SSH** (rsync, dumps, etc.), pas un dossier `data/` versionné dans Git. |

-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`.
+Sur un poste de développement, **`DOCV_PROJECTS_ROOT`** pointe typiquement vers un **cache ou miroir** alimenté par les scripts documentés dans le dépôt docv et [docv-service-integration.md](../../docs/features/docv-service-integration.md).

 ## Côté dépôt docv (amont)