Configuration

Simmetric Chat dispose de deux niveaux de configuration : des variables d'environnement validées avec Zod au démarrage du processus, et un niveau de configuration runtime stocké en base de données que les administrateurs peuvent modifier depuis l'interface sans redémarrer aucun service.

1. Variables d'environnement (démarrage du processus) - validées avec Zod dans packages/<pkg>/src/config/env.ts ; process.exit(1) si invalides.
2. Configuration runtime (DB `SystemConfig`) - modifiable depuis l'interface admin sans redémarrage.

Résolution :

• Clés ALWAYS_READONLY (JWT_SECRET, DATABASE_URL, SERVER_PORT, COLLECTOR_PORT, SERVER_URL, COLLECTOR_URL, LICENSE_SECRET) : ENV > Default, non modifiables depuis l'interface.
• Toutes les autres : DB > ENV > Default, modifiables via PUT /api/system/settings.

Les trois packages lisent .env via path.resolve(__dirname, "../../.env") (indépendant du répertoire courant). Le document de référence est .env.example à la racine du dépôt.

Variables d'environnement - server

Schéma : packages/server/src/config/env.ts. Valeurs par défaut affichées ; OBL = obligatoire.

Core / infra

Bootstrap admin (seed)

LLM

Watchdog d'agent (prévention des boucles/stalls)

Embedding / Vector DB / OCR / Synthesis

Licence, push, email, collector

Variables dans .env.example mais gérées comme settings DB (pas dans envSchema) : OCR_ENABLED, OCR_PRECHECK_CHARS, STORAGE_PATH (collector), RESET_PASSWORD_STRATEGY.

Variables d'environnement - collector

Schéma : packages/collector/src/config/env.ts.

Variables d'environnement - widget

Schéma : packages/widget/src/config/env.ts.

Frontend : aucune variable VITE_* ni fichier .env. Le frontend lit le branding/config depuis le serveur (GET /api/system/settings, GET /api/license/info).

Feature flags & licence

Définis dans packages/shared/src/constants/license.ts (FEATURE_FLAGS + valeurs par défaut). Vérification dans packages/server/src/services/licenseService.ts.

Comment passer de Community à Enterprise

1. Définissez LICENSE_KEY (JWT HS256) et, recommandé, LICENSE_SECRET.
2. jwt.verify → payload validé contre licensePayloadSchema (tier, iss, sub, iat, exp, features).
3. tier=enterprise → démarre depuis ENTERPRISE_FEATURE_DEFAULTS + les overrides features du JWT.
4. Expiré/invalide → repli Community avec avertissement.

Dégradation progressive : getLicenseInfo() vérifie l'expiration à l'exécution ; si Enterprise expire pendant l'utilisation, elle dégrade vers Community sans redémarrage. requireFeature(flag) → HTTP 402 si désactivé ; requireFeatureLimit(flag, model) → 402 si count >= limit (Enterprise = Infinity).

Flags commodity toujours actifs : depuis la suppression EPA-02, les 8 flags commodity n'existent plus dans FEATURE_FLAGS - webhooks, push_notifications, web search, memory, lead_export, widget_analytics, auto_title, synthesis_rate_limit sont toujours actifs en Community (les routes commodity tournent sans gating). priority_support n'est pas un flag : c'est un contrat commercial/SLA (EPA-08). Il reste 11 flags enterprise, dont widget_credits_editing (édition des crédits widget, Community false / Enterprise true) et custom_agents comme limite numérique (Community 3, Enterprise Infinity).

Tableau des flags (11)

Runtime config (DB SystemConfig)

Modifiable via GET/PUT /api/system/settings (bulk) et PUT /api/system/chat-retention (spécifique, audité). Les valeurs par défaut vivent dans CONFIG_DEFAULTS (packages/shared/src/constants/permissions.ts).

Groupes de clés : LLM (LLM_PROVIDER, LLM_MODEL, LLM_TEMPERATURE, ...), Embedding/Vector, Ports/URL serveur, Auth (SESSION_EXPIRY), Branding (BRANDING_APP_NAME, BRANDING_PRIMARY_COLOR, BRANDING_APP_SUBTITLE, BRANDING_APP_ICON_URL - gated white_label), Feature (DISABLE_TELEMETRY, ALLOW_REGISTRATION, DLP_ENABLED), OCR (OCR_DEFAULT_MODEL, OCR_DEFAULT_MODE, OCR_DEFAULT_CUSTOM_INSTRUCTIONS, OCR_ENABLED, OCR_PRECHECK_CHARS), Synthesis (SYNTHESIS_LLM_PROVIDER_ID, SYNTHESIS_LLM_MODEL), Retention (upload_draft_retention_days, ALLOW_NON_ADMIN_UPLOAD, chat_message_retention_days).

PUT /api/system/settings renvoie toujours 200 avec { updated: [...], rejected: [...] } (les clés readonly sont rejetées tandis que les autres sont appliquées).

Rétention des messages de chat (reaper)

Service : packages/server/src/services/chatMessageReaperJob.ts. Knob DB : chat_message_retention_days.

• Pass 1 (soft-delete) : tombstones les messages des chats ACTIFS au-delà de retentionDays. No-op si la valeur est null/""/<=0.
• Pass 2 (hard-purge) : supprime les lignes tombstonées au-delà d'une grâce de 7 jours (codée en dur). S'exécute toujours, indépendamment de la config de rétention (anti-fuite de PII).
• Cadence : setInterval de 24h, premier passage à 03:00 heure locale. Mutex isRunning.
• Uniquement PUT /api/system/chat-retention (audité, confirmDataLoss: true, retentionDays: integer|null, min 1) ; l'endpoint bulk rejette cette clé.

Rétention des sauvegardes

Par job (champ retentionDays sur BackupJob, défaut 30). backupRetentionService.ts nettoie les journaux/fichiers au-delà de cutoffDate. Ce n'est pas global.

Rotation des clés de chiffrement

packages/server/src/services/encryptionService.ts (AES-256-GCM, clé 32 octets, IV 16 octets, sel simmetric-chat-encryption-salt).

• Clé courante : ENCRYPTION_KEY (base64 32 octets) si définie ; sinon scryptSync(JWT_SECRET, salt, 32).
• LEGACY_PREVIOUS_ENCRYPTION_KEYS (CSV base64 32 octets) → chaîne de clés de déchiffrement [current, ...previous, scryptLegacy?].
• encrypt() utilise chain[0]. Aucun job automatique de ré-encryption : la procédure est manuelle déchiffrer-avec-l'ancienne → rechiffrer-avec-la-nouvelle.

Cross-link

• Endpoints de configuration : 04 - API Reference
• Fonctionnalités internes : 05 - Feature Guide
• Env vars de déploiement : 09 - Deployment