Architecture

erp-platform sépare la plateforme SaaS multi-tenant de la couche d'adapters ERP. La plateforme gère l'authentification, la tenancy, le chiffrement, le routage MCP et l'audit. Les adapters ERP vivent dans @casys/mcp-erp.

Flux logique

Client MCP / assistant IA
        ↓
  endpoint tenant erp-platform
        ↓
  authentification OAuth/OIDC + résolution tenant
        ↓
  adapter ERP actif (ERPNext, Dolibarr, ...)
        ↓
  ERP client, en direct ou via tunnel local

1. MCP-native

Les assistants IA ne devraient pas avoir à connaître chaque API ERP. erp-platform expose un serveur MCP par tenant : le client découvre les tools, leurs schémas et leurs erreurs via le protocole MCP.

Cette frontière garde les prompts et les agents stables pendant que les adapters ERP évoluent.

2. Multi-tenant

Chaque requête est résolue depuis le host tenant, par exemple acme.erp-platform.fr. Les credentials et les événements d'audit sont attachés au tenant, et les routes protocolaires (/mcp, /oauth, /.well-known) gardent des contrats stables.

3. Adapters ERP

Le repo ne duplique pas la logique ERP dans la plateforme Fresh. Il délègue à @casys/mcp-erp, qui expose une interface commune pour construire un adapter, lister ses tools et exécuter un appel.

Les types ERP actuellement connus côté plateforme sont erpnext et dolibarr. D'autres ERPs peuvent être ajoutés par nouveaux adapters plutôt qu'en réécrivant le serveur MCP.

4. Connexion directe ou tunnel local

Deux modes de connexion coexistent :

direct : la plateforme appelle l'API ERP depuis le VPS ;
tunnel : un agent local côté client ouvre une connexion sortante vers erp-platform, ce qui évite d'exposer l'ERP à Internet.

Le mode tunnel est important pour les ERPs internes, les instances on-premise et les environnements où l'ouverture réseau entrante est impossible.

5. Chiffrement et audit

Les credentials ERP sont chiffrés avec une clé AES-256-GCM par tenant. La base de données ne stocke pas les secrets en clair. Les appels MCP sensibles créent des événements d'audit avec le tenant, l'acteur et le tool appelé.

Le but est d'avoir une interface d'exécution agentique qui reste observable, réversible côté ops et défendable en cas d'incident.