Présentation du plugin Enterprise de Simmetric Chat

Enterprise est un plugin, pas un fork

La façon la plus courante dont les projets open-source livrent un niveau enterprise est un fork : une branche privée qui s'éloigne de la base de code communautaire jusqu'à ce que la mise à niveau devienne un projet de migration. Simmetric Chat a choisi l'autre voie. Le niveau enterprise est livré comme un paquet plugin optionnel - @simmetric-chat/enterprise - chargé par le serveur communautaire au boot via un chargeur de plugins. Le serveur communautaire sonde le paquet au démarrage :

• Trouvé et valide → le plugin enregistre ses routes, et les fonctionnalités enterprise passent en production.
• Non installé → une ligne de log au niveau info note la build communautaire et le serveur continue inchangé.
• Trouvé mais cassé → le serveur sort bruyamment. Une installation enterprise cassée ne dégrade jamais silencieusement vers la communauté - une pile SSO à moitié fonctionnelle est pire que rien.

La même licence régit le niveau. La base de code communautaire est AGPL-3.0 ; le plugin enterprise est un paquet commercial sous licence séparée, et un JWT de licence (LICENSE_KEY) est ce qui débloque les fonctionnalités. Sans licence valide, les routes enterprise se montent quand même, mais chaque fonctionnalité gate répond 402 avec un payload JSON explicite nommant la fonctionnalité et le niveau - votre code d'intégration peut se brancher sur l'état de licence au lieu de deviner.

Identité : SSO et SCIM prêts à l'emploi

L'authentification unique prend en charge les deux protocoles que les entreprises exécutent réellement : SAML 2.0 (avec login, callback et endpoints de métadonnées pour les flux initiés par l'IdP) et OIDC (login et callback pour le flux de redirection navigateur, construit sur une bibliothèque client OpenID Connect actuelle). Les deux se lient au même panneau SSO configurable par l'admin.

La configuration est flexible là où ça compte. OIDC peut être configuré entièrement depuis le panneau SSO admin (stocké chiffré au repos dans la base de données), entièrement depuis des variables d'environnement, ou depuis les deux - l'env a priorité quand elle est définie, donc les déploiements infrastructure-as-code peuvent épingler les paramètres du fournisseur pendant que le panneau reste la source de vérité autrement. Les fournisseurs intégrés couvrent Google, GitHub et Microsoft Entra, et un fournisseur générique accepte n'importe quel document de découverte.

SCIM 2.0 ferme la boucle du cycle de vie : le provisionnement des utilisateurs et des groupes via le protocole SCIM standard avec un endpoint protégé par jeton Bearer. Quand les RH désactivent un utilisateur dans votre fournisseur d'identité, son compte Simmetric Chat se désactive via le même flux - pas de comptes orphelins, pas de déprovisionnement piloté par tableur. Ensemble, SSO et SCIM signifient que votre IdP reste l'autorité unique sur qui existe et qui peut se connecter.

Le journal d'audit qui ne peut pas être réécrit

Les journaux d'audit ont une propriété gênante : plus ils ont de valeur, plus ils ont de valeur à modifier. Le journal d'audit enterprise de Simmetric Chat impose l'immutabilité au niveau de la base de données, pas au niveau de l'application.

Un rôle Postgres dédié - simmetric_audit_writer - ne détient qu'un privilège INSERT sur la table d'audit. Le plugin enterprise écrit les événements d'audit via un pool de connexions séparé qui s'authentifie comme ce rôle, donc UPDATE et DELETE échouent au niveau de la base de données, pas par convention applicative. Les lecteurs empruntent un chemin délibérément séparé via la connexion applicative standard, qui a SELECT mais est un rôle entièrement différent - l'écrivain ne peut pas lire, et le lecteur ne peut pas écrire.

La garantie est honnête sur sa propre configuration : quand le mot de passe de l'écrivain est défini, le log de boot confirme que la garantie d'immutabilité est active ; quand il manque, le journal d'audit enregistre toujours les événements mais un avertissement de boot indique que l'immutabilité au niveau base n'est pas appliquée. Des valeurs par défaut fail-safe plus un log de boot véridique - le modèle que cette plateforme utilise partout.

Le journal d'audit est exposé aux admins via une visionneuse de journal d'événements, gate par un flag de licence audit_log_immutable. Événements d'authentification, opérations sur les documents, changements de paramètres, contournements DLP, changements de conservation - la piste est la réponse à « que s'est-il réellement passé ? », et elle compose avec l'histoire RBAC communautaire : l'accès au journal lui-même est une permission.

White-label et sauvegardes chiffrées

Deux fonctionnalités ciblent les équipes qui livrent Simmetric Chat à leurs propres clients ou l'exécutent comme infrastructure interne avec des politiques de données strictes :

Le white-label retire le chrome produit des surfaces orientées client - le widget embarqué, les defaults de branding, la personnalisation au niveau UI - sous un flag de licence dédié. Un cabinet de conseil déployant un assistant de connaissances pour un client peut présenter l'assistant comme celui du client ; la plateforme reste en arrière-plan.

Les sauvegardes vont au-delà des dumps de base : les tâches planifiées et à la demande produisent des archives de sauvegarde chiffrées, les politiques de conservation décident quoi garder et pendant combien de temps, et une répartition des permissions sépare qui peut configurer une destination, qui peut exécuter une tâche, qui peut inspecter les logs et qui peut restaurer. Cette dernière distinction compte - déclencher une sauvegarde et restaurer des données de production dans un workspace arbitraire sont des niveaux de confiance différents, et le modèle de permissions les traite ainsi.

Licences air-gap pour les environnements réglementés

Les environnements qui ont besoin de SSO, d'audit immuable et de sauvegardes contrôlées sont fréquemment les mêmes environnements sans accès internet. La licence enterprise est conçue pour cela : la licence est un JWT signé RS256 dont la clé publique embarquée est livrée avec le serveur communautaire. La vérification se fait localement - le serveur vérifie la signature contre la clé embarquée, donc aucun serveur de licence ne doit être joignable. Définissez LICENSE_KEY dans l'environnement du serveur, redémarrez, et les fonctionnalités se débloquent ; retirez-la, et elles se referment vers la communauté avec des réponses 402 explicites.

Cette conception signifie qu'un déploiement enterprise tourne entièrement à l'intérieur d'un centre de données : LLM locaux via Ollama, magasins vectoriels locaux, embeddings locaux, OCR local, et maintenant validation de licence locale. L'air-gap n'est pas un mode dégradé boulonné plus tard - c'est la forme de déploiement autour de laquelle ce produit a été conçu.

Ce que cela signifie pour la ligne v0.22

Les lignes communautaire et enterprise avancent ensemble. Le serveur communautaire déclare le plugin enterprise comme une dépendance de pair optionnelle ; le chargeur le résout au boot et le contexte partagé du plugin injecte les préoccupations centrales (auth, crypto, base de données, logger) pour que le plugin ne dépende que du contrat partagé, jamais des internals communautaires. Les versions communautaires et enterprise sont construites contre la même version partagée, et un écart de version échoue bruyamment au boot plutôt que de se comporter mal au runtime.

Pour les opérateurs, le résumé pratique : installez le paquet plugin, définissez un LICENSE_KEY valide, configurez SSO dans le panneau admin, définissez le mot de passe de l'écrivain d'audit, et redémarrez. Le log de boot vous dit exactement lesquelles de ces étapes ont réussi. Le niveau communautaire reste AGPL-3.0 et pleinement fonctionnel - SSO, audit et sauvegardes sont additifs par-dessus, gates par licence plutôt que par un fork de code.

Lire le guide complet dans la doc →