Architecture
Vicket sépare proprement les composants qui vous appartiennent (rendus sur votre domaine) et un data plane hébergé (géré par nous). La frontière est une API REST stable.
┌────────────────┐ ┌────────────────────┐
│ Votre site │ ───▶ │ Composants à vous │
│ (toute stack) │ │ (dans votre repo) │
└────────────────┘ └─────────┬──────────┘
│ X-Vicket-Key: pk_...
▼
┌────────────────────┐ ┌──────────────────┐ ┌────────────────────┐
│ Dashboard agent │ ◀──▶ │ API Vicket (Go) │ ◀──▶ │ Postgres + workers│
│ (hébergé par nous)│ │ multi-tenant │ │ event bus, SLA │
└────────────────────┘ └──────────────────┘ └────────────────────┘
Les composants appellent l'API directement depuis le navigateur avec la clé publiable du site. Le backend applique la liste d'origins autorisées du site (CORS) et des limites de débit par site, donc la clé peut partir dans votre bundle. Voir authentification.
Modèle de tenancy
La hiérarchie est org, puis site, puis ressource. Une org est le tenant racine, typiquement une par entreprise. Un site est une surface client à votre marque, typiquement un par produit ou par client. Statuts, priorités, workflows, tickets, articles et FAQ vivent tous dans une org ; la plupart peuvent être limités à certains sites.
Une agence qui gère le support de dix clients crée donc une org et dix sites. Un SaaS avec trois produits crée une org et trois sites. Voir organisations & sites.
Propriété des données
Vous possédez la couche de présentation : chaque composant installé par le CLI vit dans votre repo et part dans votre bundle. Aucune iframe Vicket, aucun CSS Vicket, aucun JS Vicket chargé au runtime. Restylez, forkez ou remplacez ce que vous voulez.
Nous possédons le data plane : le stockage Postgres, l'API, le runtime de workflows, le dashboard agent, l'auth (adossée à WorkOS) et les notifications sortantes. Vous ne gérez jamais de base de données, ne faites jamais tourner de secrets JWT, n'êtes jamais réveillé pour un disque plein.
Le contrat entre les deux est l'API REST publique documentée dans endpoints.
Fiabilité
L'API écrit les événements de ticket dans Postgres dans la même transaction que le changement de ressource : pas de store d'événements séparé qui dérive. Un pool de workers consomme la table d'événements et alimente le moteur de workflows, les timers SLA et les notifications sortantes. Chaque exécution de workflow est enregistrée pour audit.
Le dashboard agent utilise un cookie de session (authentification) et autorise chaque requête contre la matrice de rôles & permissions.