smart_ide/docs/features/remote-deployed-data-ssh.md

# 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`

Les chemins **locaux** vers clones (`project_path`, `deploy.repository_root`, etc.) sont **relatifs à la racine du monorepo smart_ide** (ou absolus). Les **`path_on_server`** sous `smart_ide.remote_data_access` restent des chemins **absolus sur la machine déployée**.

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`** (`Host …`). Pour **enso**, le déploiement lit **`ENSO_SSH_HOST`** dans le fichier **`enso-deploy.env`** de l’environnement (exemples dans **`enso/deploy/enso-deploy.env.example`** : `test`, `pprod`, `prod`). Si votre `Host` local diffère (ex. `enso-test-app`), renseigner **ce** libellé ici pour que les outils SSH du poste ciblent la bonne entrée.
  - **`remote_app_root` (optionnel)** : chemin **absolu sur le serveur** de la racine du clone applicatif lorsqu’il est fixé par les scripts de déploiement. Pour **enso**, même sémantique que **`ENSO_REMOTE_ROOT`** (ex. `/home/ncantu/enso` dans l’exemple du dépôt enso ; sous **`$HOME`** sur la cible pour les unités systemd utilisateur, voir commentaire dans **`enso-deploy.env.example`**).
  - **`remote_data_directories`** : liste d’objets `{ "role": "…", "path_on_server": "…" }` avec **`path_on_server` en chemin absolu sur la machine déployée**. Pour **enso**, les rôles **`enso_monorepo_clone`** et **`docv_dp_git_data`** reflètent **`ENSO_REMOTE_ROOT`** et le sous-chemin par défaut **`data/dossiers-permanents`** décrit dans **`enso/deploy/enso-deploy.env.example`** et **`enso/docs/features/DOSSIERS_PERMANENTS_DATA_GIT.md`**. Ajuster si **`DOCV_DP_GIT_REPO_ROOT`** / **`DOCV_DP_GIT_DATA_SUBPATH`** sur la cible divergent.
  - **`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`). L’exemple versionné peut contenir d’autres clés purement documentaires (ex. **`notes`**) ignorées par les automatisations.

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 [`.smartIde/rules/smart-ide-ia-dev-bridge.mdc`](../../.smartIde/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/` : [repo/projects-directory.md](../repo/projects-directory.md)