smart_ide/docs/platform-target.md

Plateforme de développement en ligne — cible produit

Ce document fixe la vision d’ensemble du monorepo smart_ide : interface unifiée, services locaux, trois environnements d’exploitation, IA sur hôte unique (variante courante), SSO avec docv, et règle d’arbitrage pour un service navigateur optionnel.

Objectifs

• Création logicielle : édition, Git, agents, scripts et mémoire documentaire dans un flux cohérent (intentions, pas explorateur comme flux nominal — voir ux-navigation-model.md).
• Documents + IA : ONLYOFFICE (bureautique riche), Local Office (API programmatique docx), AnythingLLM (RAG par projet), Ollama (inférence locale).
• Apprentissage / indexation automatisés : pipelines déterministes (sync après pull, .4nkaiignore, journal d’indexation consultable) — pas d’« apprentissage » opaque non audité.
• Évolution du produit : recettes versionnées, timeline (événements gateway, Git, indexation) — voir system-architecture.md.

Variantes de déploiement

Variante	Description	Doc
Machine IA unique	Ollama et AnythingLLM sur le même hôte ; services smart_ide sur cet hôte ou derrière le même reverse proxy. Lapce et/ou front web consomment les APIs localement ou via TLS interne.	Ce fichier ; deployment-target.md § variante
Client Linux + SSH	Poste client ; socle IA et repos sur serveur distant ; tunnels ou VPN pour les URLs « localhost » côté serveur.	deployment-target.md

Les deux variantes peuvent coexister selon l’équipe ; la matrice d’environnement (test / pprod / prod) s’applique dans les deux cas.

Trois environnements : test, pprod, prod

Chaque environnement possède sa propre configuration (non versionnée : .secrets/<env>/, variables d’hébergement) :

Paramètre	Exemple de distinction
URL publique AnythingLLM	Sous-domaine ou chemin dédié par env
Clés API AnythingLLM	Une clé ou jeu de clés par env
REPOS_DEVTOOLS_ROOT, tokens micro-services	Racine Git et secrets distincts
URL orchestrateur / ia-dev-gateway	Hôte + port ou route derrière gateway
SSO (OIDC)	Client OAuth distinct par env, ou même IdP avec audience / realm différent
CORS et reverse proxy	TLS partout ; pas d’alternative HTTP de contournement

Les garde-fous prod (policy, droits déploiement, refus explicites) sont plus stricts qu’en test ; la doc métier des projets (ia_dev / projects/<id>/) reste la source des scripts réels.

Intégration navigateur (services)

Par défaut : ne pas embarquer Chromium / Playwright dans le cœur des autres services. La prévisualisation et l’UI AnythingLLM passent par le navigateur système ou un onglet web du shell (Lapce / front).

Ouvrir un service dédié browser-automation-api (futur) uniquement si besoin de : capture de rendu, E2E agents, snapshot PDF, scraping sur allowlist, tests visuels sans dépendre du poste utilisateur. Critères détaillés : features/browser-automation-criteria.md.

SSO avec docv (Enso)

Le front web de la plateforme peut s’authentifier auprès de docv (filière Enso) via OpenID Connect. Flux et contrats : features/sso-docv-enso.md. Les endpoints exacts du dépôt Enso se calent lorsque le code docv est disponible sur la machine de build.

Chaîne technique de référence

flowchart TB
  subgraph envs [Environnements]
    test[test]
    pprod[pprod]
    prod[prod]
  end
  subgraph ui [Interfaces]
    Lapce[Lapce_core_ide]
    Web[Web_front_SSO]
  end
  subgraph orch [Orchestration]
    Orch[smart_ide_orchestrator]
    IaGw[ia_dev_gateway]
  end
  subgraph ia_host [Hôte_IA_typique]
    Ollama[Ollama]
    ALLM[AnythingLLM]
    Micro[services_micro_HTTP]
  end
  envs --> ui
  Lapce --> Orch
  Web --> Orch
  Orch --> Micro
  Orch --> ALLM
  Orch --> IaGw
  IaGw --> Ollama
  ALLM --> Ollama

Documents liés

• system-architecture.md — couches, gateway, registre agents
• features/ia-dev-service.md — service ia-dev-gateway
• features/orchestrator-api.md — contrat HTTP orchestrateur
• features/lapce-porting-roadmap.md — portage extension → Lapce
• API/README.md — index des API services