Architecture et sécurité en un coup d'œil

Zentor App est conçue comme une plateforme multi-tenant. Chaque tenant dispose de son propre contexte de données, et des contrôles côté serveur limitent chaque requête authentifiée au tenant actif. Le sélecteur de tenant visible n'affaiblit pas cette séparation : il change uniquement le contexte actif pour un utilisateur ayant accès à plusieurs tenants, tandis que le backend continue de valider les autorisations à chaque requête. Les tenants supplémentaires ne sont pas créés par les utilisateurs ordinaires. Ils sont activés par Zentor, et le prix confirmé pour un tenant supplémentaire dans le forfait Sur mesure (Individuell) est de 39 € par mois.

L'authentification du tableau de bord repose sur l'e-mail et le mot de passe, avec une authentification à deux facteurs TOTP optionnelle et des flux SSO pris en charge. Un JWT de session classique est valable 12 heures, et un jeton de rafraîchissement peut rester valable jusqu'à sept jours. Il n'existe pas de système de clé API développeur distinct pour l'API publique documentée. Les formulaires publics et les points de terminaison de contenu fonctionnent sans connexion au tableau de bord, tandis que les opérations du widget utilisent un jeton d'intégration dédié associé à des restrictions d'origine. Le jeton d'intégration n'est affiché en clair qu'une seule fois et doit être traité comme un secret pendant le déploiement.

La plateforme combine le tableau de bord, des services backend propres à chaque tenant, une base de connaissances, des canaux de communication et un déploiement SIP isolé pour la téléphonie. Le voicebot SIP est séparé de l'application principale depuis le 24 juillet 2026. Chaque tenant activé reçoit une instance SIP isolée, et l'activation ou la désactivation reste une tâche réservée au Master Admin. Cette séparation empêche le tableau de bord du tenant de gérer directement les trunks ou l'infrastructure de téléphonie de bas niveau.

Les contrôles de sécurité incluent des règles par IP, domaine et pays. Chaque nouvelle règle démarre en mode simulation (dry-run) et ne peut pas être activée avant un délai d'attente obligatoire de 24 heures. Les règles d'autorisation sont prioritaires sur les règles de blocage. Cette conception laisse aux administrateurs le temps d'examiner l'effet d'une règle avant son application et réduit le risque de bloquer accidentellement un accès légitime.

La page architecture ne doit pas être lue comme un SLA public ni comme une garantie que chaque composant optionnel est disponible dans chaque forfait. L'accès aux fonctionnalités dépend des droits (entitlements) et des add-ons. L'exploitation on-premises est préparée mais pas encore prête pour la production, car le mécanisme de licence actuel contient encore une clé provisoire. Elle doit donc être présentée comme disponible sur demande et en phase d'introduction, et non comme une option de déploiement entièrement en libre-service.