smart_ide/docs/features/docv-ai-integration.md
Nicolas Cantu ac96434351 docs: centralize README content under docs/repo/
**Motivations:**
- Single canonical documentation tree under docs/; reduce drift between README copies.

**Evolutions:**
- Add docs/repo/ with operational guides (cron, systemd, projects, logs, docv, ia_dev, services, scripts, extension).
- Replace scattered README.md files with pointers to docs/repo/*.md.
- Refresh docs/README.md index and cross-links across docs/, .cursor rules/agents.
- Bump ia_dev submodule to matching doc pointer commits.
2026-04-03 18:20:31 +02:00

3.1 KiB
Raw Blame History

docv — intégrations IA via la plateforme smart_ide

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, remote-deployed-data-ssh.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.

Référence darborescence côté Enso (machine de développement type) : dépôt docv sous un chemin du genre …/enso/docv (ex. historique /home/desk/code/enso/docv). Les URLs et secrets réels par environnement restent hors dépôt (platform-target.md, sso-docv-enso.md).

Modèle « projet »

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 lespace de travail, en général sous une racine de clones distincte du dossier ./projects/ du monorepo (voir repo/projects-directory.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). Lalimentation 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, anythingllm-workspaces.md, scripts sous scripts/).
  3. Configuration ia_dev : lorsquun 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 (ou équivalent) a été exécuté.

Flux cible (vue simplifiée)

flowchart LR
  Docv[docv_backend]
  Orch[orchestrator]
  GW[ia_dev_gateway]
  ALLM[AnythingLLM]
  Oll[Ollama]
  Docv --> Orch
  Orch --> GW
  Orch --> ALLM
  Orch --> Oll

Les contrats HTTP détaillés : API/README.md, orchestrator-api.md, ia-dev-service.md. Vue densemble écosystème et synchro : ecosystem-architecture-and-sync.md.

SSO

Lauthentification utilisateur front / docv (OIDC) est décrite dans sso-docv-enso.md ; elle est orthogonale aux appels serveur à serveur (tokens API, réseau interne) entre docv et les services smart_ide.